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

[Stefano Babic <sbabic@denx.de>]

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.

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.

"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 ?

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

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

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

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

Best regards,
Stefano


-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================