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