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

[KONRAD Frederic <frederic.konrad@adacore.com>]

On 06/29/2017 06:45 PM, Peter Maydell wrote:
> On 29 June 2017 at 17:41, KONRAD Frederic <frederic.konrad@adacore.com> 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.

Hi Peter,

Fondamentaly yes, it is the same.. but it seems really strange to
me to load the elf in the alias.

If I choose (a) I'll need to objcpy all the elf to 0 or modify
the build script which should work on the real board.. This seems
not really a good option to me.

If I choose (b) I won't be able to load it to SRAM and it is
basically the same result I'll need to move or modify the config.

Thanks,
Fred

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