On Behalf Of
Immo Birnbaum via Lists.Zephyrproject.Org
Wednesday, February 26, 2020 9:55 PM
Re: [Zephyr-devel] ARMv7 Cortex-A port for Xilinx Zynq7000
here's my first update on the topic of the Zynq-7000 port, this is the progress so far:
- Set up a fresh development VM which now uses the Zephyr SDK, which works fine for the Cortex-A9.
- Forked the Zephyr repository and set up a feature branch, which can be found here: https://github.com/ibirnbaum/zephyr/tree/armv7_cortex_a
- Merged all of the changes/additions described above into the current code base.
- Updated the AXI GPIO driver to match the GPIO driver API which was heavily modified in the meantime.
- Kicked out my own GIC PL-390 interrupt controller driver and switched over to Stephanos Ionannidis' GICv1 implementation, including updated IRQ descriptors in the device tree files.
- I looked into the testsuite and ran tests on the QEMU Cortex-A9 target, plus a hand full of test cases on the actual hardware (as downloading the binary to the board is still a manual process using the Lauterbach TRACE software). The results don't look too
bad, for example, these are the results of the 'kernel' test suite:
* 86 test configurations selected, 8 configurations discarded due to filters
* 24 tests skipped (e.g. SMP/ARMv8/userspace related test cases)
* Out of the 62 remaining test cases, 60 pass. One (kernel.timer.tickless) fails to build due to an unresolved symbol (z_clock_uptime). This is odd for two reasons: one, all other 'tickless'-related tests are skipped and two, the Local APIC timer driver seems
to be the only timer driver implementing this function. To me, this looks more like a testsuite configuration issue? The other failure is the arch.interrupt test case, which actually runs but fails due to an assertion regarding the expected state of an IRQ
to be tested. This is due to the target IRQ selection logic only being implemented for Cortex-M when it comes to the ARM architecture.
The following testsuites pass all test cases on the QEMU target which aren't filtered out for whatever reason (I didn't blacklist anything myself):
I'll have to look into the details as to why in some cases, more test cases are filtered out than executed. In some cases, e.g. ARMv8-specific stuff, it's pretty obvious, but in others I'm suspecting that I ought to whitelist testcases or subsystems for testing,
likely in the target's YAML files? For example, despite having full Ethernet support, the 'net' testsuite in its current state does pretty much nothing.
I'll keep you updated and I'll look into the ongoing discussions and the mechanics of pull requests, I could start simple, as for example, the Xilinx TTC timer driver had a faulty prescaler calculation routine. As this source file is already in the main repository,
this might be a good exercise for a pull request. Until then, I'd appreciate any feedback if anyone feels like experimenting with my fork of the repository.