> On 21 Jun 2015, at 23:58, Peter Maydell wrote:
>
> There's lots of code that will run on QEMU but break on
> real hardware.
no doubt about it.
however, this shouldn't be the rule, if the efforts are reasonable, I see no
reasons for not improving the emulation quality and make code that brea
On 21 June 2015 at 15:42, Liviu Ionescu wrote:
>
>> On 21 Jun 2015, at 17:09, Peter Maydell wrote:
>>
>> Non-buggy guest code should not care whether
>> it is running on an r2p1 or an r2p0,
>
> probably not, but code developed on an emulated r2 might
> very well break on a physical r0.
There's l
> On 21 Jun 2015, at 17:09, Peter Maydell wrote:
>
> Non-buggy guest code should not care whether
> it is running on an r2p1 or an r2p0,
probably not, but code developed on an emulated r2 might very well break on a
physical r0.
> I think these should probably be cpu object properties, ...
>
On 21 June 2015 at 09:17, Liviu Ionescu wrote:
> while studying the details of cortex-m cores, I ran into the
> many differences between existing revisions, especially for
> cortex-m3, which are numerous and some significative, like
> stack alignment. for example for m3, the changes from r0p0 to
>
while studying the details of cortex-m cores, I ran into the many differences
between existing revisions, especially for cortex-m3, which are numerous and
some significative, like stack alignment. for example for m3, the changes from
r0p0 to r1p0/r1p1 are one full page of details, like "
