Re: [PATCH] hw/sd: Zero out function selection fields before being populated

[Philippe Mathieu-Daudé]

On 10/28/20 2:36 AM, Bin Meng wrote:
> Hi Niek,
> 
> On Wed, Oct 28, 2020 at 3:55 AM Niek Linnenbank
> <nieklinnenbank@gmail.com> wrote:
>>
>> 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

Same problem as before.

>> 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
> 
> Correct. The patch above has not been applied yet, and only this patch
> is now in mainline, so you will still see errors in the NetBSD 9.0
> test.

Yesterday was "feature freeze" but we still have time to do more testing
and fix bugs :)
I didn't want to rush and squeeze this fix too quickly. I kept it for
the next pull request so I have time to review and think about it more.

Thanks for the testing!

> 
>>
>> 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?
>>
> 
> Regards,
> Bin
>