Re: [PATCH] Start arch/powerpc/boot code reorganization

[Josh Boyer <jwboyer@jdub.homelinux.org>]

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