All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Golle <daniel@makrotopia.org>
To: J Mo <jmomo@jmomo.net>
Cc: "u-boot@lists.denx.de" <u-boot@lists.denx.de>,
	"Richard Weinberger" <richard.weinberger@gmail.com>,
	lede-dev@lists.infradead.org, "Gabor Juhos" <juhosg@openwrt.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"John Crispin" <john@phrozen.org>,
	"Rafał Miłecki" <rafal@milecki.pl>,
	openwrt-devel@lists.openwrt.org
Subject: Re: [LEDE-DEV] Older u-boot mangles UBI from ubinize 1.5.2
Date: Thu, 11 Aug 2016 15:32:13 +0200	[thread overview]
Message-ID: <20160811133213.GJ1644@makrotopia.org> (raw)
In-Reply-To: <420605a7-61ea-b4c8-65be-6f113a510d94@jmomo.net>

Hi J,

On Thu, Aug 11, 2016 at 06:15:32AM -0700, J Mo wrote:
> 
> 
> On 08/11/2016 05:31 AM, Daniel Golle wrote:
> > That's what I told you in the previous mail, removing the rootfs=
> > parameter from the dts should do the trick, because you just cannot
> > mount a ubi device (which is a character device in Linux) with a
> > block-based filesystem (like squashfs). This cannot and won't ever
> > work and you could either leave it to OpenWrt/LEDE's auto-probing to
> > figure out what to do based on the rootfs type (non-ubifs vs. ubifs)
> > or append even more board- and filesystem-specific crap to your cmdline
> > such as ubiblock=... root=/dev/ubiblock0_1 (however, that then won't
> > work for ubifs, thus the auto-probing patches).
> 
> ... OH!
> 
> Well, I needed some extra intellectual clubbing to catch on.
> 
> NOW I remember reading the UBI docs, about glubi, the fact that volumes are
> char devices, and I even seem to remember some ALL CAPS red size-20+ text at
> the top of the page saying something about it.
> 
> Tomorrow I'll go read the docs again, because I know I remember reading that
> you could put a RO-squashfs in a UBI volume.  I just need to have it mounted
> the right way.

Exactly. However, this makes mounting a UBIFS volume entirely different
from mounting a volume with any other (read-only) filesystem which
needs a ubiblock device (gluebi has been deprecated in favour of
ubiblock) to be created and subsequently mounted.
The idea of the auto-probing patches [1] was to keep things filesystem-
agnostic, ie. allow for either a single read-write UBIFS rootfs or any
read-only filesystem (e.g. squashfs) which needs ubiblock and have a
UBIFS read-write overlay on top.
In this way, all you have to take care of is *not* to have any rootfs=
or ubi* parameters in your kernel cmdline and all the rest should
happen automagically.


Cheers


Daniel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Golle <daniel@makrotopia.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [LEDE-DEV] Older u-boot mangles UBI from ubinize 1.5.2
Date: Thu, 11 Aug 2016 15:32:13 +0200	[thread overview]
Message-ID: <20160811133213.GJ1644@makrotopia.org> (raw)
In-Reply-To: <420605a7-61ea-b4c8-65be-6f113a510d94@jmomo.net>

Hi J,

On Thu, Aug 11, 2016 at 06:15:32AM -0700, J Mo wrote:
> 
> 
> On 08/11/2016 05:31 AM, Daniel Golle wrote:
> > That's what I told you in the previous mail, removing the rootfs=
> > parameter from the dts should do the trick, because you just cannot
> > mount a ubi device (which is a character device in Linux) with a
> > block-based filesystem (like squashfs). This cannot and won't ever
> > work and you could either leave it to OpenWrt/LEDE's auto-probing to
> > figure out what to do based on the rootfs type (non-ubifs vs. ubifs)
> > or append even more board- and filesystem-specific crap to your cmdline
> > such as ubiblock=... root=/dev/ubiblock0_1 (however, that then won't
> > work for ubifs, thus the auto-probing patches).
> 
> ... OH!
> 
> Well, I needed some extra intellectual clubbing to catch on.
> 
> NOW I remember reading the UBI docs, about glubi, the fact that volumes are
> char devices, and I even seem to remember some ALL CAPS red size-20+ text at
> the top of the page saying something about it.
> 
> Tomorrow I'll go read the docs again, because I know I remember reading that
> you could put a RO-squashfs in a UBI volume.  I just need to have it mounted
> the right way.

Exactly. However, this makes mounting a UBIFS volume entirely different
from mounting a volume with any other (read-only) filesystem which
needs a ubiblock device (gluebi has been deprecated in favour of
ubiblock) to be created and subsequently mounted.
The idea of the auto-probing patches [1] was to keep things filesystem-
agnostic, ie. allow for either a single read-write UBIFS rootfs or any
read-only filesystem (e.g. squashfs) which needs ubiblock and have a
UBIFS read-write overlay on top.
In this way, all you have to take care of is *not* to have any rootfs=
or ubi* parameters in your kernel cmdline and all the rest should
happen automagically.


Cheers


Daniel

  reply	other threads:[~2016-08-11 13:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-11  2:26 Older u-boot mangles UBI from ubinize 1.5.2 J Mo
2016-08-11  2:26 ` [U-Boot] " J Mo
2016-08-11  9:51 ` Richard Weinberger
2016-08-11  9:51   ` [U-Boot] " Richard Weinberger
2016-08-11 10:40   ` [LEDE-DEV] " Daniel Golle
2016-08-11 10:40     ` [U-Boot] " Daniel Golle
2016-08-11 11:28     ` J Mo
2016-08-11 11:28       ` [U-Boot] " J Mo
2016-08-11 12:18       ` J Mo
2016-08-11 12:18         ` [U-Boot] " J Mo
2016-08-11 12:31         ` Daniel Golle
2016-08-11 12:31           ` [U-Boot] " Daniel Golle
2016-08-11 13:15           ` J Mo
2016-08-11 13:15             ` [U-Boot] " J Mo
2016-08-11 13:32             ` Daniel Golle [this message]
2016-08-11 13:32               ` Daniel Golle
     [not found]       ` <20160811114904.GC1644@makrotopia.org>
2016-08-11 12:22         ` Richard Weinberger
2016-08-11 12:22           ` [U-Boot] " Richard Weinberger
2016-08-11 12:34           ` Daniel Golle
2016-08-11 12:34             ` [U-Boot] " Daniel Golle
2016-08-12  4:35   ` [U-Boot] " Heiko Schocher
2016-08-12  4:35     ` Heiko Schocher
2016-08-12  5:13     ` J Mo
2016-08-12  5:13       ` J Mo

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=20160811133213.GJ1644@makrotopia.org \
    --to=daniel@makrotopia.org \
    --cc=jmomo@jmomo.net \
    --cc=john@phrozen.org \
    --cc=juhosg@openwrt.org \
    --cc=lede-dev@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=openwrt-devel@lists.openwrt.org \
    --cc=rafal@milecki.pl \
    --cc=richard.weinberger@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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.