Reloading u-boot on DM355 EVM (via RS232 UART)

The DM355 serial loader is available now, the Wiki page here shows instructions, and you can download it from sourceforge here.

Great sucess - many thanks

Okay, partial success to be honest - I have now successfully erased flash and sent an image (a freshly compiled kernel's uImage, having added NAND headers, page size 2048, block num 16, and the supplied UBL) but, with SW7 headers both high, I only get the following on the UART console:

Chip initialization passed!
TI UBL Version: 1.20, Flash type: NAND
Booting Catalog Boot Loader
BootMode = NAND
Starting NAND Copy...
Valid MagicNum found.
   DONE

Is there a step I have missed out? This does not appear to be booting linux!

Cheers

 * 1081518 exits n00b mode

Typical beginner's mistake - the file loaded needed to be the uboot!

uboot 1.2.0 now loaded and can get the basic shell to carry out commands in the getting started guide

[edit] ha! /me puts my ID instead of my name!

I run sfh_DM35x.exe -nanderase on windows, it can go to Sending the UBL..., but it receive BOOTME again and again. could you help me ? thanks.

jeffrey said:

I run sfh_DM35x.exe -nanderase on windows, it can go to Sending the UBL..., but it receive BOOTME again and again. could you help me ? thanks.

The BOOTME BOOTME BOOTME coming out of the board is the ROM boot loader on the device trying to boot serially (it expects a host on the UART to acknowledge the BOOTME message), meaning you are on the right track.

Have you tried running it with just loading the UBL that comes with the utility, i.e. 'slh_DM35x.exe -load2IRAM <UBL binary file>'?

Thank you very much, the reason is my board has a hardware watch dog, So my board is reset again and again.

but, now i  have an other problem, my board can't boot from nand flash but EVM can (using the same image and tools).

I have check the content in block 1,page 0, and page1, with "nand dump". the content is the same as EVM board's. but my board's boot LED blink in 4Hz when I set BTSEL[1..0]=00.

and I have put a empty flash into EVM flash socket, burn ubl and uboot into the nand flash, EVM can boot from the flash, then I took the flash away from EVM and put it into my flash socket. but my board can't boot from nand flash  :(

I found that EVM using DM355(ZWK) but my board use DM355(ZCE). Have any difference between the two version chip?

There should not be any difference between these two versions of the parts that would prevent DM355 from booting from NAND.  The scenerio you described makes me thing that there are other hardware differences that cause UBL (or u-boot) not to initialize hardware correctly.

The blinking LED does indicate a NAND failure, but at least the fact that it is blinking at 4Hz means that the device is alive and trying to boot. Knowing that the same flash boots properly in the EVM socket, and that your device is exhibiting the 4Hz blinking, makes me think there may be some problem with the NAND interface hardware, so my first thought would be to verify your schematic against the EVM schematic, though the packages are different so there will be different BGA pin numbers, the pin names should be the same.

Another way to debug this more directly would be you have access to a JTAG emulator you could connect up to your target board and take a look at what the state of the device is, in particular you could see if anything was actually copied out of NAND, and if there is a block number written to the last 32 bits of ARM internal memory (0x7FFC) where the RBL noted that it found a magic number. If this is not present that means that it never found a valid magic number, which could be caused by an interface problem.

OK, I will try it as your advice, thanks.

I found that GPIO0 doesn't connect on my board when I verify my schematic, It determine whether fast boot or normal boot, Do you think it is the problem cause my board can't boot? It should go back to normal boot if my board go to fast boot directly and failure, I think.

I just looked at the DM355 datasheet, and I noticed that there is a note that fast boot mode bullet has been removed; therefore, this may be an issue indeed.

I cannot find where it is said that GIO000 is used for fast boot selection, perhaps this was in one of the earlier revision datasheets. Fast boot is not supported on DM355, therefore if you were getting into the fast boot mode it could explain problems booting. The latest EVM schematics available at Spectrum Digital's web site have the new .65mm package, so you may want to compare against that. Looking at the GIO000 pin in this schematic it seems to be connected to a timer output from the MSP430.

11.2.1.1 in SPRUFB3.pdf–September 2007 mention that :

Read the FASTBOOT bit in the BOOTCFG register in the System Module to determine if a normal boot
or a fastboot is required. This section describes the normal NAND boot mode, for information on Fast
Boot from NAND, refer to the section titled “Fast NAND Boot”. The external pin DEEPSLEEPZ/GIO0
must be driven high during chip reset for normal NAND boot, otherwise driven low during chip reset for
Fast Boot.

In EVM board GPIO0 connected to P1.3/TA2 of MSP430 and named as DEEPSLP_EN, it seems to be used as sleep control pin. but my board can work well in UART boot, it maybe didn't enter the deep sleep state. Right?

FYI, as a rule of thumb, the data-sheet supersedes the user guides.  Fast boot mode support has been removed from the main data-sheet.

Juan Gonzales said:

FYI, as a rule of thumb, the data-sheet supersedes the user guides.  Fast boot mode support has been removed from the main data-sheet.

The User's Guide also mentions this in section 11.1.1, so it is not limited to the datasheet. My concern is that the datasheet does not make it clear enough what this pin is for, and that it must be pulled high for a proper boot sequence, as it is not listed in the boot pin section, and the description makes it sound like it should be low from page 22 of the datasheet, which does not make sense based on what the user's guide says. This is something I would like to see fixed in the datasheet.

which datasheet is the newest one? my datasheet is SPRS463A.pdf, and it mention that :"– Supports Fast Boot option, which allows you to quickly boot and recover from a low power mode" in page 84.

could you give me the newest datasheet? thanks!

The newest datasheet is always what is posted on the web, in this case http://focus.ti.com/lit/ds/symlink/tms320dm355.pdf should take you to the latest, it is rev E from July 08.

We are up to Rev E (july 2008): http://focus.ti.com/lit/ds/symlink/tms320dm355.pdf

yes, fast boot was deleted from SPRS463E, my docment is SPRS463A shipped with EVM's DVD.

But, it seems GIO00 needn't to be pull high(the newest datasheet didn't say that), I think it shouldn't cause my board can't boot from nand flash if GIO0 didn't connenct.

