mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* CRC32 verification on NAND flash
@ 2021-09-21 14:10 Yunus Bas
  2021-09-23  9:55 ` Trent Piepho
  0 siblings, 1 reply; 3+ messages in thread
From: Yunus Bas @ 2021-09-21 14:10 UTC (permalink / raw)
  To: barebox, sha

Hello everyone,

I have a question regarding the Barebox checksum verification on NAND-
partitions. To verificate that the Barebox has been flashed correctly,
we do a crc32 check on the nand.bb-partition. The offsets for the slots
are derived from the max partition, so that the slots are equally
sized. The bb-partitions are badblock-aware partitions, meaning that
the bad-marked blocks are just skipped. This means, that the overall
size of the bb-partition also decreases relative to the number of bad-
blocks. Our problem here is, in case a badblock occurs on a block prior
to the slots, the offset to the slots where the Barebox-code resides in
the bb-partition also changes.

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.

Taking into account that with time the NAND cells will worn out and
degrate even more, we need to calculate the offset for every board to-
be tested and perform the crc32 check after that.
Using the original nand0-partition is also out of option, since the
verification would also fail when a badblock would occur somewhere in
the slot-area (in case of the above example, 0x260000).

Is there a proper way to do a checksum verification on NAND-flash,
which I'm not familiar with? Can the size of the partitions be somehow
determined dynamically? How do the experts handle this?

Thank you in advance.
-- 
With Regards,
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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: CRC32 verification on NAND flash
  2021-09-21 14:10 CRC32 verification on NAND flash Yunus Bas
@ 2021-09-23  9:55 ` Trent Piepho
  2021-09-24 14:21   ` Yunus Bas
  0 siblings, 1 reply; 3+ messages in thread
From: Trent Piepho @ 2021-09-23  9:55 UTC (permalink / raw)
  To: Yunus Bas; +Cc: barebox, sha

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?

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.

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.

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: CRC32 verification on NAND flash
  2021-09-23  9:55 ` Trent Piepho
@ 2021-09-24 14:21   ` Yunus Bas
  0 siblings, 0 replies; 3+ messages in thread
From: Yunus Bas @ 2021-09-24 14:21 UTC (permalink / raw)
  To: trent.piepho; +Cc: barebox, sha

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-09-24 14:22 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-21 14:10 CRC32 verification on NAND flash Yunus Bas
2021-09-23  9:55 ` Trent Piepho
2021-09-24 14:21   ` Yunus Bas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox