| Message ID | 20200101215905.121298-1-Jason@zx2c4.com |
|---|---|
| State | New |
| Headers | show |
| Series | q800: map reset function to poweroff of some random kernel | expand |
Superseded by https://lore.kernel.org/qemu-devel/20200102103644.233370-1-Jason@zx2c4.com , thankfully.
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c index 4ca8678007..bd75dd3141 100644 --- a/hw/m68k/q800.c +++ b/hw/m68k/q800.c @@ -339,6 +339,7 @@ static void q800_init(MachineState *machine) BOOTINFO1(cs->as, parameters_base, BI_MAC_VROW, (graphic_width * graphic_depth + 7) / 8); BOOTINFO1(cs->as, parameters_base, BI_MAC_SCCBASE, SCC_BASE); + BOOTINFO1(cs->as, parameters_base, BI_MAC_ROMBASE, 0x7248); if (kernel_cmdline) { BOOTINFOSTR(cs->as, parameters_base, BI_COMMAND_LINE,
This commit is intentionally ridiculous. Currently calling `reboot(RB_AUTOBOOT);` in Linux will result in arch/m68k/mac/misc.c's mac_reset function being called. That in turn looks at the rombase (or uses 0x40800000 is there's no rombase), adds 0xa, and jumps to that address. In the kernels I'm building for build.wireguard.com, I'm using -no-reboot, which means that reboot=poweroff for me. And on these kernels, the mac_poweroff function winds up being at 0x7252. So, this patch here hard codes 0x7252-0xa=0x7248 as the rombase, so that the reset function calls the poweroff function. The poweroff function then calls into the working via2 hook. Sorry if this absurd hack offended your sensibilities. Probably a better solution would be actually mapping in a real rom and providing something at the 0xa offset, perhaps adding some reset functionality to via2 and sticking some code there to tinker with it, or something else. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> --- hw/m68k/q800.c | 1 + 1 file changed, 1 insertion(+)