> On 09 Jun 2015, at 00:39, Peter Maydell wrote:
>
> Right, but only for your debugger.
yes, but this is consistent with other debuggers, my debug plug-ins use the
same strategy for j-link and openocd too, i.e. after flashing a new image a
reset is issued, to be sure that execution starts whe
On 8 June 2015 at 20:35, Liviu Ionescu wrote:
>
>> On 08 Jun 2015, at 22:27, Peter Maydell wrote:
>>
>> That would also fix this problem, yes. It would still leave one
>> use case wrong:
>> * start QEMU
>> * [cpu reset happens here; we load sp/pc]
>> * in the debugger load an image (with a vector
> On 08 Jun 2015, at 22:27, Peter Maydell wrote:
>
> On 8 June 2015 at 20:18, Liviu Ionescu wrote:
>>
>> aha, in this case the problem is the two step load, not the reset itself,
>> or even more accurate, it is a problem of making the reset calls in the
>> proper order.
>
> That would also fi
> On 08 Jun 2015, at 22:27, Peter Maydell wrote:
>
> That would also fix this problem, yes. It would still leave one
> use case wrong:
> * start QEMU
> * [cpu reset happens here; we load sp/pc]
> * in the debugger load an image (with a vector table) by writing it to RAM
> * let CPU run
I alread
On 8 June 2015 at 20:18, Liviu Ionescu wrote:
>
>> On 08 Jun 2015, at 22:08, Peter Maydell wrote:
>>
>> On 8 June 2015 at 19:48, Liviu Ionescu wrote:
On 08 Jun 2015, at 21:36, Peter Maydell wrote:
OK, so the problem diagnosis is right. I'm playing around with
a patch which p
> On 08 Jun 2015, at 22:08, Peter Maydell wrote:
>
> On 8 June 2015 at 19:48, Liviu Ionescu wrote:
>>> On 08 Jun 2015, at 21:36, Peter Maydell wrote:
>>>
>>> OK, so the problem diagnosis is right. I'm playing around with
>>> a patch which postpones PC/SP load until we start execution.
>>
>>
On 8 June 2015 at 19:48, Liviu Ionescu wrote:
>> On 08 Jun 2015, at 21:36, Peter Maydell wrote:
>>
>> OK, so the problem diagnosis is right. I'm playing around with
>> a patch which postpones PC/SP load until we start execution.
>
> but is this really necessary?
>
> the configuration at the momen
> On 08 Jun 2015, at 21:36, Peter Maydell wrote:
>
> OK, so the problem diagnosis is right. I'm playing around with
> a patch which postpones PC/SP load until we start execution.
but is this really necessary?
the configuration at the moment cpu_reset is called is perfectly stable, all
memory
On 8 June 2015 at 19:24, Liviu Ionescu wrote:
>
>> On 08 Jun 2015, at 21:18, Peter Maydell wrote:
>>
>> ... I meant
>>rom = rom_ptr(0x0800);
>
> this version worked for apps linked at 0x0800 and obviously
> failed for those linked at 0x0.
OK, so the problem diagnosis is right. I'm pl
> On 08 Jun 2015, at 21:18, Peter Maydell wrote:
>
> ... I meant
>rom = rom_ptr(0x0800);
this version worked for apps linked at 0x0800 and obviously failed for
those linked at 0x0.
regards,
Liviu
On 8 June 2015 at 19:12, Liviu Ionescu wrote:
>
>> On 08 Jun 2015, at 20:43, Peter Maydell wrote:
>>
>> ... Unfortunately the test we're doing to decide is calling rom_ptr(),
>> which only looks at the addresses the ROMs are registered to
>> be copied into; it doesn't know about aliasing.
>
> I g
> On 08 Jun 2015, at 20:43, Peter Maydell wrote:
>
> ... Unfortunately the test we're doing to decide is calling rom_ptr(),
> which only looks at the addresses the ROMs are registered to
> be copied into; it doesn't know about aliasing.
I guessed so.
> If you fudge the if() statement to use 0x
On 8 June 2015 at 18:32, Liviu Ionescu wrote:
> Hi Alistair/Peter,
>
> I am having difficulties to make the armv7m code run if linked from
> 0x0800.
>
> based on the tracing info that I have (copied below), it seems that the cpu
> throws an early exception, properly caught by the cpu and dis
Hi Alistair/Peter,
I am having difficulties to make the armv7m code run if linked from 0x0800.
based on the tracing info that I have (copied below), it seems that the cpu
throws an early exception, properly caught by the cpu and displayed (see the
indented lines).
this is weird, since disp
14 matches
Mail list logo
