On 15/08/2012 20:11, Benoît Thébaudeau wrote:
Hi Stefano,
Hi Benoît,
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
Note that internal NAND Flash boot is also mentioned in the RM, but without further details.
I know - thanks for sharing your information.
FSL should be contacted to know more. But the RM refers to secure boot and HAB, so it's probably something close to the internal boot modes of i.MX25 and i.MX35. Anyway, it does not seem to be used by U-Boot i.MX31 boards.
I have the same feeling.
The details about external NF boot are in the NFC chapter of the RMs. For i.MX31, it's perfectly clear: The whole 2-kiB NFC buffer is filled whether the NF pages are 512-B or 2-kiB. For i.MX25 and i.MX35, it's more difficult to find the details, but I interpret the RMs as meaning that the whole 4-kiB NFC buffer is filled whatever the NF page sizes. In both cases, the code is run from the NFC buffer, so that the SPL size cannot exceed 2 kiB for mx31pdk, and 4 kiB for tx25.
I have the same interpretation - for this reason it was interesting for me to understand the behavior with internal boot, where I can set the size of the whole image in the imx header.
However, if the boot stops after a bad block is found instead of skipping it and reading the next one, it seems to me that this feature cannot be really used. It will be also interesting to know if the behavior is the same also for the newer i.MX, I mean MX5 and MX6.
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.
The other way that a project can take is to use SLC NAND (or in any case, NAND where is guaranted that the first sector cannot be bad). A hard limitation, anyway.
Best regards, Stefano