Hi, All
About the sdcard partition support on lava, As you all have already known, the mmcblk0p8 partition can not be recognized in the master image for iMX and origen boards.
Also I have tried with my panda to mount the mmcblk0p8 as the sdcard, but because the 8th partition major number is different with others as following:
root@linaro: cat proc/partitions major minor #blocks name
179 0 7830528 mmcblk0 179 1 53248 mmcblk0p1 179 2 991232 mmcblk0p2 179 3 65536 mmcblk0p3 179 4 1 mmcblk0p4 179 5 2097152 mmcblk0p5 179 6 2097152 mmcblk0p6 179 7 2097152 mmcblk0p7 259 0 420864 mmcblk0p8 root@linaro:
the 8th partition cannot be used in android too.
So at the point now for us the only way is to reduce the partition number of our sdcard.
Here are 3 idea I have thought, but I don't which should we use:
1. merge the master boot partition and target boot partition as one partition
Problem: the master boot partition will be modified each time the target is deployed. This will increase the risk to destroy the master boot
2. merge the master boot partition and master rootfs partition as one partition
Problems:
1)we need to change to use the vfat file system format for rootfs, because the uboot need the vfat format
2)Need to change the master initrd.img and merge the two partitions in our lava-create-master script
3. merge the target boot partition and target rootfs partition as one partition
Problems:
1)we need to change to use the vfat file system format for rootfs, because the uboot need the vfat format
2)this is not the default partition layout that target image will use, and will increase the failure risk in other thing.
4. leave the iMX and origen not supported until the sdmux
Any other ideas about how to deal with this problem?
Thanks,
Yongqin Liu
On 19 Jun 2012, at 11:47, YongQin Liu wrote:
Hi, All
About the sdcard partition support on lava, As you all have already known, the mmcblk0p8 partition can not be recognized in the master image for iMX and origen boards.
Also I have tried with my panda to mount the mmcblk0p8 as the sdcard, but because the 8th partition major number is different with others as following: root@linaro: cat proc/partitions major minor #blocks name
179 0 7830528 mmcblk0 179 1 53248 mmcblk0p1 179 2 991232 mmcblk0p2 179 3 65536 mmcblk0p3 179 4 1 mmcblk0p4 179 5 2097152 mmcblk0p5 179 6 2097152 mmcblk0p6 179 7 2097152 mmcblk0p7 259 0 420864 mmcblk0p8 root@linaro: the 8th partition cannot be used in android too. So at the point now for us the only way is to reduce the partition number of our sdcard. Here are 3 idea I have thought, but I don't which should we use:
- merge the master boot partition and target boot partition as one partition Problem: the master boot partition will be modified each time the target is deployed. This will increase the risk to destroy the master boot
No. Not this one. Anything that changes the master image or fiddles with the test image means that our results could be invalid.
- merge the master boot partition and master rootfs partition as one partition Problems: 1)we need to change to use the vfat file system format for rootfs, because the uboot need the vfat format 2)Need to change the master initrd.img and merge the two partitions in our lava-create-master script
This is probably the way to go for a complete solution.
- merge the target boot partition and target rootfs partition as one partition Problems: 1)we need to change to use the vfat file system format for rootfs, because the uboot need the vfat format 2)this is not the default partition layout that target image will use, and will increase the failure risk in other thing.
No, for the same reason as (1).
- leave the iMX and origen not supported until the sdmux
This is the obvious one, as long as we aren't going to wait too long for the sdmux. If the sdmux is going to be a while, then I vote for (2).
Dave
Any other ideas about how to deal with this problem?
Thanks, Yongqin Liu
linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation
On 06/19/2012 05:47 AM, YongQin Liu wrote:
Hi, All
About the sdcard partition support on lava, As you all have already known, the mmcblk0p8 partition can not be recognized in the master image for iMX and origen boards.
Also I have tried with my panda to mount the mmcblk0p8 as the sdcard, but because the 8th partition major number is different with others as following:
root@linaro: cat proc/partitions major minor #blocks name
179 0 7830528 mmcblk0 179 1 53248 mmcblk0p1 179 2 991232 mmcblk0p2 179 3 65536 mmcblk0p3 179 4 1 mmcblk0p4 179 5 2097152 mmcblk0p5 179 6 2097152 mmcblk0p6 179 7 2097152 mmcblk0p7 259 0 420864 mmcblk0p8 root@linaro:
the 8th partition cannot be used in android too.
So at the point now for us the only way is to reduce the partition number of our sdcard.
Here are 3 idea I have thought, but I don't which should we use:
merge the master boot partition and target boot partition as one partition
Problem: the master boot partition will be modified each time the target is deployed. This will increase the risk to destroy the master boot
merge the master boot partition and master rootfs partition as one partition
Problems:
1)we need to change to use the vfat file system format for rootfs, because the uboot need the vfat format
2)Need to change the master initrd.img and merge the two partitions in our lava-create-master script
merge the target boot partition and target rootfs partition as one partition
Problems:
1)we need to change to use the vfat file system format for rootfs, because the uboot need the vfat format
2)this is not the default partition layout that target image will use, and will increase the failure risk in other thing.
leave the iMX and origen not supported until the sdmux
I think we should try this for now and maybe re-visit if it becomes a problem.
Any other ideas about how to deal with this problem?
Andy Doan andy.doan@linaro.org writes:
On 06/19/2012 05:47 AM, YongQin Liu wrote:
Hi, All
About the sdcard partition support on lava, As you all have already known, the mmcblk0p8 partition can not be recognized in the master image for iMX and origen boards.
Also I have tried with my panda to mount the mmcblk0p8 as the sdcard, but because the 8th partition major number is different with others as following:
root@linaro: cat proc/partitions major minor #blocks name
179 0 7830528 mmcblk0 179 1 53248 mmcblk0p1 179 2 991232 mmcblk0p2 179 3 65536 mmcblk0p3 179 4 1 mmcblk0p4 179 5 2097152 mmcblk0p5 179 6 2097152 mmcblk0p6 179 7 2097152 mmcblk0p7 259 0 420864 mmcblk0p8 root@linaro:
the 8th partition cannot be used in android too.
So at the point now for us the only way is to reduce the partition number of our sdcard.
Here are 3 idea I have thought, but I don't which should we use:
merge the master boot partition and target boot partition as one partition
Problem: the master boot partition will be modified each time the target is deployed. This will increase the risk to destroy the master boot
Unlike Dave, I think this option would be OK-ish (they're all bad though).
merge the master boot partition and master rootfs partition as one partition
Problems:
1)we need to change to use the vfat file system format for rootfs, because the uboot need the vfat format
2)Need to change the master initrd.img and merge the two partitions in our lava-create-master script
I guess this might work... having / be FAT doesn't really sound like a good idea.
Does uboot really only support fat still? :(
merge the target boot partition and target rootfs partition as one partition
Problems:
1)we need to change to use the vfat file system format for rootfs, because the uboot need the vfat format
2)this is not the default partition layout that target image will use, and will increase the failure risk in other thing.
This seems like a very bad idea.
- leave the iMX and origen not supported until the sdmux
I think we should try this for now and maybe re-visit if it becomes a problem.
I like this plan for now too.
Any other ideas about how to deal with this problem?
Another option would be to get rid of the master rootfs entirely run everything master-ish from a initramfs. Dunno how feasible that is though.
Cheers, mwh
On 20 Jun 2012, at 00:40, Michael Hudson-Doyle wrote:
Any other ideas about how to deal with this problem?
Another option would be to get rid of the master rootfs entirely run everything master-ish from a initramfs. Dunno how feasible that is though.
Paul and I discussed this back in SF. I think it's worth running up a BP and investigating. Would solve a lot of problems.
Dave
On 06/20/2012 03:29 AM, Dave Pigott wrote:
On 20 Jun 2012, at 00:40, Michael Hudson-Doyle wrote:
Any other ideas about how to deal with this problem?
Another option would be to get rid of the master rootfs entirely run everything master-ish from a initramfs. Dunno how feasible that is though.
Paul and I discussed this back in SF. I think it's worth running up a BP and investigating. Would solve a lot of problems.
I've been interested in that concept as well. I'd been hoping that we'd get SD muxes and just not have to think through things like this. However, I think the SD-mux is still at least 2 months away.
Just see this article. http://blog.mezeske.com/?p=483 And wondering if we can use this technique to save the boot partition for master.
Thanks, Yongqin Liu
On 20 June 2012 22:21, Andy Doan andy.doan@linaro.org wrote:
On 06/20/2012 03:29 AM, Dave Pigott wrote:
On 20 Jun 2012, at 00:40, Michael Hudson-Doyle wrote:
Any other ideas about how to deal with this problem?
Another option would be to get rid of the master rootfs entirely run everything master-ish from a initramfs. Dunno how feasible that is though.
Paul and I discussed this back in SF. I think it's worth running up a BP and investigating. Would solve a lot of problems.
I've been interested in that concept as well. I'd been hoping that we'd get SD muxes and just not have to think through things like this. However, I think the SD-mux is still at least 2 months away.
On 06/21/2012 01:17 AM, YongQin Liu wrote:
Just see this article. http://blog.mezeske.com/?p=483 And wondering if we can use this technique to save the boot partition for master.
I have little kermit experience, but since we connect to our serial sessions via conmux or telneting to a serial console server, could kermit work for us?
Andy Doan andy.doan@linaro.org writes:
On 06/21/2012 01:17 AM, YongQin Liu wrote:
Just see this article. http://blog.mezeske.com/?p=483 And wondering if we can use this technique to save the boot partition for master.
I have little kermit experience, but since we connect to our serial sessions via conmux or telneting to a serial console server, could kermit work for us?
Let's get CTS enabled for a board that doesn't require partition magic first and then worry about it? :)
Cheers, mwh
On 25 June 2012 05:34, Michael Hudson-Doyle michael.hudson@linaro.orgwrote:
Andy Doan andy.doan@linaro.org writes:
On 06/21/2012 01:17 AM, YongQin Liu wrote:
Just see this article. http://blog.mezeske.com/?p=483 And wondering if we can use this technique to save the boot partition for master.
I have little kermit experience, but since we connect to our serial sessions via conmux or telneting to a serial console server, could kermit work for us?
I don't have the experience.:( But we can try this, or we can try to boot the master form network with TFTP and NFS. because the files used for boot are not large, and the boot will not be very often, to some extent, the boot from network should be acceptable I think.
Let's get CTS enabled for a board that doesn't require partition magic first and then worry about it? :)
+1
I am thinking that making the sdcard support for Origen and iMX another BP or Bug. This time let's do the support for normal 2parts board.
Thanks, Yongqin Liu
On 25 June 2012 23:34, Andy Doan andy.doan@linaro.org wrote:
On 06/24/2012 09:07 PM, YongQin Liu wrote:
I am thinking that making the sdcard support for Origen and iMX another BP or Bug. This time let's do the support for normal 2parts board.
that sounds like a good plan. lets do that.
Add a BP for it in lava-dispatcher https://blueprints.launchpad.net/lava-dispatcher/+spec/add-sdcard-partition-...
Thanks, Yongqin Liu
linaro-validation@lists.linaro.org
-
Andy Doan -
Dave Pigott -
Michael Hudson-Doyle -
YongQin Liu