-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Afzal Nadirshah Sent: Wednesday, March 04, 2009 12:42 PM To: Pieter; u-boot@lists.denx.de Subject: [U-Boot] FW: U-Boot hangs after loading device tree
Hi Pieter, Thanks for your suggestion. I guess its halting at the point where u-boot is handing over to the Linux kernel image. For doing the post mortem analysis, I am not able to obtain the virtual address of the log_buf. grep log_buf System.map or grep __log_buf System.map doesn't give nay output.
Sorry for the double post.
Just check your platform name/machine name in the dts , most probably your platform probe is not getting called. Also may be debug version of u-boot may give better idea.
Regards, Afzal Nadirshah
-----Original Message----- From: Pieter [mailto:phenning@vastech.co.za] Sent: Monday, March 02, 2009 4:24 PM To: Afzal Nadirshah Subject: Re: [U-Boot] U-Boot hangs after loading device tree
Afzal Nadirshah wrote:
Hi, I am trying to bring linux up on our custom board,
by loading the kernel.img , canynlands.dtb and Ramdisk onto the RAM using the serial port.
However the boot process is getting hung. The bootboot process stops after the following messages :
=> run flash_self## Booting kernel from Legacy Image at 1c000000 ... Image Name: Linux-2.6.25.7-00002-geaaf8db Created: 2008-06-30 13:53:11 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1547704 Bytes = 1.5 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 1c200000 ... Image Name: Simple Embedded Linux Framework Created: 2002-10-24 9:30:38 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 1476478 Bytes = 1.4 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 1c1e0000 Booting using the fdt blob at 0x1c1e0000 Uncompressing Kernel Image ... OK Loading Ramdisk to 1fc78000, end 1fde077e ... OK Loading Device Tree to 007f9000, end 007ff0b4 ... OK
I have changed the kernel_addr, fdt_addr and the
ramdisk_addr to the RAM addresses.
This is the output of the printenv command :
=> printenv bootdelay=5 baudrate=115200 loads_echo= preboot=echo;echo Type "run flash_nfs" to mount root
filesystem over
NFS;echo hostname=canyonlands netdev=eth0 nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath} ramargs=setenv bootargs root=/dev/ram rw addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}1 addtty=setenv bootargs ${bootargs} console=ttyS0,${baudrate} addmisc=setenv bootargs ${bootargs} initrd_high=30000000 kernel_addr_r=400000 fdt_addr_r=800000 ramdisk_addr_r=C00000 hostname=canyonlands bootfile=canyonlands/uImage ramdisk_file=canyonlands/uRamdisk rootpath=/opt/eldk/ppc_4xxFP flash_self=run ramargs addip addtty addmisc;bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr} flash_nfs=run nfsargs addip addtty addmisc;bootm ${kernel_addr} - ${fdt_addr} net_nfs=tftp ${kernel_addr_r} ${bootfile}; tftp ${fdt_addr_r} ${fdt_file}; run nfsargs addip a} net_self_load=tftp ${kernel_addr_r}
${bootfile};tftp
${fdt_addr_r} ${fdt_file};tftp ${ramdisk_; net_self=run net_self_load;run ramargs addip addtty addmisc;bootm
${kernel_addr_r}
${ramdisk_a} fdt_file=canyonlands/canyonlands.dtb load=tftp 200000 canyonlands/u-boot.bin update=protect off
0x01000000
FFFFFFFF;era 0x01000000 FFFFFFFF;cp.b ${fileaddr} 0x01000000 ${fv upd=run load update nload=tftp 200000 canyonlands/u-boot-nand.bin nupdate=nand erase 0 100000;nand write 200000 0 100000;setenv filesize;saveenv nupd=run nload nupdate pciconfighost=1 pcie_mode=RP:RP fdt_addr=1c1e0000 ramdisk_addr=1c200000 ram_root=run ramargs addip;bootm ${kernel_addr} ${ramdisk_addr} ${fdt_addr} ram_ws=1C000000 kernel_addr=1c000000 stdin=serial stdout=serial stderr=serial ver=U-Boot 2009.01 (Feb 25 2009 - 15:12:15) bootcmd=run flash_self bootargs=root=/dev/ram rw ip=::::canyonlands:eth0:off panic=1 console=ttyS0,115200 filesize=1687BE
Have anybody faced a similar problem?
I recently had a similar problem - the solution was a combination of DTS tweaks and U-Boot defines for my board. have a look at the post mortem debugging and recheck all your defines.
http://www.denx.de/wiki/view/DULG/LinuxPostMortemAnalysis
or search the mailing list for my postings: [U-Boot] Custom MPC8548 boot using FDT problem cheers pieter
http://www.mindtree.com/email/disclaimer.html _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot