mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Yunus Bas <Y.Bas@phytec.de>
To: "trent.piepho@igorinstitute.com" <trent.piepho@igorinstitute.com>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>,
	"sha@pengutronix.de" <sha@pengutronix.de>
Subject: Re: CRC32 verification on NAND flash
Date: Fri, 24 Sep 2021 14:21:03 +0000	[thread overview]
Message-ID: <16f582d1cb47378e044629f43acde946c0a8bc3d.camel@phytec.de> (raw)
In-Reply-To: <CAMHeXxPsULguR1icV9cEz5v_Vb6pNsuuWiG0PgJ62ONFwFRB+g@mail.gmail.com>

Am Donnerstag, dem 23.09.2021 um 02:55 -0700 schrieb Trent Piepho:
> On Tue, Sep 21, 2021 at 7:11 AM Yunus Bas <Y.Bas@phytec.de> wrote:
> > Here an example:
> > The startpage of slot1 is 0x240000. This is the real address, where
> > Barebox is flashed into and can also be dumped using the original
> > nand0-partition. Now, when a bad-block occurs prior to the
> > startpage of
> > slot1, let's take for example the block at 0x140000, then offset of
> > slot1 changes also in the nand0.bb partition. In the original
> > partition
> > nand0, slot1 is still at 0x240000, but on nand0.bb, slot1 has been
> > moved one block prior to the original offset and changed to
> > 0x220000.
> 
> If you partition nand, via e.g. device tree entries, those partition
> start offsets are non-BB aware, so do not move.
> 
> So if I write X pages to partition 0 BB and read back X pages, I will
> know the crc.  And the same for partition 1, even if some blocks in
> partition 0 are bad.
> 
> But these "slots" you talk about, I think these are not nand
> partitions.  Maybe more like the two bootloader slots in an IMX boot
> image?

Oh, maybe my description wasn't quite understandable, sorry for that.
Of course I mean the bootloader slots, which is calculated from the
barebox partition size.

> 
> If the position of the slots is determined dynamically at flash time,
> then I think your answer is you must also determine it when you check
> CRC.  For instance, on imx one could create a command that queries
> the
> FCB to find the two bootloader slot start addresses.  Code is already
> there in the imx bbu handler, it just needs an interface.  Or,
> something had to determine this dynamic address of the slot, so have
> that process also tell you what it determined.  For example, have the
> imx bbu code set env variables with the address of the bootloader
> slots that it calculates when it flashes barebox.
> 
> If you want to calculate one CRC value for all of NAND, then I think
> you can not do that.  Because the contents of the entire nand flash
> chip are not constant.  Instead have a list of CRCs and lengths for
> the parts you have actually flashed.  Most of flash is usually blank
> anyway, why even flash blank space?  It just slows down
> manufacturing.

In our case, we just want to verify if our bootloader has been flashed
error-free after the flash process.
> 
> You must just find the start location for these lengths of data that
> have CRCs.  As above, nand partitions start at a constant location,
> so
> this is easy.  Dynamically determined locations one would need to:
> query location if it is stored somewhere, have code that determined
> the location also provide the value to the verification code, or
> repeat the calculation by which the location was determined in the
> first place to independently arrive at the same answer.

Thank you for your detailed answer.

-- 
Mit freundlichen Grüßen
Yunus Bas

-Software Engineer-
PHYTEC Messtechnik GmbH
Robert-Koch-Str. 39
55129 Mainz
Germany
Tel.: +49 (0)6131 9221- 466
Web: www.phytec.de

Sie finden uns auch auf: Facebook, LinkedIn, Xing, YouTube

PHYTEC Messtechnik GmbH | Robert-Koch-Str. 39 | 55129 Mainz, Germany
Geschäftsführer: Dipl.-Ing. Michael Mitezki, Dipl.-Ing. Bodo Huber |
Handelsregister Mainz HRB 4656 | Finanzamt Mainz | St.Nr. 266500608, DE
149059855
This E-Mail may contain confidential or privileged information. If you
are not the intended recipient (or have received this E-Mail in error)
please notify the sender immediately and destroy this E-Mail. Any
unauthorized copying, disclosure or distribution of the material in
this E-Mail is strictly forbidden.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

      reply	other threads:[~2021-09-24 14:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-21 14:10 Yunus Bas
2021-09-23  9:55 ` Trent Piepho
2021-09-24 14:21   ` Yunus Bas [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=16f582d1cb47378e044629f43acde946c0a8bc3d.camel@phytec.de \
    --to=y.bas@phytec.de \
    --cc=barebox@lists.infradead.org \
    --cc=sha@pengutronix.de \
    --cc=trent.piepho@igorinstitute.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox