Actions
Forum Thread Details
  • State Verified Answer
  • Replies 6 replies
  • Subscribers 300 subscribers
  • Views 1329 views
  • Users 0 members are here
Related

adding packagegroup-core-buildessential boot problem - petalinux

mhanuel

Hello,

I have found that when adding packagegroup-core-buildessential using petalinux-config -c rootfs menu, my image is not been able to boot properly.

The error is

RAMDISK: Couldn't find valid RAM disk image starting at 0.
VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
0100           16384 ram0  (driver?)
random: fast init done
mmc1: new high speed MMC card at address 0001
0101           16384 ram1
 (driver?)
0102           16384 ram2
 (driver?)
0103           16384 ram3
 (driver?)
0104           16384 ram4
 (driver?)
0105           16384 ram5
 (driver?)
0106           16384 ram6
 (driver?)
0107           16384 ram7
 (driver?)
0108           16384 ram8
 (driver?)
0109           16384 ram9
 (driver?)
010a           16384 ram10
 (driver?)
010b           16384 ram11
 (driver?)
010c           16384 ram12
 (driver?)
010d           16384 ram13
 (driver?)
010e           16384 ram14
 (driver?)
010f           16384 ram15
 (driver?)
1f00           16320 mtdblock0
 (driver?)
1f01           13824 mtdblock1
 (driver?)
1f02              64 mtdblock2
 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
mmcblk1: mmc1:0001 Q2J55L 7.09 GiB
mmcblk1boot0: mmc1:0001 Q2J55L partition 1 16.0 MiB
mmcblk1boot1: mmc1:0001 Q2J55L partition 2 16.0 MiB
mmcblk1rpmb: mmc1:0001 Q2J55L partition 3 4.00 MiB
mmc0: new high speed SDIO card at address 0001
 mmcblk1: p1

 

I have notice my image grows ~20MB, yielding a final size around 92MB.

I have grow the /mnt/emmc partition to 1G.

If I remove the buildessential package my image boot correctly. For example

mmc1: new high speed MMC card at address 0001
Freeing unused kernel memory: 1024K (c0900000 - c0a00000)
INIT: mmcblk1: mmc1:0001 Q2J55L 7.09 GiB
mmcblk1boot0: mmc1:0001 Q2J55L partition 1 16.0 MiB
version 2.88 bootingmmcblk1boot1: mmc1:0001 Q2J55L partition 2 16.0 MiB
mmcblk1rpmb: mmc1:0001 Q2J55L partition 3 4.00 MiB
 mmcblk1: p1

mmc0: new high speed SDIO card at address 0001

Anyone has experience this issue before?

 

