John Linn wrote:
I realize this could be posted to the linuxppc-dev also, but my kernel is running fine so I think it's a u-boot to kernel interface problem. I am able to pass a device tree to the kernel and get it to boot fine, and using NFS root also.
I can't get it to find my initrd ramdisk is my problem. A kernel image, zImage.initrd, works with the ramdisk image, so I think everything is setup ok with the kernel. I'm using a uImage and using mkimage on my ramdisk also for u-boot.
The messages look to me like linux is finding, decompressing, etc. the RAM disk. It jumps the tracks sometime later.
I realize it could be that I'm just loading the images in the RAM such that when the kernel gets uncompressed it stomps on the ram disk. I have tried moving to other addresses without any luck. When I look in memory where the ram disk was loaded by uboot, I can see the image fine after the kernel has paniced because it didn't find the root file system.
Is there something basic that I'm missing?
Thanks, appreciate any help, John
=> bootm 0x1c00000 0x1800000 0x1000000 ## Booting image at 01c00000 ... Image Name: Linux-2.6.26-rc8 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1536987 Bytes = 1.5 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK
kernel check
## Loading RAMDisk Image at 01800000 ... Image Name: Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 1507104 Bytes = 1.4 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Booting using the fdt at 0x1000000 Loading Ramdisk to 0fd35000, end 0fea4f20 ... OK
ramdisk check
Loading Device Tree to 007fc000, end 007fefff ... OK Loading Device Tree to 007fa000, end 007fcfff ... OK
fdt check, but why are there two of them??? I don't have access to a successful system boot at the moment, so I don't know if this is normal or not. I'm thinking not. Does your kernel have a device tree blob built in?
Using Xilinx Virtex machine description Linux version 2.6.26-rc8 (linnj@wolfgang-pc) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #4 PREEMPT Tue Jul 8 14 :45:07 PDT 2008 Zone PFN ranges: DMA 0 -> 131072 Normal 131072 -> 131072 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 131072 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: console=ttyS0 ip=on root=/dev/ram Xilinx intc at 0xD0020200 mapped to 0xfdfff200 PID hash table entries: 2048 (order: 11, 8192 bytes) clocksource: timebase mult[c800000] shift[22] registered Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 514432k/524288k available (3024k kernel code, 9332k reserved, 128k data, 149k bss, 156k init) Mount-cache hash table entries: 512 device-tree: Duplicate name in /, renamed to "chosen#1"
This is interesting. Looks like you have two /chosen nodes??? Is this related to having two "Loading Device Tree" messages? I don't know if/how this would be the problem, but my theory of making things work is to fix the known problems before debugging the unknown problems.
[snip]
Best regards, gvb