On 12/08/2010 12:53 PM, Wolfgang Denk wrote: > Dear Hollis Blanchard, > > In message<4cffcec1.6000...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot