From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Thu, 27 Apr 2006 15:33:28 -0400 Subject: [U-Boot-Users] Re: FT u-boot shim In-Reply-To: References: <20060427190547.1DD90353DAC@atlas.denx.de> Message-ID: <44511C88.1010107@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Kumar Gala wrote: >> Let's say we have to support such situations, too. >> >>> * dts owned by u-boot?? >> I'm not sure about this. I tend to believe the dts belongs to the >> kernel. >> >>> Some questions/issues: >>> * ownership of .dts is problematic. I hate having a file duplicated >>> by both u-boot and kernel. However it also seems bad to make the >>> build of either depend on the user grabbing a dts from some third >>> party. Ideas? A concrete example would be the MPC8349 ADS/SYS/MDS >>> port. Boards ship with an "old" u-boot, thus we need a kernel >>> wrapper with .dts. However, newer u-boot's can (hopefully will) have >>> a dts in them >> Can we provide the dts as a separate blob that gets built with the >> kernel image? From U-Boot's point of view, this could be a multi-file >> image which combines the dts and the kernel into a single file so >> that users don't have to care much about this. > > The problem is that there are somethings that u-boot knows that needs > to go into the blob (memory size, boot args, initrd info, > frequencies, etc.) [snip] > - kumar A thought that keeps recurring (but I've suppressed because I don't have time to play...) is that it would be Really Cool[tm] to store the u-boot env variables in a flat tree and then pass the env/tree to linux. It also sounds like a major change & disruption to u-boot :-(. I haven't looked at what it would do to code size either. U-boot could then be a better OpenBoot than OpenBoot ;-) gvb