From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from agrxsusmail.smiths.aero (host241-chi.smiths-group.com [65.216.75.241]) by ozlabs.org (Postfix) with ESMTP id 171A467A3B for ; Fri, 28 Apr 2006 06:31:19 +1000 (EST) Message-ID: <44511C88.1010107@smiths-aerospace.com> Date: Thu, 27 Apr 2006 15:33:28 -0400 From: Jerry Van Baren MIME-Version: 1.0 To: "linuxppc-dev@ozlabs.org list" Subject: Re: FT u-boot shim References: <20060427190547.1DD90353DAC@atlas.denx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: U-Boot Users List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 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