Re: [Qemu-devel] [PATCH v1 2/3] arm: fix the armv7m reset state

[Peter Maydell]

On 29 June 2017 at 17:41, KONRAD Frederic <address@hidden> wrote:
> On 06/29/2017 05:14 PM, Peter Maydell wrote:
>> This is awkward, because in the "we have a ROM but it's not been
>> copied into memory yet" case, the only thing we have is the
>> rom->addr, which is the address which the user's ROM blob said
>> it ought to be loaded in at. If the user didn't actually provide
>> a ROM blob that loads at 0 that seems a bit like a user error,
>> and I don't think this patch will catch all the cases of that
>> sort of mistake.
>
>
> I don't think it's really a user mistake because on the real HW
> the alias is configurable.. at least in my case.
>
> There is a "jumper" setting to mirror either the Flash or the
> SRAM, etc. So the binaries isn't located at 0 but at the flash
> address 0x8000000 or some such. That's the case with u-boot and
> the precompiled examples I found for this stm32fxxxx board.
>
>>  For instance if address 0 is real flash and the
>> high address alias is modelled by having the high address be the
>> alias, then if the user passes us an ELF file saying "load to
>> the high address" then this change won't catch that I think
>> (because doing the memory_region_find/get_offset_within_address_space
>> will return 0, which has already been tried). You'd need to
>> somehow have a way to say "find all the addresses within this
>> AS where this MR is mapped" and try them all...
>
>
> This is more likely to be a user error :). Maybe we can load
> the ROM before the reset but that seems a lot more invasive..

It's the same thing, though, right? If the user's ELF file
says "vector table is at 0x8000000" then we should either
(a) say that's a user error, or
(b) handle it right, whether we implemented the QEMU model with
the flash at 0 and the alias at 0x8000000, or with the flash
at 0x8000000 and the alias at 0.

> BTW isn't there a trick with the ELF entry somewhere? Or is that
> for the Cortex-A?

We don't honour the ELF entry point on M profile (arguably
a bug) -- armv7m_load_kernel() ignores the entry point
returned by load_elf() in the 'entry' variable.

thanks
-- PMM