Re: [U-Boot] Kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block (1, 0)

[Zoran S]

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  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  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: 0x8800
 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: 0x8200
 Loading: #
  

Re: [U-Boot] Kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block (1, 0)

[Stefano Babic]

Hi Zoran,

On 03/03/2018 08:18, Zoran S wrote:
> 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).
> 

This was already discussed - and rejected, too. In fact, this
constraints people to switch over and over from one ML to the other one,
and this makes things worse as better. We have also discussed to have
one ML per each subsystem, but we miss then the overview on the project.
U-Boot is not like the kernel where such split makes sense.

We all received thousands of e-mails each day - I need for my work, near
U-Boot ML, several kernel MLs (MTD, input, ARM, .) and several other
MLs from other projects. I just tell you that I cannot manage this
amount of traffic without help, and I use "imapfilter" on my server to
sort all incoming patches and put them in separate folders before my
e-mailer is checking them.

Best regards,
Stefano

> Thank you,
> Zoran
> ___
> 
> On Fri, Mar 2, 2018 at 11:03 AM, Stefano Babic  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  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

Re: [U-Boot] Kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block (1, 0)

[Stefano Babic]

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  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: 0x8800
>>> 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: 0x8200
>>> Loading: #
>>>  #
>>>  #
>>>  #
>>>  
>>>  772.5 KiB/s
>>> done
>>> Bytes transferred = 4161160 (3f7e88 hex)
>>> => tftp 0x8808 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: 0x8808
>>> Loading: #
>>>  #
>>>
>>>  [snap]
>>>
>>>  ###
>>>  767.6 KiB/s
>>> done
>>> Bytes transferred = 46599246 (2c70c4e hex)
>>> 

Re: [U-Boot] Kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block (1, 0)

[Zoran S]

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).

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.

I would like to thank you for the hint.

Best Regards,
Zoran Stojsavljevic
___

On Wed, Feb 21, 2018 at 5:31 PM, Stefano Babic  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: 0x8800
>> 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: 0x8200
>> Loading: #
>>  #
>>  #
>>  #
>>  
>>  772.5 KiB/s
>> done
>> Bytes transferred = 4161160 (3f7e88 hex)
>> => tftp 0x8808 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: 0x8808
>> Loading: #
>>  #
>>
>>  [snap]
>>
>>  ###
>>  767.6 KiB/s
>> done
>> 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 8808 ...
>>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: 
>>Entry Point:  
>>Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 8800
>>Booting using the fdt blob at 0x8800
>>Loading Ramdisk to 8d38f000, end 8c0e ... OK
>>Loading Device Tree to 8d383000, 

Re: [U-Boot] Kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block (1, 0)

[Zoran S]

Hello Stefano,

> I do not see how you start the kernel. Anyway, it should be something
> like "bootz 0x8200 0x8800 0x8808". This is enough for U-Boot
> to pass the offset for ramdisk to kernel.

Here is my environment:
https://pastebin.com/nN4AbqMK

in.tftpd is set correctly, it takes files from the VM, where these
files reside in tftp directory (zImage, am335x-boneblack.dtb,
initramfs.uImage).

initramfs.uImage is of type .ext2.gz.

Here is how I do it, starting from environment:
fdtfile=am335x-boneblack.dtb
bootfile=zImage
fdtaddr=0x8800
loadaddr=0x8200
console=ttyO0,115200n8
netloadfdt=tftp ${fdtaddr} ${fdtfile}
netloadimage=tftp ${loadaddr} ${bootfile}
ramargs=setenv bootargs console=${console} ${optargs} root=${ramroot}
rootfstype=${ramrootfstype}
ramboot=echo Booting from ramdisk ...; run ramargs; bootz ${loadaddr}
${rdaddr} ${fdtaddr}
___

Here are the commands I issued:

run netloadfdt
run netloadimage
tftp 0x8808 initramfs.uImage
dhcp (dhcpd is set on VM, BBB gets the address over private net
192.168.15.0/24 as 192.168.15.159)
run ramboot

Pls, note that rdaddr and fdtaddr changed the places (from your hint),
so it could be that this is the cause of the problem. I'll check upon
this.

> 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.

I doubt the actual cause is the missing compression, but missing
configuration in kernel, it very well could be.

I'll also check upon this.

Thank you,
Zoran
___

On Wed, Feb 21, 2018 at 5:31 PM, Stefano Babic  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: 0x8800
>> 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: 0x8200
>> Loading: #
>>  #
>>  #
>>  #
>>  
>>  772.5 KiB/s
>> done
>> Bytes transferred = 4161160 (3f7e88 hex)
>> => tftp 0x8808 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: 0x8808
>> Loading: #
>>  #
>>
>>  [snap]
>>
>>  ###
>>  767.6 KiB/s
>> done
>> 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 8808 ...
>>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: 
>>Entry Point:  
>>Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 8800
>>Booting using the fdt blob at 0x8800
>>Loading Ramdisk to 8d38f000, end 8c0e ... OK
>>Loading Device Tree to 8d383000, end 8d38e8c7 ... OK
>>
>> Starting kernel ...
>>
>> [0.00] Booting Linux on physical CPU 0x0

Re: [U-Boot] Kernel panic - not syncing: VFS: Unable to mount rootfs on unknown-block (1, 0)

[Stefano Babic]

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: 0x8800
> 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: 0x8200
> Loading: #
>  #
>  #
>  #
>  
>  772.5 KiB/s
> done
> Bytes transferred = 4161160 (3f7e88 hex)
> => tftp 0x8808 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: 0x8808
> Loading: #
>  #
> 
>  [snap]
> 
>  ###
>  767.6 KiB/s
> done
> 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 8808 ...
>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: 
>Entry Point:  
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>Loading Ramdisk to 8d38f000, end 8c0e ... OK
>Loading Device Tree to 8d383000, end 8d38e8c7 ... OK
> 
> Starting kernel ...
> 
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] 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.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black
> [0.00] Memory policy: Data cache writeback
> [0.00] cma: Reserved 16 MiB at 0x9f00
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] AM335X ES2.1 (sgx neon)
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 130048
> 
> Please, note the Kernal Command line in the log!
> [0.00] 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