On 12 August 2016 at 09:38, Cédric Le Goater <c...@kaod.org> wrote: > On 08/11/2016 12:47 PM, Peter Maydell wrote: >> On 2 August 2016 at 18:15, Cédric Le Goater <c...@kaod.org> wrote: >>> On the AST2500, I am still having a little issue under uboot which >>> sets the vbar doing : >>> >>> mcr p15, 0, r0, c12, c0, 0 /* Set VBAR */ >>> >>> and this is trapped as an undefined instruction by qemu. >>> >>> Looking at hw/arm/helper.c, the VBAR register seems to be defined >>> only for feature ARM_FEATURE_V7 (v7_cp_reginfo). The AST2500 SoC >>> uses a arm1176 which defines ARM_FEATURE_EL3 which gives us a >>> VBAR_EL3. According to th specs, the arm1176jzf-s has a Vector >>> Base Address Register. So am I missing something in the board >>> definition or is uboot being too optimistic on the cpu features ? >>> This is confusing for me, some direction would be welcomed :) >> >> This looks like a bug in helper.c -- we originally added the VBAR >> definition as a bit of a hack since it's only supposed to exist >> in CPUs with the security extensions and at the time we didn't >> implement those at all. It should definitely exist in the 1176 >> too, so we should move the definition around somewhere so it does. >> (The 1176 is the only non-v7 CPU with security extensions support, >> which is why it got missed I suspect.) > > OK. I will give it a try in a standalone patch. Is there a scenario > I could use to catch possible regression on other cpus ?
I don't have any test cases to hand that I know use VBAR, no. thanks -- PMM
