All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Smith <john.smith@arrows.demon.co.uk>
To: linux-mtd@lists.infradead.org
Subject: Re: UBI: Can I boot with an UBI volume holding a root file system?
Date: Sun, 6 May 2007 11:25:46 +0000 (UTC)	[thread overview]
Message-ID: <loom.20070506T124743-262@post.gmane.org> (raw)
In-Reply-To: 1178374139.3659.150.camel@sauron

Artem Bityutskiy <dedekind <at> infradead.org> writes:

> 
> On Fri, 2007-05-04 at 23:42 +0100, John Smith wrote:
> > I am hoping to build a root file system and store it as a squashfs
> > image in a static UBI volume. What command line should I should pass
> > to the kernel at boot time?
> > 
> > There are likely to be other UBI volumes in the UBI partition which
> > will each get mapped to a /dev/mtdblock device. Is it going to be
> > difficult to identify the major/minor numbers of the device which will
> > mapped to my squashfs image?
> > 
> > I think that I need to add some initramfs logic, but I am very
> > uncertain of the details. I will be grateful for any ideas,
> 
> I have never tried this and I guess nobody did. But you may try and send
> us a text to add to faq on MTD site 
> 

I can make some progress. With a boot line

   boot vmlinux "root=31:4 rootfstype=squashfs ubi.mtd=0 ubi.mtd=3"

I can boot the kernel and mount /dev/mtdblock4 as the root file system. 
(31,4 are the major and minor numbers of /dev/mtdblock4, which is the mtd 
block device mapped to the UBI volume which holds my squashfs image.)

The kernel has logic in the function name_to_dev_t() in file 
init/do_mounts.c to convert the string "root=31:4" to the block device.
There is already logic in name_to_dev_t() for handling disks by name.
name_to_dev_t() could be extended to identify mtd partitions by name
so that 
   root=mtd:my_squashfs_image
returns the mtd block device containing mtd image "my_squashfs_image"

> One thing for you to keep in mind: use proper volume alignment. I am not
> sure what is squashfs block size probably 512 bytes, then use alignment
> 512. In this case you will end up with 512-byte aligned logical
> eraseblocks. this will make your life easier.

I have not done anything explicit about alignment. Have I just been lucky 
because my NAND device works in pages of 512 bytes? The squashfs block size is 
currently 65536 bytes, though may be the word block is describing a different 
concept. Perhaps it would be best to make the squashfs block size the same size 
as the UBI logical erase block size. 

John

  reply	other threads:[~2007-05-06 11:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-04 22:42 UBI: Can I boot with an UBI volume holding a root file system? John Smith
2007-05-05 11:51 ` Artem Bityutskiy
2007-05-05 14:08 ` Artem Bityutskiy
2007-05-06 11:25   ` John Smith [this message]
2007-05-06 11:55     ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20070506T124743-262@post.gmane.org \
    --to=john.smith@arrows.demon.co.uk \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.