Re: [PATCH v2 0/7] Enable Cubieboard A10 boot SPL from SD card

[Philippe Mathieu-Daudé]

On 18/12/22 23:57, Strahinja Jankovic wrote:
> Hi,
>
> I just looked around a bit more. Would OpenWrt image be acceptable?

Sure.

> It looks like there are releases for cubieboard that are kept for a
> longer time, and I just checked that they work properly, so I could
> add them to the acceptance test.
>
> Best regards,
> Strahinja
>
> On Sun, Dec 18, 2022 at 11:34 PM Strahinja Jankovic
> <strahinjapjankovic@gmail.com> wrote:
> > Hi,
> >
> >
> > On Sun, Dec 18, 2022 at 11:17 PM Philippe Mathieu-Daudé
> > <philmd@linaro.org> wrote:
> > > On 18/12/22 22:19, Strahinja Jankovic wrote:
> > > > This patch series adds missing Allwinner A10 modules needed for
> > > > successful SPL boot:
> > > > - Clock controller module
> > > > - DRAM controller
> > > > - I2C0 controller (added also for Allwinner H3 since it is the same)
> > > > - AXP-209 connected to I2C0 bus
> > > >
> > > > It also updates Allwinner A10 emulation so SPL is copied from attached
> > > > SD card if `-kernel` parameter is not passed when starting QEMU
> > > > (approach adapted from Allwinner H3 implementation).
> > > >
> > > > Boot from SD card has been tested with Cubieboard Armbian SD card image and 
> > > > custom
> > > > Yocto image built for Cubieboard.
> > > > Example usage for Armbian image:
> > > > qemu-system-arm -M cubieboard -nographic -sd 
> > > > ~/Armbian_22.11.0-trunk_Cubieboard_kinetic_edge_6.0.7.img
> > >
> > > As a follow-up, could you add a test similar to
> > > test_arm_orangepi_bionic_20_08() in tests/avocado/boot_linux_console.py?
> > >
> > > This test could be refactored as do_test_arm_allwinner_armbian(), called
> > > for orangepi and cubieboard with the corresponding url / hash.
> >
> > I was planning to do it (I already have a patch for cubieboard), but
> > there is a problem with finding a stable-enough image for cubieboard
> > for automated testing.
> > Unfortunately, Cubieboard does not have supported Armbian images as
> > OrangePi-PC has (it only has weekly builds).

Developers shouldn't worry about that but focus on the testing. The
QEMU project doesn't have dedicated sysadmin / storage, but if it had
it should be their problem, not yours. Meanwhile such a test is still
useful. Artifacts come with their hash, so can be uploaded elsewhere
later.

> > From the images that can
> > be found on archive.armbian.com, there is only one bionic image
> > (21.02) and it won't boot because it hangs due to the musb issue (I
> > tried both with my patches and without, by extracting
> > kernel/dtb/initrd).

Similar approach:
https://lore.kernel.org/qemu-devel/20201018205551.1537927-4-f4bug@amsat.org/

> > Other images are focal, but for some reason, in
> > those images it is impossible to interrupt U-Boot (tested with 21.08),
> > so I could not append to bootcmd to make boot process more verbose and
> > easier to monitor for automated testing.
> >
> > That is why, for now, I would suggest not updating the SPL/SD boot
> > test for Cubieboard.

Niek can tell how many times his tests catched regressions for his
OrangePi machine; I remember at least 3 occasions :)

Regards,

Phil.