So, what is the real reason? Maybe I should re-manufacture my PCB. :( 

The DM355 does not support Fast NAND boot.  The ARM Subsystem guide mentions this and states that the GIO0 pin should be held high for normal NAND boot; but not as prominently is I would wish.  I am revising the document to make it clearer.

Jeffrey,

Based on Steve's feedback you may want to try pulling GIO0 (ball C16) high if that is possible on your PCB just to see if this is the root of your NAND booting issues, unfortunately if that is what fixes it you will probably have to revise your PCB.

Thank you very much! my board can boot from nand, now. I pulled high GIO000  and  it  works now

my board can mount NFS, but it seems has some problems when I try to create yaffs2 in mtdblock3.

I erased mtd3 and mount mtdblokc3 to /mnt/nand, then copied a file to /mnt/nand , umount it and mount it again. but the file lost. I test it on EVM board, EVM can't save file, too. what's wrong?

my log as blow:

*******************************************************************************************************************

root@192.168.1.7:~# flash_eraseall /dev/mtd3
Erasing 128 Kibyte @ 1fe0000 -- 99 % complete.

root@192.168.1.7:~# mount -t yaffs2 /dev/mtdblock3 /mnt/nand
yaffs: dev is 32505859 name is "mtdblock3"
yaffs: Attempting MTD mount on 31.3, "mtdblock3"

root@192.168.1.7:~# cd /mnt/nand/

root@192.168.1.7:/mnt/nand# ls
lost+found

root@192.168.1.7:/mnt/nand# cp /root/cif.bmp ./

root@192.168.1.7:/mnt/nand# ls
cif.bmp  lost+found                                                                     /*cif.bmp can be listed here*/

root@192.168.1.7:/mnt/nand# cd
root@192.168.1.7:~# umount /mnt/nand/

root@192.168.1.7:~# mount -t yaffs2 /dev/mtdblock3 /mnt/nand
yaffs: dev is 32505859 name is "mtdblock3"
yaffs: Attempting MTD mount on 31.3, "mtdblock3"

root@192.168.1.7:~# ls /mnt/nand/
lost+found                                                                                  /*cif.bmp lost*/
root@192.168.1.7:~#

I am not too sure what the problem might be, but the following wiki article may help

http://wiki.davincidsp.com/index.php?title=HOWTO_Create_Filesystems_on_DaVinci

Bernie,

I am using the instructions indicated for you.

In the command:

 sfh_<DEVICENAME>.exe -nandflash  <UBL binary file> <binary application file>

I konw where is <UBL file Binary> that is into past UBL in the package downloaded from sourceforge but where can I find the <binary application file> that is the u-boot image?

It looks like the DM355 serial loader does not include the U-Boot binary, this being the case you just have to get the U-Boot binary from your DVSDK installation, in particular you should be able to find a U-Boot binary within dvsdk_1_30_00_40\PSP_01_20_00_014\bin\dm355 or similar.

Thank you Bernie. I found the u-boot image and reloaded in NAND Flash.

I am glad to hear you were able to find it and get the image into the flash, it is nice now that these serial tools are available (you used to have to use CCS and an emulator: $$$) and good to know they are not too hard to use. If you run into any further trouble, please let us know.