Paul Larson <paul.lar...@linaro.org> writes: > On Mon, Jun 18, 2012 at 5:03 PM, Michael Hudson-Doyle < > michael.hud...@linaro.org> wrote: > >> Paul Larson <paul.lar...@linaro.org> writes: >> >> > On Mon, Jun 18, 2012 at 8:32 AM, Marcin Juszkiewicz < >> > marcin.juszkiew...@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,
I think the present motivation is that the CTS needs to have sdcard mounted. > 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. OK. Doesn't sound too hard really. > 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. Yeah, I've thought about that a bit too. One problem at a time :-) (and hopefully sdmux will happen and we can forget about this whole issue). Cheers, mwh _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
