Date: Tue, 31 Oct 2006 19:57:57 +0100 From: Rafal Jaworowski <raj@semihalf.com> To: Peter Grehan <grehan@freebsd.org> Cc: freebsd-ppc@freebsd.org Subject: Re: PowerPC architecture directory layout Message-ID: <45479CB5.3040403@semihalf.com> In-Reply-To: <4546CBB7.4040202@freebsd.org> References: <4542188D.6010600@semihalf.com> <4546CBB7.4040202@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Peter,
Peter Grehan wrote:
>
>> Our initial thoughts and approach was splitting out the existing
>> low-level code into the following hierarchy:
>>
>> sys/powerpc/powerpc - files common to all PowerPC variants
>> sys/powerpc/aim - specific to "traditional" PowerPC specs
>> (most of present sys/powerpc/powerpc)
>> sys/powerpc/{e500, others} - specific to e500 or other specs to be
>> supported
>
> I'd like to keep all aim (oea ?)/e500/other-arch processor-specific
> stuff in the powerpc directory if possible, since I think that there
> isn't a whole lot there.
>
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".
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
copyinout.c - changes required due to different MMU design, address
spaces management etc.
interrupt.c - not sure yet, may require changes
locore.S - complete replacement, no common parts with existing code
machdep.c - significant changes to init pieces, new helper routines, and
yet more to come
nexus.c - complete replacement (existing is OF-only)
pmap.c - complete replacement (new MMU design: based on TLB-only
approach, no segments/BATs as in "traditional" PowerPC)
swtch.S - changes required as now is using segment regs explicitly
trap.c, trap_subr.S - major changes (to complete replacement) due to
new exceptions, changes to their handling etc.
<other changes we did not come accross yet>
In some of the cases we could get away with slicing the code with
#ifdefs, but generally these are quite deep surges.
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?) as it doesn't
make much sense to me - Operating Environment Architecure is just a
generic name for a layer in PowerPC specification nomenclature
describing supervisor level resources, and therefore each variant of the
CPU has actually its own OEA defined...
> i/o could go into it's own directory such as the existing powermac
> directory.
>
> What I want to avoid is the confusion of processor type/board type as
> in netBSD where they are in a flat space under arch.
>
Yes, agreed, let me think a bit more and I'll get back to you. It would
be great if you could still think about how to best attack this, so we
have a scalable schema, considering what I have tried to explain above.
>> What is your view and recommended route to follow? Can we work
>> together on redisigning the sys/powerpc layout to make it more
>> extensible when new platforms are added etc.?
>
> My goals would be:
>
> - as much runtime customization as possible. The CPU type can be
> determined very early in the boot sequence and a CPU-specific function
> table init'd. This would have routines for setting up vectors, context
> switching, the mmu kobj, cache syncing etc.
>
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.
> - 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.
> - a way of describing bus layout would be very useful. Something like
> the Linux device tree compiler, but BSD licensed :) That way, a platform
> could supply it's own nexus driver and enumerate buses for the on-chip
> peripherals that abound in the embedded PPC world.
>
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.
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.
>> I believe FreeBSD/ARM folks must have had similar considerations
>> exercise as they have a number of different variations within ARM
>> family, maybe we can learn from them somehow?
>
> I tend to think that PPC systems are a lot less memory constrained than
> ARM systems, and as such don't need the same level of compile-time
> customization. I would hope that there isn't a proliferation of kernel
> config files for PPC systems - 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.
Let me hear what you think on all the above issues.
kind regards,
Rafal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45479CB5.3040403>