Hello Stefano,
This, what you wrote here is very correct assumption.
CONFIG_BLK_DEV_INITRD=y <<===== To have Block device initramfs/rootfs CONFIG_RD_GZIP=y <<===== To have initramfs/rootfs in .gz format CONFIG_RD_BZIP2=y <<===== To have initramfs/rootfs in .bz2 format CONFIG_RD_LZMA=y <<====== To have initramfs/rootfs in .7z format CONFIG_RD_XZ=y <<===== To have initramfs/rootfs in .xz format CONFIG_RD_LZO=y CONFIG_RD_LZ4=y
(I unsubscribed from u-boot list since every day there are gazillions of patches @ - you guys can reconsider to create one special mailing list for only U-Boot patches).
Thank you, Zoran _______
On Fri, Mar 2, 2018 at 11:03 AM, Stefano Babic sbabic@denx.de wrote:
Hi Zoran,
On 26/02/2018 11:57, Zoran S wrote:
Hello Stefano,
If it canot be mounted, the cause is in the most of cases in a missing configuration in kernel, like initrd not supported, missing compression type, and so on.
After some investigation, I found that you were correct, most likely. I did this investigation on two similar platforms, in two different environments (since one is corporate one, with some firewalls around, another is outside of the reach, simply it hangs on the open net, my private setup). Just to be sure that I excluded all the corporate security influences.
I used the off shelf kernel for BBB (BeagleBone Black), using YOCTO Project (Rocko release) to compile form the scratch, with assurance that this kernel is set correctly (configuration wise).
After several days of testing (since my U-Boot skills are a bit rusty, so I assumed I am scripting wrong), I have concluded that I have a correct U-Boot setup, but that the kernel image is not set correctly (as you suggested), since I tested it with at least 5 differently compiled ramdisks.
I found one BBB kernel on Linaro site (this one is Debian one, Linux beaglebone 4.9.0-4-armmp #1 SMP Debian 4.9.65-3 (2017-12-03) armv7l GNU/Linux), and tried it with minimal setup (have no idea what/how .config looks like), including ramdiskfs-es (I tested it with several ones, all compiled in the same YOCTO Rocko package) and DTB from the same.
It worked for me from the very first time (on both setups).
ok - this confirms that the defconfig for kernel in Yocto build does not contain enough to start from ramdisk.
Conclusion is: Something in .config is wrong. What? This needs some serious investigation, since I think the failed one is also set to use ramdisk.
Usually, some of these are missing:
CONFIG_BLK_DEV_INITRD=y CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_RD_LZ4=y
Of course, not all of them can be necessary, I am just speculating.
I would also check (but they should be on) the CONFIG_DECOMPRESS_* options and if not, you could turn them on.
I would like to thank you for the hint.
You're welcoime,
Best regards, Stefano
Best Regards, Zoran Stojsavljevic _______
On Wed, Feb 21, 2018 at 5:31 PM, Stefano Babic sbabic@denx.de wrote:
Hi Zoran,
On 21/02/2018 11:45, Zoran S wrote:
Hello to U-Boot list,
I have encountered an interesting problem which I do not entirely understand. I am trying to boot MLO and u-boot.bin from the SD Card, and rest from the initramfs.
I tried several initramfs images, and so far I am always failing on the same place: [ 2.135533] No filesystem could mount root, tried: [ 2.135541] ext2 [ 2.140682] [ 2.144262] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) [ 2.153034] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
I have tried mostly .gz images (cpio.gz and ext2.gz). Does not help. Even does not with ext2.gz after YOCTO is done. In order to do it correctly, I MUST to add U-Boot header, and I do this with the following command:
mkimage -n 'Ramdisk Image' -A arm -O linux -T ramdisk -C gzip -d initramfs.ext2.gz initramfs.uImage
And the image I actually supply is: initramfs.uImage
Then, the following happens:
=> run netloadfdt link up on port 0, speed 100, full duplex Using cpsw device TFTP from server 192.168.15.2; our IP address is 192.168.15.20 Filename 'am335x-boneblack.dtb'. Load address: 0x88000000 Loading: ### 697.3 KiB/s done Bytes transferred = 35016 (88c8 hex) => run netloadimage link up on port 0, speed 100, full duplex Using cpsw device TFTP from server 192.168.15.2; our IP address is 192.168.15.20 Filename 'zImage'. Load address: 0x82000000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ######################## 772.5 KiB/s done Bytes transferred = 4161160 (3f7e88 hex) => tftp 0x88080000 initramfs.uImage link up on port 0, speed 100, full duplex Using cpsw device TFTP from server 192.168.15.2; our IP address is 192.168.15.20 Filename 'initramfs.uImage'. Load address: 0x88080000 Loading: ################################################################# #################################################################
[snap] ####################################################### 767.6 KiB/sdone Bytes transferred = 46599246 (2c70c4e hex) => dhcp link up on port 0, speed 100, full duplex BOOTP broadcast 1 DHCP client bound to address 192.168.15.159 (21 ms) => run ramboot Booting from ramdisk ... ## Loading init Ramdisk from Legacy Image at 88080000 ... Image Name: Ramdisk Image Created: 2018-02-21 9:46:15 UTC Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 46599182 Bytes = 44.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Ramdisk to 8d38f000, end 8ffffc0e ... OK Loading Device Tree to 8d383000, end 8d38e8c7 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.13.8-jumpnow (oe-user@oe-host) (gcc version 7.2.0 (GCC)) #1 Tue Jan 9 15:37:12 CET 2018 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Black [ 0.000000] Memory policy: Data cache writeback [ 0.000000] cma: Reserved 16 MiB at 0x9f000000 [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] AM335X ES2.1 (sgx neon) [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
Please, note the Kernal Command line in the log! [ 0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/ram0 rw rootfstype=ext2 <<======================== Kernel Command Line
[SNAP]
[ 1.770469] omap_voltage_late_init: Voltage driver support not added [ 1.777510] ThumbEE CPU extension supported. [ 1.791397] mmcblk0: mmc0:59b4 USD 1.87 GiB [ 1.801349] mmcblk0: p1 p2 [ 1.868955] mmc1: new high speed MMC card at address 0001 [ 1.876511] mmcblk1: mmc1:0001 MMC04G 3.60 GiB [ 1.882230] mmcblk1boot0: mmc1:0001 MMC04G partition 1 2.00 MiB [ 1.890172] mmcblk1boot1: mmc1:0001 MMC04G partition 2 2.00 MiB [ 1.896948] mmcblk1rpmb: mmc1:0001 MMC04G partition 3 128 KiB [ 1.906237] mmcblk1: p1 p2 [ 1.925804] tps65217 0-0024: TPS65217 ID 0xe version 1.2 [ 1.932470] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz [ 1.948789] omap_rtc 44e3e000.rtc: setting system clock to 2017-12-04 18:09:58 UTC (1512410998) [ 1.963613] List of all partitions: [ 1.967311] 0100 16384 ram0 [ 1.967322] (driver?) [ 1.973831] 0101 16384 ram1 [ 1.973840] (driver?) [ 1.980294] 0102 16384 ram2 [ 1.980303] (driver?) [ 1.986703] 0103 16384 ram3 [ 1.986711] (driver?) [ 1.993144] 0104 16384 ram4 [ 1.993153] (driver?) [ 1.999582] 0105 16384 ram5 [ 1.999590] (driver?) [ 2.005991] 0106 16384 ram6 [ 2.005999] (driver?) [ 2.012428] 0107 16384 ram7 [ 2.012437] (driver?) [ 2.018903] 0108 16384 ram8 [ 2.018911] (driver?) [ 2.025313] 0109 16384 ram9 [ 2.025321] (driver?) [ 2.031776] 010a 16384 ram10 [ 2.031785] (driver?) [ 2.038304] 010b 16384 ram11 [ 2.038312] (driver?) [ 2.044804] 010c 16384 ram12 [ 2.044812] (driver?) [ 2.051344] 010d 16384 ram13 [ 2.051352] (driver?) [ 2.057871] 010e 16384 ram14 [ 2.057879] (driver?) [ 2.064371] 010f 16384 ram15 [ 2.064379] (driver?) [ 2.070912] b300 1960960 mmcblk0 [ 2.070922] driver: mmcblk [ 2.078079] b301 131072 mmcblk0p1 46a788a5-01 [ 2.078088] [ 2.085214] b302 1828863 mmcblk0p2 46a788a5-02 [ 2.085222] [ 2.092652] b308 3776512 mmcblk1 [ 2.092663] driver: mmcblk [ 2.099840] b309 98304 mmcblk1p1 00000000-01 [ 2.099849] [ 2.106975] b30a 3677184 mmcblk1p2 00000000-02 [ 2.106984] [ 2.114160] b320 128 mmcblk1rpmb [ 2.114169] (driver?) [ 2.121235] b318 2048 mmcblk1boot1 [ 2.121244] (driver?) [ 2.128401] b310 2048 mmcblk1boot0 [ 2.128410] (driver?) [ 2.135533] No filesystem could mount root, tried: [ 2.135541] ext2 [ 2.140682] [ 2.144262] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) [ 2.153034] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
What could be the (list of) problem(s) here?
I do not see how you start the kernel. Anyway, it shopuld be something like "bootz 0x82000000 0x88000000 0x88080000". This is enough for U-Boot to pass the offset for ramdisk to kernel.
If it canot be mounted, the cause is in the most of cases in a missing configuration in kernel, like initrd not supported, missing compression type, and so on.
Best regards, Stefano
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de =====================================================================
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de =====================================================================