imx6 nand: dbbt version/layout

[Middelschulte, Leif]

Am Montag, dem 03.05.2021 um 14:32 +0200 schrieb Sascha Hauer:
> Hi Leif,
Hi Sascha,

>
> On Thu, Apr 22, 2021 at 12:13:59PM +0000, Middelschulte, Leif wrote:
> > Hi,
> >
> > I'm in the process of fixing up imx-kobs to support
> > - boot configuration dumps
> > - boot stream extracts/updates
> > on iMX6QDL using the GPMI-NAND interface, as provided by some more
> > "recent" kernels.
> >
> > I updated barebox on the NAND flash storage using another instance of
> > barebox. Now it turns out that the dbbt version used (i.e. written)
> > by
> > barebox and supported by imx-kobs (as it was) is not documented in
> > the
> > i.MX6 QDL reference manual.
> > Barebox uses[0] DBBT version 0x1000000, while the reference manual
> > describes (i.MX6DQRM Rev 3., section 8.5.2.4) layout version 0x1.
>
> It's stored in big endian. Just endianess swap 0x01000000 and you have
> your 0x00000001.
Thank you for explaining the quite obvious, my bad.  :)

On another note though: Barebox writes[0] and verifies[1] ' BCF' and
'TBBD' in the BCB.

The most recent manual (IMX6DQRM rev. 6)* states the following though:
- FCB FingerPrint "FCB ": also given as 0x20424346, which is ' BCF' in
ascii
- DBBT FingerPrint "DBBT": also given as 0x44424254, which is 'DBBT' in
ascii
Notice how the value is reversed in the first case, while it is not in
the second.

Other tools, such as imx-kobs, seem to use[2] the value given in the
reference manual for the DBBT.

Since the ROM seems to boot either way, finding "the correct"
Fingerprint might be nitpicking, besides the verification (write skip).


[0]
https://git.pengutronix.de/cgit/barebox/tree/include/soc/imx/imx-nand-bcb.h?id=7689055a8b037363dae840eee33a0ed43f905b7a

[1]
https://git.pengutronix.de/cgit/barebox/tree/common/imx-bbu-nand-fcb.c?id=7689055a8b037363dae840eee33a0ed43f905b7a#n791
[2]
https://github.com/NXPmicro/imx-kobs/blob/269fdffcf97238684de9f28977a73677282e061f/src/BootControlBlocks.h#L35

*CAUTION: Older versions of the IMX6DQRM state even other hex values
for the FCB fingerprint (i.e. the ascii equivalent of ` BCN`).

>
> >
> > Besides that, the reference manual apparently does not describe the
> > field `BBMarkerPhysicalOffsetInSpareData` at the end of the FCB
> > structure. Yet again, imx-kobs and barebox are reading/writing it.
>
> barebox doesn't actively sets the value to anything else than 0x0. I
> have no idea if and how the ROM interprets this value. Indeed the name
> of the field seems to be inconsistent to the reference manual.
Never mind this.
>
> Regards,
>   Sascha
>
>
> --
> Pengutronix e.K.
> |                             |
> Steuerwalder Str. 21                       |
> http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-
> 0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-
> 5555 |

--
Kind regards

Leif Middelschulte
Software Development

KLS Martin GmbH + Co. KG
A company of the KLS Martin Group
Am Flughafen 18
79108 Freiburg, Germany

Phone
Fax
Mail
Web

+49 761 557 997 -543
+49 761 557 997 -152

leif.middelschulte at klsmartin.com
www.klsmartin.com




Commercial Register: Freiburg im Breisgau HRA 4044
Managing directors: Michael Martin, Karl Leibinger, Christian
Leibinger
General partner: KLS Martin Verwaltungsgesellschaft mbH
Commercial register: Stuttgart HRB 451316
Tax ID number: DE 237467280

This e-mail may contain confidential and/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.
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. Any views or opinions expressed are solely those of the author and do not necessarily represent those of KLS Martin. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.