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

[Hollis Blanchard <hollis_blanchard@mentor.com>]

On 12/08/2010 12:53 PM, Wolfgang Denk wrote:
> Dear Hollis Blanchard,
>
> In message<4CFFCEC1.6000103@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?
Yes, I do include memory initialization. In our use case, u-boot must 
know about all memory (to configure the memory controller), but each OS 
is only made aware of a piece of it. They really do have different 
information about the 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 think the current way that u-boot updates the memory node is valuable 
for other use cases. In particular, it is very convenient for single-OS 
systems. Our goal is to avoid affecting those use cases.
> 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.
I see it as allowing the user to optionally override auto-detected 
information. The user has to go out of their way to request this 
behavior, so I think the visibility/awareness is there.

The existing bootm_low/bootm_size facility does exactly this, but I 
think we can improve on its design.
> 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.
I agree that all (device tree aware) systems should behave consistently 
in this regard. Of course, in that case, we don't need weak functions?

Documenting the behavior is a very good point.

Hollis Blanchard
Mentor Graphics, Embedded Systems Division