• State
  • Locked Locked
  • Replies 19 replies
  • Subscribers 104 subscribers
  • Views 1675 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

dm365 u-boot questions (rebuilding then reflashing from within u-boot)

Craig Smith
Intellectual 810 points

Hello, I have a few questions regarding u-boot and the dm365 EVM:

1) Rebuilding u-boot from the source provided with PSP_02_10_00_14/board_utilities/u-boot.tar.gz does not yield the same size binary file as what is included in PSP_02_10_00_14/bin/dm365, which is 152328 bytes:

ls -l
total 2888
-rwxr-xr-x 1 csmith git  340827 Jul 14 11:15 NANDEraser_DM36x.out
-rwxr-xr-x 1 csmith git  361943 Jul 14 11:15 NANDWriter_DM36x.out
-rwxr-xr-x 1 csmith git   20480 Jul 14 11:15 UBL_DM36x_NAND.bin
-rwxr-xr-x 1 csmith git     359 Jul 14 11:15 readme.txt
-rwxr-xr-x 1 csmith git  152328 Jul 14 11:15 u-boot-1.3.4-dm365_evm.bin
-rwxr-xr-x 1 csmith git 2049992 Jul 14 11:15 uImage-dm365
csmith@ucme:~/GitWham/master/WhamCamAlphaSoftware/3rdParty/TI/dvsdk_2_10_00_17/PSP_02_10_00_14/bin/dm365$

The binary file generated from the above source is 150504 bytes (compiled with no errors simply by typing "make davinci_dm365_evm_config", then "make").

-rwxr-xr-x   1 csmith git  150504 Sep 10 11:00 u-boot-1.3.4-dm365_evm.bin

Question(s): Why are the 2 files different sizes? Is the source provided really the same source used to build the binary file provided? Has anyone used the "smaller" binary file and found it to work?

2) I believe it should be possible to re-flash the u-boot binary w/out XDS/JTAG using the "nand" commands from a running u-boot. Has anyone every tried this?

Is it just a matter of erasing and rewriting the u-boot .bin file at address 0x0? For example, I am considering the following procedure:

1. Boot board, stop at u-boot prompt

2. Load new u-boot .bin file into RAM via tftp
tftp 0x80700000 u-boot-1.3.4-dm365_evm.bin

3. Erase the u-boot partition
nand erase 0x0 0x30000

4. write the new image
nand write 0x80700000 0x0 0x30000

5. Pray that your board boots again

Question: Does anyone see a problem with this procedure?

Thanks for any help,

