Bug 7580

Update : After discussing on IRC (with NRoach44), here are some tests I did :

* First, I tried modifying the conf in menuconfig so that the generated rootfs was in ext3 instead of ext2. This worked out of the box nicely.

* Then, I used again the ext2 filesystem for the rootfs, and disabled any filesystem support in linux-menuconfig except the first line, corresponding to ext2.

In this case, I got the following error instead of the previous one :
2.331848] Waiting for root device /dev/mmcblk0p2...
2.363922] mmcblk0: mmc0:59b4 SDC   7.34 GiB
2.372253]  mmcblk0: p1 p201.
2.455871] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -19
2.464447] Please append a correct "root=" boot option; here are the available partitions:
2.473388] b300         7697408 mmcblk0  driver: mmcblkiales
2.477478]   b301           72261 mmcblk0p1 00000000-01
2.477478]   b302         7622842 mmcblk0p2 00000000-02
2.490356] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)

I tried to mount mmcblk0p2 on my computer, and it mounted successfully using the ext2 filesystem.

(In reply to comment #1)

> In this case, I got the following error instead of the previous one :
> 2.331848] Waiting for root device /dev/mmcblk0p2...
> 2.363922] mmcblk0: mmc0:59b4 SDC   7.34 GiB
> 2.372253]  mmcblk0: p1 p201.
> 2.455871] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2):
> error -19
> 2.464447] Please append a correct "root=" boot option; here are the available
> partitions:
> 2.473388] b300         7697408 mmcblk0  driver: mmcblkiales
> 2.477478]   b301           72261 mmcblk0p1 00000000-01
> 2.477478]   b302         7622842 mmcblk0p2 00000000-02
> 2.490356] Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(179,2)

Did you had the "rootwait" parameter passed on the kernel command line?

(In reply to comment #2)
> (In reply to comment #1)
> 
> > In this case, I got the following error instead of the previous one :
> > 2.331848] Waiting for root device /dev/mmcblk0p2...
> > 2.363922] mmcblk0: mmc0:59b4 SDC   7.34 GiB
> > 2.372253]  mmcblk0: p1 p201.
> > 2.455871] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2):
> > error -19
> > 2.464447] Please append a correct "root=" boot option; here are the available
> > partitions:
> > 2.473388] b300         7697408 mmcblk0  driver: mmcblkiales
> > 2.477478]   b301           72261 mmcblk0p1 00000000-01
> > 2.477478]   b302         7622842 mmcblk0p2 00000000-02
> > 2.490356] Kernel panic - not syncing: VFS: Unable to mount root fs on
> > unknown-block(179,2)
> 
> Did you had the "rootwait" parameter passed on the kernel command line?

Not sure about it. I finally got a working setup using Ubuntu 12.04 and the TI OMAP kernel. Though it's quite old stuff, it's the only fully working setup I had so far.

Using buildroot, I just used the defconfig file associated with pandaboard, which was expecting to produce a working (although minimalistic, so potentially without Bluetooth / wifi and that kind of stuff) image for the Pandaboard. Clearly, the easy way is to use this image with an ext3 partition. But using ext2 might requires some tweaking and this image is no longer working out of the bo, that's what I wanted to report.

I don't have it right now to find the exact kernel parameteres which are passed.

Unfortunately, due to lack of details, it's hard to know whether this bug is really a Buildroot bug, or a configuration error in the kernel arguments / usage of the Buildroot image. Since there is really not much difference between the process to generate an ext2 and ext3 image in Buildroot, I'm leaning towards some other configuration issue done by the bug reporter when using the Buildroot image.

I'll therefore mark this bug as "worksforme", since we're using the ext2 filesystem image successfully on other systems. Feel free to reopen with more details (kernel version, kernel configuration, kernel argument, full kernel log) if you don't agree with my conclusion.

(In reply to comment #4)
> Unfortunately, due to lack of details, it's hard to know whether this bug is
> really a Buildroot bug, or a configuration error in the kernel arguments /
> usage of the Buildroot image. Since there is really not much difference between
> the process to generate an ext2 and ext3 image in Buildroot, I'm leaning
> towards some other configuration issue done by the bug reporter when using the
> Buildroot image.
> 
> I'll therefore mark this bug as "worksforme", since we're using the ext2
> filesystem image successfully on other systems. Feel free to reopen with more
> details (kernel version, kernel configuration, kernel argument, full kernel
> log) if you don't agree with my conclusion.

Hmmm, I think I may have missed something. Here are the *exact* steps I used to build the faulty image :

* Clone buildroot repo
* In this repo, `make pandaboard_defconfig`
* Checked the settings, did *not* change anything.
* `make`
* Create the partitions on the SD, cf http://elinux.org/Panda_How_to_buildroot
* Copy MLO, u-boot.bin, uImage and .dtb file to the first partition on the SD card.
* `dd` the .ext2 file onto the second partition of the device.
* Put the SD card in the Pandaboard, power it on and see what is going on over serial.

With *nothing* else than these steps, it does *not* boot, due to the first error reported.

After having came accross this error, I played a bit with the settings until I could figure out something working.



I finally moved to the minimal Ubuntu 12.04 image with TI kernel, which allows me to use wifi / ethernet / bluetooth / ducati etc out of the box, so I did not do further tests. I can do some extra tests this week, if such tests are necessary, but I did not tweak the defconfig before building it.

I may have missed something, but as far as I understood, this was supposed to work and the defconfig was supposed to provide a basic setup running out of the box on the pandaboard (although it may not have all the stuff to use all the devices on the Pandaboard).

Please provide the *complete* boot log of the system, in both the working and non-working configurations. Thanks!

Created attachment 5768 [details]
Full log on serial on boot.

(In reply to comment #7)
> Created attachment 5768 [details]
> Full log on serial on boot.

I attached the full log obtained on serial after following the steps described in comment #5 (failed boot).

P.S.: Sorry for the double comment, I missed the comment area in the attachment…

I could successfully reproduce this error.

The problem is that an ext2 rootfs image is generated, and by default u-boot passes rootfstype=ext3 to the kernel command line, so the kernel panics trying to mount ext2 as ext3:

[    2.573730] No filesystem could mount root, tried:  ext3
[    2.578399] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)

Changing rootfs to ext3 or removing rootfstype from the kernel command line should fix this problem.

I've also tested with the last U-Boot mainline (2015.10) and it worked (this version does not pass rootfstype to the kernel command line).

So I'm preparing a patch to bump U-Boot and kernel version and fix this problem.

(In reply to Sergio Prado from comment #9)
Thanks a lot for the investigation Sergio, definitely much appreciated! Looking forward to seeing your patches on the list to update the Pandaboard support. Thanks!

Fixed by commit:

commit 000b972f49bcf9ed35417bb787a4440f22b12f8e
Author: Sergio Prado <sergio.prado@e-labworks.com>
Date:   Tue Feb 9 16:14:52 2016 -0200

    configs: pandaboard: bump u-boot to 2015.10 and kernel to 4.3
    
    VFPv3 and NEON was enabled and a readme.txt file was added.
    
    Fixes bug #7580.
    
    Tested on Pandaboard ES.
    
    [Peter: use EABIhf]
    Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
    Signed-off-by: Peter Korsgaard <peter@korsgaard.com>