Hello Philippe, Bin,

Thanks for your support on this. I've just tried this patch and
unfortunately it doesn't seem to
resolve the issue, at least on my machine. This is the output that I get
when running the avocado test for NetBSD9.0:

 (5/5)
tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_arm_orangepi_uboot_netbsd9:
|console: U-Boot SPL 2020.01+dfsg-1 (Jan 08 2020 - 08:19:44 +0000)
console: DRAM: 1024 MiB
console: Failed to set core voltage! Can't set CPU frequency
console: Trying to boot from MMC1
console: U-Boot 2020.01+dfsg-1 (Jan 08 2020 - 08:19:44 +0000) Allwinner
Technology
console: CPU:   Allwinner H3 (SUN8I 0000)
...
console: [   1.2957642] sdmmc0: SD card status: 4-bit, C0
console: [   1.3094731] ld0 at sdmmc0:
<0xaa:0x5859:QEMU!:0x01:0xdeadbeef:0x062>
console: [   1.3159383] ld0: 1024 MB, 1040 cyl, 32 head, 63 sec, 512
bytes/sect x 2097152 sectors
console: [   1.3763222] ld0: 4-bit width, High-Speed/SDR25, 50.000 MHz
console: [   2.0592109] WARNING: 4 errors while detecting hardware; check
system log.
console: [   2.0693403] boot device: ld0
console: [   2.0798960] root on ld0a dumps on ld0b
console: [   2.0994141] vfs_mountroot: can't open root device
console: [   2.0994141] cannot mount root, error = 6
<FREEZE>

When starting NetBSD 9.0 manually, it shows clearly that the SD card is
recognized with 1GiB size, also from U-Boot:
$ qemu-system-arm -M orangepi-pc -nographic -nic user -sd ./armv7.img
WARNING: Image format was not specified for './armv7.img' and probing
guessed raw.
         Automatically detecting the format is dangerous for raw images,
write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.

U-Boot SPL 2020.07-00610-g610e1487c8 (Jul 11 2020 - 22:31:58 +0200)
DRAM: 1024 MiB
Failed to set core voltage! Can't set CPU frequency
Trying to boot from MMC1

U-Boot 2020.07-00610-g610e1487c8 (Jul 11 2020 - 22:31:58 +0200) Allwinner
Technology

CPU:   Allwinner H3 (SUN8I 0000)
Model: Xunlong Orange Pi PC
DRAM:  1 GiB
MMC:   mmc@1c0f000: 0
...
Hit any key to stop autoboot:  0
=> mmc info
Device: mmc@1c0f000
Manufacturer ID: aa
OEM: 5859
Name: QEMU!
Bus Speed: 50000000
Mode: SD High Speed (50MHz)
Rd Block Len: 512
SD version 2.0
High Capacity: No
Capacity: 1 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
=>
=> boot
8846552 bytes read in 931 ms (9.1 MiB/s)
...
[   1.3447558] sdmmc0: SD card status: 4-bit, C0
[   1.3546801] ld0 at sdmmc0: <0xaa:0x5859:QEMU!:0x01:0xdeadbeef:0x062>
[   1.3647790] ld0: 1024 MB, 1040 cyl, 32 head, 63 sec, 512 bytes/sect x
2097152 sectors
[   1.4150230] ld0: 4-bit width, High-Speed/SDR25, 50.000 MHz
[   2.0800893] WARNING: 4 errors while detecting hardware; check system log.
[   2.0800893] boot device: ld0
[   2.0900792] root on ld0a dumps on ld0b
[   2.1004160] vfs_mountroot: can't open root device
[   2.1004160] cannot mount root, error = 6
[   2.1004160] root device (default ld0a):
<FREEZE>

Note that the image has been resized to 2GiB with qemu-img:
$ ls -alh armv7.img
-rw-rw-r-- 1 user user 2,0G okt 28 22:45 armv7.img

The previous patch proposed by Bin did resolve the error ("hw/sd: Fix 2GiB
card CSD register values" ):
 https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg07318.html

Although I see that this patch is now in master
(89c6700fe7eed9195f10055751edbc6d5e7ab940),
can you please confirm that the issue is still present when testing this on
your machine as well?

With kind regards,
Niek


On Mon, Oct 26, 2020 at 9:10 AM Philippe Mathieu-Daudé <f4bug@amsat.org>
wrote:

> On 10/24/20 3:49 AM, Bin Meng wrote:
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > The function selection fields (399:376) should be zeroed out to
> > prevent leftover from being or'ed into the switch function status
> > data structure.
> >
> > This fixes the boot failure as seen in the acceptance testing on
> > the orangepi target.
> >
> > Fixes: b638627c723a ("hw/sd: Fix incorrect populated function switch
> status data structure")
> > Reported-by: Michael Roth <mdroth@linux.vnet.ibm.com>
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > ---
> >
> >   hw/sd/sd.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/hw/sd/sd.c b/hw/sd/sd.c
> > index c3febed243..bd10ec8fc4 100644
> > --- a/hw/sd/sd.c
> > +++ b/hw/sd/sd.c
> > @@ -824,6 +824,7 @@ static void sd_function_switch(SDState *sd, uint32_t
> arg)
> >       sd->data[12] = 0x80;    /* Supported group 1 functions */
> >       sd->data[13] = 0x03;
> >
> > +    memset(&sd->data[14], 0, 3);
> >       for (i = 0; i < 6; i ++) {
> >           new_func = (arg >> (i * 4)) & 0x0f;
> >           if (mode && new_func != 0x0f)
> >
>
> Thanks, series applied to sd-next tree.
>
>

-- 
Niek Linnenbank