All partitions from mmc is expected.
This depends on Jim Huang's patch "init: support mmc device mount" in android/system/core to work.
Signed-off-by: Jeremy Chang jeremy.chang@linaro.org --- init.rc | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/init.rc b/init.rc index b6a92c5..a3f72e1 100644 --- a/init.rc +++ b/init.rc @@ -90,12 +90,12 @@ loglevel 3 write /dev/cpuctl/bg_non_interactive/cpu.shares 52
on fs -# mount mtd partitions - # Mount /system rw first to give the filesystem a chance to save a checkpoint - mount yaffs2 mtd@system /system - mount yaffs2 mtd@system /system ro remount - mount yaffs2 mtd@userdata /data nosuid nodev - mount yaffs2 mtd@cache /cache nosuid nodev +# mount mmc partitions + mount ext4 mmc@blk0p3 /system + mount ext4 mmc@blk0p3 /system ro remount + mount ext4 mmc@blk0p5 /cache + mount ext4 mmc@blk0p6 /data + mount ext4 mmc@blk0p7 /sdcard
on post-fs # once everything is setup, no need to modify /
Looks good to me.
/Patrik
On 14 March 2011 15:37, Jeremy Chang jeremy.chang@linaro.org wrote:
All partitions from mmc is expected.
This depends on Jim Huang's patch "init: support mmc device mount" in android/system/core to work.
Signed-off-by: Jeremy Chang jeremy.chang@linaro.org
init.rc | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/init.rc b/init.rc index b6a92c5..a3f72e1 100644 --- a/init.rc +++ b/init.rc @@ -90,12 +90,12 @@ loglevel 3 write /dev/cpuctl/bg_non_interactive/cpu.shares 52
on fs -# mount mtd partitions
- # Mount /system rw first to give the filesystem a chance to save
a checkpoint
- mount yaffs2 mtd@system /system
- mount yaffs2 mtd@system /system ro remount
- mount yaffs2 mtd@userdata /data nosuid nodev
- mount yaffs2 mtd@cache /cache nosuid nodev
+# mount mmc partitions
- mount ext4 mmc@blk0p3 /system
- mount ext4 mmc@blk0p3 /system ro remount
- mount ext4 mmc@blk0p5 /cache
- mount ext4 mmc@blk0p6 /data
- mount ext4 mmc@blk0p7 /sdcard
on post-fs # once everything is setup, no need to modify / -- 1.7.1
On Mon, Mar 14, 2011 at 9:37 AM, Jeremy Chang jeremy.chang@linaro.orgwrote:
+# mount mmc partitions
- mount ext4 mmc@blk0p3 /system
- mount ext4 mmc@blk0p3 /system ro remount
- mount ext4 mmc@blk0p5 /cache
- mount ext4 mmc@blk0p6 /data
- mount ext4 mmc@blk0p7 /sdcard
In my understanding, this will require a very particular sd card partition
layout, which seems to use quite a few partitions. Is this documented somewhere? I'm trying to think about whether it will be possible to make this coexist with Linaro image testing in our validation environment where we currently have 2 partitions for booting a master image, and two partitions for booting a new linaro image we wish to test.
Thanks, Paul Larson
On 14/03/11 at 10:28am, Paul Larson wrote:
On Mon, Mar 14, 2011 at 9:37 AM, Jeremy Chang jeremy.chang@linaro.orgwrote:
+# mount mmc partitions
- mount ext4 mmc@blk0p3 /system
- mount ext4 mmc@blk0p3 /system ro remount
- mount ext4 mmc@blk0p5 /cache
- mount ext4 mmc@blk0p6 /data
- mount ext4 mmc@blk0p7 /sdcard
In my understanding, this will require a very particular sd card partition
layout, which seems to use quite a few partitions. Is this documented somewhere? I'm trying to think about whether it will be possible to make this coexist with Linaro image testing in our validation environment where we currently have 2 partitions for booting a master image, and two partitions for booting a new linaro image we wish to test.
The partition layout is described at:
https://wiki.linaro.org/Platform/Android/DevBoards
Thanks, Paul Larson
Regards, Jamie. -- Linaro Release Manager | Platform Project Manager
On 14 March 2011 16:28, Paul Larson paul.larson@linaro.org wrote:
On Mon, Mar 14, 2011 at 9:37 AM, Jeremy Chang jeremy.chang@linaro.orgwrote:
+# mount mmc partitions
- mount ext4 mmc@blk0p3 /system
- mount ext4 mmc@blk0p3 /system ro remount
- mount ext4 mmc@blk0p5 /cache
- mount ext4 mmc@blk0p6 /data
- mount ext4 mmc@blk0p7 /sdcard
In my understanding, this will require a very particular sd card partition
layout, which seems to use quite a few partitions. Is this documented somewhere? I'm trying to think about whether it will be possible to make this coexist with Linaro image testing in our validation environment where we currently have 2 partitions for booting a master image, and two partitions for booting a new linaro image we wish to test.
An Android system has a rootfs (either in flash or RAM), one system partition that is mounted read only as /system, one user data partition mounted as /data, a cache partition and then we decided to use the rest as sdcard.
It was documented as a bug https://bugs.launchpad.net/linaro-image-tools/+bug/724207 on the image tool.
/Patrik
Thanks, Paul Larson
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Mon, Mar 14, 2011 at 11:28 PM, Paul Larson paul.larson@linaro.org wrote:
On Mon, Mar 14, 2011 at 9:37 AM, Jeremy Chang jeremy.chang@linaro.org wrote:
+# mount mmc partitions
- mount ext4 mmc@blk0p3 /system
- mount ext4 mmc@blk0p3 /system ro remount
- mount ext4 mmc@blk0p5 /cache
- mount ext4 mmc@blk0p6 /data
- mount ext4 mmc@blk0p7 /sdcard
In my understanding, this will require a very particular sd card partition layout, which seems to use quite a few partitions. Is this documented somewhere? I'm trying to think about whether it will be possible to make this coexist with Linaro image testing in our validation environment where we currently have 2 partitions for booting a master image, and two partitions for booting a new linaro image we wish to test.
Hi, Paul: There's a wiki page here, https://wiki.linaro.org/Platform/Android/DevBoards Also I have created a branch lp:~jeremychang/linaro-image-tools/android for bug #724207. Besides using linaro-media-create to deploy the android contents, indeed I am curious about how we should create the 2 partitions for master image for automatic validation. Regarding to deployment, is there any effort we should do to integrate android to LAVA? Thanks.
Regards, -Jeremy Chang
Thanks, Paul Larson
Hi, Paul:
There's a wiki page here,
https://wiki.linaro.org/Platform/Android/DevBoards Also I have created a branch lp:~jeremychang/linaro-image-tools/android for bug #724207. Besides using linaro-media-create to deploy the android contents, indeed I am curious about how we should create the 2 partitions for master image for automatic validation. Regarding to deployment, is there any effort we should do to integrate android to LAVA? Thanks.
Do you think the sizes listed there will be adequate for long? They seem a
bit small, but then again I know android is a lot more stripped down than most of our linaro images.
You don't need to worry about creating the master image part. That's basically a piece that we put on the machine to make sure we have some stable image to boot back into. The only part that concerned me here was the static mapping of partition numbers to mountpoints. There are a couple of different ways I could see this working: 1. with the current way we do things, we typically either do: mmcblk0p1 - boot (for master image) mmcblk0p2 - root (for master imge) then either p3, p4 for testboot, testrootfs, or an extended partition, with 2 or more logical partitions labeled testboot, testrootfs. We could adjust this slightly and do: 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
We would need to try it, but it might make a good solution for the short term.
2. Long term, I think we want to eventually get to a system where we are loading a minimal initramfs from somewhere. We're currently looking into a custom hardware device that would allow us to load this from one sdcard, then switch over to another for building images on. If we get something like that in place, then we can completely wipe out a "test" sd card that would allow us to put whatever we want on it. There are a lot of details to work out with this, so I don't see it happening this cycle, but I think it's where we want to be eventually.
Thanks, Paul Larson
On Mon, Mar 14, 2011 at 12:05 PM, Paul Larson paul.larson@linaro.orgwrote:
- with the current way we do things, we typically either do:
mmcblk0p1 - boot (for master image) mmcblk0p2 - root (for master imge) then either p3, p4 for testboot, testrootfs, or an extended partition, with 2 or more logical partitions labeled testboot, testrootfs. We could adjust this slightly and do: 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
We would need to try it, but it might make a good solution for the short term.
I see one thing that could cause a problem here. I tried actually creating an SD card with this partitioning scheme and it seems to choke on the last partition. Looking at the mmc block driver, it seems the default value for MMC_BLOCK_MINORS is 8, so we only see the first 7 (one is for the whole disk) partitions under /dev. Even if we change this default in the kernel, I'm not sure if uboot would still have a problem with it or not.
Thanks, Paul Larson
On Mon, Mar 14, 2011 at 3:37 PM, Jeremy Chang jeremy.chang@linaro.org wrote:
All partitions from mmc is expected.
This depends on Jim Huang's patch "init: support mmc device mount" in android/system/core to work.
Signed-off-by: Jeremy Chang jeremy.chang@linaro.org
init.rc | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/init.rc b/init.rc index b6a92c5..a3f72e1 100644 --- a/init.rc +++ b/init.rc @@ -90,12 +90,12 @@ loglevel 3 write /dev/cpuctl/bg_non_interactive/cpu.shares 52
on fs -# mount mtd partitions
- # Mount /system rw first to give the filesystem a chance to save
a checkpoint
- mount yaffs2 mtd@system /system
- mount yaffs2 mtd@system /system ro remount
- mount yaffs2 mtd@userdata /data nosuid nodev
- mount yaffs2 mtd@cache /cache nosuid nodev
+# mount mmc partitions
- mount ext4 mmc@blk0p3 /system
- mount ext4 mmc@blk0p3 /system ro remount
- mount ext4 mmc@blk0p5 /cache
- mount ext4 mmc@blk0p6 /data
- mount ext4 mmc@blk0p7 /sdcard
what happened with the "by-name" approach? Is this something we plan to do next?
On 15 March 2011 16:29, Alexander Sack asac@linaro.org wrote:
On Mon, Mar 14, 2011 at 3:37 PM, Jeremy Chang jeremy.chang@linaro.org wrote:
All partitions from mmc is expected. This depends on Jim Huang's patch "init: support mmc device mount" in android/system/core to work.
what happened with the "by-name" approach? Is this something we plan to do next?
hi Alexander,
Yes, that is the next patch I would like to submit. At present, Jeremy and I just make sure the minimal-but-working patches landed in Linaro first.
Sincerely, -jserv
On Tue, Mar 15, 2011 at 10:17 AM, Jim Huang jim.huang@linaro.org wrote:
On 15 March 2011 16:29, Alexander Sack asac@linaro.org wrote:
On Mon, Mar 14, 2011 at 3:37 PM, Jeremy Chang jeremy.chang@linaro.org wrote:
All partitions from mmc is expected. This depends on Jim Huang's patch "init: support mmc device mount" in android/system/core to work.
what happened with the "by-name" approach? Is this something we plan to do next?
hi Alexander,
Yes, that is the next patch I would like to submit. At present, Jeremy and I just make sure the minimal-but-working patches landed in Linaro first.
OK, thanks for the update. I think once we start working on the by-name patches we should involve android-platform to see if they like that approach as well (and prepare eventual upstreaming).
-
Alexander Sack -
Jamie Bennett -
Jeremy Chang -
Jeremy Chang -
Jim Huang -
Patrik Ryd -
Paul Larson