From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Mon, 05 Jan 2015 12:50:20 -0700 Subject: [U-Boot] [PATCH V2] add README.distro file In-Reply-To: <1419758817.13595.33.camel@hellion.org.uk> References: <1419281200-6634-1-git-send-email-swarren@wwwdotorg.org> <1419758817.13595.33.camel@hellion.org.uk> Message-ID: <54AAEAFC.30003@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 12/28/2014 02:26 AM, Ian Campbell wrote: > On Mon, 2014-12-22 at 13:46 -0700, Stephen Warren wrote: >> From: Dennis Gilmore >> >> Add documentation on how to setup a system to use the generic distro >> configs and boot commands. This spells out what is needed to make a >> system conformant, but does not limit the board to only the defaults. >> >> Signed-off-by: Dennis Gilmore >> [swarren, added concept, user config, BOOT_TARGET_DEVICES sections. >> edited the rest] >> Signed-off-by: Stephen Warren > > Looks good thanks. A few comments below. > >> +Finally, a few options that are mostly relevant only when using U-Boot- >> +specific boot.scr boot configuration files are enabled This enables >> +compatibility with various board configurations that existed before these >> +distro default existed, and assumed boot.scr-based booting. > > Missing a "." in "are enabled This enables", I think. > >> +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? I hope it will remain, in which case I'd > be happier if this parenthetical were remove or replaced with something > like "(not used in extlinux.conf mode)". The intent here isn't really to deprecate anything but rather to introduce something new. The new thing introduced here is a common way for distros to boot systems using extlinux.conf. The One True Way(TM) according to this feature is extlinux.conf:-) However, since many boards already support boot.scr, and some (Tegra, RPi at least) automatically search for it in the same way this new feature searches for extlinux.conf, the scripts in config_distro_bootcmd.h fold in direct (compatibility) support for boot.scr too, so that boards don't have to implement that themselves and duplicate all the logic. So, I don't expect anyone to remove boot.scr support. That said, I would hope for Debian to transition to using extlinux.conf so that when new boards enable it, Debian won't have to do work to update its boot.scr to cope with those boards. >> +scan_dev_for_extlinux: >> + >> + If you want to disable extlinux.conf on any disk, delete this. >> + >> +scan_dev_for_scripts: >> + >> + If you want to disable boot.scr on any disk, delete this. > > Does deleting them not result in a message about an undefined command > during boot? Would it be better to replace with some sort of null > command (e.g. ":" in shell, not sure what the u-boto equivalent is). Yes, unsetting the variables does cause an error. I see I misremembered what I was doing here when I actually did NULL those out; the text should recommend "setenv scan_dev_for_extlinux true", not completely clearing the variables.