M5485evb boot up stalling issues with new 2.6.25 Linux BSP

[jkimble]

I'm working with a modified version of the m5485EVB board and the new 2.6.25 Linux BSP. The biggest difference between my board and the evaluation board is that I have 128MB of RAM (same type) and 64MB of Flash (P33). I've had this working fine for some time with the 2.6.10 BSP but I really want to get on the newer kernel. Got U-Boot working fine but the kernel hangs halfway into the boot up process.

I've got the sequence listed below. Has anyone else experienced this?


U-Boot 1.3.3 (Oct  8 2008 - 13:57:33)

CPU:   Freescale MCF5484
       CPU CLK 200 Mhz BUS CLK 100 Mhz
Board: Freescale FireEngine 5485 EVB
I2C:   ready
DRAM:  128 MB
FLASH: 64 MB
In:    serial
Out:   serial
Err:   serial
Net:   FEC0, FEC1
-> bdinfo
memstart    = 0x00000000
memsize     = 0x08000000
flashstart  = 0xFC000000
flashsize   = 0x04000000
flashoffset = 0x00000000
sramstart   = 0xF2000000
sramsize    = 0x00001000
mbar        = 0xF0000000
busfreq     =    100 MHz
pcifreq     =      0 MHz
ethaddr     = 00:E0:0C:BC:E5:60
eth1addr    = 00:E0:0C:BC:E5:61
ip_addr     = 192.168.1.110
baudrate    = 115200 bps

-> tftp 02000000 uImage
Using FEC0 device
TFTP from server 192.168.1.105; our IP address is 192.168.1.110
Filename 'uImage'.
Load address: 0x2000000
Loading: #################################################################
         #################################################################
         ###########################################################
done
Bytes transferred = 2768960 (2a4040 hex)
-> bootm 02000000
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   Linux Kernel Image
   Image Type:   M68K Linux Kernel Image (uncompressed)
   Data Size:    2768896 Bytes =  2.6 MB
   Load Address: 00020000
   Entry Point:  00020000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
Linux version 2.6.25 (jkimble@localhost.localdomain) (gcc version 4.2.3 (Source8
starting up linux startmem 0x302000, endmem 0x8000000,          size 124MB
console [ttyS0] enabled
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16312
Kernel command line: root=/dev/nfs rw nfsroot=172.27.163.2:/tftpboot/ltib ip=17)
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 3, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 2, 32768 bytes)
Memory: 127184k/127224k available (2056k kernel code, 1696k data, 88k init)
SLUB: Genslabs=13, HWalign=16, Order=0-2, MinObjects=8, CPUs=1, Nodes=1
Mount-cache hash table entries: 1024
net_namespace: 152 bytes
NET: Registered protocol family 16
MCF5485x INIT_DEVICES
SCSI subsystem initialized
NET: Registered protocol family 23
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 0, 8192 bytes)
TCP established hash table entries: 4096 (order: 2, 32768 bytes)
TCP bind hash table entries: 4096 (order: 1, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
m547x_8x DMA: Initialize Multi-channel DMA API v1.0


I've looked further and still not getting this. As I said before the only change to U-Boot was to increase the size and type of flash but this was done in a way that I know works. I'm going to start putting some debug in the kernel to see what's happening but I have no debugger so it's going to be painful. The size of SDRAM was changed to 128Mb. I made the change in the /include/config.h file. Is there another place to change this in U-Boot? The kernel?

This is sooo frustrating. I feel like I'm so close to getting this up!!

Thanks for any suggestions or help...

[kmahan]

It looks like you've got the size configured based on the kernel messages.

If I was debugging it without a hardware debugger I'd start dropping printks throughout the kernel and try and figure out where it is hanging.  It's a bit of work, but you start binary chopping down locations in the kernel.  I do this a lot -- a hardware debugger is nice but it isn't the answer to everything.  Sometimes just understanding the kernel boot flow and some well placed printks will get you your answer.

For this I'd disable the ethernet and dma and all the other drivers except for the serial port.  When you get to the "unable to mount root filesystem" panic you know you've made it through most of the kernel and are getting ready to start up userspace.  That's a good sign!  Then turn on ethernet and dma (gotta have DMA) and get it mounting a root filesystem over NFS.  Then start adding things like flash drivers.

--Kurt

[jkimble]

Got it!!

This is (I should have mentioned) a MCF5484 (not 5485) and it lacks a hardware SEC device. The v2.6.10 kernel also hung on this but SEC was shown in the bootup messages and I could see where it was hanging. In this case it didn't give a clue and, where the 2.6.10 kernel configuration listed the SEC directly under drivers->misc, the 2.6.25 menu doesn't list SEC at all.

I found this through a very indirect route. I modified the 2.6.25 kernel to boot with my old colilo boot loader. The kernel hung at the same point as with U-Boot but, having left the console hung while I was looking at other code, the console suddenly displayed the message "talitos: failed to id device" and continued to boot! It never did this with U-Boot and I did let it sit to see if something would time out. It just hung forever. A quick search on talitos showed it to be a part of Freescals SEC engine. I searched around the kernel a bit and found that I had to disable the OCF crypto routines to avoid invoking talitos. Once OCF was diabled the kernel booted to the point of trying to mount the rootfs by NFS. It fails there but I know what that's all about.

Man, that was painful!!