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