Here: custom board 'based' on SabreSD. Yocto dora with 3.0.35 kernel. I 'moved' the fsl-image-mfgtool-initramfs.bb from daisy to dora to build an initramfs file to use in MFGtool.
I got the title error when start the MFGTool. After much struggling I found the real error was rather before in printks:
|[||2.707858] Unpacking initramfs...|
|[||2.711280] Initramfs unpacking failed: junk in compressed archive|
Going through the kernel source I found that the initramfs image was being lost in the path from uboot to kernel.
I solved it changing:
bootm 0x10800000 0x10C00000
bootm 0x12800000 0x12C00000
and configuring the MFGTool to load the files to that address.
I am losing something and I am not able to see why this change is necesary. Anybody can explain it to me?
U-Boot > run bootcmd_mfg
## Booting kernel from Legacy Image at 12800000 ...
Image Name: Linux-3.0.35dora-hs-03023-gf6dd2
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3472132 Bytes = 3.3 MiB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 12c00000 ...
Image Name: hs-fsl-image-mfgtool-initramfs-i
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 6931695 Bytes = 6.6 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Kernel Image ... OK
I found this at u-boot -- BOOTM - Linux Kernel
"For Linux, exactly one optional argument can be passed. If it is present, it is interpreted as the start address of a initrd ramdisk image (in RAM, ROM or flash memory). In this case the bootm command consists of three steps: first the Linux kernel image is uncompressed and copied into RAM, then the ramdisk image is loaded to RAM, and finally control is passed to the Linux kernel, passing information about the location and size of the ramdisk image."
When my process failed:
I load uImage to 0x10800000
I load initramfs to 0x10C00000
I call bootm 0x10800000 0x10C00000
bootm checksumed the kernel and the initramfs
u-boot says my kernel is uncompressed
bootm copy uImage to 0x10008000, as uImage says
bootm jump to 0x10008000 to execute kernel, as uImage says
0x10008000+kernel size is pretty close to 0x10C00000 ¿any additional memory for kernel overwritten intiramfs start memory zone?
kernel looks for intramfs at 0x10C00000 but it founds ¿kernel written data?. So, no ram disk is mounted
I remembered a piece of start log:
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xf4600000 - 0xffe00000 ( 184 MB)
vmalloc : 0xc0800000 - 0xf2000000 ( 792 MB)
lowmem : 0x80000000 - 0xc0000000 (1024 MB)
pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)
modules : 0x7f000000 - 0x7fe00000 ( 14 MB)
.init : 0x80008000 - 0x8003a000 ( 200 kB)
.text : 0x8003a000 - 0x809ef038 (9941 kB)
.data : 0x809f0000 - 0x80a444a0 ( 338 kB)
Seems as if kernel knows the memory as 0x80000000 (where uboot sees it as 0x10000000).
Code kernel sizes up to 0x8003a000. Kernel uses up to 0x80a444a0 for data and variables (see System.map at kernel compilation). Initramfs, when start failed, is at 0x80C00000.
I suposse kernel initialitation starts to ask for available memory just beginning from 0x80a444a0 and it overwrites the initramfs file.
Yes. That was the trick that made it work. I was trying to understand why.
Yet I have an unsoresolved question (between many other:):
- Are uboot 0x10c00000 and kernel 0x80c0000 the same physical memory address?
I think the answer is yes, but I am not able to find anybody talking about this change of addresses from u-boot to kernel
Thank you and bests regarads,