• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 99 subscribers
  • Views 859 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RBL/UBL & U-Boot interoperability problem when reprogramming in large (4K page) flash

Jay Leslie
Prodigy 60 points
Other Parts Discussed in Thread: CCSTUDIO

I'm working on a 6446-based system, and I have a requirement to be able to reprogram all software on it.  I developed a reprogramming capability as an extension to U-Boot, which worked fine on our preproduction boards populated with 2K page flash.  Production boards' page size is 4K, and that broke the reprogrammer.  When I load UBL & U-Boot via UART, UBL writes the program data, 2K + ECC codes per each 4K page.  The ECC codes appear just behind the program data and the remaining 2K and OOB never get touched.  This arrangement boots up fine (though it was hard to figure out how, exactly).  However, my reprogrammer shares U-Boot's "architecturally correct" view of flash and it will fill the entire 4K page with data, and ECC codes end up in OOB.  So now neither RBL or UBL can access these regions.  My conclusion is that I will have to somehow fake U-Boot out (only when reprogramming itself or UBL) to treat the flash as a 2K per page part.  Any suggestions for a quick, direct way to do this?  Thanks!

  • 0
    TI__Guru* 84110 points

    I don't know of any limitation that would prevent you from using a 4K page size NAND. It sounds like you may have a mismatch in the page size in your programmer.  One place to start would be here: http://wiki.davincidsp.com/index.php/Serial_Boot_and_Flash_Loading_Utility .

    You might try using this utility and then modify the source to accommodate your flash type and page size.

  • 0 in reply to RandyP
    Prodigy 60 points

    Thanks for your reply, RandyP.  Since I've posted this, I have learned that U-Boot patches have been released to correct problems with 4K page flash as well as ECC syndromes.  I'm trying to figure out the best way to bring the files (and all the files they depend on!) into our project without turning the world upside down.  But you're right, there is a mismatch.  I'm going to try modifying UBL to use a different page size, and see if it will generate the additional syndromes to do ECC for the larger page.  I'll try the sfh code; hopefully it's easier than doing the DVFlasher thing.

    Cheerio...

  • 0 in reply to Jay Leslie
    Prodigy 60 points

    In attempting to use the sfh/sfl tools, I downloaded and attempted to build.  The makefile is attempting to invoke "timake".  Where, oh where might I find that?  I confess that I was not surprised that it was not included in the distribution or readme files...

    Sigh.

  • 0 in reply to Jay Leslie
    TI__Guru* 84110 points

    Look for timake in your cc/bin folder for CCS 3.3. I have a copy of it in my CCS 3.3 and 3.1 and 2.21 cc/bin folders, so it has been around for a while. It probably is part of the CCS installation, either that or the CodeGen tools installation, but my guess is CCS.

  • 0 in reply to RandyP
    TI__Guru* 84110 points

    There may be a problem with the NAND IDs that are supported by the DM6446 RBL. In the ARM SS Reference Guide SPRUE14 on page 134, Table 12-5 lists the supported NAND Device IDs and their characteristics.

    Unfortunately, the block sizes for the supported IDs only go up to 2K+64.

    What other choices can be made on your NAND device?

  • 0 in reply to RandyP
    TI__Guru* 84110 points

    There is a chance that a ROM code change could add support for larger NAND page sizes. I do not have a date for that, but would like to check for you if a fix would be possible for your case.

    What is the Device ID for the NAND you are using today?

  • 0 in reply to RandyP
    Prodigy 60 points

    ROM code is truly that, right?  Masked ROM, unalterable by customer, manufacturer, or supreme deity; so this would be a die revision, yes?  Is this ROM code change in-work, officially planned, merely under discussion, something less substantive?

    Our current NAND is MT29F1608DAAWP.  However, this part is being obsoleted by Micron, and our replacement was MT29F16G08ABABAWP.

    However, it was discovered that there is an issue with this part, so I believe the long term solution will be a member of that family, perhaps the

    MT 29F16G08A

     

    EABAWP IT:B

    Thanks for your help!

  • 0 in reply to Jay Leslie
    Intellectual 885 points

    I also had the same problem, "make: timake: Command not found", when trying to build the UBL from DM646x_FlashAndBootUtils_1_50 in the cygwin environment.  timake is in the folder C:\CCStudio_v3.3\cc\bin.  I added it to the Windows Path environment variable, restarted cygwin, and then it built successfully.