Le 30/10/2018 à 12:48, Mark Cave-Ayland a écrit : > On 30/10/2018 08:15, Richard Henderson wrote: > >> On 10/29/18 1:39 PM, Mark Cave-Ayland wrote: >>> You can install your own disk using debian-installer, with: >>> >>> ... >>> -M q800 \ >>> -serial none -serial mon:stdio \ >>> -m 1000M -drive file=m68k.qcow2,format=qcow2 \ >>> -net nic,model=dp83932,addr=09:00:07:12:34:57 \ >>> -append "console=ttyS0 vga=off" \ >>> -kernel vmlinux-4.15.0-2-m68k \ >>> -initrd initrd.gz \ >>> -drive file=debian-9.0-m68k-NETINST-1.iso \ >>> -drive file=m68k.qcow2,format=qcow2 \ >>> -nographic >> >> I tried this and got >> >> Trace 0: 0x7f2e886c7140 [00000000/0000d404/0xe000] >> INT 1: Unassigned(0xf4) pc=0000d404 sp=00393e60 sr=2700 >> INT 2: Access Fault(0x8) pc=00000000 sp=00393e58 sr=2700 >> ssw: 00000506 ea: 00000000 sfc: 5 dfc: 5 >> >> which lead straight to buserr and panic. This happens way early in boot -- >> only 1926 TranslationBlocks generated. >> >> Is there some device missing from the command-line that the kernel is >> expecting? > > Heh that's annoying. The original branch I forked that Laurent was working on > had > some extra patches at the start of the series: some were required for q800 > whilst > others were for new development. I thought that all of the patches required > for q800 > had been applied over the past few months, but sadly that isn't the case :( > > I've pushed an updated branch to > https://github.com/mcayland/qemu/tree/q800-test > which contains the patchset plus two extra patches that are still needed to > boot to > the debian installer here: > > 9281a5371f "tmp" > 629754d847 "target/m68k: manage FPU exceptions" > > Laurent, are these patches ready for upstream or do they need work in which > case we > should leave q800 until the 3.2 cycle?
The only needed part is from 9281a5371f. --- a/target/m68k/translate.c +++ b/target/m68k/translate.c @@ -1552,7 +1552,7 @@ DISAS_INSN(undef) but actually illegal for CPU32 or pre-68020. */ qemu_log_mask(LOG_UNIMP, "Illegal instruction: %04x @ %08x\n", insn, s->base.pc_next); - gen_exception(s, s->base.pc_next, EXCP_UNSUPPORTED); + gen_exception(s, s->base.pc_next, EXCP_ILLEGAL); } DISAS_INSN(mulw) @@ -2799,7 +2799,7 @@ DISAS_INSN(mull) if (ext & 0x400) { if (!m68k_feature(s->env, M68K_FEATURE_QUAD_MULDIV)) { - gen_exception(s, s->base.pc_next, EXCP_UNSUPPORTED); + gen_exception(s, s->base.pc_next, EXCP_ILLEGAL); return; } @@ -4509,7 +4509,7 @@ DISAS_INSN(strldsr) addr = s->pc - 2; ext = read_im16(env, s); if (ext != 0x46FC) { - gen_exception(s, addr, EXCP_UNSUPPORTED); + gen_exception(s, addr, EXCP_ILLEGAL); return; } ext = read_im16(env, s); Because kernel only manages illegal instruction exception not unsupported. Without the patch, we have: IN: 0x0000d454: 071400 INT 1: Unassigned(0xf4) pc=0000d454 sp=00331e60 sr=2700 with the patch: IN: 0x0000d454: 071400 INT 1: Illegal Instruction(0x10) pc=0000d454 sp=00331e60 sr=2700 We have in linux/arch/m68k/kernel/vectors.c: /* * this must be called very early as the kernel might * use some instruction that are emulated on the 060 * and so we're prepared for early probe attempts (e.g. nf_init). */ void __init base_trap_init(void) { ... vectors[VEC_BUSERR] = buserr; vectors[VEC_ILLEGAL] = trap; vectors[VEC_SYS] = system_call; } So I think the unsupported vector jumps to an invalid address. This seems triggered by the aranym native feature: d454: 7300 mvsb %d0,%d1 from linux/arch/m68k/emu/natfeat.c Thanks, Laurent