mbox series

[RFC,0/4] tests/acceptance: Test U-Boot/Linux from Armbian 20.08 on Orange Pi PC

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

Message

Philippe Mathieu-Daudé Oct. 23, 2020, 1:18 p.m. UTC
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(-)

-- 
2.26.2

Comments

Bin Meng Oct. 23, 2020, 5:42 p.m. UTC | #1
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
Philippe Mathieu-Daudé Oct. 23, 2020, 5:56 p.m. UTC | #2
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
>
Bin Meng Oct. 24, 2020, 1:06 a.m. UTC | #3
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
Philippe Mathieu-Daudé Oct. 24, 2020, 7:34 a.m. UTC | #4
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
>
Paolo Bonzini Oct. 24, 2020, 8:47 a.m. UTC | #5
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?
Bin Meng Oct. 24, 2020, 3:03 p.m. UTC | #6
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
Philippe Mathieu-Daudé Oct. 26, 2020, 8:49 a.m. UTC | #7
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.