On Tue, 13 Jan 2026 at 18:08, BALATON Zoltan <[email protected]> wrote: > > 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.
To me it looks like we are already modelling "load SP and PC from memory", we're just doing it in each board model rather than in the CPU model for some reason... -- PMM
