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

[Stephen Warren]

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.