While working on getting the new u-boot as part of the Snowball hwpack, I noticed that wasn't loading the boot.scr file properly, as the hwpack itself was only creating the flash.src.
Once I fixed this issue, and got the hwpack in place for testing on a Snowball with the external SD card interface, it all worked as expected, and I'm even able to run flash-kernel as the mmc_id provided by the hwpack is also correct for the SD setup.
The problem happens once I tried using the same hwpack at the eMMC device provided by Snowball. As the mmc_id is different, neither boot.src nor flash-kernel were able to correctly find the root device, and as a result I wasn't even able to boot the system (due u-boot environment trying to load uImage/uInitrd from the SD interface).
Thinking more about the issue, it seems there are two possible solutions, with each causing side effects that can confuse the users/developers:
1 - Producing 2 different hwpacks, one to be used at the SD card and another at the eMMC. This seems to be the right way to go, as the hwpack is the correct place to put any meta-data information, and mmc_id is one that's part of it. The bad side effect is that we'd have 2 different hwpacks that would only differ at the mmc_id (which is used by u-boot src script and flash-kernel).
2 - Adding a hack/workaround at linaro-image-tools, to find the correct mmc_id based on the device id. While this would let having only one hwpack, we'd again fix something on the old v1 style, as we'd be moving board specific logic inside it, instead of leaving that to the hwpack itself.
Would be happy to hear suggestions from different solutions, or at least discuss which one to take.
It kind of depends of how the rest of the boot looks like; one way you could cheat a bit is by having u-boot try SD and then fallback to eMMC, setting root= from this logic as well. You would need to have the same partition layout from linaro-image-tools perspective for the images to be mostly similar so that MMC layout doesn't matter.
Alternatively, you could set root device in an initrd.
Finally, we could have some options on top of hwpacks. Hwpacks were meant to split out board specific things from userspace specific things, but they also made it harder to support multiple similar boards, or multiple use cases for the same board; I guess it might make sense to have multiple profiles in the same hwpack? For instance we could have multiple manifests in the same hwpack and have a linaro-media-create flag to select the manifest (profile) that you want to use. Profiles could differ per-board or per use case so that we could have a single omap3 hwpack with support for beagle and overo, or a single snowball hwpack with support for SD and eMMC.