On 02/18/2017 01:38 PM, Peter Maydell wrote:
> On 18 February 2017 at 17:45, Michael Davidsaver
> wrote:
>> On 02/16/2017 09:11 AM, Peter Maydell wrote:
>>> I haven't actually checked real hardware behaviour, but I think
>>> we can fairly safely implement this as not checking the IPSR
>>> excepti
On 18 February 2017 at 17:45, Michael Davidsaver wrote:
> On 02/16/2017 09:11 AM, Peter Maydell wrote:
>> I haven't actually checked real hardware behaviour, but I think
>> we can fairly safely implement this as not checking the IPSR
>> exception field. (We might as well go with the "reads 1 in
>>
On 02/16/2017 09:11 AM, Peter Maydell wrote:
> I haven't actually checked real hardware behaviour, but I think
> we can fairly safely implement this as not checking the IPSR
> exception field. (We might as well go with the "reads 1 in
> handler mode" choice of UNKNOWN that the M3 documents, though.
On 15 February 2017 at 13:34, Peter Maydell wrote:
> On 15 February 2017 at 12:46, Alex Bennée wrote:
>> Can we not calculate a vector index rather than abusing the meaning of
>> offset while switching on it?
>
> Yeah, we could. (This is just a case where I thought "I could
> rewrite the code Mic
On 15 February 2017 at 13:34, Peter Maydell wrote:
> On 15 February 2017 at 12:46, Alex Bennée wrote:
>>
>> Peter Maydell writes:
>>> +/* Return the value of the ISCR RETTOBASE bit:
>>> + * 1 if there is exactly one active exception
>>> + * 0 if there is more than one active exception
>>> + * UN
Peter Maydell writes:
> On 15 February 2017 at 14:14, Alex Bennée wrote:
>> I guess it would be easier to remove the asserts if we had run test
>> cases that explicitly exercised all this code. What are you currently
>> running to test this code?
>
> The cover letter has a pointer to the tests
On 15 February 2017 at 14:14, Alex Bennée wrote:
> I guess it would be easier to remove the asserts if we had run test
> cases that explicitly exercised all this code. What are you currently
> running to test this code?
The cover letter has a pointer to the tests I've been using
(plus the usual "
Peter Maydell writes:
> On 15 February 2017 at 12:46, Alex Bennée wrote:
>>
>> Peter Maydell writes:
>>
>>> From: Michael Davidsaver
>>>
>>> Despite some superficial similarities of register layout, the
>>> M-profile NVIC is really very different from the A-profile GIC.
>>> Our current attemp
On 15 February 2017 at 12:46, Alex Bennée wrote:
>
> Peter Maydell writes:
>
>> From: Michael Davidsaver
>>
>> Despite some superficial similarities of register layout, the
>> M-profile NVIC is really very different from the A-profile GIC.
>> Our current attempt to reuse the GIC code means that
Peter Maydell writes:
> From: Michael Davidsaver
>
> Despite some superficial similarities of register layout, the
> M-profile NVIC is really very different from the A-profile GIC.
> Our current attempt to reuse the GIC code means that we have
> significant bugs in our NVIC.
>
> Implement the N
From: Michael Davidsaver
Despite some superficial similarities of register layout, the
M-profile NVIC is really very different from the A-profile GIC.
Our current attempt to reuse the GIC code means that we have
significant bugs in our NVIC.
Implement the NVIC as an entirely separate device, to
11 matches
Mail list logo
