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

[Peter Crosthwaite]

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" ?
>

Well the problem started with elfs that try and load at 0x08000000. I
think I've found some relevant documentation though.

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00037051.pdf

page 69.

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/DM00031020.pdf

page 287 (thanks Alistair).

It's a chip-level memory region aliasing system. The elfs are loading
via the actual address but the code or at least the initial PC/SP
retrieval them executes via the @0 alias.

I think the best answer is probably then a board level memory_region
alias. Check memory_region_init_alias.

Regards,
Peter

> thanks
> -- PMM
>