On Tue, Sep 02, 2014 at 06:31:21PM -0500, Peter A. Bigot wrote:
This series aims at addressing an issue discovered with SPL mode when the MMC device being used lacks an environment partition. http://www.mail-archive.com/meta-ti@yoctoproject.org/msg04320.html includes details on the original failure with this diagnosis:
This is a bug in handling mmc_switch_part: what's happening is that the code reconfigures the mmc device to look at the partition on which the environment is to be found, but fails to restore it to reflect the state of the whole device. I.e., the mmc capacity and lba are zero in my case (I have no partition 2 on the uSD card), but mmc_switch_part() returns -ENODEV on the attempt to switch back in fini_mmc_for_env() without also resetting the capacity to what the rest of the system expects.
1/2 has been superseded and there's some questions about 2/2. I'm going to take 2/2 as it fixes a real problem. But Stephen brings up some good questions that do need to be answered. The first thing is that SPL today assumes that it only has one MMC device registered with the subsystem, not 2. This may be reworkable (and maybe not have a big size change) but it's a bit late in this release cycle for that. So what this means is that on some hardware like say Beaglebone Black we either have an SD card (which lacks physical partitions) or we have an eMMC which means the 2 boot partitions and the user partition.
The next part of the problem is that we have some cases where we say "environment is on eMMC, in one of the boot partitions" and we say "SPL needs to look at the environment". This situation works fine when we boot from eMMC. Things fail when we use this same binary to boot from SD card. We don't have env and somewhere along the line what fails is that we tried to switch physical partition, noticed a failure, tried to correct said failure but instead end up with our internal representation of the SD/MMC device being invalid. Peter's patch 2/2 corrects this so that when we hit a failure it goes and re-sets that representation.
But the next question is "wait, why did it get set _wrong_ to start with?". I'm not sure actually. The fini_mmc_for_env call isn't making us be restored to what the physical partition was before, if that's what it was intended to do, it's making sure that we're still on the env partition. Which I'm not sure why it needs to do since we've already read a copy into memory at this point.