Will appreciate your comments,

  • 0

    Hi mhanuel,

    I am guessing that the changing size of the RAMdisk image is having some effect on either how it is packed into the image.ub file or how/where it is loaded into RAM.  In any case, it looks like it is somehow getting corrupted.

    Is it possible that you are running into this issue found here:

    https://forum.digilentinc.com/topic/621-zybo-tutorial-ramdisk-not-found/

    https://forums.xilinx.com/t5/Embedded-Linux/ZC702-How-to-use-uramdisk-image-gz/td-p/272416

    Also, keep in mind that MiniZed FAT32 partition on eMMC is only ~123089 1K-blocks large:

    root@minized_2017_2:~# df
    Filesystem           1K-blocks      Used Available Use% Mounted on
    devtmpfs                241956         0    241956   0% /dev
    tmpfs                   255444        84    255360   0% /run
    tmpfs                   255444        40    255404   0% /var/volatile
    /dev/mmcblk1p1          123089     24051     99038  20% /mnt
    root@minized_2017_2:~#

    Best Regards,

    -Kevin

  • 0 in reply to zedhed

    Hi Kevin,

    I have expanded the partition on emmc to 1024MB, for that I have booted into qspi and delete partition /dev/mmcblk1p1, then create a new one and it works so far, the only problem is when I build  packagegroup-core-buildessential into the image, I am not sure how this affect the image. 

    I was trying to find how it works the ramdisk but the links you provide are not closely related to this.

    root@MiniZed:/etc/init.d# df -h

    Filesystem                Size      Used Available Use% Mounted on
    devtmpfs                208.9M         0    208.9M   0% /dev
    tmpfs                   249.4M     96.0K    249.4M   0% /run
    tmpfs                   249.4M     44.0K    249.4M   0% /var/volatile
    /dev/mmcblk1p1          974.7M     69.1M    905.5M   7% /mnt/emmc
     
    Above you can see the size of /mnt/emmc, my current image which works is ~69M, the one with buildessential is circa 91M.
     
    I am using petalinux to build the image so in case the image is corrupted this might be a buggy petalinux 2017.2.
     
    In case you might wonder if this might be because of the new emmc partition size, I found the issue when working with 128M partition size as originally from minized bsp. 
     
    I will appreciate any hints to debug this issue,
     
    Thanks. 
     
  • 0 in reply to mhanuel

    I have found the problem has nothing to do with the package been added such buildessential, I remove that package and add python3 packages using petalinux-config -c rootfs, up to the point where my image.ub grows to ~ 82M

    root@MiniZed:~# ls -la /mnt/emmc/
    total 84524
    drwxr-xr-x    2 root     root          4096 Apr  4 23:52 .
    drwxr-xr-x    4 root     root            80 Apr  4 22:48 ..
    -rwxr-xr-x    1 root     root      85330484 Apr  5  2018 image.ub
    -rwxr-xr-x    1 root     root       1210300 Mar 22 17:11 smallboot.bin
    -rwxr-xr-x    1 root     root           169 Nov  3 01:05 wpa_supplicant.conf
     
     
    And the same behavior arise at boot
     
      RAMDISK: Couldn't find valid RAM disk image starting at 0.
      VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
      Please append a correct "root=" boot option; here are the available partitions:
      0100           16384 ram0  (driver?)
      random: fast init done
      mmc1: new high speed MMC card at address 0001
      0101           16384 ram1
       (driver?)
      0102           16384 ram2
       (driver?)
      0103           16384 ram3
       (driver?)
      0104           16384 ram4
       (driver?)
      0105           16384 ram5
       (driver?)
      0106           16384 ram6
       (driver?)
      0107           16384 ram7
       (driver?)
      0108           16384 ram8
       (driver?)
      0109           16384 ram9
       (driver?)
      010a           16384 ram10
       (driver?)
      010b           16384 ram11
       (driver?)
      010c           16384 ram12
       (driver?)
      010d           16384 ram13
       (driver?)
      010e           16384 ram14
       (driver?)
      010f           16384 ram15
       (driver?)
      1f00           16320 mtdblock0
       (driver?)
      1f01           13824 mtdblock1
       (driver?)
      1f02              64 mtdblock2
       (driver?)
      Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
      ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
       
      So my conclusion is that is something related to the image size
       
       
      I found this topic with similar problem but different architecture
       
       
      Someone from Avnet can shed some light here please.
       
      Comments will be appreciated!
       
  • 0

    Hi mhanuel,

    I agree, the evidence you provide points to some sort of limitation upon the RAMdisk image size.  Based upon that information, I came across this thread which shows similar behavior from 2016.4 tools, so it may not be entirely tools version dependent.

    https://forums.xilinx.com/t5/Embedded-Linux/Petalinux-2016-4-large-image-boot/td-p/751694

    The suggestion from that thread is to use INITRD instead of INITRAMFS strategy.

    There is a section entitled "Root file system Type Configuration" with more detailed instructions within UG1144:

    https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_2/ug1144-petalinux-tools-reference-guide.pdf

    Best Regards,

    -Kevin

  • 0

    I think the problem is that INITRAMFS is configured for 16 blocks of 16384k bytes, and when image.ub get decompressed, it becomes bigger, I notice this when migrate to ext4 rootfs on emmc.

    I wrote this guide in case someone is interested in a persistent rootfs on emmc using ext4. No more image.ub issue.

    https://www.hackster.io/mhanuel/minized-linux-tutorial-part-i-e2fa9d

    Cheers, 

  • 0

    Hi mhanuel,

    I was reading through this last night and did not put things together to realize you are the author until now.

    Thank you for putting this guide together!

    Best Regards,

    -Kevin