From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Mon, 24 Feb 2014 11:40:02 -0700 Subject: [U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work. In-Reply-To: <20140222022024.5e7e58e9@adria.ausil.us> References: <1392659798-1665-1-git-send-email-dennis@ausil.us> <1392659798-1665-2-git-send-email-dennis@ausil.us> <5304EC7F.2010907@wwwdotorg.org> <20140222022024.5e7e58e9@adria.ausil.us> Message-ID: <530B9202.2050104@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 02/22/2014 01:20 AM, Dennis Gilmore wrote: > On Wed, 19 Feb 2014 10:40:15 -0700 Stephen Warren wrote: >> On 02/17/2014 10:56 AM, Dennis Gilmore wrote: >>> diff --git a/include/config_distro_bootcmd.h >>> +#define BOOTCMDS_COMMON \ >>> + "rootpart=1\0" \ >> >> We should really stop hard-coding that. I meant to (but evidently >> never got around to) re-write the commands so that they could >> automatically determine which partition to use, based on the MBR >> bootable flag or GPT partition flags. >> >> Still, we can probably make that enhancement separately later. > > I fully agree, we should be able to work it out later. I also renamed > it to bootpart since it is where we will boot from, which may or may > not be the root filesystem Just as some history, when I first wrote these boot scripts for Tegra, I was actually using that variable both inside the environment scripts to find/load boot.scr, and within boot.scr to set the kernel root= command-line option. More recently, I've moved to using root=PARTUUID= or root=UUID= on the kernel command-line, so rootpart has become less relevant, and indeed renaming it bootpart does make a lot more sense, as you say. >>> + "scan_boot=" >>> \ >>> + "echo Scanning ${devtype} ${devnum}...; >>> " \ >>> + "for prefix in ${boot_prefixes}; do >>> " \ >>> + "run sysboot_boot; >>> " \ >>> + "run envimport; >>> " \ >>> + "run script_boot; >>> " \ >> >> This isn't quite right for the Raspberry Pi at least. >> >> What I wanted was for uEnv.txt to *always* be loaded from SD card >> before any other boot activity. The SD card is known to exist on this >> platform, since it's the only place the SoC's boot ROM can load the >> initial binary firmware from. > > I know some distros use commands in uEnv.txt to boot, or at the least > they set variables and load a boot.scr I was trying to make sure we > cover those people. The definition of what uEnv.txt is and how it > should be used is pretty murky to me. I have seen it used in a few > different ways. I know some people really want them. So probably best > to work out a better way to support it. > http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-uEnv.txtbasedbootscript > for instance specifies all the boot commands in uEnv.txt really I would > rather people just use a extlinux.conf file, I just do not want to take > away the option to use something people see as valuable. I'd suggest not touching uEnv.txt in config_distro_bootcmd.h, since it's really not a part of the new standard we want to create. Instead, have each board define CONFIG_PREBOOT to load it if they want it. I assume that a very small number of boards will need uEnv.txt once we've switched to this new scheme; just those that have nowhere to store a persistent environment.