-Craig

 

  • 0
    Intellectual 810 points

    I just wanted to add one more quick question. When building u-boot I see the following warning for almost every file. Is this normal?

    warning: target CPU does not support interworking

    UPDATE: OK, I found a solution to this....just add the following line to cpu/arm926ejs/config.mk

    PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,)

    I still wonder if the source is the same that was used to build the binary image included with the PSP.

  • 0
    Expert 1780 points

    Hi Craig,

    the procedure is incorrect:

    1) Blocks 1-24 are reserved for UBL descriptor (and, depending on how your flash is organized, UBL code. But it can also be in another place on flash). So don't erase them if you don't know how to restore them.

    2) The actual position of U-Boot on the flash is not 0, but depends on how your UBL works. TI's one looks for U-Boot descriptor on blocks 25-50: the actual U-Boot code position is written in that descriptor. Other first stage bootloaders can work in another way. Even knowing you are using UBL, the actual U-Boot code position depends on bad blocks on your flash.

    So, basically, boot is a 2 stage process (UBL + U-Boot). Details of boot depend on your UBL, flash organization and bad blocks.

    Rewriting U-Boot should involve rewriting its descriptor, since several details can require it (i.e. the image size has increased or moved, bad blocks are encountered, etc). You can try to preserve previous descriptor and simply overwrite the U-boot image, but you must know where previous image is actually placed on the flash. Also if the number of flash pages used is increased, this will not work.

    So, to put it simple, U-Boot can't easily update itself. If you know how to do it, you can still try, but you must be very careful of details.

    Erasing 0x30000 bytes from address 0 of flash will most probably cause your board not to boot anymore, so don't do this unless you have a JTAG cable ready.

     

  • 0 in reply to Marco Braga
    Intellectual 810 points

    Thanks Marco, this is what I suspected.

     

    Question for TI folks: What about a UART based UBL/u-boot flash programmer for dm365 (similar to other Davinci chips)? Was this ever developed? If not, will it be (and when)?

    Thanks again.

    -Craig

  • 0 in reply to Craig Smith
    TI__Mastermind 41665 points

    CraigSmith said:
    Question for TI folks: What about a UART based UBL/u-boot flash programmer for dm365 (similar to other Davinci chips)? Was this ever developed? If not, will it be (and when)?

    Unfortunately this may not be available soon as it will likely require a silicon rev to fix, as there is an errata with the ROM boot loader on DM365 that prevents the UART boot mode from operating at a standard baud rate, so when you go to talk to the board over the serial port to boot instead of seeing "BOOTME BOOTME ..." you see "P?tig) P?tig) ..." or "'PÔtig) 'PÔtig) ...". Since most terminals do not necessarily operate outside of standard baud rates there has been no serial booting utility for the DM365, if/when this errata is fixed in a future silicon revision the serial boot utilities should work for it.

  • 0 in reply to Bernie Thompson TI
    Intellectual 810 points

    OK, thanks Bernie. We are going to go ahead an order an XDS510 from Spectrum Digital. Can you confirm that the XDS510 USB PLUS ($1495) is the correct model to purchase for the dm365? (you may remember we did not have any success with the device we bought from Wintech, so I don't want to make the mistake again)? There is another model (without the "PLUS") for $989, but I'm not sure about the difference.

    Thanks.

  • 0 in reply to Craig Smith
    TI__Mastermind 41665 points

    I suspect both would work, I have never used a USB PLUS myself, I think the difference has to do with supporting some other ARM debug modes but I have not really looked into it much, all the SD XDS510 USB emulators I have around here are the standard old model, including the one I used on your board a while back. To be specific, this is the model I use when I need to emulate on the go, so unless you find a good reason to get the PLUS, I would save the $500.

  • 0 in reply to Bernie Thompson TI
    Intellectual 810 points

    Yes, this model works just fine.


    So, now I still have the same question as above. The tried the u-boot binary compiled from the source included with the PSP and it does not boot. As I mentioned above the size is considerably smaller than the binary file provided (which does work).

    Is this the correct procedure to re-build u-boot from the source?

    make davinci_dm365_evm_config

    make all

    If so, then why is the resulting binary so much smaller (and why does it not work)?

     

    Regards,

    -Craig

  • 0 in reply to Craig Smith
    Intellectual 305 points

    I have a related question and possibly an answer.

    I am building the same uboot as specified above.  I am usein the BlackHawk 560 to load u-boot rather than u-boot-1.3.4-dm365_evm.bin.  When I run it the ethernet initialiation fails.  The version I still have in flash works though.  Any ideas why the flash version works with ethernet while the built version does not?  See the console logs below

    ==================  Flash Version =========================

    U-Boot 1.3.4 (Mar  2 2009 - 11:50:39)

     

    I2C:   ready

    DRAM:  128 MB

    NAND:  NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)

    Bad block table not found for chip 0

    Bad block table not found for chip 0

    Bad block table written to 0x3ffe0000, version 0x01

    Bad block table written to 0x3ffc0000, version 0x01

    NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)

    Bad block table not found for chip 0

    Bad block table not found for chip 0

    Bad block table written to 0x3ffe0000, version 0x01

    Bad block table written to 0x3ffc0000, version 0x01

    2048 MiB

    In:    serial

    Out:   serial

    Err:   serial

    Ethernet PHY: GENERIC @ 0x00

    Hit any key to stop autoboot:  0

    ==================  My built version running from JTAG =========================

    U-Boot 1.3.4 (Sep 16 2009 - 09:11:52)

    I2C:   ready

    DRAM:  128 MB

    NAND:  NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)

    Bad block table found at page 524224, version 0x01

    Bad block table found at page 524160, version 0x01

    NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)

    Bad block table found at page 524224, version 0x01

    Bad block table found at page 524160, version 0x01

    2048 MiB

    In:    serial

    Out:   serial

    Err:   serial

    ethernet init failed!

    Hit any key to stop autoboot:  0

  • 0 in reply to Keith13636
    TI__Mastermind 37340 points

    keith36119 said:

    I am building the same uboot as specified above.  I am usein the BlackHawk 560 to load u-boot rather than u-boot-1.3.4-dm365_evm.bin.  When I run it the ethernet initialiation fails.  The version I still have in flash works though.  Any ideas why the flash version works with ethernet while the built version does not?  

    Did you try bulding with the options Keith suggested above?

       PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,)

    I am also looking into this internally

  • 0 in reply to Juan Gonzales
    Intellectual 810 points

    Just to be clear.....I tried building with that "no-thumb-interwork" option, I'm not sure if Keith did.

    The build I tried did not print anything to the console. I have not tried debugging this yet, I just expected it to work (even though I suspected it wouldn't because of the file size difference).

  • 0 in reply to Juan Gonzales
    Intellectual 305 points

    I hadn't tried PLATFORM_CPPFLAGS +=$(call cc-option,-mno-thumb-interwork,) before but I just tried them with no difference.  I figured out how to make it work though.

    1. Atl-c to disconnect the jtag

    2. power cycle the evm

    3. alt-c to connect the evm before the resident u-boot initializes the ethenet.  If I am not  fast enough I have the same problem.  Not only that, but if I have my boot options such that it tries to use the ethernet such as TFTP then the ethernet initializatioin will cause a processor reset.

    4. My problem seemed to be that u-boot requires the ethernet hardware to be in the default power on state during initialition.

    It would be nice if the GEL file and/or the hardware initialiation could handle it.  But I have a work around for now.

    FYI my build steps each time were 

    make distclean

     

    This generate the error "gcc: Command not found"

     

    make distclean

    the second time I get no errors

    make davinci_dm365_evm_config 

    make ARCH=arm CROSS_COMPILE=arm_v5t_le-

     

    cp u-boot uboot.out 
    Then I load in uboot.out with CCS using evmdm365.gel

     

  • 0 in reply to Craig Smith
    Expert 2995 points

    Craig Smith said:
    What about a UART based UBL/u-boot flash programmer for dm365 (similar to other Davinci chips)? Was this ever developed? If not, will it be (and when)?

    Here is SD card flash programmer for dm365.

  • 0 in reply to Keith13636
    Intellectual 305 points

    I erased my flash so that I wouldn't have to hit alt-c so fast to catch u-boot before teh ethernet init.  Now my unit is dead.  

    I get nothing from the console any more and the new U-boot seems to be running based on the break points and my ability to single step.  But nothing comes out the console any more.

  • 0 in reply to Keith13636
    Expert 2995 points

    keith36119 said:

    I erased my flash so that I wouldn't have to hit alt-c so fast to catch u-boot before teh ethernet init.  Now my unit is dead.  

    I get nothing from the console any more and the new U-boot seems to be running based on the break points and my ability to single step.  But nothing comes out the console any more.

    1. Try to switch to another boot mode and catch RBL with debugger

    2. Try this http://e2e.ti.com/forums/t/10032.aspx

  • 0 in reply to Constantine
    Intellectual 305 points

    I just restored my board with UBL and my new u-boot that I built.   have a black hawk 560 jtag and I followed the instructions in dvsdk_2_10_01_18/PSP_02_10_00_14/docs/DM365-installation.doc.  It took a while for me to get all the updates straight.  But after that it worked like a charm.

    I think that u-boot depends on UBL initializing certain hardware before it runs.  I am assuming this because once I flashed in the new u-boot along with the factory supplied UBL_DM36x_NAND.bin my u-boot ran fine.

  • 0 in reply to Keith13636
    Intellectual 810 points

    Keith, can you tell me to size of the resulting u-boot.bin file you built from the source at dvsdk_2_10_00_17/PSP_02_10_00_14/board_utilities/u-boot.tar.gz?

    This is what I built (that doesn't seem to work):

    -rwxr-xr-x   1 csmith git  150504 Sep 10 11:00 u-boot-1.3.4-dm365_evm.bin

    Thanks.

  • 0 in reply to Craig Smith
    Intellectual 305 points

    I have added a little code mainly printfs of my own so mine is slightly bigger.  So for a test I reverted my changes and built it.  I got the same size as you.

    -rwxr-xr-x   1 keith keith  150504 2009-09-18 07:40 u-boot-1.3.4-dm365_evm.bin

    I keep my notes so others in my team could do it also.  This is mostly a copy if TI notes but in case it helps here they are:
    This is modified from /home/keith/dvsdk_2_10_01_18/PSP_02_10_00_14/docs/DM365-installation.doc
    It uses files in /home/keith/dvsdk_2_10_01_18/PSP_02_10_00_14/board_utilities/flash_utils/DM36x/CCS
    First install the updates for ccs including:
       SR12_CCS_v3.3_SR_3.3.82.13.exe   // CCS updates. Without this update you can't load the Black Hawk drivers for the DM365EVM
       BHEMU-SetupCCS_v3.3.300.2.zip    // Black hawk driver for the DM365EVM
       ti_cgt_tms470_4.6.0_setup_win32.exe // Code generation for the arm processor
       // Remember to go into help about on code composer studio and select component manager.
       // Then select the latest components that you just installed !!!!   Very important !!!!
    1. System Requirements:
       Code Composer Studio 3.3.38
       dvsdk_2_10_01_18
       PSP_02_10_00_14
    2. Use the following Configuration and gel file to set up CCS
       evmdm365.gel   // This is the latest version from spectrum digitals website
    3. Jumper and/or Switch settings 
       SW4: in NAND mode 000000
       SW5: should be 000110 if REV B EVM is used or 000010 if REV EVM is used
    4. Connect the XDS560 to the TI JTAG 
       I use the 16 pin connector not the 20.  This also coresponds to ARM9_0 on the Parallel Debug Manager
    5. Setup CCS 3.3 with the CCS configuration and GEL files corresponding to the DM365 EVM 
    6. Open CCS 3.3, Alt+C to connect to the device. Ctrl+R to reset from CCS 
    7. If the EVM has been loaded with older flash utilties then  run the NAND eraser binary that is now supplied as part of the release. 
       This is essential if the EVM has been flashed with utilities from older LSP 2.10 releases. This is done so that the entire NAND 
       is erased and we want the Bad Block Tables to be re written.
    8. Load the NANDEraser_DM36x.out from the release and run it (Press F5). 
       The eraser will ask for an input. Input "0x02000000". 
       Run the eraser again. This time input "0x02004000". 
    9. Load the NAND programmer. Choose NANDWriter_DM36x.out for NAND mode from the release and run it (F5). 
    10. The NAND programmer will ask for input for the UBL binary. Choose the UBL_DM36x_NAND.bin  file from the release 
    11. NAND programmer will then ask for the U-Boot binary. Choose the u-boot-1.3.4-dm365_evm.bin. 
        Set 0x81080000 for the Application Entry Point and 
        set 0x81080000 for the Application Load Address 
    12. Disconnect the CCS from the device then turn off the board.
    13. Connect the RS232 cable between your PC and EVM.
        Run Teraterm at 115200,8,N,1
        Power on the DM365EVM 
    14. You will see console messages, UBL identifying the U-Boot magic number and giving control to U-Boot 1.3.4 with todays build date.
    Good luck

  • 0 in reply to Keith13636
    Intellectual 810 points

    I will try it after a full erase and see if it works.  Thanks for confirming the size, so as least now I believe it should work.

  • 0 in reply to Craig Smith
    Intellectual 810 points

    Success! (problem was probably not running the erase tool first).  I tried a subsequent update with u-boot only (entering 'none' for UBL) and it also worked.  Thanks again.