[U-Boot-Users] u-boot, powerpc with device tree, initrd problem

[Jerry Van Baren <gerald.vanbaren@ge.com>]

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 at 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