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
prev parent 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