[U-Boot-Users] u-boot, powerpc with device tree, initrd problem
Jerry Van Baren
gerald.vanbaren at ge.com
Wed Jul 9 21:08:13 CEST 2008
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
More information about the U-Boot
mailing list