On Mon, 2015-01-12 at 10:34 -0700, Stephen Warren wrote:
On 01/11/2015 11:15 AM, Tom Rini wrote:
On Sun, Jan 11, 2015 at 10:54:03AM -0700, Stephen Warren wrote:
On 01/11/2015 02:45 AM, Ian Campbell wrote:
On Sun, 2014-12-28 at 09:26 +0000, Ian Campbell wrote:
+boot_scripts:
- The name of U-Boot style boot.scr files that $bootcmd searches for.
- Example: boot.scr.uimg boot.scr
- (Typically we expect extlinux.conf to be used, but execution of boot.scr is
- maintained for backwards-compatibility.)
I'm slightly concerned by the implied deprecation of the boot.scr method here, since at least Debian uses boot.scr exclusively and not the extlinux stuff. Will boot.scr be maintained going forward or are there plans to eventually remove it?
Can someone confirm that there is no long term plan to drop boot.scr support?
extlinux.conf *is* the standard Linux boot process that config_distro_bootcmd.h enables. boot.scr is *not*. The whole point is to introduce a new simple standard that works the same everywhere (for Linux: across boards, across distros, across bootloaders).
Well, the only problem I see with this statement is that, uh, do we have buy-in from Debian?
Well, there was some discussion about standard boot setups on the cross-distro mailing list. I believe someone from Debian is at least familiar with Dennis's proposal to use extlinux.conf as the standard. There was certainly no definitive agreement in those discussions though
I hadn't appreciated that that this proposal was so heavily geared towards the extlinux.conf aspect, as opposed to standardising a bunch of useful env variables, which is what I thought it was mainly doing.
That said, I don't think there's much choice but to standardize on /something/ other than boot.scr. boot.scr really isn't scalable for generic distros (as opposed to board-specific BSPs):
- boot.scr works differently on different boards, since the set of
environment variables and U-Boot commands/features available to the script are different. This leads to extremely complex boot.scr implementations that distros each have to maintain.
A side effect (which I actually thought was part of the purpose until now) of config_distro_bootcmd.h was to standardize these variables. Debian now ships a common boot.scr which should work on any config_distro_bootcmd-enabled system.
I suppose we could fix this by standardizing the boot.scr execution environment; providing a consistent set of variables indicating where to load kernel/DTB/..., the board name (to auto-generate DTB filename), etc. However, standardizing this is more complex that standardizing on extlinux.conf
AFAICT you've already done it ;-)
and still doesn't solve:
- boot.scr doesn't work across different bootloaders. There's no reason
generic distros should know anything much about bootloaders, other than how to generate a config file so the bootloader knows which kernel/initrd/DTB binaries to load.
The distro needs to know enough about the bootloader to know it speaks extlinux.conf, which means in practice it needs to know if it is u-boot or not.
From Debian's PoV the usual default bootloader is grub, which is pretty
much a no-go on top of u-boot in practice.
So whether it's extlinux.conf or boot.scr we have to treat things specially at the distro level and have some firmware awareness, and boot.scr is there and working today.
- boot.scr must be generated (to boot.scr.uimg) using
bootloader-specific tools, rather than extlinux.conf, grub.conf, ... all just need the generation of a text file.
Debian already has the tooling (and has for years) to reproduce boot.scr automatically on upgrades of various relevant components, the user never needs to see the mkimage stuff (that tooling also handles various legacy non-config_distro_bootcmd systems, so it's going to have to remain for the time being either way).
Currently the extlinux.conf generating stuff is tied to the x86 syslinux packages, it could be reworked and pulled out into arch indep packages, but there doesn't seem to be all that much benefit compared with what we have now which is working fairly well for us (not to imply that it's perfect).
Ian.