> 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
13 matches
Mail list logo
