Re: [RFC PATCH v1 00/12] *** Add allwinner R40 device support ***

[Peter Maydell]

On Wed, 8 Mar 2023 at 20:47, Niek Linnenbank <nieklinnenbank@gmail.com> wrote:
> Thanks for contributing this work to Qemu! With your contribution, we would 
> get yet another Allwinner SoC supported, making it three in total 
> (A10/H3/R40). That's great.
> My thoughts are that maybe we should try to re-use commonality between these 
> SoCs where we can. Ofcourse, that may be difficult as the 
> internals/peripherals of these SoCs often really are different.

Thanks for having had a look at this patchset, Niek -- it
has saved me a job :-)

> Your patches look good already, and I saw patches 02 and 03 are already 
> merged too. I did a quick regression test with
> avocado for cubieboard/orangepi-pc with your patches applied and that went OK:
>
> $ ARMBIAN_ARTIFACTS_CACHED=yes AVOCADO_ALLOW_LARGE_STORAGE=yes 
> ./build/tests/venv/bin/avocado --show=app,console run -t machine:orangepi-pc 
> -t machine:cubieboard tests/avocado/boot_linux_console.py
> ...
> PASS (22.09 s)
> RESULTS    : PASS 8 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | 
> CANCEL 0
> JOB TIME   : 169.73 s
>
> For now, I have only two suggestions for you to consider:
> 1) You could add a new acceptance test for the new bananapi board to 
> ./tests/avocado/boot_linux_console.py.
> This helps in your current work to (re)test your code quickly, and after the 
> code is merged it helps to keep to board working when other changes are done.
> 2) If time permits, it may be interesting to document your board for example 
> in a new file at ./docs/system/arm/bananapi.rst
>    If you do this, it will make the board a lot more valuable for other 
> people to use, since you can add some basic instructions on how to use the 
> board with qemu there.
>    Additionally, it also helps yourself to store this information somewhere, 
> since it can be easy to forget all the specific commands/flags/arguments and 
> links to board specific images.

I think I would raise this to "definitely provide board documentation".
All our board models should have at least a basic documentation
page that says what the board model is, lists what QEMU does or
doesn't implement, and describes any QEMU-specific oddities.

thanks
-- PMM