On 18 February 2014 01:14, Andreas Färber <afaer...@suse.de> wrote: > While first_cpu may help Andreas in his local copy for STM32, that > assumption is not okay in general. The Vybrid VF6 has both a GIC and an > NVIC, so our NVIC code should not make assumptions which CPU it can > access.
Do you mean it has an M core CPU with an NVIC plus some other A-class CPU with a GIC. Certainly in a system with heterogenous CPUs this change won't work, but we don't support that at all currently and there's a lot of work between here and there. > I assume we would shield both using CPU address spaces The GIC needs to know which CPU it's being accessed by. I guess in theory you could have it export N distributor memory regions which were identical apart from making "I assume I'm being accessed by CPU X" assumptions, but that seems like a bit of a kludge. Ideally we should have some way for the target of a memory transaction to get at information about the source (ie all the out of band info that hardware sends like master ID, privilege level, secure vs nonsecure, etc). > but I > wonder if either of you two has already thought about how those will > interact for gdbstub? I'd need to look at the protocol to figure out if gdbstub does memory accesses in the context of a particular thread (CPU for us) or not. If not, that could be awkward. thanks -- PMM
