EVM Puzzle

Charles Krinke said:

The morning, after being away on another project for a week, I set it up, turn it on and admire the last message on the serial terminal which goes "......done, booting the kernel".  At this point, there is no demo visible on the LCD and the serial terminal is unresponsive.

Usually this sort of operation indicates something is messed up in the U-Boot arguments, could you post your U-Boot arguments and a boot log of when this happens? If you are going into development on this, you may want to try booting the board via TFTP and NFS as described in the getting started guide, this can often get things working if your flash is somehow corrupted.

Dear Bernie:

I really appreciate your considering my problem. What is puzzling about this is I turned the EVM on two weeks ago when I received it and then left it on the corner of my desk. So, ... I expected it to work. Unless someone 'pixie' has been in my office when I wasnt looking.

At this point, I would like to understand why it doesnt boot before I go to the NFS mount stage. I'm one of those dreaded 'step-by-boring-step' guys.

Charles

In any case, here is the environment from the uboot prompt:

OMAP3EVM # printenv

bootargs=mem=128M console=ttyS0,115200n8 noinitrd root=/dev/mtdblock4 rw rootfstype=jffs2
baudrate=115200
ipaddr=192.168.1.10
serverip=192.168.1.20
preboot=
gatewayip=192.168.1.1
netmask=255.255.255.0
bootfile="uImage"
get_kernel=run nand_kernel
get_initrd=run nand_initrd
nand_kernel=nand read.i 0x80000000 280000 200000
nand_initrd=nand read.i 0x81600000 780000 1000000
tftp_kernel=tftpboot 0x80000000 uImage
tftp_initrd=tftpboot 0x81600000 ramdisk.gz
bootargs_rd=mem=128M console=ttyS0,115200n8 root=/dev/ram0 initrd=0x81600000,40M ramdisk_size=40960
bootargs_fs=mem=128M console=ttyS0,115200n8 noinitrd root=/dev/mtdblock4 rw rootfstype=jffs2
bootargs_nfs=mem=128M console=ttyS0,115200n8 noinitrd rw root=/dev/nfs nfsroot=/mnt/nfs,nolock
addip=setenv bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):eth0:on
boot_rd=run get_kernel; run get_initrd; setenv bootargs $(bootargs_rd); run addip; bootm 0x80000000
boot_fs=run get_kernel; setenv bootargs $(bootargs_fs); run addip; bootm 0x80000000
boot_nfs=run get_kernel; setenv bootargs $(bootargs_nfs); run addip; bootm 0x80000000
bootcmd=run boot_fs
bootdelay=6
ethaddr=00:50:c2:7e:8c:e9
stdin=serial
stdout=serial
stderr=serial
mmcboot=mmcinit;fatload mmc 0 0x80000000 uImage;fatload mmc 0 0x81600000 ramdisk.gz;bootm 0x80000000

Environment size: 1315/131068 bytes
OMAP3EVM #

And here is what it does if I dont press a key during the 10 second uboot count down.

 2097152 bytes read: OK
## Booting image at 80000000 ...
   Image Name:   Linux-2.6.22.18-omap3
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1898688 Bytes =  1.8 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux............................................................................................................................... done, booting the kernel.

Charles Krinke said:

I really appreciate your considering my problem. What is puzzling about this is I turned the EVM on two weeks ago when I received it and then left it on the corner of my desk. So, ... I expected it to work. Unless someone 'pixie' has been in my office when I wasnt looking.

This is a bit puzzling if no one had used the board at all, it should still boot reliably if nothing was changed in the U-Boot arguments or the flash itself, there are of course boot mode switches though if you are getting to U-Boot than you are already a valid boot mode, so there is not much you could physically do to cause this.

Charles Krinke said:

At this point, I would like to understand why it doesnt boot before I go to the NFS mount stage. I'm one of those dreaded 'step-by-boring-step' guys.

While I agree with being thorough, there is not much else that can be done at a hardware level to debug this very easily, I am afraid that debugging a kernel boot issue like this can be fairly involved, though there are some options available. This being said, the typical course of action would be to redo everything and try booting again, or booting another way like TFTP/NFS, as generally the problem lies in the boot conditions, such as how things were flashed, as opposed to a problem within the kernel software itself, particularly since the out of the box binary is known to be good.

Charles Krinke said:

In any case, here is the environment from the uboot prompt:

The U-Boot arguments do look to be ok here for a Micron PoP memory based EVM, and should get more output than you are getting, they can be compared to the arguments found in the GSG here though the GSG adds in a few extra options for running the DVSDK examples as opposed to the out of the box slide show demo.

One thought would be if you are using the same PC and serial port you used before? The kernel will reconfigure the terminal UART port when it tries to boot, so if your particular machine is somehow sensitive to the change than that could explain this (it should be the same parameters though), other than that it just appears your kernel is not booting properly somehow, even though the checksum succeeded and it was recognized as an image, so all that I can think of to try to fix it would be the TFTP route.

I think I got it. By reloading u-boot with the Windows DownloadUtility, I was able to get back to the demo app running.

I then got the tftp and nfs root working, so am off to the next step now, and thank you for the advice so far.

Charles