[U-Boot] [RFC PATCH 1/3] add file with a default boot environment based heavily on Stephen Warrens recent tegra work.

[Dennis Gilmore]

On Wed, 19 Feb 2014 10:40:15 -0700
Stephen Warren <swarren at wwwdotorg.org> wrote:

> On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
> > Signed-off-by: Dennis Gilmore <dennis at ausil.us>
> 
> Patch description?
I failed in my rush to get it out for feedback.
 
> > diff --git a/include/config_distro_bootcmd.h
> > b/include/config_distro_bootcmd.h
> 
> > +#ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
> > +#define _CONFIG_CMD_DISTRO_BOOTCMD_H
> > +
> > +
> 
> Is there a need for 2 blank lines there?
no, will clean it up
 
> > +#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
 
> > +#define BOOT_TARGETS_MMC "mmc1 mmc0"
> 
> We really ought to make the order of multiple MMC devices in
> BOOT_TARGETS configurable. For example, we may have 2 boards that both
> want to boot from SD card if present, else fall back to internal eMMC,
> yet one has mmc0=eMMC,mmc1=SD, and the other mmc0=SD,mmc1=eMMC. On
> Tegra, we're just lucky that hasn't been an issue yet. Equally, not
> all boards have 2 eMMC devices.

I did wonder if that was better being left out here and something that
the board set.
 
> > +	"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.
 
> The idea is that since the Pi has nowhere to store any environment,
> and the default environment's boot_targets is hard-coded in the U-Boot
> binary, we need some way for the user to configure the value of
> boot_targets to e.g. force network or USB boot. We want to do this
> before executing bootcmd, so that bootcmd looks at the user's desired
> boot_targets, rather than part way through executing bootcmd, which is
> far too late.
> 
> Now, on the Pi, this all happens via CONFIG_PREBOOT, so it will still
> work even with the "run envimport" as above. However, I think we want
> to make the "run envimport" within scan_boot optional, so it doesn't
> get repeated.
> 
> I wouldn't be surprised if other platforms ought to be working in the
> exact same way?
> 
> > +	"boot_targets=" \
> > +		BOOT_TARGETS_MMC " "  \
> > +		BOOT_TARGETS_USB " "  \
> > +		BOOT_TARGETS_SATA " " \
> > +		BOOT_TARGETS_PXE " "  \
> > +		BOOT_TARGETS_DHCP " " \
> > +		"\0" \
> 
> I'd be tempted to require the board-specific config to set
> boot_targets, so that appropriate customization can be applied?
sure, Ideally its something that can be changed on the fly and we just
ship a suggested ordering. That is probably something for down the road
though. 
 
> > +	"boot_envs=uEnv.txt\0" \
> 
> I wonder if boards want to customize that for backwards-compatibility?
Perhaps.

Might need to redo some of this. I've since added SCSI and IDE and they
are things I have seen in the wild also. Maybe we can simplify things
somehow so that adding new hardware types is really simple.


Dennis