From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 08 Aug 2013 14:01:12 -0600 Subject: [U-Boot] Unified u-boot feature set for simpler distro support In-Reply-To: References: <20130803021104.1fecaf5a@adria.ausil.us> Message-ID: <5203F908.1080209@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 08/08/2013 12:48 PM, Dirk M?ller wrote: ... > Therefore, the openSUSE on ARM team has a locally patched version of > u-boot that handles booting from extX directly, because we did not > like to use FAT or anything similar for /boot, and didn't see the need > for adding a special /load (or similar) partition that is only there > to make u-boot happy. Could you expand upon what "handles booting from extX directly" means? Upstream U-Boot has supported ext2/3 for as long as I've been involved with it (which admittedly isn't that long), and ext4 support was added recently. This allows U-Boot commands "extload" or "load" to access ext* just like any other file-system. Is there something more involved when you say "booting from extX directly" beyond just the extload/load commands? ... > on openSUSE for ARM, we're converging to using only one boot.scr > template, that is > only templatized on the various addresses that are needed to be passed > down and the flavor name (mostly for being able to print the right > information during boot). > > If it is reasonably possible to avoid the templatisation of the > addresses, I'm all for it. I don't know if it is feasible, and for us > it is not really an issue (unless it is a board supported by the > zimage flavor). I think it's reasonable to require that boards supported by generic distros have upgraded/recent U-Boots that export a standard set of environment variables that define the various addresses, so that boot.scr authors don't have to care about platform differences, but rather simply use those variables. For example, kernel_addr_r, ramdisk_addr_r, fdt_addr_r, etc.