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@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