PowerPC architecture directory layout

[Peter Grehan]

Hi Rafal,

> Well, I guess there is quite a lot when considering the non-traditional 
> (like BookE, IBM/AMCC 4xx) variants of PowerPC (where we have a 
> completely different MMU design, new/changed exceptions, own local 
> buses, changes to vectors handling etc.) - they are very much just a 
> different CPU happening to have a similar core, although usually with 
> new and specific machine instructions not seen on the "traditional".

  If it turns out to be too painful to keep stuff in that directory I 
guess I could live with powerpc/cpu_*/ directories. At least the 
distinction between cpu type and platform would be obvious.

> For example, see the summary of our current and forseen changes to the 
> sys/powerpc/powerpc files:
> 
> clock.c        - OF-entangled, requires at least changes to decrementer 
> initialisation

  Yes, easy to fix.

> copyinout.c    - changes required due to different MMU design, address 
> spaces management etc.

  Yep, though a very small amount of code.

> interrupt.c    - not sure yet, may require changes

  Possibly, though once again tiny.

> locore.S    - complete replacement, no common parts with existing code

  Actually, I would like to see a single entry to the kernel, with a 
switch based on the bootloader type to do any early fixups. See the 
uboot section below.

> machdep.c    - significant changes to init pieces, new helper routines, 
> and yet more to come

  Yes, but that code path is small before SYSINITs start running so is 
feasible to have a per-CPU version selected at boot.

> nexus.c        - complete replacement (existing is OF-only)

  Agreed, this is totally bogus, but it is simple to declare child nexus 
drivers and only attach if running on a particular platform.

> pmap.c        - complete replacement (new MMU design: based on TLB-only 
> approach, no segments/BATs as in "traditional" PowerPC)

  CURRENT has the required indirection, should be easy to backport to 
6.* if need be.

> swtch.S        - changes required as now is using segment regs explicitly

  Absolutely, and this is easy to indirect through a function pointer, 
or even a boot-time code patch.

> trap.c, trap_subr.S    - major changes (to complete replacement) due to 
> new exceptions, changes to their handling etc.

  Yep. My plan for the G5 was to conditionally compile this file ala 
elf32/elf64 to handle the differences between the G5 and G3/4 exception 
handling. In a way that's almost all the effort since installing vectors 
is now CPU-type specific.

> <other changes we did not come accross yet>

  Some more to look at are:

  - halt/reboot
  - the assumption that all of memory is directly addressable (pmap page 
zero code, uma small malloc etc)
  - ddb: register dumping, handling backtrace across exceptions, 
hardware breakpoint support
  - libkvm support for different mmu implementations. not even there for 
the existing one :(
  - bus space ala alpha-style function pointers rather than inline lwbrx 
instructions only applicable on PCI.
  - soft float ?

> In some of the cases we could get away with slicing the code with 
> #ifdefs, but generally these are quite deep surges.

  No #ifdefs is the goal, however lofty.

> BTW: I'm not sure why this OEA define is currently used in current 
> code/kernel config (it's some NetBSD relic, isn't it?)

  Yes, inherited from NetBSD and should be terminated.

>>  - as much runtime customization as possible.
> ...
> I share your views on the general directions, although given the actual 
> constraints it might not be that easily made generic, but we are already 
> (and will be) following this route wherever possible.

  Good.

>>  - it should be mandatory for the bootloader to pass up FreeBSD-style 
>> metadata.
> 
> Yes, we stick with metadata conventions and it will be the bootloader's 
> job to format and pass these properly. BTW: we have working changes for 
> U-Boot that supplement the 'bootm' command in a way it recognises 
> FreeBSD kernel, composes metadata in FreeBSD-expected style (limited to 
> boothowto at the moment) for it and passes control.

  That's GREAT NEWS ! Please check that in to uboot :) I'd love to use 
that on my KuroBox. Now all that is needed is a BSD-licensed jffs2 :) 
Exporting uboot Environment variables would be super-useful, and not too 
hard.

  One thing I would like to retain is the register convention on boot. 
Currently, the OpenFirmware convention is assumed, and maintained by the 
loader, allowing a direct boot from OpenFirmware (e.g. in gdb's psim or 
from the Apple ofw prompt) or the loader without change.

  I'd like to extend this slightly (using unused registers) to support 
other loaders, so here is my suggestion. The interface is C-callable:

   r1 - valid stack
   r3 - unused ? kernel start maybe ?
   r4 - unused ? metadata end maybe ala amd64 ?
   r5 - boot-loader private. Callback on openfirmware systems.
   r6 - meta-data pointer
   r7 - boot-loader type. 0 = openfirmware-direct
                          1 = freebsd-ofw-loader
                          etc

  A little weird, but it preserves compatibility with the existing 
loader and gdb psim. Actually, the loader will have to be changed a bit, 
since r7 is sizeof(void *), but that parameter isn't used.

  locore.S, or maybe even locore.c since it's C-callable, can do a 
run-through of linker sets looking for code that will handle entry from 
that boot-loader, and call it. The usual init/mi_init could be done at 
the end of the routine.

> Heh, would be nice indeed, although it's not easily done (dtc/dtd is 
> only recently getting momentum for Linux), and not very quickly I'm afraid.

  What are the issues with dtc on linux ? Looks good to me, except for 
the small number of "linux," strings embedded when phandles are used :)

> Before we have this, we employed a simplified approach for the built-in 
> devices: since they are not auto-configurable in terms the mem-mapped 
> ranges, offsets they occupy, irq lines are fixed etc. we have just one 
> pseudo device which is self-identified and early attached and added to 
> the bus, and which in turn based upon hints (derived from device.hints 
> or built-in) instantiates on the bus all peripheral devices specified in 
> hints, sets their resources as provided and so on. This is similar to 
> what ISA bus driver has.

  The issue I have with hints is that it is difficult to represent a 
hierarchy easily. You can hard-code the ".at" to point to the parent bus 
but painful.

  Also, rather than a self-identifying pseudo driver, you can put in a 
nexus child which can do the top-level attaching itself. This does 
involve fixing the existing ofw nexus driver but that is sorely overdue.

>> in my utopia, GENERIC would be able to deal with all processor types and board 
>> options, and you would only need a custom config to reduce options.
>>
> I'm not sure if this can be achieved cheaply.

  Sure, but I don't want to immediately discount it. I also don't want 
to hinder progress :) I'm sure there's a practical balance somewhere 
between the two.

later,

Peter.