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.