On Wed, 19 Feb 2014 10:40:15 -0700
Stephen Warren <swar...@wwwdotorg.org> wrote:
> On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
> > Signed-off-by: Dennis Gilmore <den...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
