[U-Boot] [PATCH] Honor /memory/reg node in DTB files
Hollis Blanchard
hollis_blanchard at mentor.com
Wed Dec 8 22:08:20 CET 2010
On 12/08/2010 12:53 PM, Wolfgang Denk wrote:
> 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?
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
More information about the U-Boot
mailing list