Hi Peter,
On 2/27/20 2:35 PM, Philippe Mathieu-Daudé wrote:
On 2/27/20 1:13 PM, Peter Maydell wrote:
On Thu, 27 Feb 2020 at 11:27, Stephanos Ioannidis
wrote:
The ARMv7-M CPU reset handler, which loads the initial SP and PC
register values from the vector table, is currently executed before
t
On Thu, 27 Feb 2020 at 15:08, Stephanos Ioannidis wrote:
> On 2/27/20 10:31 PM, Philippe Mathieu-Daudé wrote:
> > I think Alistair and myself use the 'loader' device with Cortex-M boards
> > and never hit this problem.
>
> I tried both `-kernel [ELF IMAGE]` and `-device loader,file=[ELF IMAGE]`
Hi Peter and Philip,
Thanks for your insight on this matter.
I am okay as long as this issue is going to be eventually fixed in one way or
another; the three-phase reset scheme you mentioned does sound like a more
manageable approach for this purpose; though, I still believe having the option
On 2/27/20 1:13 PM, Peter Maydell wrote:
On Thu, 27 Feb 2020 at 11:27, Stephanos Ioannidis wrote:
The ARMv7-M CPU reset handler, which loads the initial SP and PC
register values from the vector table, is currently executed before
the ROM reset handler (rom_reset), and this causes the devices
On Thu, 27 Feb 2020 at 11:27, Stephanos Ioannidis wrote:
>
> The ARMv7-M CPU reset handler, which loads the initial SP and PC
> register values from the vector table, is currently executed before
> the ROM reset handler (rom_reset), and this causes the devices that
> alias low memory region (e.g.
The ARMv7-M CPU reset handler, which loads the initial SP and PC
register values from the vector table, is currently executed before
the ROM reset handler (rom_reset), and this causes the devices that
alias low memory region (e.g. STM32F405 that aliases the flash memory
located at 0x800 to 0x0)
