Dear Rogan Dawes,
In message <4c6c0b33.8090...@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 (w...@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: w...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
