qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x080


From: Peter Maydell
Subject: Re: [Qemu-devel] armv7m/stm32f205 not starting if code linked from 0x08000000
Date: Mon, 8 Jun 2015 20:27:09 +0100

On 8 June 2015 at 20:18, Liviu Ionescu <address@hidden> wrote:
>
>> On 08 Jun 2015, at 22:08, Peter Maydell <address@hidden> wrote:
>>
>> On 8 June 2015 at 19:48, Liviu Ionescu <address@hidden> wrote:
>>>> On 08 Jun 2015, at 21:36, Peter Maydell <address@hidden> 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 regions are defined, the image was loaded, etc.
>>
>> No, the image hasn't been loaded into RAM yet, that's why
>> the ldl_phys codepath doesn't work.
>
> 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 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

If we've already loaded sp/pc and then the user via the debugger
changes the vector table, at the moment I don't think we will
get the updated values. (Disclaimer: I haven't tested that, so
it's speculation rather than confirmed behaviour.)

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]