DM355 - Nand configuration for serial flasher

Richard,

Can you please provide the error logs? What changes were introduced in the files listed?

UBLStartAddr need to be changed if the start address of the UBL changes (same applies for APPStartAddr ). It has nothing to do with NAND size.

Thanks,
Gaurav

Hi Gaurav,

Thank you for your answer.

The errors and the debug messages are put in the file " error.txt "

For the modifications and the changes,  look rather files "device_nand.c ", " device_nand.h", " nand.c " and nand.h ". The changes are there very visibles.

We also have difficulty in finding the following informations for our NAND:

                                                                                                              - NAND_MAX_PAGE_SIZE

                                                                                                              - NAND_MAX_BYTES_PER_OP         

                                                                                                              - NAND_MIN_SPAREBYTES_PER_OP

Are they parameters fixed by the EMIF interface?

In the end, we want to flash NAND the reference of which is given to the previous post.

Thank you still for your help.

Kind regards,

Richard & Sakho

Richard & Sakho,

Thanks for sending the error log.

NAND_MAX_PAGE_SIZE, NAND_MAX_BYTES_PER_OP  and NAND_MIN_SPAREBYTES_PER_OP are generic information used by the code and should be fine w.r.t the NAND in question.

Can you please specify which silicon Revision are you using?

The NAND in question has to be supported by the RBL (ROM bootloader) for boot to happen. That depends on the silicon version.

Also the device ID for this NAND (0xD3) is present in DEVICE_NAND_CHIP_infoTable table (device_nand.c). However the page size is defined as 2048 + 64. The actual page size seems to be 4096 + 128 (from NAND datasheet). However given that the NAND is ONFI, the UBL should be able to talk to the NAND. You might have to introduce debug statements to see where is the problem.

Thanks,
Gaurav

Dear Gaurav,

Thank you for the reply.

The exact part number is :

MT29F8G08AAAWP-ET:A

Can you please confirm that this NAND is OK ?

Thanks a lot

Regard

Richard

Richard,

I meant the silicon revision/part no for DM355. I apologize for the confusion.

Thanks,
Gaurav

Gaurav,

Thank you for your answer.

The reference completes of the DM355 which I use is the following one:  TMS320DM355ZCE 216 $4A-9BA7R7W EI

It is all that we have on this chip, and I hope that can help.

Otherwise I manage to read all the parameters of the NAND. The writing and the erasing are well made. And thus, the UBL indeed spells at the good address.

The problem remains to write U-boot on the NAND. During this writing I have only bad block:

        ........................................................................................................

     Block number 22 is a BAD BLOCKBlock 22 is a bad block
     Block number 23 is a BAD BLOCKBlock 23 is a bad block
     Block number 24 is a BAD BLOCKBlock 24 is a bad block
     Block number 25 is a BAD BLOCKBlock 25 is a bad block
     Block number 26 is a BAD BLOCKBlock 26 is a bad block
    .........................................................................................................

Then, which would raise problem according to you? Should the function  "DEVICE_NAND_BB_checkSpareBytes()" or "DEVICE_NAND_BB_markSpareBytes()" and the structures "NAND_ECC_InfoObj DEVICE_NAND_ECC_info{}" or "NAND_BB_InfoObj DEVICE_NAND_BB_info{}" not be adapted to our NAND?

U-boot, would it proceed in a different way to detect Bad block?  Have you an idea for the origin of this problem?

Once again, thank you.

Richard & Sakho

Richard and Sakho,

Thanks for the information. The device that you have is Rev 1.1 (you can find this information on the Silicon Errata Sec 1.2)

DEVICE_NAND_BB_checkSpareBytes()", "DEVICE_NAND_BB_markSpareBytes()" and the structures "NAND_ECC_InfoObj DEVICE_NAND_ECC_info{}" or "NAND_BB_InfoObj DEVICE_NAND_BB_info{}" are generic function and structures and uses parameters for different NANDs.

If the NAND doesn't have actual bad blocks, then the NAND geometry information that UBL has is not correct.

The UBL uses atleast the following information about the NAND:
1. Page size
2. Pages per block
3. Address cycles

Can you please print this information from the UBL and see if this is matching the NAND information (from the NAND datasheet).

As I mentioned in the previous post, for this NAND, if the device is is 0xD3 (please check from the NAND datasheet), then the entry in the table DEVICE_NAND_CHIP_infoTable should be updated from:

  { 0xD3,   4096,       64,             2048+64}

to

  { 0xD3,   4096,       64,             4096+128}

Let me know how it goes.

Thanks,
Gaurav

Sakho,

The silicon version no of the device is required to figure out the features supported in RBL (ROM bootloader). This in turns determine if a particular NAND is compatible with that version of RBL.

If the NAND is not compatible, RBL will not be able to load UBL.

From the description given, the silicon revision is 1.1 and this RBL might not work with the NAND in question. In this case the NAND page size is 4K but the RBL will read 2K.
One possible workaround is to flash multiple version of header descriptor. A similar issue is discussed at the forum post:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/48003/169881.aspx#169881

There are later versions of the DM355. Can you please suggest is there is any specific reason why you are using an earlier version?

Thanks,
Gaurav

Dear Gaurav,

Thank you for the reply.

We bought the DM355 parts from DIGIKEY for our prototypes and unfortunatly the revision was not specified on it :(

I just hope that the workaround you suggested works otherwise I will have to get new prototypes to have this fixed...

If you have any other documentation regarding this workaround, can you please post it here ?

Thanks a lot again for your help !

Richard