On Wed, Sep 05, 2012 at 09:16:33PM +0800, Guodong Xu wrote: > > 2012-9-5 9:00 Dave Martin д > > > On Wed, Sep 05, 2012 at 04:32:01PM +0800, Guodong Xu wrote: > > Turn on CCI snoops. Data abort exception is captured and handled > > for implementations where CCI is not integrated. > > > This may work for now, but it's potentially fragile. We may get > platform variants where there is some different peripheral at 0x2c090000. > > > <guodong> Actually, peripheral base address should be get by reading cp15, for > both > GIC (+0x1000), and CCI (+0x90000). Eg. > ; Get the address of the GIC > MRC p15, 4, r0, c15, c0, 0 ; Read periph base address (see > DE593076) > ADD r0, r0, #0x1000 ; Add GIC offset to base address > > But in current boot wrapper, GIC address is also hardcoded, so I just follow > for CCI. > Maybe I can submit another patch to change both these to reading from cp15? It might be appropriate to find the GIC base this way since the bootwrapper only supports a limited set of platforms, though in general it's broken (it only works on certain CPUs, the address you get is sometimes wrong, and it's not very useful for SoCs with multiple GICs). I suggest not to bother changing this until we encounter a platform which really does have a different base address for the GIC (unless you are already trying to use the bootwrapper with such a platform). So far as I know, there's no guarantee that the CCI base address is at a fixed offset from periphbase. Do you have specific documentation of this somewhere? > > > > > The cleanest solution would be to examine the device tree, but > > <guodong> Our tests show 'Turning on CCI snoop' in Hyp mode fails. But current > boot-wrapper C code > and Linux kernel runs in Hyp mode. So, device tree method may not work. Hmmm, I think this must be because those registers can only be manipulated while we are still in the Secure World. I've posted an experimental RFC hack to delay the switch until much later, just before the kernel has been entered (see separate CC). If this works, we have a chance to control the CCI enabling code via the semihosting command-line or the DT. For simplicity, we could have something like: --board=<string> where <string> is the appopriate top-level compatible string from the relevant .dts file. If we are given a DT, we should just get the compatible string from there instead of looking at the command-line. In the meantime, we can just have a table of function pointers for the extra setup code each platform needs. We could then fix the code later to use the actual gic and cci nodes from the device tree when those are available. (But as mentioned above, it may not be worth abstracting the GIC in this way until we really need to). Cheers ---Dave _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
