On Mon, May 09, 2022 at 11:59:59AM +0200, Cornelia Huck wrote:
On Fri, May 06 2022, Mark Brown broonie@kernel.org wrote:
I would expect them to work, they seemed happy when I was doing the async mode support IIRC and a quick spin with -next in qemu everything seems fine, I'm travelling so don't have the environment for models to hand right now.
Thanks; I think that points to some setup/config problem on my side, then :/ (I ran the selftests under QEMU's tcg emulation, and while it looks better, I still get timeouts for check_gcr_el1_cswitch and check_user_mem.)
That might just be an actual timeout depending on the preformance of the host system.
where $AXF contains a kernel at v5.18-rc5-16-g107c948d1d3e[2] and an initrd built by mbuto[3] from that level with a slightly tweaked "kselftests" profile (adding /dev/shm).
What are you using for EL3 with the model? Both TF-A and boot-wrapper are in regular use, TF-A gets *way* more testing than boot-wrapper which is mostly used by individual developers.
I'm building the .axf via boot-wrapper-aarch64 (enabling psci and gicv3, if that matters.) Didn't try to make use of TF-A yet beyond the dtb (I'm still in the process of getting familiar with the arm64 world, so I'm currently starting out with the setups that others had shared with me.)
I'm now back with the models and it turns out that while qemu is happy I can reproduce what you're seeing with the model, at least as far back as v5.15 which suggests it's likely to be more operator error than a bug. Trying to figure it out now.