[PATCH 0/3] aarch64: boot in to EL1NS
Gedare Bloom
gedare at rtems.org
Wed Jan 12 18:40:06 UTC 2022
Thanks, I checked these in.
On Thu, Jan 6, 2022 at 3:38 PM Kinsey Moore <kinsey.moore at oarcorp.com> wrote:
>
> These changes look good. I'm glad you were able to simplify this a bit.
>
> As for the test failures, they all fall into that category of timing sensitive tests that QEMU breaks with large bursts of near-simultaneous timer ticks.
>
> Kinsey
>
> -----Original Message-----
> From: devel <devel-bounces at rtems.org> On Behalf Of Gedare Bloom
> Sent: Thursday, January 6, 2022 16:23
> To: devel at rtems.org
> Subject: Re: [PATCH 0/3] aarch64: boot in to EL1NS
>
> rtems-test results for xilinx-zynqmp_lp64_qemu with RTEMS_SMP:
>
> Passed: 632
> Failed: 5
> User Input: 5
> Expected Fail: 0
> Indeterminate: 3
> Benchmark: 3
> Timeout: 1
> Test too long: 1
> Invalid: 0
> Wrong Version: 0
> Wrong Build: 0
> Wrong Tools: 0
> Wrong Header: 0
> ------------------
> Total: 650
> Failures:
> spintrcritical24.exe
> smpschededf01.exe
> smpmrsp01.exe
> spintrcritical21.exe
> smpschedaffinity02.exe
>
> On Thu, Jan 6, 2022 at 3:13 PM Gedare Bloom <gedare at rtems.org> wrote:
> >
> > This patch series resolves a lingering problem with the
> > aarch64 port for the versal, which uses gicv3, that it
> > is not possible to initialize the GIC distributor and
> > redistributor (cpuif) while in the non-secure world.
> > Previously we added a configuration option to allow
> > running RTEMS in secure world as a way to overcome
> > this problem, but that is not the right thing to do
> > in general. Only trusted firmware is expected to run
> > in secure world, and it is not supported to run an SMP
> > kernel in secure world, so this problem needs a different
> > fix.
> >
> > We now use the bsp_start_hook_0 to initialize the GIC from
> > EL3 secure before stepping down to EL1NS.
> > This hook is only called when execution begins in EL3S, which is the
> > case for the versal running on qemu. GIC initialization is still
> > attempted again during the generic IRQ initialization. BSPs that
> > start in EL2 or EL1, or that use gicv2, behave as before, but the
> > BSP-specific SMP initialization for xilinx-zynqmp moves from hook_0
> > to hook_1.
> >
> > rtems-test results for xilinx-versal_lp64_qemu:
> > Passed: 578
> > Failed: 2
> > User Input: 5
> > Expected Fail: 0
> > Indeterminate: 0
> > Benchmark: 3
> > Timeout: 1
> > Test too long: 2
> > Invalid: 0
> > Wrong Version: 0
> > Wrong Build: 0
> > Wrong Tools: 0
> > Wrong Header: 0
> > ------------------
> > Total: 591
> > Failures:
> > sp69.exe
> > spintrcritical21.exe
> >
> > ------------------
> >
> > rtems-test results for xilinx-zynqmp_lp64_qemu:
> >
> > Passed: 577
> > Failed: 1
> > User Input: 5
> > Expected Fail: 0
> > Indeterminate: 3
> > Benchmark: 3
> > Timeout: 1
> > Test too long: 1
> > Invalid: 0
> > Wrong Version: 0
> > Wrong Build: 0
> > Wrong Tools: 0
> > Wrong Header: 0
> > ------------------
> > Total: 591
> > Failures:
> > spintrcritical21.exe
> >
> > ------------------
> >
> > Gedare Bloom (3):
> > bsps/aarch64: refactor register init and hooks
> > arm/gicv3: refactor DIST initialization to helper
> > aarch64: always boot into EL1NS
> >
> > bsps/aarch64/shared/start/start.S | 127 ++++++++++--------
> > .../xilinx-versal/start/bspstarthooks.c | 3 +-
> > .../xilinx-zynqmp/start/bspstarthooks.c | 12 +-
> > bsps/shared/dev/irq/arm-gicv3.c | 75 +++++------
> > spec/build/bsps/aarch64/a53/grp.yml | 2 -
> > spec/build/bsps/aarch64/a72/grp.yml | 2 -
> > spec/build/bsps/aarch64/optisns.yml | 20 ---
> > spec/build/bsps/aarch64/xilinx-versal/grp.yml | 2 -
> > spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml | 2 -
> > 9 files changed, 109 insertions(+), 136 deletions(-)
> > delete mode 100644 spec/build/bsps/aarch64/optisns.yml
> >
> > --
> > 2.25.1
> >
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
More information about the devel
mailing list