On Tue, 13 Jan 2026, Peter Maydell wrote:
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...
Only q800 seems to do that, virt passes this info in a struct not thorugh
memory and other boards don't seem to have a cpu reset function at all and
just poke the cpu object directly without resetting it unless I missed
something. Looks like each board came up with its own way independently
but could be cleaned up the way you propose implementing the proper reset
behaviour of the CPU then changing boards to just put the addresses in
memory or do the ROM remap if needed. But how could boards write the
addresses on reset without using qemu_register_reset or needing a lot of
boilerplate to add a reset method to machine? Maybe it is simple and I
just don't remember how machine reset works for machine or it could be
that MACHINE class needs a simple way for boards to register a reset
method. Maybe this is the reason why several boards use a boot info struct
to pass reset info into cpu_reset and don't model board reset?
Regards,
BALATON Zoltan
