This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3352 ROM code boot from NAND device with OOB of 112

Other Parts Discussed in Thread: AM3352

I'm in the process of bringing up a new board based on the AM3352, it has a Macronix 2Gb NAND device (PN MX30LF2G28AB) The interesting thing about this part is that has a page size of 2048 and OOB of 112. 

I believe that I've properly modified SPL, u-boot, and Linux to deal with this unusual OOB size. 

I have configured sysboot 4:0  to 10011, i.e. 1st boot device NAND, last boot device UART. I have checked STATUS_CONTROL register to confirm that the processor is reading the sysboot pins correctly. 

I've booted from UART and written the MLO and u-boot.img files to NAND, further more I have read the MLO sector back from NAND and verified that it matches the MLO file. 

However the board will not boot from NAND, it always go to the UART boot. 

I noticed on pg4683 of the TRM under Features it states:

Support for large page size (2048 bytes + 64 spare bytes) or very large page size 4096 bytes + 128 /
218 spare bytes)

So I'm wondering if the boot ROM code only supports OOB sizes of 64 for devices with pages sizes of 2048 and therefore this NAND device will not work? 
Or if this is not the problem what else might be wrong? 

Thanks,
Matt S. 

 

  • Hi Matthew,

    Quoting from an e-mail exchange some time ago:

    "Based on the number of spare bytes per page, the ROM boot loader will try to use the largest ECC algorithm that it can. So for NAND flash memories with 64 bytes per page, the ROM boot loader will assume BCH8 as the ECC algorithm. When we have 112 spare bytes per page, the ROM boot loader assumes that the ECC algorithm should be BCH16.  Since we are using BCH8 during the flashing process, the ECC data in the spare memory is thus incorrect, and this is why the ROM boot loader is failing to boot."

    Hope this helps.

  • Hi Biser, 

    Thank you for the quick response. I hope that wasn't a e-mail exchange with me because I don't remember seeing it. I did post a slightly different question about this NAND a few weeks ago and you're response was that "NAND should just work" http://e2e.ti.com/support/arm/sitara_arm/f/791/t/376001.aspx. 

    I'd like to be clear on what this means,  does this mean that this NAND won't work with the AM335x or that further modifications SPL, U-Boot, and linux will be required? I'm really not all that familiar with ECC and the BCH algorithms so I do need some advice. 

    We intend to run Linux on this board and use a ubi file system so I want to make sure that there is enough OOB for the ECC and anything required by the file system, etc. 

    Thank you,
    Matt S. 

  • No, this was taken from a similar issue with a customer, where e-mails were exchanged internally. Further info from this exchange:

    "Since we are using BCH8 during the flashing process, the ECC data in the spare memory is thus incorrect, and this is why the ROM boot loader is failing to boot.

    The problem we have is that this would mean that we need to keep track of two different ECC calculations in order to double source with NAND flash memories that have a different number of spare bytes per page.  My customer does not want to maintain this, so they have decided to only use NAND flash memories with 64 spare bytes per page, so that the ECC algorithm will always be BCH8 when programming the NAND flash memory."

    The other approach will be to enable BCH16 for SPL, u-boot and kernel. See this wiki for BCH16 support in SDK 7.0.

  • Hi Biser, 

    Did you intend include a link to the wiki on BCH16 support in SDK 7.0? 

    Thanks, 
    Matt S.