Message ID | 20201023131808.3198005-1-f4bug@amsat.org |
---|---|
Headers | show |
Series | tests/acceptance: Test U-Boot/Linux from Armbian 20.08 on Orange Pi PC | expand |
Hi Philippe, On Fri, Oct 23, 2020 at 9:18 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > Series meant to help Bin Meng to debug the SD card issue > reported by Michael Roth. Thank you for the patches. > > Philippe Mathieu-Daudé (4): > Revert "hw/sd: Fix incorrect populated function switch status data > structure" > tests/acceptance: Allow running Orange Pi test using cached artifacts > tests/acceptance: Extract do_test_arm_orangepi_armbian_uboot() method > tests/acceptance: Test U-Boot/Linux from Armbian 20.08 on Orange Pi PC > > hw/sd/sd.c | 3 +- > tests/acceptance/boot_linux_console.py | 68 +++++++++++++++++++------- > 2 files changed, 50 insertions(+), 21 deletions(-) With this series, I used: $ ARMBIAN_ARTIFACTS_CACHED=1 AVOCADO_ALLOW_LARGE_STORAGE=1 make check-acceptance It looks that the failure still exists? Log below: 13-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_orangepi_bionic_20_08/debug.log: 01:11:27 DEBUG| => boot 01:11:27 DEBUG| unable to select a mode 01:11:27 DEBUG| Device 0: unknown device 01:11:27 DEBUG| BOOTP broadcast 1 01:11:27 DEBUG| DHCP client bound to address 10.0.2.15 (1 ms) 01:11:27 DEBUG| *** Warning: no boot file name; using '0A00020F.img' 01:11:27 DEBUG| Using ethernet@1c30000 device 01:11:27 DEBUG| TFTP from server 10.0.2.2; our IP address is 10.0.2.15 01:11:27 DEBUG| Filename '0A00020F.img'. 01:11:27 DEBUG| Load address: 0x42000000 01:11:27 DEBUG| Loading: *^H 01:11:27 DEBUG| TFTP error: 'Access violation' (2) 01:11:27 DEBUG| Not retrying... Regards, Bin
On 10/23/20 7:42 PM, Bin Meng wrote: > Hi Philippe, > > On Fri, Oct 23, 2020 at 9:18 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >> >> Series meant to help Bin Meng to debug the SD card issue >> reported by Michael Roth. > > Thank you for the patches. > >> >> Philippe Mathieu-Daudé (4): >> Revert "hw/sd: Fix incorrect populated function switch status data >> structure" >> tests/acceptance: Allow running Orange Pi test using cached artifacts >> tests/acceptance: Extract do_test_arm_orangepi_armbian_uboot() method >> tests/acceptance: Test U-Boot/Linux from Armbian 20.08 on Orange Pi PC >> >> hw/sd/sd.c | 3 +- >> tests/acceptance/boot_linux_console.py | 68 +++++++++++++++++++------- >> 2 files changed, 50 insertions(+), 21 deletions(-) > > With this series, I used: > > $ ARMBIAN_ARTIFACTS_CACHED=1 AVOCADO_ALLOW_LARGE_STORAGE=1 make check-acceptance > > It looks that the failure still exists? Log below: > > 13-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_orangepi_bionic_20_08/debug.log: > > 01:11:27 DEBUG| => boot > 01:11:27 DEBUG| unable to select a mode > 01:11:27 DEBUG| Device 0: unknown device > 01:11:27 DEBUG| BOOTP broadcast 1 > 01:11:27 DEBUG| DHCP client bound to address 10.0.2.15 (1 ms) > 01:11:27 DEBUG| *** Warning: no boot file name; using '0A00020F.img' > 01:11:27 DEBUG| Using ethernet@1c30000 device > 01:11:27 DEBUG| TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > 01:11:27 DEBUG| Filename '0A00020F.img'. > 01:11:27 DEBUG| Load address: 0x42000000 > 01:11:27 DEBUG| Loading: *^H > 01:11:27 DEBUG| TFTP error: 'Access violation' (2) > 01:11:27 DEBUG| Not retrying... Have you rebuilt qemu-system-arm with the reverted patch included? > > Regards, > Bin >
Hi Philippe, On Sat, Oct 24, 2020 at 1:56 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > On 10/23/20 7:42 PM, Bin Meng wrote: > > Hi Philippe, > > > > On Fri, Oct 23, 2020 at 9:18 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > >> > >> Series meant to help Bin Meng to debug the SD card issue > >> reported by Michael Roth. > > > > Thank you for the patches. > > > >> > >> Philippe Mathieu-Daudé (4): > >> Revert "hw/sd: Fix incorrect populated function switch status data > >> structure" > >> tests/acceptance: Allow running Orange Pi test using cached artifacts > >> tests/acceptance: Extract do_test_arm_orangepi_armbian_uboot() method > >> tests/acceptance: Test U-Boot/Linux from Armbian 20.08 on Orange Pi PC > >> > >> hw/sd/sd.c | 3 +- > >> tests/acceptance/boot_linux_console.py | 68 +++++++++++++++++++------- > >> 2 files changed, 50 insertions(+), 21 deletions(-) > > > > With this series, I used: > > > > $ ARMBIAN_ARTIFACTS_CACHED=1 AVOCADO_ALLOW_LARGE_STORAGE=1 make check-acceptance > > > > It looks that the failure still exists? Log below: > > > > 13-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_orangepi_bionic_20_08/debug.log: > > > > 01:11:27 DEBUG| => boot > > 01:11:27 DEBUG| unable to select a mode > > 01:11:27 DEBUG| Device 0: unknown device > > 01:11:27 DEBUG| BOOTP broadcast 1 > > 01:11:27 DEBUG| DHCP client bound to address 10.0.2.15 (1 ms) > > 01:11:27 DEBUG| *** Warning: no boot file name; using '0A00020F.img' > > 01:11:27 DEBUG| Using ethernet@1c30000 device > > 01:11:27 DEBUG| TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > > 01:11:27 DEBUG| Filename '0A00020F.img'. > > 01:11:27 DEBUG| Load address: 0x42000000 > > 01:11:27 DEBUG| Loading: *^H > > 01:11:27 DEBUG| TFTP error: 'Access violation' (2) > > 01:11:27 DEBUG| Not retrying... > > Have you rebuilt qemu-system-arm with the reverted patch included? Oops, I took it for granted that the `make check-acceptance` will automatically rebuild the QEMU binary, which is not the case. Should we enforce the rebuild before testing in Makefiles? Regards, Bin
On 10/24/20 3:06 AM, Bin Meng wrote: > Hi Philippe, > > On Sat, Oct 24, 2020 at 1:56 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >> >> On 10/23/20 7:42 PM, Bin Meng wrote: >>> Hi Philippe, >>> >>> On Fri, Oct 23, 2020 at 9:18 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: >>>> >>>> Series meant to help Bin Meng to debug the SD card issue >>>> reported by Michael Roth. >>> >>> Thank you for the patches. >>> >>>> >>>> Philippe Mathieu-Daudé (4): >>>> Revert "hw/sd: Fix incorrect populated function switch status data >>>> structure" >>>> tests/acceptance: Allow running Orange Pi test using cached artifacts >>>> tests/acceptance: Extract do_test_arm_orangepi_armbian_uboot() method >>>> tests/acceptance: Test U-Boot/Linux from Armbian 20.08 on Orange Pi PC >>>> >>>> hw/sd/sd.c | 3 +- >>>> tests/acceptance/boot_linux_console.py | 68 +++++++++++++++++++------- >>>> 2 files changed, 50 insertions(+), 21 deletions(-) >>> >>> With this series, I used: >>> >>> $ ARMBIAN_ARTIFACTS_CACHED=1 AVOCADO_ALLOW_LARGE_STORAGE=1 make check-acceptance >>> >>> It looks that the failure still exists? Log below: >>> >>> 13-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_orangepi_bionic_20_08/debug.log: >>> >>> 01:11:27 DEBUG| => boot >>> 01:11:27 DEBUG| unable to select a mode >>> 01:11:27 DEBUG| Device 0: unknown device >>> 01:11:27 DEBUG| BOOTP broadcast 1 >>> 01:11:27 DEBUG| DHCP client bound to address 10.0.2.15 (1 ms) >>> 01:11:27 DEBUG| *** Warning: no boot file name; using '0A00020F.img' >>> 01:11:27 DEBUG| Using ethernet@1c30000 device >>> 01:11:27 DEBUG| TFTP from server 10.0.2.2; our IP address is 10.0.2.15 >>> 01:11:27 DEBUG| Filename '0A00020F.img'. >>> 01:11:27 DEBUG| Load address: 0x42000000 >>> 01:11:27 DEBUG| Loading: *^H >>> 01:11:27 DEBUG| TFTP error: 'Access violation' (2) >>> 01:11:27 DEBUG| Not retrying... >> >> Have you rebuilt qemu-system-arm with the reverted patch included? > > Oops, I took it for granted that the `make check-acceptance` will > automatically rebuild the QEMU binary, which is not the case. Should > we enforce the rebuild before testing in Makefiles? Well I'm not sure, because I don't want to have to rebuild all targets before rerunning a single test, but this is a Meson issue that could be fixed soon. I'll let Cleber/Paolo decide. Does that mean I can add your "Tested-by: Bin Meng <bin.meng@windriver.com>" to the test patches btw? > > Regards, > Bin >
On 24/10/20 09:34, Philippe Mathieu-Daudé wrote: >> >> Oops, I took it for granted that the `make check-acceptance` will >> automatically rebuild the QEMU binary, which is not the case. Should >> we enforce the rebuild before testing in Makefiles? > > Well I'm not sure, because I don't want to have to rebuild all > targets before rerunning a single test, but this is a Meson issue > that could be fixed soon. I'll let Cleber/Paolo decide. It's actually Makefile since check-acceptance is not meson-ified. If you want to add the dependency just write $(filter qemu-system-%, $(ninja-targets)) Paolo > Does that mean I can add your "Tested-by: Bin Meng > <bin.meng@windriver.com>" to the test patches btw?
Hi Philippe, On Sat, Oct 24, 2020 at 3:34 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > On 10/24/20 3:06 AM, Bin Meng wrote: > > Hi Philippe, > > > > On Sat, Oct 24, 2020 at 1:56 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > >> > >> On 10/23/20 7:42 PM, Bin Meng wrote: > >>> Hi Philippe, > >>> > >>> On Fri, Oct 23, 2020 at 9:18 PM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > >>>> > >>>> Series meant to help Bin Meng to debug the SD card issue > >>>> reported by Michael Roth. > >>> > >>> Thank you for the patches. > >>> > >>>> > >>>> Philippe Mathieu-Daudé (4): > >>>> Revert "hw/sd: Fix incorrect populated function switch status data > >>>> structure" > >>>> tests/acceptance: Allow running Orange Pi test using cached artifacts > >>>> tests/acceptance: Extract do_test_arm_orangepi_armbian_uboot() method > >>>> tests/acceptance: Test U-Boot/Linux from Armbian 20.08 on Orange Pi PC > >>>> > >>>> hw/sd/sd.c | 3 +- > >>>> tests/acceptance/boot_linux_console.py | 68 +++++++++++++++++++------- > >>>> 2 files changed, 50 insertions(+), 21 deletions(-) > >>> > >>> With this series, I used: > >>> > >>> $ ARMBIAN_ARTIFACTS_CACHED=1 AVOCADO_ALLOW_LARGE_STORAGE=1 make check-acceptance > >>> > >>> It looks that the failure still exists? Log below: > >>> > >>> 13-tests_acceptance_boot_linux_console.py_BootLinuxConsole.test_arm_orangepi_bionic_20_08/debug.log: > >>> > >>> 01:11:27 DEBUG| => boot > >>> 01:11:27 DEBUG| unable to select a mode > >>> 01:11:27 DEBUG| Device 0: unknown device > >>> 01:11:27 DEBUG| BOOTP broadcast 1 > >>> 01:11:27 DEBUG| DHCP client bound to address 10.0.2.15 (1 ms) > >>> 01:11:27 DEBUG| *** Warning: no boot file name; using '0A00020F.img' > >>> 01:11:27 DEBUG| Using ethernet@1c30000 device > >>> 01:11:27 DEBUG| TFTP from server 10.0.2.2; our IP address is 10.0.2.15 > >>> 01:11:27 DEBUG| Filename '0A00020F.img'. > >>> 01:11:27 DEBUG| Load address: 0x42000000 > >>> 01:11:27 DEBUG| Loading: *^H > >>> 01:11:27 DEBUG| TFTP error: 'Access violation' (2) > >>> 01:11:27 DEBUG| Not retrying... > >> > >> Have you rebuilt qemu-system-arm with the reverted patch included? > > > > Oops, I took it for granted that the `make check-acceptance` will > > automatically rebuild the QEMU binary, which is not the case. Should > > we enforce the rebuild before testing in Makefiles? > > Well I'm not sure, because I don't want to have to rebuild all > targets before rerunning a single test, but this is a Meson issue > that could be fixed soon. I'll let Cleber/Paolo decide. > > Does that mean I can add your "Tested-by: Bin Meng > <bin.meng@windriver.com>" to the test patches btw? Sure. Regards, Bin
On 10/23/20 3:18 PM, Philippe Mathieu-Daudé wrote: > Series meant to help Bin Meng to debug the SD card issue > reported by Michael Roth. > > Philippe Mathieu-Daudé (4): > Revert "hw/sd: Fix incorrect populated function switch status data > structure" > tests/acceptance: Allow running Orange Pi test using cached artifacts > tests/acceptance: Extract do_test_arm_orangepi_armbian_uboot() method > tests/acceptance: Test U-Boot/Linux from Armbian 20.08 on Orange Pi PC > > hw/sd/sd.c | 3 +- > tests/acceptance/boot_linux_console.py | 68 +++++++++++++++++++------- > 2 files changed, 50 insertions(+), 21 deletions(-) Thanks, patch #2 applied to my acceptance-testing tree.