On Mon, Jun 18, 2012 at 5:03 PM, Michael Hudson-Doyle <michael.hudson@linaro.org> wrote:
Paul Larson <paul.larson@linaro.org> writes:

> On Mon, Jun 18, 2012 at 8:32 AM, Marcin Juszkiewicz <
> marcin.juszkiewicz@linaro.org> wrote:
>
>> W dniu 18.06.2012 15:02, YongQin Liu pisze:
>> > Hi, Saugata
>> >
>> > We have a problem to use the mmcblk0p8 partition, do you know if we
>> > can use it, and how can we use it?
>> >
>> > I created the 8th partition with fdisk command and the 8th partition
>> > is listed in the output of fdisk -l command but it is not listed in
>> > /proc/partitions file, even after reboot And also I can't use
>> > mkfs.vfat -n sdcard /dev/mmcblk0p8 to format.
>> >
>> > Could you give me some help about this?
>>
>> Check /dev/mmcblk1p0 node number for answer. IIRC there is limited
>> amount of partitions on MMC cards which Linux handles (a bit stupid
>> limit imho).
>>
> Yes it is stupid, and it's bit us before [1].  The better thing is to
> rethink your partitioning and see if you can come up with a better way to
> lay it out.  It's worked for us so far, but it's been tight on the lava
> side due to the number of partitions that android wants, and especially
> with the annoying hardcoded partition numbers that android uses.
> The max partitions can be changed but requires rebuilding your kernel
> MMC_BLOCK_MINORS on *every* machine that you will ever need to mess with
> that mmc card on.  So if you are building a master image on your laptop,
> you'll need to rebuild that one, the kernels for all platform images you
> want to boot on it, etc.

Gah.  I don't think insisting every system involved in LAVA has a custom
kernel can really work :/

One thing I _think_ we could do would be to share the boot and testboot
partitions -- we could install the kernels to be tested in
/boot/test-kernel or something and carefully tweak the commands we pass
to uboot to load that kernel.  Sounds like a fiddle, but might work?
Yes, we've discussed that very thing before but it was a lower priority because we didn't need to extend the partition numbers that far.  Not sure why we are needing to do it now, but it was always assumed that if we hit a situation that made it necessary, this would be the most straightforward thing to do until we have the necessary hardware/software in place to image a complete, recoverable system onto the SD externally in a generic way.  Basically, we just replace the reformatting of the boot partition with removal of a testboot directory, and point at the directory for grabbing the new kernel and initrd.

One thing I was thinking, is whether we could munge the boot script when we install it to this partition and replace the paths in some automagic way.  This would solve the issue of making sure we always have the latest bootargs and dtb files for booting, and get us one step closer to parity with a manually imaged system.

Thanks,
Paul Larson