On Mon, Jan 12, 2015 at 11:57 AM, Ian Campbell <i...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot