entirely possible that i'm totally confused but after
reflashing my BBB, i powered down, powered up again but forgot
to take out the SD card, at which point -- even without
holding down the boot button -- the reflash procedure
apparently started all over again.
why? i was under the impression that it was *necessary* to
hold down "boot" to kick off the reflashing procedure -- that
is, to force an SD-based boot when there's a valid eMMC
bootable image.
what have i hopelessly misunderstood?
Here's the deal. When you don't push the boot button, SYSBOOT2 (aka
GPIO2_8, aka gpio 72) remains high. This tells the CPU to try to boot
(look for MLO) from the devices in the following sequence: MMC1
(aka onboard flash), MMC0 (aka sd card), UART0, USB0.
U-boot's default bootcmd (even on the onboard flash) tries to boot
preferentially from the sd card (indented for easier reading).
gpio set 53;
i2c mw 0x24 1 0x3e;
run findfdt;
mmc dev 0;
if mmc rescan ; then
echo micro SD card found;
setenv mmcdev 0;
else
echo No micro SD card found, setting mmcdev to 1;
setenv mmcdev 1;
fi;
setenv bootpart ${mmcdev}:2;
mmc dev ${mmcdev};
if mmc rescan; then
gpio set 54;
echo SD/MMC found on device ${mmcdev};
if run loadbootenv; then
echo Loaded environment from ${bootenv};
run importbootenv;
fi;
if test -n $uenvcmd; then
echo Running uenvcmd ...;
run uenvcmd;
fi;
gpio set 55;
if run loaduimage; then
gpio set 56;
run loadfdt;
run mmcboot;
fi;
fi;
If you hold the boot button, SYSBOOT2 is low, and the CPU tries to
boot from the devices in the following order: SPI0, MMC0 (aka sd
card), USB0, UART0.
Typically, the u-boot you are using (along with its default bootcmd)
is the same on either the onboard flash or sd card, so once you hit
that logic, you are going to boot off the sd card preferentially.
To behave as the documentation suggests, the bootcmd logic should be
looking at the state of (from uboot's perspective) gpio 72, instead.
That's as far as I've gotten.