On Dec 4, 2007, at 6:16 AM, Robert P. J. Day wrote:
toward the bottom of init/initramfs.c, we can see that the in-
kernel initramfs is getting "unpacked", followed by the unpacking of
an option external initrd of some format. but what are those things
getting unpacked *into*?
i'm assuming there's an early ramfs that's created by the kernel
that all this content is being placed in, but where exactly is that
ramfs created? that is, at what step in the early kernel booting?
thanks.
Here's my custom ARM setup's boot spew (elided for brevity) from uboot
and the kernel:
Loading from partition Bnrd [0x580000 bytes of 0x1000000 allocated]
unit size 0x40000.
done.
Loading from partition Bkrn [0x140000 bytes of 0x140000 allocated]
unit size 0x40000.
done.
## Booting image at 10000000 ...
Image Name: 2.6.21-custom
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1174528 Bytes = 1.1 MB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 12000000 ...
Image Name: cashwell:CT:00.06.00.00297
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size: 5603328 Bytes = 5.3 MB
Load Address: 13400000
Entry Point: 13400000
Verifying Checksum ... OK
Starting kernel ...
Uncompressing
Linux
............................................................................. done
,
booting the kernel.
Linux version 2.6.21-custom (cashwell@devmec) (gcc version 4.1.1) #1
PREEMPT Tue Nov 20 08:17:15 EST 2007
CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=00053177
Memory policy: ECC disabled, Data cache writeback
OMAP162123 revision 2 handled as 16xx id: 2d0594085990120d
SRAM: Mapped pa 0x20000000 to va 0xd0000000 size: 0x100000
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets
Built 1 zonelists. Total pages: 15748
Kernel command line: console=ttyS2,115200n8 mem=62m ro initrd root=/
dev/ram ip=dhcp
Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2eb3 ARM_CKCTL: 0x3509
Clocking rate (xtal/DPLL1/MPU): 13.0/188.5/188.5 MHz
Total of 128 interrupts in 4 interrupt banks
OMAP GPIO hardware version 1.0
PID hash table entries: 256 (order: 8, 1024 bytes)
OMAP1 MPU Timer clock rate being set to 94250000
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 62MB = 62MB total
Memory: 54844KB available (2156K code, 224K data, 108K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
OMAP DMA hardware version 1
DMA capabilities: 000c0000:00000000:01ff:003f:007f
Time: mpu_timer2 clocksource has been installed.
Switched to high resolution mode on CPU 0
...
I think the boot-loader-supplied initrd content is copied into a
ramdisk at /dev/ram and then that boot-loader provided memory is freed
into the slab handler for the first time:
checking if image is initramfs...it isn't (bad gzip magic numbers);
looks like an initrd
Freeing initrd memory: 5472K
...
Then my normal 4 ramdisks are created at /dev/ram0 through /dev/ram3.
RAMDISK driver initialized: 4 RAM disks of 16384K size 4096 blocksize
...
Then it goes hunting for a root and uses the kernel arg "root=/dev/
ram" to find what it copied above. The code you were looking at then
copies the contained file system (cramfs in my case) into the real
ramdisk for use at /dev/ram0. It then creates a symlink named /dev/
root pointing to /dev/ram0.
RAMDISK: cramfs filesystem found at block 0
RAMDISK: Loading 5472KiB [1 disk] into ram disk... done.
VFS: Mounted root (cramfs filesystem) readonly.
Also interesting is that mount show 2 mounts over /:
dm139:~ $ mount
rootfs on / type rootfs (rw)
/dev/root on / type cramfs (ro)
The second makes sense given the link from /dev/root -> /dev/ram0
which contains the cramfs file system. The first is more curious. It
looks like the rootfs type has some connection to the original /dev/
ram copied from the boot loader. I don't know if /dev/ram ever
actually exists or is just a sentinel but there's no such device by
the time I get a prompt.
I fought with this under 2.4 and 2.6. (Boy was cramfs broken under
2.4!) The epiphany was realizing that for some reason the ramdisk
block size had to be 4K for it to work. I don't know if this was some
hidden agreement with the settings in the cramfs file system (or the
tools used to create it) or if it must match the VM page size. I just
know it's 2 days I'll never get back! :-)
I hope there's info here you can use.
-Mike
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
