ARM-software / tf-issues

Issue tracking for the ARM Trusted Firmware project
37 stars 16 forks source link

GICv2 producing external aborts in Linux (aarch32) #686

Closed mmind closed 5 years ago

mmind commented 5 years ago

I'm trying to go a similar way as https://github.com/ARM-software/arm-trusted-firmware/pull/1828 creating a boot chain of uboot-spl --> BL32(sp_min) --> BL33(u-boot) --> Linux kernel and would like to replicate how aarch64 Rockchip platforms use TF-A for psci and such, as the synergies for also doing aarch32 psci in TF-A are quite high.

Platform for this experiment is the rk3288 (Cortex-A12).

So far reaching the Linux kernel actually works quite nicely, but early after start on the first read of any GICv2 register I run into an Unhandled fault: imprecise external abort

Reading other registers like the (secure) timer does work nicely [as the secure timer is not yet marked as secure in the SGRF]. Disabling GICv2 init in TF-A doesn't solve the issue.

Dropping the BL32 step completely makes the GICv2 behave again, so it looks like some more fundamental issue I have here, but so far my RK3288 implementation does look very similar to the Versatile Express FVP from the 1828-pull request, so I can't really see what may go wrong here and would be very glad about any pointers on what to poke :-)

Current state at https://github.com/mmind/arm-trusted-firmware/tree/wip/rk3288

soby-mathew commented 5 years ago

@mmind, The GICv2 registers are memory mapped. The BL32 could configure some of the interrupts as secure (Group0), but only registers corresponding to those secure interrupts would be RAZ/WI for the normal world. The other registers should still be accessible.

We are able to boot linux on multiple AArch32 platforms with the GICv2 driver. Is there any other component that controls non-secure accesses to peripherals/address space (eg: NIC-400 ?). Possibly that component needs initialization from within BL32.

mmind commented 5 years ago

Meanwhile I was able to track down the missing bit to set to enable non-secure access through the soc vendor, so now it boots thankfully :-) . Sorry for the slight noise