On Tue, 13 Jan 2026, Peter Maydell wrote:
On Thu, 8 Jan 2026 at 14:34, Alex Bennée <[email protected]> wrote:
It looks like allowing a -kernel to override any firmware setting is
intentional.
Signed-off-by: Alex Bennée <[email protected]>
---
hw/m68k/mcf5208.c | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
index c6d1c5fae9f..5680d516a23 100644
--- a/hw/m68k/mcf5208.c
+++ b/hw/m68k/mcf5208.c
@@ -27,6 +27,7 @@
#include "qemu/timer.h"
#include "hw/core/ptimer.h"
#include "system/system.h"
+#include "system/reset.h"
#include "system/qtest.h"
#include "net/net.h"
#include "hw/core/boards.h"
@@ -274,6 +275,20 @@ static void mcf_fec_init(MemoryRegion *sysmem, hwaddr
base, qemu_irq *irqs)
memory_region_add_subregion(sysmem, base, sysbus_mmio_get_region(s, 0));
}
+static void mcf5208evb_cpu_reset(void *opaque)
+{
+ M68kCPU *cpu = opaque;
+ CPUM68KState *env = &cpu->env;
+ CPUState *cs = CPU(cpu);
+
+ cpu_reset(cs);
+ /* Initialize CPU registers. */
+ env->vbr = 0;
+ /* TODO: Configure BARs. */
+ env->aregs[7] = ldl_phys(cs->as, 0);
+ env->pc = env->reset_pc;
+}
It looks from my quick skim of the m68k manual like
"on reset, initial PC is read from offset 4, initial
SP is read from offset 0" is part of the architected
CPU reset, not board-specific. Maybe we should model
that inside the CPU reset method? Compare M-profile
Arm, which does basically the same thing in
arm_cpu_reset_hold().
(I really need to look again at whether we can move
that to the reset_exit phase now and drop the awkward
"maybe we need to look at a rom blob" special casing.)
Real machines usually have a way to remap ROM to address 0 on reset
shadowing RAM and then the firmware flips the bits needed to set up the
memory map with RAM at 0 and ROM at somewhere higher up but the way to do
it is different for each board. Maybe in QEMU we don't bother to model
this and have this special case instead to simplify things and be able to
start from the final ROM address without needing to model this ROM remap
thing. So modeling real CPU behaviour might make board models more
complex.
Regards,
BALATON Zoltan
