qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/24] hw/arm: New board model mps3-an524


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH 00/24] hw/arm: New board model mps3-an524
Date: Fri, 5 Feb 2021 19:05:28 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

On 2/5/21 5:59 PM, Peter Maydell wrote:
> This patchseries implements a new board model in the mps2/mps3 family,
> based on Application Note AN524:
> https://developer.arm.com/documentation/dai0524/latest/
> 
> Like the other MPS models, this board is an FPGA image; the AN524
> image is based on the SSE-200, like the mps2-an521, but it is
> for the MPS3 board rather than the MPS2+. The major differences
> are QSPI flash and USB (which we don't model), and support for
> 2GB of RAM (which we do). Since the MPS3 is very similar to the
> MPS2, I've implemented mps3-an524 as a subclass of TYPE_MPS2TZ_MACHINE,
> sharing most of the code with mps2-an505 and mps2-an521.
> 
> The motivation for this model is two-fold:
>  * Linaro's Zephyr team would like it, so they can test their
>    code targeting the MPS3 on QEMU
>  * It's a useful stepping-stone towards a future MPS family model
>    which uses the SSE-300 and Cortex-M55. All the "make various bits
>    of mps2-tz.c be driven by per-board data structures rather than
>    hardcoding them" changes will be needed for that future board model.
>    This way they can be code-reviewed now, rather than making the
>    future patchseries even bigger (it will be pretty large even so,
>    because of all the "implement SSE-300 model" patches).
> 
> This model can run the parts of the AN524 selftest image that
> would be expected to work, i.e. the ones that don't rely on things
> QEMU doesn't implement.

Yes selftest are annoying when emulation :) Lot of features important
for real hardware but we can happily bypass when emulation.

> (The selftest is part of the AN524
> download so it's behind a EULA click-through and we can't put it
> into an acceptance test. We might be able to get something
> based on Zephyr or Arm TFM.)

Wondering about that... If anyone can go/click/accepts the EULA and
download artifacts, then I'd like these tests to be committed to the
repository, with a comment containing the download link, and the test
can use the skipUntil(BLOB_PATH && BLOB_HASH) syntax to assert the
binary I downloaded is the same you used for your test. Then I could
run locally:

  $ PATH_TO_EULA_ACCEPTED_ARTIFACTS=~/Private/DL avocado run ...

Would it be acceptable? What is missing or should be fixed?

Thanks,

Phil.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]