On 01/12/2015 10:57 AM, Ian Campbell wrote:
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.
Oh, I didn't realize that at all.
I know that in the discussions on the cross-distro@ mailing list, there
were arguments against standardizing on extlinux.conf. I hadn't read any
of the replies as meaning Debian was picking up the boot.scr
standardization work I had been doing though. Rather, since no agreement
seemed to have been reach, I had assumed that Debian (and other distros)
were sticking with the per-board-custom-boot.scr stuff they'd always had
before.
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 ;-)
Oh, so there's enough there to be considered complete?
I certainly was originally working towards standardizing boot.scr, so
it's good to hear that was pretty successful.
However, since realizing that extlinux.conf was a cross-bootloader
standard, I changed my mind and decided that was a better approach, so
I've been looking to see that move forward.
I suppose for config_disto_bootcmd.h to be useful for non-Linux OSs too
(which aren't supported by extlinux.conf AFAIK unless their boot
protocol is compatible with Linux), we likely want to keep the boot.scr
logic in config_distro_bootcmd.h fully enabled in all cases. As such,
perhaps it does make sense to remove any reference to the boot.scr
support config_distro_bootcmd.h as being legacy.
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.
Well, at least Barebox also supports extlinux.conf IIUC. The idea is
that if the distro assumes extlinux.conf, it shouldn't have to know
which bootloader is installed. More x86 implies Grub, ARM implies
extlinux.conf.
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.
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
