On 2018-10-30 13:39, Laurent Vivier wrote: > Le 30/10/2018 à 14:12, Mark Cave-Ayland a écrit : >> 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. [...] >>> 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? > > It's a bug in QEMU. > > EXCP_UNSUPPORTED is defined to a QEMU specific value (61) that is in the > Unassigned/Reserved range of the vector table. > > It is used by QEMU user-mode to trigger illegal instruction, whereas > illegal is also used to do simcalls (some thing like a syscall with an > illegal instruction trap). I think this should be deprecated as no one > is maintaining that and knows how to use that. > > Perhaps Thomas as an idea as it comes with the coldfire implementation? > (e6e5906b6e ColdFire target)
No clue, I've never used those simcalls before. Maybe we could "fix" it simply by changing the #define in cpu.h like this: #if defined(CONFIG_USER_ONLY) #define EXCP_UNSUPPORTED 61 #else #define EXCP_UNSUPPORTED EXCP_ILLEGAL #endif ? If that does not work, I'm also fine if we simply deprecate the simcalls (if possible). Thomas
