SD boot and NAND boot for DM355

SAKHO said:

Why the sequence of boot does not arrive up to the end? Anybody would have an idea?

The lack of a full boot here is most likely due to a lack of proper bootargs in your U-Boot environment variables. When it gets to the point that it is counting down at 'Hit any key to stop autoboot:' press a key on the serial terminal to bring it to the U-Boot prompt and than run the printenv command to see what your U-Boot environment variables are. Usually you will get this if your bootargs variable is missing or corrupted, in particular if the console= value is incorrect.

SAKHO said:

According to you what is wrong on this last demo board?

Assuming you are using the same physical SD card which works on the first board, than my guess would be that either the boot pins you are configuring with the DIP switches are not getting set correctly or that the SD card interface is not functioning properly.The 'BOOTME BOOTME' message implies that the processor itself is in a good state, and that the UART RS232 interface is functioning properly.

SAKHO said:

Is it normal that I have no output on my console for the second demo boad?

No, as long as you have the boot switch settings correct and a bootable media available (NAND or SD card with valid boot images in this case) it should start outputting to the serial terminal.

SAKHO said:

Is it possible to boot on a 2G SD given silicon revision number?

It should be possible, your first board is doing it after all.

SAKHO said:

What is wrong on these parameters?

I think the bootcmd=bootm 0x80700000 will work in this case because the SD card boot utility from Constantine seems to be copying the kernel uImage file to that location in DDR (see the 'kernel  sdcard_read sdc_src=0x00104400 dst=0x80700000...' line from the first post), so as long as you are always booting off of that SD card first this bootcmd should be ok. As John suggests this same bootcmd would fail in a typical NAND boot system, since nothing would have loaded the kernel uImage to DDR, the command to load from storage to DDR has to be done manually.

The bootargs also look mostly ok (one concern), though I do not often use RAM disks this seems reasonable as the SD card boot utility is placing the RAM disk in DDR as well. For a pure SD card boot you might consider making a dual partition card, one with the Constantine boot utility in it and boot loaders, and a second with a Linux file system (such as EXT3) which you could mount directly instead of using the RAM disk. There is one potential issue I see with the bootargs, I am not sure why you have a ;bootm 0x80700000 in there, that should be the bootcmd, and I am not sure what that does if you have it in the bootargs, perhaps this is messing up your kernel boot?

SAKHO said:

( DM355->SD based uboot -> SD based u-image -> SD based filesys). Is this possible already? Have you any idea what I should do or not do? what I need to change?

I have not tried this on DM355, but it should be possible, this sort of boot sequence is very common on some other TI platforms, namely the OMAP3530 and Beagle Board. I think you are on the right track with what you are doing, we just need to figure out why your uImage boot is not outputting anything, and I suspect it may be the extra bootm value in your bootargs as suggested above.

Hi,

I can boot entirely from SD card with the following parameters:

     bootargs =  ip=off mem=120M console=ttyS0,115200n8 root=/dev/ram0 rw initrd=0x82000000,4M

     bootcmd = bootm 0x80700000

For the SD interface of the second demo board, I think there is a problem above. In fact, I like voltage level of 1.4V while on the right demo board, there is 3V. And suddenly, I think the demo board can not detect the SD card. What do you think?

Thank you for everything.

Sakho

SAKHO said:

In fact, I like voltage level of 1.4V while on the right demo board, there is 3V. And suddenly, I think the demo board can not detect the SD card. What do you think?

I am not sure which voltages you are referring to here, but all else being the same (SD card and dip switch settings known to work on the first board) than there may be something wrong with the second board's SD interface.

You may want to try to get NAND boot working on the first board, and than swap the NAND chip from the first board to the second board (since the DM355 EVMs happen to have sockets for the NAND flash) to see if the second board would then boot off of NAND, which would take the SD interface out of the equation for bringing up the board initially. Once the second board is booted into Linux you could try testing the SD interface from there.

Hello,
Thank you for your answers and your advice...

In fact, the second board based DM355 is not really an evaluation board. It was rebuilt following the scheme of the demo board (TMS320DM355), and therefore we can not interchange the NAND flash (NAND is directly soldered on the new board).
Anyway, the SD card seems to be detected by the DM355 the new board (after some modification on the hardware). The problem we face now is the following:

When we select the SD boot mode, we have nothing else on the console output (via UART) as follows: (a series of - -- - - - -)

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------

And yet we have the same behavior as the original demo board using the SD boot (visually) except that a change in the brightness of the boot LED is sometimes found.

But, without turning off the board and selecting just after the UART boot mode, we have this on the console:

SD card boot and flashing tool for DM355 and DM365
by Constantine Shulyupin http://www.LinuxDriver.co.il/
Online manual: http://wiki.davincidsp.com/index.php/SD_card_boot_and_flashing_tool_for_DM355_and_DM365
based on TI DM35x FlashAndBootUtils 1.10 SFT, TI flash_utils and SpectrumDigital evmdm355, evmdm365
Compiled on Sep 13 2010 at 18:19:39 with gcc 3.4.3 (MontaVista 3.4.3-25.0.104.0600975 2006-07-06)
SYSTEM->DEVICE_ID=0x0B73B02F
DM355_MHZ=216 DDR_MHZ=171
PLL1->PLLM=143 PLL2->PLLM=113 PLL1->PLLDIV3=0x0000800F DDR->SDTIMR=0x2A9� BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOOTME BOO

We feel that the SD boot mode messages are stored in a buffer whose content is displayed on the console (before displaying BOOTME BOOTME ...) when we move in UART mode.

Why we do not have appropriate message output when we select the SD mode? I believe that the UART is set in the tools developed by Constatine (proof it works on the demo board). Someone had a similar situation? Would there be a problem when reading the SD card or a problem on the configuration of the UART interface? Have you any idea what's wrong?
Feel free to request more information if you have not understood the explanations I have given....

Again thank you

Sakho

SAKHO said:

When we select the SD boot mode, we have nothing else on the console output (via UART) as follows: (a series of - -- - - - -)

When you see these --- lines, do they come out at the rate and of the form of the SD card utility? If they are coming out at the same rate and with similar number of characters, than it may be that something is wrong with the UART configuration, which should be in the SD card utility sources somewhere. This is a bit unusual though since the same SD card works on the EVM, so there may be something else wrong with the custom board leading to this.

SAKHO said:

But, without turning off the board and selecting just after the UART boot mode, we have this on the console:

I am not sure what you mean by this? You power on the board in SD boot and switch to UART immediately after power on, and that gets you some expected output?

SAKHO said:

We feel that the SD boot mode messages are stored in a buffer whose content is displayed on the console (before displaying BOOTME BOOTME ...) when we move in UART mode.

The BOOTME BOOTME messages do indicate the ROM boot loader (RBL) is trying to boot over the UART interface, however the RBL should only be running when the device is reset, so you are resetting the device and seeing the messages?

SAKHO said:

I believe that the UART is set in the tools developed by Constatine (proof it works on the demo board). Someone had a similar situation?

The UART should be configured by the SD boot utility, as far as someone else having this sort of issue you may want to look through the thread here, or post in it as Constantine tends to respond there regularly. However I am not sure how much he can help since the same SD card works on the EVM, thus there is something unusual about the custom board leading to the failure.

SAKHO said:

Would there be a problem when reading the SD card or a problem on the configuration of the UART interface?

This could be either, if the SD card read was corrupted it could prevent the SD boot utility from working properly, or if the UART interface on your board is somehow different than the EVM's the configuration could be bad. Seeing the actual messages you are getting output makes it seem like more of a UART problem than a SD card read corruption issue.