* [PATCH] hw/sd: Zero out function selection fields before being populated @ 2020-10-24 1:49 Bin Meng 2020-10-24 19:47 ` Philippe Mathieu-Daudé 2020-10-26 8:08 ` Philippe Mathieu-Daudé 0 siblings, 2 replies; 6+ messages in thread From: Bin Meng @ 2020-10-24 1:49 UTC (permalink / raw) To: Philippe Mathieu-Daudé, qemu-block, qemu-devel Cc: Bin Meng, Michael Roth 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) -- 2.25.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] hw/sd: Zero out function selection fields before being populated 2020-10-24 1:49 [PATCH] hw/sd: Zero out function selection fields before being populated Bin Meng @ 2020-10-24 19:47 ` Philippe Mathieu-Daudé 2020-10-26 8:08 ` Philippe Mathieu-Daudé 1 sibling, 0 replies; 6+ messages in thread From: Philippe Mathieu-Daudé @ 2020-10-24 19:47 UTC (permalink / raw) To: Bin Meng, qemu-block, qemu-devel; +Cc: Bin Meng, Michael Roth 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); This is indeed the simpler fix. Thanks for looking at it so quickly! Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> > for (i = 0; i < 6; i ++) { > new_func = (arg >> (i * 4)) & 0x0f; > if (mode && new_func != 0x0f) > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] hw/sd: Zero out function selection fields before being populated 2020-10-24 1:49 [PATCH] hw/sd: Zero out function selection fields before being populated Bin Meng 2020-10-24 19:47 ` Philippe Mathieu-Daudé @ 2020-10-26 8:08 ` Philippe Mathieu-Daudé 2020-10-28 9:47 ` Niek Linnenbank 1 sibling, 1 reply; 6+ messages in thread From: Philippe Mathieu-Daudé @ 2020-10-26 8:08 UTC (permalink / raw) To: Bin Meng, qemu-block, qemu-devel; +Cc: Bin Meng, Michael Roth 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] hw/sd: Zero out function selection fields before being populated 2020-10-26 8:08 ` Philippe Mathieu-Daudé @ 2020-10-28 9:47 ` Niek Linnenbank 2020-10-28 1:36 ` Bin Meng 0 siblings, 1 reply; 6+ messages in thread From: Niek Linnenbank @ 2020-10-28 9:47 UTC (permalink / raw) To: Philippe Mathieu-Daudé Cc: Bin Meng, Bin Meng, QEMU Developers, Qemu-block, Michael Roth [-- Attachment #1: Type: text/plain, Size: 4902 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 6357 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] hw/sd: Zero out function selection fields before being populated 2020-10-28 9:47 ` Niek Linnenbank @ 2020-10-28 1:36 ` Bin Meng 2020-10-28 10:10 ` Philippe Mathieu-Daudé 0 siblings, 1 reply; 6+ messages in thread From: Bin Meng @ 2020-10-28 1:36 UTC (permalink / raw) To: Niek Linnenbank Cc: Michael Roth, Bin Meng, Philippe Mathieu-Daudé, Qemu-block, QEMU Developers 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] hw/sd: Zero out function selection fields before being populated 2020-10-28 1:36 ` Bin Meng @ 2020-10-28 10:10 ` Philippe Mathieu-Daudé 0 siblings, 0 replies; 6+ messages in thread From: Philippe Mathieu-Daudé @ 2020-10-28 10:10 UTC (permalink / raw) To: Bin Meng, Niek Linnenbank Cc: Bin Meng, Michael Roth, Qemu-block, QEMU Developers 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-10-28 10:11 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-24 1:49 [PATCH] hw/sd: Zero out function selection fields before being populated Bin Meng 2020-10-24 19:47 ` Philippe Mathieu-Daudé 2020-10-26 8:08 ` Philippe Mathieu-Daudé 2020-10-28 9:47 ` Niek Linnenbank 2020-10-28 1:36 ` Bin Meng 2020-10-28 10:10 ` Philippe Mathieu-Daudé
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.