MFGTool - initramfs - and Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) error

[controlhorus]

Hello

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

to:

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?

Thank you,

Jose

Uboot run

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

:

[controlhorus]

Hello

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

Thanks,

Jose

[controlhorus]

Hello

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.

Thanks,

Jose

[alejandrolozan1]

Hi,

Have you tried to change the 0x10C00000  addres to a higher number?

It might be happenning that the images  are overlapping.

Best Regards,

Alejandro

[controlhorus]

Thanks Alejandro

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,

Jose.