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

[Rob Herring]

On Mon, Jan 12, 2015 at 11:57 AM, Ian Campbell <ijc at hellion.org.uk> 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.
>
>> 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).

I had a patch for syslinux doing just this sometime back. My mistake
was giving it to Canonical to do something with. I could dig this up.
It is pretty straightforward moving of files into the syslinux-common
package. There were also some settings controlling generating the menu
files needed on the target rootfs to get it to work with u-boot's
limited syslinux. It wasn't something we could work-around or add
support for in u-boot IIRC.

Rob