From: Artem Bityutskiy <dedekind@infradead.org>
To: Richard Titmuss <richard_titmuss@logitech.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Bootloader support for UBI images
Date: Wed, 02 Jul 2008 12:02:58 +0300 [thread overview]
Message-ID: <1214989379.6573.85.camel@sauron> (raw)
In-Reply-To: <486B34D9.2070009@logitech.com>
On Wed, 2008-07-02 at 08:57 +0100, Richard Titmuss wrote:
> Right, I was thinking that it would allow any number of volumes for
> renaming. I am also not sure about the interface, and was hoping to get
> some suggestions here. I will think about it and propose something in a
> few days.
Do you absolutely need multiple renames? Could you live with one at
a time?
> > So you use the sub-page read patch BTW?
> No, I'd missed that. Where is it?
Here is the relevant thread. Some people already use that patch. dwmw2
was positive about it and told he would accept it.
http://lists.infradead.org/pipermail/linux-mtd/2008-April/021412.html
> Ok, that is possible. This would also have to include the bad block and
> bit flip status for each PEB. At the moment the Redboot flash api does
> not make this available, so it would mean extending Redboot or writing
> custom flash drivers to access this information.
Well, bit-flip information is not mandatory and may be done later as
an improvement. Bad-block information have to be available.
> > I did not actually catch the second part (LER and PER) tables - this is
> > something I am not aware of. UBI has only volume table on flash, the
> > other things are in-memory and build by scanning.
> >
> It was a proposal to _add_ an addition table, that provided a LER to PER
> mapping for static volumes.
Ah, this is s/LER/LEB/, s/PER/PEB/.
> If this table was stored near the beginning
> of the flash, then it could be accessed without a full scan. This could
> only be used if the UBI volume was mounted read-only, any write
> operations would require scanning all the flash blocks. This is an
> alternative approach to passing data from the bootloader to the kernel.
Well, may be done, but the R/O limitation seems to be too hard.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
prev parent reply other threads:[~2008-07-02 9:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-01 11:43 Bootloader support for UBI images Richard Titmuss
2008-07-01 12:26 ` Artem Bityutskiy
2008-07-01 12:34 ` Artem Bityutskiy
2008-07-02 7:57 ` Richard Titmuss
2008-07-02 9:02 ` Artem Bityutskiy [this message]
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=1214989379.6573.85.camel@sauron \
--to=dedekind@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard_titmuss@logitech.com \
/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.