One thing my team has been working on recently is a test automation framework for ARM systems running Linaro images. Since Linaro is also now looking at providing Android based images, the scope increased slightly, and we need a way to cover those as well. My original though for doing this was to have what we call a "master image", basically the first 2 partitions on the SD card which would house a boot and rootfs partition for a stable image, followed by a testboot and testroot partition that could be reformatted and reinstalled at will. This works pretty nicely for Linaro images, but our android images require several more partitions. So... rethinking this, we should be able to accommodate both:
mmcblk0p1 - boot
mmcblk0p2 - root
mmcblk0p3 - androidsystem
mmcblk0p4 [extended]
mmcblk0p5 - androidcache
mmcblk0p6 - androiddata
mmcblk0p7 - androidsdcard / testrootfs (this could be the bulk of remaining space used by both, depending on which image type we are booting)
mmcblk0p8 - testboot
When I actually tried to implement this, I hit a wall at the 8th partition. Only the first 7 show up under /dev. A little digging in the mmc driver reveals that MMC_BLOCK_MINORS is set to default of 8 (1 for the whole device + 7 partitions). So without changing this, by default we can only have 7 partitions on an sd card.
We could probably push this change in the Linaro kernels, but why is it set so low to begin with? Furthermore, will changing it help at all. If uboot does't like it (haven't checked yet) then it doesn't really matter.
Long term, I think the approach will be different. However this requires special hardware. We've been talking about a new approach that would allow us to have a dual mmc interface. The board would boot from the first mmc, load an initramfs, then switch over to the other mmc card. This would be the master image boot, and since we would be running from a ramfs, we could have full access to the second mmc to repartition and destroy it however we like. Then boot into a test image on the second mmc. I think this is where we want to be eventually, but is a ways off still. Now we need to find a way around this silly partition limitation if we want to support android in the short term.
