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

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

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
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.

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.

> >> Of couse, we cannot break these boards,
> > 
> > They're already broken with the current nand_spl. See my 07/13.
> > 
> 
> Mmmhh...a bug is a bug, and should be fixed, I agree with you on this
> point.

OK.

> >> but a move will be
> >> more
> >> difficult if we increase the number of boards using nand_spl.
> > 
> > Sure, but my series does not add new boards.
> 
> Right. Maybe I was expecting a new patch series from you adding a new
> board, because I thought you have a "use case" for i.MX5,  (that
> means,
> support for NAND in i.MX5). In other words, a new board based on
> nand_spl will be not accepted.

I indeed have such boards supported locally, but they are not yet ready for
upstream, and I did not intend to post patches for them before the other i.MX
nand_spl boards have moved to generic SPL.

> But again, fixing current issues is another thing. I will go on on to
> review the rest of patches (I admit I skip the rest of nand_spl
> related
> patches).

OK.

> > Just tell me what to do. I don't have time to port nand_spl boards
> > to general
> > SPL. The only thing I may find time for is to refactor the series
> > in an
> > acceptable way for you.
> 
> You convinced me that you are fixing current issues in already
> supported
> boards - then it is fine with me to go on with this patchset.

Great.

Best regards,
Beno?t