[U-Boot] [PATCH] Honor /memory/reg node in DTB files

[Wolfgang Denk]

Dear Hollis Blanchard,

In message <4CFFCEC1.6000103 at mentor.com> you wrote:
> On 12/07/2010 11:09 AM, Wolfgang Denk wrote:
> > There are many board vendors who shipt boards with different
> > configurations - with or without NAND flash; with or without other
> > peripherals like CAN contollers, LCD, etc.; with different LCD sizes
> > and types, in portrait or landscape orientation, etc.  Some of these
> > features can be determined by probing the hardware, others (like the
> > orientation of a LCD) cannot.  It is sometimes a maintenance nightmare
> > to provide tens of different configurations of U-Boot for a single
> > product.  Being able to cinfigure available hardware through the DT,
> > and using a single common binary image of U-Boot for such systems
> > would be a great benefit.
> That's fine, but so far I don't see how it's related. This is 
> information u-boot needs during its own initialization, right?

Right.

> We need a way for our tools to specify information to the kernels' 
> initialization, and still want u-boot to do all the hardware 
> configuration it does today. It really doesn't matter to us if in the 
> future u-boot uses device trees for that configuration: we just need a 
> way to interact with the kernels.

When U-boot is supposed to do the hardware initialization, you
probably include memory initialization, right?  If so, should we then
not make sure that U-Boot and the OS we're booting use the same
information about this resource?

If, on the other hand, you really want to make U-Boot ignore any
/memory nodes in the device tree, then this should be done straight
and without additional magic.  In this case the DT should be
responsible to provide all information the OS needs, and U-Boot should
not touch this in any way.  Then just do not call fdt_fixup_memory()
at all for such configurations.

I dislike the idea that U-Boot will not touch the DT entry in one
situation, but will do so in another, without any visibility to (and
eventually without awareness by) the user.

If there is really a good reason for such magic, then this should be
clearly documented (not only in some comment in some source file),
and eventually fdt_fixup_memory() (or fdt_fixup_memory_banks() ?)
should be made weak so it can be redefined by board-specific
implementations.

In any case, any such changes should be implemented in a generic way,
i. e. not only for one specific processor family.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Conceptual integrity in turn dictates that the  design  must  proceed
from  one  mind,  or  from  a  very small number of agreeing resonant
minds.               - Frederick Brooks Jr., "The Mythical Man Month"