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

Wed Jul 9 22:04:45 CEST 2008

I turned on extra debug and got some more data.

That's strange, u-boot is finding the device twice at the same location
in memory.  I must have something configured wrong.

-- 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:    1536962 Bytes =  1.5 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Current stack ends at 0x0FEA4990 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF3A
bd address  = 0x0FEA4E80
memstart    = 0x00000000
memsize     = 0x10000000
flashstart  = 0x00000000
flashsize   = 0x00000000
flashoffset = 0x00000000
sramstart   = 0x00000000
sramsize    = 0x00000000
bootflags   = 0x0FEA5C88
procfreq    =    400 MHz
plb_busfreq =     20 MHz
ethaddr     = 00:0A:35:01:02:03
IP addr     = 172.16.40.227
baudrate    =   9600 bps
Not skipping initrd
## 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
## initrd at 0x01800040 ... 0x0196FF5F (len=1507104=0x16FF20)
   Loading Ramdisk to 0fd34000, end 0fea3f20 ... OK
## device tree at 0x01000000 ... 0x01002FFF (len=12288=0x3000)
   Loading Device Tree to 007fc000, end 007fefff ... OK
## device tree at 0x01000000 ... 0x01002FFF (len=12288=0x3000)
   Loading Device Tree to 007fa000, end 007fcfff ... OK
## Transferring control to Linux (at address 00000000) ...
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)) #6 PREEMPT Wed Jul 9 12
:36:41 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

> -----Original Message-----
> From: Jerry Van Baren [mailto:gerald.vanbaren at ge.com]
> Sent: Wednesday, July 09, 2008 1:08 PM
> To: John Linn
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] u-boot, powerpc with device tree, initrd
problem
> 
> 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
> 

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.