[PATCH] Start arch/powerpc/boot code reorganization
Josh Boyer
jwboyer at jdub.homelinux.org
Thu Sep 21 07:04:44 EST 2006
On Wed, 2006-09-20 at 22:23 +0200, Segher Boessenkool wrote:
> > It was pointed out on IRC that the "address" property is defined in
> > the
> > OF spec for specifying virtual address mappings. This is exactly what
> > we need in that it allows the zImage wrapper to use the fw defined
> > UART
> > mapping, but the kernel still gets the real physical address later on.
> > And other things that don't use zImage wrappers, like u-boot, can
> > simply
> > ignore the "address" property defined within the UART node.
>
> The "address" property has several problems. An obvious one is that the
> name is too generic. A nastier one is that once you start making new
Well, I agree. But it's documented in the spec. Blame the spec
writers ;).
> MMU
> mappings, you have to keep *all* old mappings, or blow away the mapping
> for this "address" as well (you don't know the size of the mapping).
Which we do on 4xx in the kernel (the blow away part).
>
> And
> a third problem is that it can only encode 32-bit virtual addresses.
Which isn't a _current_ problem, since the use case here is the
bootwrapper and that limits itself to 32bit already anyway.
>
> Now, if it's only used for the very-early-debug UART console on machines
> that cannot accesses physical addresses directly, in things like a boot-
> wrapper that cannot be bothered to set up a MMU mapping themselves (and
> there might be good reasons not to), and only when there is no client
> interface (i.e., it uses the flat tree only); then it might be a
> reasonable
> approach. All alternatives I can think of have their own nasty
> problems.
Right, that's where we were at too.
> So please comment the nastiness with a big "HACK HACK HACK" comment and
> make sure it only ever gets used on systems where nothing better is
> available, and all should be fine.
I'll leave that to Mark ;)
josh
More information about the Linuxppc-dev
mailing list