[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 12:15, Beno?t Th?baudeau wrote:
> > Then, I don't know what to do with these patches.
> 
> I see two main points in your patches. You cleanup mxc-nand code and
> add
> support for i.MX5. This is one topic, and it can go on.

OK, but then do you want to keep the register definitions inside mxc_nand?

> > Note that this is not a new implementation, but only an enhancement
> > of the
> > existing one. But I understand your point.
> 
> ;-)
> 
> > 
> > I don't see any i.MX board using the general SPL for NAND.
> 
> At least the MX28, and using nand_spl with MX28 was rejected for the
> same reason when it was pushed. Then it was switched to SPL.

OK. But I meant MXC. MXS does not use the same NAND driver.

> But surely it should be better to have more examples - I am working
> to
> get a MX35 booting from external SD, and using the SPL.

Great! Having mxc_nand examples would be great too.

> > So we can't say that
> > it's usable with the current mtd mxc_nand driver in its current
> > state. Moreover,
> > with the general SPL, I'd be very concerned as to the code size of
> > mxc_nand (the
> > target size of the whole SPL code is only 2 kiB for current i.MX
> > users of
> > nand_spl).
> 
> Mainly because the restriction came from the original implementation,
> that was for PowerPC 4xx with only a small buffer (NFC buffer) to
> copy
> data from NAND.
> 
> 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).

> IMHO the fact that only two IMX boards are using this mechanism
> (nand_spl) is also due the fact that is not very flexible. And moving
> to
> SPL we are not fixed to boot exclusively from NAND,

Sure.

> > IMHO, we could improve and fix the nand_spl code while it's still
> > there and
> > used.
> 
> However, as you say, if the code is still available, this makes
> people
> think that is the correct way to do and we will have two distinct
> implementation (the old one and the new one), both to be supported.

Right.

> Not to forget that the SPL is thought to work with different SOCs,
> even
> if currently it is mainly used by TI, and with different media
> storage.
> All features taht we discussed previously in the ML if we had to add
> them to nand_spl, before the new implementation was pushed.

OK.

> > This does not prevent from moving to the general SPL once ready for
> > mxc_nand. These are two different topics.
> 
> The fact is it will be nice if also the two supported boards will
> move
> to SPL.

Sure, but I don't have time to do that.

> Of couse, we cannot break these boards,

They're already broken with the current nand_spl. See my 07/13.

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

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.

Best regards,
Beno?t