Curran, Tom wrote:

I am using u-boot on the Avnet V5FX30T (Xilinx FPGA, PPC440) eval board to boot a Linux 2.6.27-rc4 kernel. I can use u-boot to tftp the kernel, ramdisk, and device tree blob to RAM and boot from there OK. I copied the kernel, ramdisk and blob to flash and verified those elements were programmed in flash correctly with 'iminfo', but when I try to boot from flash the boot process hangs at "Loading Ramdisk to 03d59000, end 03ec8f20 ... OK". At this point u-boot will restart (after a WDT-induced reset?) after a few minutes. Interestingly enough, I can boot from flash IF the ramdisk is already in RAM with a "bootm $(kernel_flash_addr) $(ramdisk_ram_addr) $(blob_flash_addr)". This leads me to believe something is going wrong in the copying of the ramdisk from flash to RAM. Perhaps I am doing something wrong or missed a step somewhere? I have read the FAQ, but have not found anything relevant. Perhaps someone here has had this problem too and can offer a solution? Any help is appreciated. Many thanks in advance!

--Tom

Hi Tom,

Do you have *no* console output from linux with the ramdisk-in-flash version? I assume you have normal console diarrhea when the ramdisk is in ram. Is linux booting at all? If your console output isn't outputting, it is hard to tell the difference between crashing before linux even starts or something much less fatal like the ramdisk not mounting properly (rebooting in 180 seconds...).

Can you look in the linux debug output buffer in memory in the failed boot? Find the symbol log_buf in the map file System.map. This will be a virtual address, e.g. c013c494 b log_buf . Drop the first nibble to get the physical address, e.g. 0x0013c494. Dump this area of memory to find what was sent to the system log before the crash.

What happens if you load your ramdisk into ram at 03d59000 (like your failed boot) rather than whatever $(ramdisk_ram_addr) is?

Best regards, gvb

P.S. You should use curly braces ${variable} rather than $(variable).