On Wed, 19 Feb 2014 10:40:15 -0700 Stephen Warren swarren@wwwdotorg.org wrote:
On 02/17/2014 10:56 AM, Dennis Gilmore wrote:
Signed-off-by: Dennis Gilmore dennis@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.t... 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