Thanks for the review. I agree that this fix is more a workaround,
but it is local to
the only currently existing board with STM32 (AFAIK), so I couldn't
break other targets.
I'll try to implement one of your proposals.
Marko
On 2018-08-20 2:33 PM, Peter Maydell
wrote:
On 20 August 2018 at 12:10, Marko Klopcic <address@hidden> wrote:
Because roms are located on aliased addresses on netduino2 (Cortex M3,
STM32F205), PC and SP are not read from loaded kernel, which means
that the first reset fails. This fix adds additional call to reset.
See more details in code comment below.
Signed-off-by: Marko Klopcic <address@hidden>
---
hw/arm/netduino2.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/hw/arm/netduino2.c b/hw/arm/netduino2.c
index f936017d4a..a2f102b14b 100644
--- a/hw/arm/netduino2.c
+++ b/hw/arm/netduino2.c
@@ -25,6 +25,7 @@
#include "qemu/osdep.h"
#include "qapi/error.h"
#include "hw/boards.h"
+#include "hw/loader.h"
#include "qemu/error-report.h"
#include "hw/arm/stm32f205_soc.h"
#include "hw/arm/arm.h"
@@ -39,6 +40,32 @@ static void netduino2_init(MachineState *machine)
armv7m_load_kernel(ARM_CPU(first_cpu), machine->kernel_filename,
FLASH_SIZE);
+
+ /*
+ The following two calls are a workaround for problem with rom on
aliased
+ addresses on STM32.
+ Kernel is loaded into Rom objects, which are stored in loader.c. Roms
+ are copied to memory in:
+
+ void rom_reset() {
+ ...
+ cpu_physical_memory_write_rom(rom->as, rom->addr, rom->data,
+ rom->datasize);
+ ...
+ }
+
+ However, since CPU reset is registered BEFORE
+ rom_reset(), SP and PC are read from memory BEFORE roms are copied to
+ memory. CPU reset also checks Roms for data, so this is normally not
a
+ problem, but in STM32 PC and SP are read from aliased memory, and
these
+ memory addresses are not mapped to Roms. Since ROMs are private in
+ loader.c the only option to copy Roms to memory is through reset. So
we
+ first have to register Roms for reset, and then trigger system reset,
which
+ copies Roms to mem, so that reset vectors are in memory, when
+ qemu_system_reset() is called again from main().
+ */
+ rom_check_and_register_reset();
+ qemu_system_reset(SHUTDOWN_CAUSE_NONE);
}
I agree that this is a bug, but I think this is not the right way
to fix it, as it is not specific to this particular board. We need
to either somehow ensure the reset order between the rom code
and the Arm CPU reset is enforced, or change how we do the SP/PC
load on reset of an M-profile core.
thanks
-- PMM
|