diff mbox

[2/2,android/device/linaro/common] mount mmc partitions instead of mtd partitions

Message ID AANLkTikyqCRwX_CP7zVB6togY39L+rTGz9Gt0=pd27BS@mail.gmail.com
State New
Headers show

Commit Message

Jeremy Chang March 14, 2011, 2:37 p.m. UTC
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(-)

     # once everything is setup, no need to modify /

Comments

Patrik Ryd March 14, 2011, 3:23 p.m. UTC | #1
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
>
Paul Larson March 14, 2011, 3:28 p.m. UTC | #2
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.

Thanks,
Paul Larson
Jamie Bennett March 14, 2011, 3:39 p.m. UTC | #3
On 14/03/11 at 10:28am, Paul Larson 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.

The partition layout is described at:

  https://wiki.linaro.org/Platform/Android/DevBoards
 
> Thanks,
> Paul Larson

Regards,
Jamie.
--
Linaro Release Manager   |   Platform Project Manager
Patrik Ryd March 14, 2011, 3:50 p.m. UTC | #4
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.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.
>

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
>
>
Jeremy Chang March 14, 2011, 3:50 p.m. UTC | #5
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
>
Paul Larson March 14, 2011, 5:05 p.m. UTC | #6
>
> 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
Paul Larson March 14, 2011, 6:33 p.m. UTC | #7
On Mon, Mar 14, 2011 at 12:05 PM, Paul Larson <paul.larson@linaro.org>wrote:

>
> 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.
>
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
Alexander Sack March 15, 2011, 8:29 a.m. UTC | #8
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?
Jim Huang March 15, 2011, 9:17 a.m. UTC | #9
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
Alexander Sack March 15, 2011, 10:13 a.m. UTC | #10
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).
diff mbox

Patch

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