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.

CCS NANDWRITER

Other Parts Discussed in Thread: TMS320DM6446

Have a TMS320DM6446 prototype board.

 Currently have DVFlasher working and can boot up on hyperterminal to the boot prompt.

Have been unable to get CCS Nandwriter to work though.

Modified the code and it indicates that the ubl and u-boot write to NAND completes successfully.

But on reboot it hyperterminal just echoes "BOOTME BOOTME"

Below I have listed the tech info and mods that I have made.

Has anyone gotten CCS Nandwriter working for BBN?

                                                                                                    Jerry

 

The NAND flash on the board  is Micron Big Block NAND  MT29F1G08ABBHC(1Gb).

 

     Our total pages size is 2112, 2048 data with 64 bytes spare byte block size.

       I found technical note TN-29-16 which lays out the page-level boot code storage

 2kb page:   SectorA(512) Sector B(512) Sector C(512) Sector D(512) Spare (64

 Spare       BB Marking(1byte) Sector A ECC(3) Sector B ECC(3) Sector C ECC(3) Sector D ECC(4)

 Given the above I assume the following values we are to use in flash_util.

#define DEVICE_NAND_MAX_BYTES_PER_OP       (2048)   // Max Bytes per operation (EMIF IP constrained)

#define DEVICE_NAND_MAX_SPAREBYTES_PER_OP  (64)    // Max Spare Bytes per operation

#define DEVICE_NAND_MIN_SPAREBYTES_PER_OP  (16)    // Min Spare

#define NAND_MAX_PAGE_SIZE          (2112) 

#define DEVICE_NAND_ECC_START_OFFSET_LARGEPAGE (1)

const NAND_ECC_InfoObj DEVICE_NAND_ECC_info =

{

  TRUE,         // ECCEnable

  12,            // calcECCByteCnt

  12,            // storedECCByteCnt

  &(DEVICE_NAND_ECC_calculate),

  &(DEVICE_NAND_ECC_store),

  &(DEVICE_NAND_ECC_enable),

  &(DEVICE_NAND_ECC_disable),

  &(DEVICE_NAND_ECC_read),

  &(DEVICE_NAND_ECC_correct)

};

const NAND_PAGE_LayoutObj DEVICE_NAND_PAGE_layout =

{

  // Data region definition

  {

    NAND_REGION_DATA,                         // Region Type

    NAND_OFFSETS_RELTODATA,                   // Offsets relative type

    DEVICE_NAND_MAX_BYTES_PER_OP,      // bytesPerOp

    { 0*(2048) ,1*(2048) ,2*(2048) ,3*(2048) ,

      4*(2048) ,5*(2048) ,6*(2048) ,7*(2048) ,

      8*(2048) ,9*(2048) ,10*(2048),11*(2048),

      12*(2048),13*(2048),14*(2048),15*(2048) }

  },

 

  // Spare region definition

  {

    NAND_REGION_SPARE,                  // Region Type

    NAND_OFFSETS_RELTODATA,     // Offsets relative type

      DEVICE_NAND_MAX_SPAREBYTES_PER_OP, // bytesPerOp 

   { 1*2048+0*64  ,2*2048+1*64  ,3*2048+2*64  ,4*2048+3*64  ,      // spareOffsets

      5*2048+4*64  ,6*2048+5*64  ,7*2048+6*64  ,8*2048+7*64  ,

      9*2048+8*64  ,10*2048+9*64 ,11*2048+10*64,12*2048+11*64,

      13*2048+12*64,14*2048+13*64,15*2048+14*64,16*2048+15*64 }

  }

};

  • jalexander said:

    Currently have DVFlasher working and can boot up on hyperterminal to the boot prompt.

    Have been unable to get CCS Nandwriter to work though.

    While I do not know of any modified CCS flash burning utilities, I am somewhat curious why you would want a CCS NANDwriter when you have DVFlasher working? If DVFlasher is working from you and you have the source you may compare that to the CCS NANDwriter to see if there is anything that sticks out, perhaps modify the project to just read out the contents of the NAND and do a comparison of what your CCS writer is getting into NAND vs what DVFlasher gets into NAND.

  • To add to Bernie's great response, I just wanted to point out that the code for Nandwriter is very poorly written and much of the code is not even exercised; this is why we invested in DVFlasher utility as a better alternative reference code than Nandwriter.

  • Juan,

             Neal sent us the flash_utils and recommended using nandwriter.

            Our board has two DM6446's but uart  and network access is only available via jtag

            to the second one right now(serial/network access to the first host only)

            Another question.   What is the speed of the jtag download to NAND?

           We had wanted to flash the NAND with UBL/U-Boot/kernel/filesystem.

            We were assuming that jtag downloads  are much faster  than the kermit downloads.

             Neal had also told us that we could flash the kernel and filesystem via the nandwriter

             by modifying the code.

  • I was not aware that your uart was only accessible via JTAG; now it makes a bit more sense on why Neal recommended this approach.  Neal is correct that flashing all these software components via JTAG shoud be possible, but it will take some modification of nandwriter code.

    I am not too familiar with JTAG technology myself, but I believe the download speed is dependant on the JTAG emulator you use (there are high speed rtdx enabled JTAGs) and should be faster than the kermit downloads. 

    That said, BOOTME occur when the DM6446 cannot find a valid UBL and reverts back to UART boot mode (if not there already).  What boot mode is your hardware on (UART or NAND)?  If you are using JTAG, NAND boot mode would make sense to me, unless there is something special about your hardware.

    Also, with regards to BBN, RBL supports a given set of NAND devices outlined in the ARM Subsystem Guide (see page 134 on http://focus.ti.com/lit/ug/sprue14b/sprue14b.pdf ).  Even if you managed to get UBL, u-boot... written to your NAND device, if it is not in the list of supported devices by RBL, RBL may not be able to load UBL properly and hence you may not be able to boot. 

  • Juan,

     

                 Please note, that I am downloading  the same UBL as the one in DVFLasher and that works.

                 The board is in NAND mode.

                 Our NAND is in the list of supported devices and it is recognized.

                The rest of the code was pretty much hardcoded for small block.  I provided some of my changes in one of  the earlier

                correspondences.   These changes made it possible for the nandwriter to work.

                Given that the RBL is proprietary,  I am concerned that I am missing something that the RBL is expecting that I am not aware of.

     

     

  • That is great news, thank you for the feedback.  Let me see what I can do about getting you access to RBL code; please note that this will likely be for reference only as RBL cannot be changed once in the silicon.

  • jalexander said:
    What is the speed of the jtag download to NAND?

    As Juan mentioned this is really dependent on your emulation hardware, in general it will be much faster with XDS560 over XDS510, as the XDS560 can reach speeds upwards of 2Mbps. The XDS510 class is significantly slower though I don't have any benchmark handy, and the XDS100 is even slower than that. Usually we see customers using the DVFlasher based burning process if they can due to the cost of the emulation hardware and software, most any PC can be used to burn a board with DVFlasher but you need ~$5k of emulation hardware/software to do the same effectively with the JTAG solution, so for production DVFlasher allows you to have a large array of systems burning simultaneously cheaper. This being said, it would be unusual to see any volume production done with a JTAG based solution, the JTAG solution is generally only used in a lab environment, which is why I was initially suprised by your desire to use JTAG over DVFlasher.

  • jalexander,

    I spoke too soon when I offered to try to get you access to the RBL code; there appears to be legal issues with this.  The propoer path is to work with your local TI representative to see if he can make this happen (NDA required). 

  • Juan,

     

               What documentation can you supply that details what fields,location, cross talk etc.  the RBL is doing?

               Any detailed info would be appreciated.  

     

     

  • Juan,

     

              From what RBL documentation I have found,  the failure is probably being caused by RBL checking the ECC's and

             it is failing.    We are using MT29F1G08ABB NAND.  There is a TI Technical note TN-29-16,  which outlines the NAND

             ECC layout  which I am have defined.

                                                                                                                                                             Jerry

  • Jerry,

    have you seen this post: http://e2e.ti.com/forums/p/3736/21010.aspx#21010

    It explainshow another of our customers resolved their ECC issue.  In addition, the ARM Subsystem Guide ( http://focus.ti.com/lit/ug/sprue14b/sprue14b.pdf ) has information in DM644x boot process; but I suspect you have already seen this.

  • Yes.  Looks like what I need.  Will let you know.