From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Wed, 08 Dec 2010 13:08:20 -0800 Subject: [U-Boot] [PATCH] Honor /memory/reg node in DTB files In-Reply-To: <20101208205359.6A1DDCF5CA6@gemini.denx.de> References: <4CFD863A.7070000@mentor.com> <20101207065234.DC3BB280@gemini.denx.de> <4CFE775C.6050001@mentor.com> <20101207190936.EC285D0E429@gemini.denx.de> <4CFFCEC1.6000103@mentor.com> <20101208205359.6A1DDCF5CA6@gemini.denx.de> Message-ID: <4CFFF3C4.20800@mentor.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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