On 30/10/2018 12:49, Laurent Vivier wrote: > 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.
Yeah I think you're right, sorry about that. I'm sure I tried without 629754d847 and I got a premature exit from QEMU but only in graphic mode, but I've just tried again and can't seem to recreate it now. > --- 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 Interesting. So is this an actual bug in QEMU in terms of implementing the processor specification, or is it relying on undefined behaviour on real hardware? ATB, Mark.