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.
[1] http://linuxtesting.blogspot.com/2011/03/max-partitions-on-mmc.html
Thanks, Paul Larson
W dniu 18.06.2012 16:20, Paul Larson pisze:
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.
I do wonder why Linaro Android team did not tried to make /data /system parts of one filesystem instead of moving them to separate ones. Or maybe I do not know something ;)
On 18 June 2012 19:54, Marcin Juszkiewicz marcin.juszkiewicz@linaro.orgwrote:
W dniu 18.06.2012 16:20, Paul Larson pisze:
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.
I do wonder why Linaro Android team did not tried to make /data /system parts of one filesystem instead of moving them to separate ones. Or maybe I do not know something ;)
/system (core rootfs) is mounted as read-only filesystem and /data as read-write, to store user profiles/settings/apps, so we need two separate partitions.
Regards, Amit Pundir
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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?
Cheers, mwh
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
Paul Larson paul.larson@linaro.org writes:
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,
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
On 06/19/12 09:45, the mail apparently from Michael Hudson-Doyle included:
Paul Larson paul.larson@linaro.org writes:
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).
Have we given up on Lava ever supporting / testing non-SD boot paths, or is that going to be supported by this sdmux implementation?
-Andy
Andy Green andy.green@linaro.org writes:
On 06/19/12 09:45, the mail apparently from Michael Hudson-Doyle included:
Paul Larson paul.larson@linaro.org writes:
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).
Have we given up on Lava ever supporting / testing non-SD boot paths, or is that going to be supported by this sdmux implementation?
No, we have not given up -- although it's not a focus of current work -- and no, it is not going to be supported by this sdmux implementation.
Cheers, mwh
On 06/19/12 11:04, the mail apparently from Michael Hudson-Doyle included:
Andy Green andy.green@linaro.org writes:
On 06/19/12 09:45, the mail apparently from Michael Hudson-Doyle included:
Paul Larson paul.larson@linaro.org writes:
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).
Have we given up on Lava ever supporting / testing non-SD boot paths, or is that going to be supported by this sdmux implementation?
No, we have not given up -- although it's not a focus of current work -- and no, it is not going to be supported by this sdmux implementation.
So if I understood, it's not supported and there is no plan to support it.
-Andy
Andy Green andy.green@linaro.org writes:
On 06/19/12 11:04, the mail apparently from Michael Hudson-Doyle included:
Andy Green andy.green@linaro.org writes:
On 06/19/12 09:45, the mail apparently from Michael Hudson-Doyle included:
Paul Larson paul.larson@linaro.org writes:
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).
Have we given up on Lava ever supporting / testing non-SD boot paths, or is that going to be supported by this sdmux implementation?
No, we have not given up -- although it's not a focus of current work -- and no, it is not going to be supported by this sdmux implementation.
So if I understood, it's not supported and there is no plan to support it.
Correct.
Cheers, mwh
On 18 Jun 2012, at 23:49, Paul Larson wrote:
On Mon, Jun 18, 2012 at 5:03 PM, Michael Hudson-Doyle michael.hudson@linaro.org wrote: 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,
This is because YonQin was adding an android userdata partition to the partitioning script. Works fine on panda et al, because they start off with two partitions. origen and imx53 have that magic additional first partition, so this pushes it over the limit.
Dave
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 _______________________________________________ linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
On 19 June 2012 16:46, Dave Pigott dave.pigott@linaro.org wrote:
On 18 Jun 2012, at 23:49, Paul Larson wrote:
On Mon, Jun 18, 2012 at 5:03 PM, Michael Hudson-Doyle < michael.hudson@linaro.org> wrote: 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,
This is because YonQin was adding an android userdata partition to the partitioning script. Works fine on panda et al, because they start off with two partitions. origen and imx53 have that magic additional first partition, so this pushes it over the limit.
Yeah, the latest CTS test needs both the data partition and sdcard
partition on android.
Thanks Yongqin Liu
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 _______________________________________________ linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
linaro-validation@lists.linaro.org
-
Amit Pundir -
Andy Green -
Dave Pigott -
Marcin Juszkiewicz -
Michael Hudson-Doyle -
Paul Larson -
YongQin Liu