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