Problems booting EVM from host - beginner

I haven't used the DM8168 EVM but I comment on the network part. EVMs can be setup for static or DHCP addresses. This is controlled by U-boot for U-Boot itself as well as the Linux kernel. I think your EVM should be connected by cable to the same router that your laptop is wirelessly connected to. That way the router's DHCP server can give out an address to both your laptop and EVM. Assuming your router has wired ports.

Thanks. I tried that, but it doesn't seem to make any difference. The board boots fine if I set it to boot from the SD card, but I get no serial console messages if I try to boot from the host. I think that the system should boot the kernel from the host using TFTP, and boot the file system from the host using NFS. However, I assume the lack of serial port activity suggest that it's not getting that far. I have set SW3 to 0x012 (NAND Boot) and SW4 to NAND.

My understanding is that there is a early bootloader in ROM, and that should copy the late bootloader in NAND into on-chip SRAM, then start execution from there. Is that correct? I'm a bit confused, because the memory map for the NAND in the u-boot documentation suggests thet u-boot is 0x260000 bytes, which wouldn't fit in on-chip SRAM. The EZ Software Developer's Guide talks as though u-boot is already built and in NAND. Perhaps that's not true, and I need to build and flash it first.

Any advice? I re-iterate that I'm new to this board (and part) so I'm probably making some really simple mistake.

Thanks

Pete

I think booting from SD card will succeed regardless of the network connection but I doubt the network is up if it is connected to the laptop. Check with "ifconfig" after logging into Linux. My background is with the OMAP-L137. My guess at the boot sequence:

RBL (Root Boot Loader) - Reads boot pins for determine where is the next bootloader, SPI Flash, NAND, SD Card, etc. May or may not use SRAM. Loads the next bootloader in SRAM.

UBL (User Boot Loader) - Usually hard-coded to look in a specific media for the next bootloader. Some chips have this UBL split into DSP and ARM parts. Usually executes in SRAM, sets up DRAM, loads next bootloader into DRAM and jumps to DRAM.

U-Boot - A generic bootloader for Linux. Generally executes in DRAM which means it is not limited to SRAM size. It will load Linux into DRAM and jump. The source for the Linux image is runtime configurable, eg SD Card or TFTP'ed across the network. U-boot passes bootargs to Linux that define filesystem, network addresses, serial port for console etc.

Linux - Executes in DRAM. It's file system can be on the network (NFS), on the SD Card, in RAM as a ramdisk, etc. Usually U-Boot will pass the location in the bootargs.

Perhaps try booting from SD Card. Break into the U-Boot command prompt by hitting any key while it is counting down. Print out the environment variables with the "printenv: command. The variables define how U-boot boots Linux. Posting the environment variables and serial port output will help others help you. Also helps to focus on one particular situation or problem at a time.

Norman Wong said:

I think booting from SD card will succeed regardless of the network connection but I doubt the network is up if it is connected to the laptop.

......

Perhaps try booting from SD Card. Break into the U-Boot command prompt by hitting any key while it is counting down. Print out the environment variables with the "printenv: command. The variables define how U-boot boots Linux. Posting the environment variables and serial port output will help others help you. Also helps to focus on one particular situation or problem at a time.

Here's the SD U-boot printenv:

bootcmd=if mmc init; then if run loadbootscript; then run bootscript; else echo In case ENV on MMC/SD is required; echo Please put a
 valid script named boot.scr on the card; echo Refer to the User Guide on how to generate the image; fi; else echo Please set bootar
gs and bootcmd before booting the kernel; echo If that has already been done please ignore this message; fi
bootdelay=3
baudrate=115200
autoload=no
verify=yes
bootfile=uImage
ramdisk_file=ramdisk.gz
loadaddr=0x81000000
script_addr=0x80900000
loadbootscript=fatload mmc 1 ${script_addr} boot.scr
bootscript= echo Running bootscript from MMC/SD to set the ENV...; source ${script_addr}
stdin=serial
stdout=serial
stderr=serial
ethaddr=90:d7:eb:94:ba:1c
ethact=DaVinci EMAC
ver=U-Boot 2010.06 (Jun 01 2011 - 12:30:57)

Environment size: 779/8188 bytes

I think though that the NAND boot environment is supposed to be stored on NAND.

When I try to boot from NAND I get nothing over the serial port.

When I do boot from the SD card I get the following in the serial port diagnostics:

I2C: ready
DRAM: 2 GiB
NAND: HW ECC Hamming Code selected
No NAND device found!!!
0 MiB
*** Warning - bad CRC or NAND, using default environment

I'm not sure if that means the NAND really is bad, or if it's just a bogus message.

I've tried re-seating the NAND in its socket, but no change.

Thanks

Pete

I assume that when you change from NAND to SD boot that you are changing the boot pins. I am not sure about this, but I think the NAND and SD Card are mutually exclusive. They share pins. Here's some wild guesses:

NAND Boot: NAND memory is muxed in. SD Card is not accessible. RBL loads UBL from NAND. If nothing is NAND, boot hangs. I think you might have to JTAG in the RBL, UBL, U-Boot into NAND. There should be CCS projects for that in your SDK. Hopefully there are instructions something in the SDK as well. I could not find any online instructions on http://processors.wiki.ti.com. Maybe buried deep.

SD Card Boot: SD Card is muxed in. NAND memory is not accessible. RBL loads UBL from SD Card. UBL loads U-Boot from SD Card. U-Boot loads Linux kernel from directions in the boot.scr file on the SD Card. The SD Card will contain the UBL, U-Boot and kernel on the first partition. It probably contains the Linux file system on the second partition. I am surprised that U-Boot is configured to use NAND for it's environment variables. In my case on the OMAP-L137 EVM, SPI Flash is used instead.

Perhaps try the SPI Flash boot. It is likely that it is has been pre-programmed by the board manufacturer. There should be CCS projects or binaries that will program the SPI flash in the SDK.

Norman Wong said:

If nothing is NAND, boot hangs. I think you might have to JTAG in the RBL, UBL, U-Boot into NAND. There should be CCS projects for that in your SDK. Hopefully there are instructions something in the SDK as well. I could not find any online instructions on http://processors.wiki.ti.com. Maybe buried deep.

Thanks Norman.

My mistake was in assuming that the bootloader was already in NAND (The TI docs certainly suggest that).

I found a procedure for writing the bootloader to NAND from the SD boot menu (I don't have CCS or an emulator yet).

That seemed to work for a couple of resets, then the system would no longer recognize the NAND. I don't think that I changed anything; I suspect that the NAND might have died. I have taken it out of the socket a couple of times, but didn't catch any pins or bend anything. It seems to be seated OK. It's a bit frustrating.

Pete

Hi,

   In the latest release there is a script setup-nand-images.sh that can flash the u-boot image to the NAND using minicom.

You can refer to the following link for steps to flash the image to NAND using the script.

http://processors.wiki.ti.com/index.php/EZSDK_DM816x_Flashing_NAND

Thanks & Regards,

Amarinder

http://processors.wiki.ti.com/index.php/Category:EZSDK

http://processors.wiki.ti.com/index.php/Category:EZSDK_Flashing_NAND