[U-Boot] Debugging why my kernel won't start

[Wolfgang Denk <wd@denx.de>]

Dear Rogan Dawes,

In message <4C6C0B33.8090703@dawes.za.net> you wrote:
>
> Well, I thought that was the point of the "mkimage" header, with the
> Load Address and Entry Point fields. Although, of course, you'll never

These fields are only relevant for executable images, not for data
like ramdisk images.

> actually "enter" a ramdisk image. I had still thought that they would be
> copied, regardless. Otherwise, what is the point in specifying those
> fields? They might just as well be zero.

Indeed, and that's they usally are:

	-> mkimage -l /opt/eldk-4.2/arm/images/uRamdisk
	Image Name:   Simple Embedded Linux Framework
	Created:      Sun Dec  7 18:27:20 2008
	Image Type:   ARM Linux RAMDisk Image (gzip compressed)
	Data Size:    1659739 Bytes = 1620.84 kB = 1.58 MB
	Load Address: 00000000
	Entry Point:  00000000

Copying the image is just a waste of boot time. I see no reeason why
the kernel should not be able to read the image from RAM or from
flash. On PowerPC this has always been possible, for well over a
decade now.  But in ARM land they reject patches that would add such
support.

> So, the question then is, what is current u-boot doing? And why does it

In mainline code, it is supposed to verify the checksum and pass
the start address of the data to the kernel.

> not work when the ramdisk is copied over to memory?

This I cannot answer.

> It looks like U-Boot for ARM doesn't handle ramdisks at all? From
> common/cmd_bootm.c:

It does.

> #if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
>                 case BOOTM_STATE_RAMDISK:

This is actually the wrong place.

> Is this the missing functionality that I am looking for?

No.

For a test you might try to hook into this part of code, though:

"common/image.c":

 952 #if defined(CONFIG_B2) || defined(CONFIG_EVB4510) || defined(CONFIG_ARMADILLO)
 953                 /*
 954                  * We need to copy the ramdisk to SRAM to let Linux boot
 955                  */
 956                 if (rd_data) {
 957                         memmove ((void *)rd_load, (uchar *)rd_data, rd_len);
 958                         rd_data = rd_load;
 959                 }
 960 #endif /* CONFIG_B2 || CONFIG_EVB4510 || CONFIG_ARMADILLO */

This indeed performs a copy to the load address, as you expected.

Here is a log from a working example (QOng board, i. e. ARM11):

=> run flash_self
## Booting kernel from Legacy Image at a00a0000 ...
   Image Name:   Linux-2.6.34-rc1
   Created:      2010-04-28  22:07:22 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1964848 Bytes = 1.9 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at a0300000 ...
   Image Name:   Simple Embedded Linux Framework
   Created:      2008-11-24  16:44:17 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    1659703 Bytes = 1.6 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34-rc1 (wd at sirius.denx.de) (gcc version 4.2.2) #3 Thu Apr 29 00:07:17 CEST 2010
CPU: ARMv6-compatible processor [4107b364] revision 4 (ARMv6TEJ), cr=00c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Dave/DENX QongEVB-LITE
Memory policy: ECC disabled, Data cache writeback
INITRD: 0xa0300040+0x00195337 extends beyond physical memory - disabling initrd
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: root=/dev/ram rw ramdisk_size=8192 ip=192.168.20.12:192.168.1.1::255.255.0.0:qong:eth0:off panic=1 console=ttymxc0,115200 mtdparts=physmap-flash.0:384k(U-Boot),128k(env1),128k(env2),2432k(kernel),61m(rootfs),64m(user) ethaddr=00:50:c2:1e:af:e7 nohlt
...
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
...
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 140K
init started: BusyBox v1.7.1 (2008-11-24 17:40:49 MET)
starting pid 612, tty '': '/etc/rc.sh'
starting pid 617, tty '': '/bin/application'
### Application running ...
starting pid 618, tty '': '/bin/sh'
~ # eth0: link up (100/Full)
~ # 


[Note: the Qong is running a kernel version that has the patch added
which supports loading the ramdisk image from a flash address.]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The years of peak mental activity are undoubtedly between the ages of
four and eighteen. At four we know all the questions, at eighteen all
the answers.