All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Leo Barnes <barnes.leo@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Flashing UBIFS over fastboot
Date: Sun, 28 Nov 2010 16:55:52 +0200	[thread overview]
Message-ID: <1290956152.2032.15.camel@koala> (raw)
In-Reply-To: <AANLkTinxyagZ+_5_fv2ei0bF=N3Ww0KJhjSNKqNmQHpr@mail.gmail.com>

On Sun, 2010-11-28 at 17:46 +0900, Leo Barnes wrote:
> Hello again,
> 
> New problem:
> 
> On Fri, Nov 26, 2010 at 10:58 PM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> >
> > I think you can hack ubinize and teach it to add OOB bytes.
> >
> 
> I have now managed to transform a UBIFS image so that it is flashable
> by fastboot. The system then boots once without any trouble (at least
> any immediate trouble), but when I reboot, it refuses to start. I have
> narrowed the problem down to the fact that fastboot does not strip
> trailing 0xFF pages from the blocks and instead writes them as usual.
> As explained in the FAQ this has some nasty consequences. I have no
> way (currently at least) of modifying how fastboot works on the
> device. Is it somehow possible to fill these pages with dummy data and
> tell UBI/UBIFS that it is ok to discard this data when the block is
> erased sometime in the future? Or is there any other way of doing it?

I guess for data and indexing eraseblocks you can just pad the left
space with UBIFS padding nodes (struct ubifs_pad_node).

But then there are special UBIFS areas which go before the data area.
Things might me trickier there. I am not sure the padding node trick
will work there, but it might. If this does not work for some areas,
they can be tricked a different way.

The other ugly option would be to make UBI do ubi_leb_change() for each
eraseblock after scanning. Or only for those which have 0xFFs at the
end.

But I do not have ready solution for this.

> If UBI/UBIFS clones/remaps a block, does it strip empty trailing
> pages?

Yes, it does, this is why ubi_leb_change() will work.

-- 
Best Regards,
Artem Bityutskiy (Битюцкий Артём)

      reply	other threads:[~2010-11-28 14:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-26 13:39 Flashing UBIFS over fastboot Leo Barnes
2010-11-26 13:58 ` Artem Bityutskiy
2010-11-26 14:07   ` Leo Barnes
2010-11-28  8:46   ` Leo Barnes
2010-11-28 14:55     ` 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=1290956152.2032.15.camel@koala \
    --to=dedekind1@gmail.com \
    --cc=barnes.leo@gmail.com \
    --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.