qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 1/1] target_arm: Make the reset rom_ptr a pro


From: Alistair Francis
Subject: Re: [Qemu-devel] [PATCH v1 1/1] target_arm: Make the reset rom_ptr a property
Date: Thu, 21 Aug 2014 22:37:54 +1000

On Thu, Aug 21, 2014 at 10:24 PM, Peter Maydell
<address@hidden> wrote:
> On 21 August 2014 13:09, Alistair Francis <address@hidden> wrote:
>> On Thu, Aug 21, 2014 at 7:14 PM, Peter Maydell <address@hidden> wrote:
>>> This isn't making a great deal of sense to me. If you
>>> mean that the board design allows some sort of
>>> programmable or configurable remapping of the
>>> address space, we should implement that by
>>> mapping and remapping MemoryRegions into place
>>> as appropriate, not by messing with the CPU reset.
>>
>> This is the one that I mean.
>>
>> Either Main Flash, System Flash, FSMC Bank1 or SRAM
>> are mapped to address 0 based on the value of a register.
>>
>> This is checked after reset or when the device exits standby.
>>
>> If trying to run any code on QEMU, it will immediately error with
>> executing code out of memory at address 0 (if compiled without
>> this change). What do you think would be the best method to
>> implement this in QEMU?
>
> You need to model the behaviour of the board in the
> QEMU machine model, so that the right kind of
> thing appears at address zero. It doesn't sound like
> you need to change the behaviour of the CPU emulation
> at all, because reading the PC and SP from 0 is the
> correct behaviour.
>
> Since we don't support this board upstream I assume
> you're talking about some out-of-tree board model, so
> it's a bit difficult to give exact suggestions.
>
> Does the guest code actually make use of the dynamic
> remapping, or is it sufficient to implement your board
> as "always flash at 0" or "always RAM at 0" ?

The guest code sort of uses the dynamic mapping.

If any of the memory regions are moved to zero (instead
of where they should be) the guest fails to run (although
QEMU doesn't return an error).

So it can't just use "always flash at 0", there would need
to be two copies of the same memory.

If the reset address is changed by this patch it runs well.

The board I'm working on can be seen at:
https://github.com/alistair23/qemu

>
> thanks
> -- PMM



reply via email to

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