qemu-block
[Top][All Lists]
Advanced

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

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


From: Bin Meng
Subject: Re: [PATCH] hw/sd: Zero out function selection fields before being populated
Date: Wed, 28 Oct 2020 09:36:33 +0800

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
> 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.

>
> 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



reply via email to

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