[U-Boot] Weird problem with kernel/initrd loading
Hi all,
I have a query regarding the boot of an initrd with U-boot. ASAIK, ramdisk.gz should be converted to a type supported by U-boot with the use of mkimage tool (with a -T ramdisk switch). Also, the "bootm" command should be invoked by passing the address of uImage first and then the address of ramdisk.gz as it is mentioned here http://www.denx.de/wiki/DULG/UBootCmdGroupExec. However, in this case I get the following output and the kernel can't recognize/mount the ramdisk.
OMAP3 beagleboard.org # setenv bootargs 'console=ttyS2,115200n8, root=/dev/ram0 rw initrd=0x81600000,8M, init=/linuxrc'
OMAP3 beagleboard.org # mmcinit; fatload mmc 0 0x80002000 uImage; fatload mmc 0 0x81600000 ramdisk.gz; bootm 0x80002000 0x81600000
reading uImage
1950244 bytes read
reading ramdisk.gz
2910640 bytes read
## Booting kernel from Legacy Image at 80002000 ...
Image Name: Linux-2.6.32-rc7
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1950180 Bytes = 1.9 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 81600000 ...
Image Name: my_ramdisk
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 2910576 Bytes = 2.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux....................................................................... .................................................. done, booting the kernel.
[ 0.000000] Linux version 2.6.32-rc7 (limp@ubuntu) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #1 Thu Nov 26 12:32:47 GMT 2009
[ 0.000000] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7f
[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] Machine: OMAP3 Beagle Board
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] OMAP3430 ES3.0
[ 0.000000] SRAM: Mapped pa 0x40200000 to va 0xe3000000 size: 0x100000
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
[ 0.000000] Kernel command line: console=ttyS2,115200n8, root=/dev/ram0 rw initrd=0x81600000,8M, init=/linuxrc
[ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Memory: 128MB 128MB = 256MB total
[ 0.000000] Memory: 247552KB available (3332K code, 307K data, 120K init, 0K highmem)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] NR_IRQS:402
[ 0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
[ 0.000000] Reprogramming SDRC clock to 332000000 Hz
[ 0.000000] GPMC revision 5.0
[ 0.000000] IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
[ 0.000000] Total of 96 interrupts on 1 active controller
[ 0.000000] OMAP34xx GPIO hardware version 2.5
[ 0.000000] OMAP clockevent source: GPTIMER1 at 13000000 Hz
[ 0.000000] Console: colour dummy device 80x30
[ 0.000000] Calibrating delay loop... 498.07 BogoMIPS (lpj=2490368)
[ 0.000000] Mount-cache hash table entries: 512
[ 0.000000] CPU: Testing write buffer coherency: ok
[ 0.000000] regulator: core version 0.5
[ 0.000000] NET: Registered protocol family 16
[ 0.000000] Found NAND on CS0
[ 0.000000] Registering NAND on CS0
[ 28.064483] OMAP DMA hardware revision 4.0
[ 28.080444] bio: create slab <bio-0> at 0
[ 28.083923] SCSI subsystem initialized
[ 28.084747] usbcore: registered new interface driver usbfs
[ 28.085235] usbcore: registered new interface driver hub
[ 28.085540] usbcore: registered new device driver usb
[ 28.086151] i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
[ 28.089538] twl4030: PIH (irq 7) chaining IRQs 368..375
[ 28.089569] twl4030: power (irq 373) chaining IRQs 376..383
[ 28.090026] twl4030: gpio (irq 368) chaining IRQs 384..401
[ 28.091735] regulator: VUSB1V5: 1500 mV normal standby
[ 28.092315] regulator: VUSB1V8: 1800 mV normal standby
[ 28.092895] regulator: VUSB3V1: 3100 mV normal standby
[ 28.094299] twl4030_usb twl4030_usb: Initialized TWL4030 USB module
[ 28.095184] regulator: VMMC1: 1850 <--> 3150 mV normal standby
[ 28.095794] regulator: VDAC: 1800 mV normal standby
[ 28.096374] regulator: VPLL2: 1800 mV normal standby
[ 28.096984] regulator: VSIM: 1800 <--> 3000 mV normal standby
[ 28.097167] i2c_omap i2c_omap.3: bus 3 rev3.12 at 100 kHz
[ 28.099304] Switching to clocksource gp timer
[ 28.102264] musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0
[ 28.104858] musb_hdrc: USB OTG mode controller at d80ab000 using DMA, IRQ 92
[ 28.105468] NET: Registered protocol family 2
[ 28.105682] IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
[ 28.106262] TCP established hash table entries: 8192 (order: 4, 65536 bytes)
[ 28.106536] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[ 28.106719] TCP: Hash tables configured (established 8192 bind 8192)
[ 28.106750] TCP reno registered
[ 28.106964] NET: Registered protocol family 1
[ 28.107391] RPC: Registered udp transport module.
[ 28.107391] RPC: Registered tcp transport module.
[ 28.107421] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 28.107666] Trying to unpack rootfs image as initramfs...
[ 28.107971] rootfs image is not initramfs (junk in compressed archive); looks like an initrd
[ 28.154846] Freeing initrd memory: 8192K
[ 28.155548] NetWinder Floating Point Emulator V0.97 (double precision)
[ 28.157684] VFS: Disk quotas dquot_6.5.2
[ 28.157775] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 28.158996] NTFS driver 2.1.29 [Flags: R/O].
[ 28.159301] JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
[ 28.160034] msgmni has been set to 499
[ 28.161315] alg: No test for stdrng (krng)
[ 28.161407] io scheduler noop registered
[ 28.161437] io scheduler anticipatory registered (default)
[ 28.161437] io scheduler deadline registered
[ 28.161621] io scheduler cfq registered
[ 28.162353] omapfb: configured for panel omap3beagle
[ 28.172393] omapfb: DISPC version 3.0 initialized
[ 28.186523] Console: switching to colour frame buffer device 128x48
[ 28.199157] omapfb: Framebuffer initialized. Total vram 1572864 planes 1
[ 28.199188] omapfb: Pixclock 48000 kHz hfreq 44.7 kHz vfreq 57.7 Hz
[ 28.218811] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 28.241882] serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
[ 28.262725] serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
[ 28.283538] serial8250.2: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
[ 28.754913] console [ttyS2] enabled
[ 28.759857] brd: module loaded
[ 28.768463] loop: module loaded
[ 28.772796] usbmon: debugfs is not available
[ 28.777099] Initializing USB Mass Storage driver...
[ 28.782531] usbcore: registered new interface driver usb-storage
[ 28.788604] USB Mass Storage support registered.
[ 28.793304] i2c /dev entries driver
[ 28.910125] TCP cubic registered
[ 28.913391] NET: Registered protocol family 17
[ 28.917907] NET: Registered protocol family 15
[ 28.922515] Power Management for TI OMAP3.
[ 28.926818] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
[ 28.936676] regulator_init_complete: incomplete constraints, leaving VDVI on
[ 28.943908] regulator_init_complete: incomplete constraints, leaving VDAC on
[ 28.951171] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 28.957794] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[ 28.969543] List of all partitions:
[ 28.973083] No filesystem could mount root, tried: ext3 ext2 vfat msdos ntfs
[ 28.980346] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
The weird thing is that by using the very same uImage and ramdisk.gz but without using the mkimage tool to convert ramdisk.gz to a U-boot compatible type and without passing the ramdisk.gz memory address at "bootm" command, the filesystem gets mounted and the kernel boots successfully.
Does anyone has any clue of what is getting wrong in the first case?
Thanks in advance.
Dear "Ioannis Kyriakopoulos",
In message SNT111-DS83CB13AA8D729B0D4A82FA79B0@phx.gbl you wrote:
OMAP3 beagleboard.org # setenv bootargs 'console=ttyS2,115200n8, root=/dev/ram0 rw initrd=0x81600000,8M, init=/linuxrc'
OMAP3 beagleboard.org # mmcinit; fatload mmc 0 0x80002000 uImage; fatload mmc 0 0x81600000 ramdisk.gz; bootm 0x80002000 0x81600000
This is obviously wrong, isn't it?
If you store the U-Boot image file with the file header and the ramdisk image as payload at address 0x81600000, you _cannot_ use the same address in the "initrd=0x81600000" argument, as this address is the image header and not the ramdisk.
And anyway - why are you passing "initrd=" at all? Which part of the documentation shows such an example? None, because it's wrong.
The weird thing is that by using the very same uImage and ramdisk.gz but without using the mkimage tool to convert ramdisk.gz to a U-boot compatible type and without passing the ramdisk.gz memory address at "bootm" command, the filesystem gets mounted and the kernel boots successfully.
I am not surprised.
Does anyone has any clue of what is getting wrong in the first case?
You pass incorrect parameters to the kernel.
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
Thanks very much for your reply.
And anyway - why are you passing "initrd=" at all? Which part of the documentation shows such an example? None, because it's wrong.
Can you then please tell me in which cases initrd command is used because I've seen it being used in many examples like here http://wiki.davincidsp.com/index.php/Initrd You are right though that there is in nowhere documented as a command!
you _cannot_ use the same address in the "initrd=0x81600000" argument, as this address is the image header and not the ramdisk."
So the actual ramdisk address should be the one being set using the Load Address (-a switch) and the entry point (-e switch) switches of mkimage?
The weird thing is that by using the very same uImage and ramdisk.gz but without using the mkimage tool to convert ramdisk.gz to a U-boot compatible type and without passing the ramdisk.gz memory address at "bootm" command, the filesystem gets mounted and the kernel boots successfully.
I am not surprised.
But how the kernel knows where the ramdisk is and mounts it if I don't pass any arguments on the command line about its memory location? That's what I don't understand! Also, I thought it is necessary to use mkimage not only for the kernel image but also for the initrd for being able to be used by U-boot, but as it seems it's not!
Thanks again for the valuable help.
Kind Regards,
Ioannis Kyriakopoulos
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: 26 November 2009 22:20 To: Ioannis Kyriakopoulos Cc: u-boot@lists.denx.de Subject: [!! SPAM] Re: [U-Boot] Weird problem with kernel/initrd loading
Dear "Ioannis Kyriakopoulos",
In message SNT111-DS83CB13AA8D729B0D4A82FA79B0@phx.gbl you wrote:
OMAP3 beagleboard.org # setenv bootargs 'console=ttyS2,115200n8, root=/dev/ram0 rw initrd=0x81600000,8M, init=/linuxrc'
OMAP3 beagleboard.org # mmcinit; fatload mmc 0 0x80002000 uImage; fatload mmc 0 0x81600000 ramdisk.gz; bootm 0x80002000 0x81600000
This is obviously wrong, isn't it?
If you store the U-Boot image file with the file header and the ramdisk image as payload at address 0x81600000, you _cannot_ use the same address in the "initrd=0x81600000" argument, as this address is the image header and not the ramdisk.
And anyway - why are you passing "initrd=" at all? Which part of the documentation shows such an example? None, because it's wrong.
The weird thing is that by using the very same uImage and ramdisk.gz but without using the mkimage tool to convert ramdisk.gz to a U-boot compatible type and without passing the ramdisk.gz memory address at "bootm" command, the filesystem gets mounted and the kernel boots successfully.
I am not surprised.
Does anyone has any clue of what is getting wrong in the first case?
You pass incorrect parameters to the kernel.
Best regards,
Wolfgang Denk
Dear "Ioannis Kyriakopoulos",
please do not send separate copies of the same message to individual mail addresses and the mailing list. And please don't full-quote.
In message SNT111-DS791525D81F9DA69DED9DDA79A0@phx.gbl you wrote:
Can you then please tell me in which cases initrd command is used
There is no such thing as an "initrd command". What you are referring to here is the "initrd=" command line argument to the Linux kernel.
because I've seen it being used in many examples like here http://wiki.davincidsp.com/index.php/Initrd You are right though that there is in nowhere documented as a command!
It is not a command.
You have many ways to to the same thing (see http://en.wikipedia.org/wiki/TIMTOWTDI).
With U-Boot, you use a U-Boot image which contains a ramdisk, and you pass the address of this image as the second argument to the "bootm" command. U-Boot will do the necessary things, which on ARM includes setting up the required ATAG_INITRD / ATAG_INITRD2 entries. The Linux kernel picks up the location of the ramdisk from these ATAGs.
you _cannot_ use the same address in the "initrd=0x81600000" argument, as this address is the image header and not the ramdisk."
So the actual ramdisk address should be the one being set using the Load Address (-a switch) and the entry point (-e switch) switches of mkimage?
A ramdisk is no executable code, so it cannot have somethign as an "entry point". You use "-a 0 -e 0" when building a ramdisk image.
But how the kernel knows where the ramdisk is and mounts it if I don't pass any arguments on the command line about its memory location? That's what
This is architecture dependent. Some architectures use a device tree, others use other means. On ARM, they use ATAGs.
I don't understand! Also, I thought it is necessary to use mkimage not only for the kernel image but also for the initrd for being able to be used by U-boot, but as it seems it's not!
The U-Boot way is to create a U-Boot image, but as mentioned above - TIMTOWTDI.
Best regards,
Wolfgang Denk
participants (2)
-
Ioannis Kyriakopoulos -
Wolfgang Denk