I am using Code Composer Studio and a Blackhawk JTAG pod to burn U-Boot to Flash memory on my DaVinci-based board. I'm using the flash writer CCS application supplied by TI for programming the EVM, modified to recognize the Flash chip/manufacturer that I'm using. Furthermore, I have modified U-Boot to make use of the correct DDR memory timings for my board. After burning U-Boot in flash, I can use Code Composer and my JTAG pod to set the DaVinci's program counter to 0x02000000 (the beginning of Flash memory), begin execution, and watch U-Boot messages come out of the UART. If I turn off the power, disconnect my JTAG pod and power on the board (with BTSEL pins configured to boot from NOR flash: BTSEL1=0, BTSEL0=1) nothing happens.
I have previously tried to use TI's DVFlasher utility although I had to modify it to recognize my flash chip and deal with a bottom-boot flash device. However the programming sequence either experiences a write timeout or gets stuck in an infinite loop. It seems to happen around the same address every time.
If U-Boot runs when I tell the chip to start execution at 0x02000000 in CCS, shouldn't it also run when I power on the board without JTAG?
Thanks.
I assume by DaVinci EVM, you mean DM644X EVM (DaVinci represents family of processors: DM355, DM644X, DM6467, DM643X...).
If so, can you confirm the CS2 jumper is set to FLASH and S3 settings are 1011111110 (1=ON, 0=OFF). If the switch settings are correct, as soon as you power on the board (with, or without JTAG), you should see u-boot messages.
Yes, I meant the DM644X EVM, but I don't think I was clear enough in my explaination.
I'm trying to do this on my own custom board, NOT the EVM. I meant that I'm using the tools supplied to program U-Boot onto the EVM to program U-Boot onto my custom hardware.
2 things to consider.
1) Read BOOTCFG register to determine BTSEL settings at reset, just to make sure you are really in NOR boot mode.
2) When you are connecting with CCS, are you using a GEL file (often changes hardware state)? If so, try running without the GEL file and see if you can still get CCS to work.
What address is the BOOTCFG register at?
The datasheet for TMS320DM6446 states that it is at 0x01C4 000A (section 3.3.1.1) while the "TMS320DM644x DMSoC ARM Subsystem Reference Guide" (SPRUE14A) indicates that BOOTCFG should be at 0x01C40014 (section 10.9). If the datasheet is right, then my BOOTCFG values are incorrect. If the ARM Subsystem Reference Guide is right, then my values are OK.
0x01C40014 is correct. Actually, this value is also found in table 3-1 on the data-sheet; you seemed to have found a typo in section 3.3.1.1 of the data-sheet. I will make sure this gets corrected.
Did you check the GEL file?
Since your BOOTCFG register is correct, that indicates that your boot mode is being latched in properly, so the only obvious point that could be causing this is the GEL file, as the only difference between running the code out of flash directly with this boot mode and setting the PC to the beginning of the flash with CCS is the GEL file. I would guess that if you have a GEL file it is doing some configuration that is allowing the binary to run properly (power up, clocks, DDR, EMIF, etc). If you are already running without a GEL file than I am not sure what the problem could be, it may be worth checking your new schematic against the EVM to make sure no reserved pins or boot pins are being treated incorrectly.
When using CCS, I cannot get U-Boot to run without a GEL file so it seems that there's some configuration going on in the GEL file that isn't happening on the board. Its interesting that U-Boot would run fine on the EVM but not on my custom board when, as far as low level init goes, I'm only using different flash and different DDR. In any case, I am exploring modifying U-Boot to use the same procedures as the GEL file in hopes that it will alleviate the problem.
Nice icon by the way.
Thanks :)
It sounds like you are on the right track, I imagine there is some DDR initialization the GEL file is doing that U-Boot is not handling properly for your particular DDR device, the rest of the init sequence should be the same as you mention the only difference with your board vs the EVM is the flash and DDR, assuming your flash can handle the default EMIF timings used by this boot mode (which I believe are the slowest possible so it should).
Turns out that somehow the symbol CONFIG_SKIP_LOWLEVEL_INIT got defined and completely bypassed all the DDR2 initialization that should have been taking place. Things seem to work now.
Thanks for all the help!