qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 00/20] Add Allwinner H3 SoC and Orange Pi PC Machine


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v4 00/20] Add Allwinner H3 SoC and Orange Pi PC Machine
Date: Tue, 18 Feb 2020 07:46:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

On 2/17/20 9:27 PM, Niek Linnenbank wrote:
Hi Philippe,

On Wed, Feb 12, 2020 at 11:12 PM Philippe Mathieu-Daudé <address@hidden <mailto:address@hidden>> wrote:

    On 2/12/20 10:47 PM, Niek Linnenbank wrote:
     > Hi all,
     >
     > Short status update regarding this series.
     >
     > Currently I am debugging booting NetBSD 9.0-RC2, which is recently
     > released [1]
     > The problem is that, apparently, RC2 can't mount the rootfs properly:
     >
     > [   3.1871510] vfs_mountroot: can't open root device
     > [   3.2141370] cannot mount root, error = 6
     >
     > This only happens using the RC2 filesystem image. However, the RC2
     > kernel can
     > properly load & boot the RC1 filesystem image, and the RC1 kernel
    gives
     > the same error
     > on the RC2 filesystem.  But I dont think its a NetBSD-RC2 issue,
    because
     > on a real
     > Orange Pi PC hardware board, this problem does not show.

    Linux shows:
        console: mmc0: Problem switching card into high-speed mode!

    QEMU MMC support is not in good shape, and high-speed SD card
    support is
    limited. I keep procrastinating at reviewing your SDHCI patch hmmmmm.

    So you added:

       * DMA transfers
       * Direct FIFO I/O
       * Short/Long format command responses

    I'd start diffing the trace output of the following events:

    allwinner_sdhost*
    sdcard*

    with both kernels.

Thanks for the kind suggestions Philippe.
Indeed, comparing the trace files of both the RC1 and RC2 kernels is one of the things I did, and many more.

After extensive low-level debugging, I discovered that the issue is much more simple than I thought. In particular, when using -sd <file>, the emulated device gets the same physical size as the file. Normally this is not a problem, but for the NetBSD RC2 image, the kernel reads the MBR partition table, compares it with the device size and concludes that the NetBSD partition in the image is larger than the actual device.

Unfortunately, this root cause is not printed on the NetBSD console, only the final  'can't open root device' message. Also, when running on hardware, obviously the SD card will be larger, e.g. 4GB or more, so that is why this issue does not show.

So the fix is to extend the input image by a few megabytes before booting it. And on the positive side, with this search we now have more confidence that the
emulated SD/MMC device in Qemu works as expected.

Good news!

IIRC from the specs, cards are block devices and the only alignment required is the size of a block (512KiB for your 4GiB card).

That said I never saw a card not pow2 aligned, but the card firmware should be able to discard blocks and announce fewer. Maybe FreeBSD is incorrect assuming a pow2 alignment?


Kind regards,
Niek

     >
     > I'm comparing traces and adding more low-level debug output to
    NetBSD
     > and QEMU to find the issue.
     >
     > Also I processed the review remarks which were send so far.
     >
     > Kind regards,
     > Niek
     >
     > [1] https://www.netbsd.org/releases/formal-9/NetBSD-9.0.html



--
Niek Linnenbank





reply via email to

[Prev in Thread] Current Thread [Next in Thread]