mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Trent Piepho <trent.piepho@igorinstitute.com>
To: Sascha Hauer <sha@pengutronix.de>
Cc: Andrej Picej <andrej.picej@norik.com>,
	Barebox List <barebox@lists.infradead.org>
Subject: Re: [PATCH 2/2] ARM: i.MX: xload: consider ECC strength when reading page
Date: Tue, 15 Jun 2021 13:25:06 -0700	[thread overview]
Message-ID: <CAMHeXxN60A5SEC=wHdB+4AMsTh56CDstn2KAj2ZYHLcBK8T3Eg@mail.gmail.com> (raw)
In-Reply-To: <20210615143535.GJ9782@pengutronix.de>

On Tue, Jun 15, 2021 at 7:35 AM Sascha Hauer <sha@pengutronix.de> wrote:
> >
> > I do not see any imx nand xloader users at all in mainlinux Barebox
> > codebase.  Which is annoying, since I'm trying to boot barebox from
> > NAND on iMX6ULL and there are no boards in barebox that do this.  So I
> > have to do it from scratch, even though I know such boards exist and
> > in fact you are using one.
> >
> > Do I do not know of any specific imx6 boards that do this.  As there
> > are apparently no imx boards booting barebox from nand....
>
> There are several i.MX6 boards mainline that support booting from NAND,
> one of them being the phyFLEX-i.MX6 board which I am using all day. It
> doesn't use any xload mechanism, theres's only one stage in NAND. We
> also have imx6_nand_start_image() which can be used when a xload
> mechanism is desired for cases when the SDRAM shall be initialized in
> code rather than using DCD data. This part indeed has no users in tree,
> but there shouldn't be much to implement to get this working.

That's the issue, this patch is to the code for xload, which has no in
tree users.

The patch either doesn't matter, fixes, or breaks a board, depending
on what it did with NAND.  A normal
NAND layout doesn't matter, but there are "wrong", or at least
non-standard, layouts that it will either fix or break.

Andrej has one real example where it fixes.  There are no known
specific examples where it would break, but absence of evidence is not
evidence of absence!

If there was an in-tree board using xload gpmi, then one could also
look for a BSP software update system or published software update
instructions for that board, and see what they do.

For example, Variscite's DART-6UL instructions for u-boot update from
Linux in §5.4 of
https://variwiki.com/index.php?title=Yocto_NAND_Flash_Burning&release=RELEASE_ZEUS_V1.2_DART-6UL
These have both SPL + 2nd stage replacement in one block, which is
good and this patch will not break a board flashed this way.

Of course, SPL flash uses kobs-ng, which needs the debugfs bch hack
that's not in the mainline kernel, so maybe someone skips that step
and doesn't update SPL?

> > But consider that even if barebox spl can support two different BCH
> > configs on same nand device for booting, neither Barebox nor Linux
> > support this concept at all.
>
> At least the OMAP NAND driver in barebox supports different ECC configs
> that are switchable during runtime. The ECC scheme once switched is used
> for the whole device though, what's missing is indeed to attach an ECC
> scheme to a partition rather than to the whole device. I have that dream
> each time when hacking OMAP NAND...

Even if Barebox could do it, it won't work in Linux, which would be a
huge drawback.  AFAIK, even the new dts based ECC properties are still
attached to a device and not a partition.

When hardware ECC first appeared, it seemed obvious to me that an mtd
ioctl to get/set ecc values was needed.  kobs-ng needs this.  The
thing I can't remember for the MXS boot system needed it.  One could
have different ECC for different partitions.  One could switch the ECC
used when reflashing a partition.  But no, we have stuff like the
debugfs bch file that is still not mainlined after a decade.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2021-06-15 22:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-07  9:09 [PATCH 1/2] ARM: i.MX: xload-gpmi-nand: fix bad block mark swapping Andrej Picej
2021-06-07  9:09 ` [PATCH 2/2] ARM: i.MX: xload: consider ECC strength when reading page Andrej Picej
2021-06-07 20:03   ` Trent Piepho
2021-06-08  6:28     ` Sascha Hauer
2021-06-08  7:23     ` Andrej Picej
2021-06-08 12:38       ` Trent Piepho
2021-06-09  6:34         ` Andrej Picej
2021-06-14 22:14           ` Trent Piepho
2021-06-15 14:35             ` Sascha Hauer
2021-06-15 20:25               ` Trent Piepho [this message]
2021-06-16  7:48                 ` Andrej Picej

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='CAMHeXxN60A5SEC=wHdB+4AMsTh56CDstn2KAj2ZYHLcBK8T3Eg@mail.gmail.com' \
    --to=trent.piepho@igorinstitute.com \
    --cc=andrej.picej@norik.com \
    --cc=barebox@lists.infradead.org \
    --cc=sha@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox