[U-Boot] [PATCH V2] add README.distro file

[Ian Campbell]

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.