[U-Boot] [PATCH 01/13] mxc nand: Merge mtd and spl register definitions

["Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>]

Hi Stefano,

On 08/14/2012 04:29:04 PM, Beno?t Th?baudeau wrote:
> Hi Stefano,
> 
> > On 14/08/2012 13:13, Beno?t Th?baudeau wrote:
> > > Hi Stefano,
> > > 
> > 
> > Hi Beno?t,
> > 
> > >> We have currently only two boards supporting this mechanismus,
> > >> using
> > >> MX25 (karo tx25) and MX31. Both MX25 and MX31 have an internal
> > >> RAM
> > >> (128KB) that is is suitable for installing the SPL. Note that TI
> > >> SOCs
> > >> have less RAM available, and they support SPL.
> > > 
> > > The available RAM size is not the issue. i.MX boards using
> > > nand_spl
> > > can use
> > > internal or external RAM. The issue comes from the i.MX ROM
> > > bootloader that only
> > > uses the NFC buffer. On i.MX31, that means max 2 kiB for SPL, and
> > > 4
> > > kiB on
> > > i.MX25/35/51. What can be done on the latter if using internal
> > > boot
> > > (with DCD
> > > header) is to use at most one NF block (more is not possible
> > > because the i.MX
> > > bootloader goes back to serial mode if any bad block is found,
> > > and
> > > one of the
> > > 1st or 2nd block has to be good).
> > 
> > We are both a little off-topic here, but because we are reading
> > probably
> > the same part of the manuals I would like to clear this point.
> 
> OK.
> 
> > What you are saying is not exactly what I read from the manual - I
> > checked it now in mx35, I will take a look also on the other ones.
> > 
> > In 7.4.1.6 NAND Flash Boot Operation, I read:
> > 
> > "1. On device power-on, the boot ROM copies the first 4 Kbytes of
> > boot
> > code from the NAND Flash to the NFC buffer."
> > 
> > So this correspond to your statement - and DCD tables go into NFC
> > buffer. DCD table must be smaller as 4KB, but this is always the
> > case.
> 
> Indeed.
> 
> > "2. ROM code checks the first 4 Kbytes of boot data copied in step
> > 1
> > above.
> > a) If no ECC error, then DCD is verified.
> > ? If DCD verification is successful, then the rest of the boot code
> > image is copied to destination RAM (internal RAM or SDRAM) and
> > secure
> > boot is performed."
> > 
> > I understand this part as the mx35 goes on to copy the whole image,
> > depending on the size set into the header, to the address specified
> > in
> > the table itself. There is no limitation. Exactly in the same way
> > it
> > works on i.MX5 (I know, this does not mean nothing, but..)
> > 
> > I think the limitation of 2KB or 4KB is not correct and is valid
> > only
> > for the DCD data. Do you agree ?
> 
> No, it's way more complicated than that.
> 
> First, there various boot modes available depending on the device for
> NAND:
> i.MX31: external only

Note that internal NAND Flash boot is also mentioned in the RM, but without
further details. FSL should be contacted to know more. But the RM refers to
secure boot and HAB, so it's probably something close to the internal boot modes
of i.MX25 and i.MX35. Anyway, it does not seem to be used by U-Boot i.MX31
boards.

> i.MX25 and i.MX35: internal or external
> i.MX51: internal only
> 
> External means that the NFC buffer is filled from NAND and executed
> without any
> DCD or flash header. The limit is 2 kiB on i.MX31. On i.MX25 and
> i.MX35, it is
> not clear from the RMs if only a single NF page is read, or if the
> NFC buffer is
> fully filled (4 kiB). This is the use case for mx31pdk and tx25.

The details about external NF boot are in the NFC chapter of the RMs. For
i.MX31, it's perfectly clear: The whole 2-kiB NFC buffer is filled whether the
NF pages are 512-B or 2-kiB. For i.MX25 and i.MX35, it's more difficult to find
the details, but I interpret the RMs as meaning that the whole 4-kiB NFC buffer
is filled whatever the NF page sizes. In both cases, the code is run from the
NFC buffer, so that the SPL size cannot exceed 2 kiB for mx31pdk, and 4 kiB for
tx25.

> Internal means that 4 kiB are read from NF. If this fails from the
> 1st block, it
> is retried with the 2nd block. If it fails again, boot is aborted. If
> it
> succeeds, DCD and Flash headers are checked and executed. The
> behavior of the
> ROM bootloader while loading the image indicated by the headers is
> not clear
> from the RMs in case of bad blocks, so I asked FSL support which told
> me that
> as soon as a bad block is found, the boot is aborted. This means that
> an SPL is
> required for NAND boot to be reliable, even with internal boot. This
> also means
> that this SPL can not be larger than a single block.

Best regards,
Beno?t