On 12/08/2010 12:53 PM, Wolfgang Denk wrote:
Dear Hollis Blanchard,
In message4CFFCEC1.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