From: Alexander Stein <alexander.stein@systec-electronic.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org,
"Daniel Krüger" <daniel.krueger@systec-electronic.com>
Subject: Re: UBIFS recovery fails in barebox while Linux suceeds
Date: Thu, 03 Mar 2016 08:16:13 +0100 [thread overview]
Message-ID: <9617410.tHQtcjn6HO@ws-stein> (raw)
In-Reply-To: <20160302195613.GU9224@pengutronix.de>
On Wednesday 02 March 2016 20:56:13, Sascha Hauer wrote:
> On Wed, Mar 02, 2016 at 05:19:08PM +0100, Alexander Stein wrote:
> > Hi,
> >
> > in case a UBIFS needs recovery (unclean write or whatever on NOR
> > flash) it is possible that barebox fails to do so while Linux suceeds.
> > The main cause, IMHO, is that Linux takes max_write_size into account
> > (starting with commit 2765df7da540687c4d57ca840182122f074c5b9c "UBIFS:
> > use max_write_size during recovery") while barebox doesn't. Apparently
> > is_last_write (fs/ubifs/recovery.c) results differently due to that
> > fact which explains why recovery progress differently. I don't know
> > which linux version the ubifs code in barebox is taken from but I
> > guess this needs to be updated. Are there any plans?
>
> The barebox UBIFS code is taken from U-Boot 2013.07 which is taken from
> Linux-2.6.29-rc6, so indeed the code is quite old. U-Boot has updated
> UBIFS support to Linux-4.2. The question is if we update UBIFS from
> U-Boot or directly from the Kernel, I have no idea which way is easier.
I still wonder if this problem should have been avoided in the first place. It seems like the change in the kernel is like chaning the on-disk-format.
> Currently there are no plans to update UBIFS, but of course you are
> invited to create them ;)
I expected an answer like that ;-) I did a quick compare and there are a lot of changes in barebox upon the code taken from u-boot. AFAICS those are not documented :(
Best regards,
Alexander
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
alexander.stein@systec-electronic.com
Legal and Commercial Address:
Am Windrad 2
08468 Heinsdorfergrund
Germany
Office: +49 (0) 3765 38600-0
Fax: +49 (0) 3765 38600-4100
Managing Directors:
Director Technology/CEO: Dipl.-Phys. Siegmar Schmidt;
Director Commercial Affairs/COO: Dipl. Ing. (FH) Armin von Collrepp
Commercial Registry:
Amtsgericht Chemnitz, HRB 28082; USt.-Id Nr. DE150534010
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2016-03-03 7:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 16:19 UBIFS recovery fails in barebox while Linux suceeds Alexander Stein
2016-03-02 19:56 ` Sascha Hauer
2016-03-03 7:16 ` Alexander Stein [this message]
2016-03-03 8:28 ` Sascha Hauer
2016-03-03 8:38 ` Alexander Stein
2016-03-03 9:23 ` Sascha Hauer
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=9617410.tHQtcjn6HO@ws-stein \
--to=alexander.stein@systec-electronic.com \
--cc=barebox@lists.infradead.org \
--cc=daniel.krueger@systec-electronic.com \
--cc=s.hauer@pengutronix.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.