(MCA: Laurent is AFK today so I'm posting the latest version of this
in advance of soft freeze. I've addressed the technical comments, the
only outstanding feedback is related to i) should comment blocks copied
from Linux headers be removed in patch 1?, ii) is it worth keeping ASC
emulation given that it is broken in Linux? and iii) are there meaningful
constants that can be defined for the IRQ encoder in patch 11?)

I'm rebasing some of these patches for seven years now,
too many years...

if you want to test the machine, I'm sorry, it doesn't boot
a MacROM, but you can boot a linux kernel from the command line.

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

If you use a graphic adapter instead of "-nographic", you can use "-g" to set the
size of the display (I use "-g 1600x800x24").

You can get the ISO from:

https://cdimage.debian.org/mirror/cdimage/ports/9.0/m68k/iso-cd/debian-9.0-m68k-NETINST-1.iso

and extract the kernel and initrd.gz:

guestfish --add debian-9.0-m68k-NETINST-1.iso --ro \
          --mount /dev/sda:/ <<_EOF_
copy-out /install/cdrom/initrd.gz .
copy-out /install/kernels/vmlinux-4.15.0-2-m68k .
_EOF_

The mirror to use is: http://ftp.ports.debian.org/debian-ports/
when it fails, continue without boot loader.

In the same way, you can extract the kernel and the initramfs from the qcow2
image to use it with "-kernel" and "-initrd":

guestfish --add m68k.qcow2 --mount /dev/sda2:/ <<_EOF_
copy-out /boot/vmlinux-4.15.0-2-m68k .
copy-out /boot/initrd.img-4.15.0-2-m68k .
_EOF_

and boot with:

   ...
   -append "root=/dev/sda2 rw console=ttyS0 console=tty \
   -kernel vmlinux-4.15.0-2-m68k \
   -initrd initrd.img-4.15.0-2-m68k


v5: Rebase onto git master
    Add Philippe's R-B to patch 10
    Include the command line to boot a Linux kernel under the q800 machine in the
    commit message for patch 11 (Philippe)
    Fix up comments in hw/misc/mac_via.c (Thomas)
    Add asserts to VIA ADB support to prevent potential buffer overflows (Thomas)
    Move macfb surface/resolution checks to realise and remove hw_error (Thomas)
    Move macfb draw_line functions inline and remove macfb-template.h (Mark)
    Use guest address rather than source pointer in draw_line functions - this brings
      macfb in line with the VGA device and can prevent a potential buffer overflow
    Use g_strdup_printf() for memory region names in NuBus devices instead of
      hardcoded length char arrays (Thomas)
    Move NuBus QOM types from patch 7 to patch 8 (spotted by Thomas)
    Move CONFIG_COLDFIRE sections together in hw/m68k/Makefile.objs (Thomas)
    Remove obsolete comment from q800.c in patch 11 (Thomas)

v4: Drop RFC from subject prefix as this is getting close to final
    Rebased onto master (fixing ESP, rom_ptr() conflicts)
    Reworked q800.c based upon Thomas' comments about cpu_init() and
      qemu_check_nic_model()
    Address Thomas' comments on using error_report() instead of hw_error()
    Change the NuBus memory regions from DEVICE_NATIVE_ENDIAN to
      DEVICE_BIG_ENDIAN
    Split macfb Nubus support into separate commit
    Change VMSTATE_BUFFER_UNSAFE() to VMSTATE_UINT8_ARRAY() in macfb.c as
      suggested by David
    Remove dummy Apple Sound Chip migration state as pointed out by David
    Keep VIA ADB state and buffers in the mac_via device rather than adding
      to existing ADBState (this matches the pattern used in the PPC CUDA/PMU
      VIAs)
    Remove blacklisting for q800 machine from "make check" as requested by
      Thomas with the following fixes:
        - Fix incorrect MemoryRegion owner in ASC device
        - Add qtest_enabled() check in q800_init() to allow testing when no
          kernel is specified
        - Move some Mac VIA initialisation from init to realize
    Remove legacy drive properties from SWIM floppy controller and instead
      expose separate floppy bus and drive devices as requested by Kevin
        
v3: fix subject prefix "C" -> "RFC"

v2: remove the dp8393x fixes, because one of the patch breaks something
    Update "dp8393x: manage big endian bus" with idea from Thomas
    Mark has reworked most of the patches:
    - use mos6522
    - some code move, renamings and cleanup


Laurent Vivier (10):
  hw/m68k: add via support
  hw/m68k: implement ADB bus support for via
  escc: introduce a selector for the register bit
  hw/m68k: add macfb video card
  hw/m68k: Apple Sound Chip (ASC) emulation
  esp: add pseudo-DMA as used by Macintosh
  hw/m68k: add Nubus support
  hw/m68k: add a dummy SWIM floppy controller
  dp8393x: manage big endian bus
  hw/m68k: define Macintosh Quadra 800

Mark Cave-Ayland (1):
  hw/m68k: add Nubus support for macfb video card

 MAINTAINERS                         |  19 +
 arch_init.c                         |   4 +
 default-configs/m68k-softmmu.mak    |  14 +
 hw/Makefile.objs                    |   1 +
 hw/audio/Makefile.objs              |   1 +
 hw/audio/asc.c                      | 446 +++++++++++++++++++
 hw/block/Makefile.objs              |   1 +
 hw/block/swim.c                     | 415 +++++++++++++++++
 hw/char/escc.c                      |  30 +-
 hw/display/Makefile.objs            |   1 +
 hw/display/macfb.c                  | 475 ++++++++++++++++++++
 hw/intc/Makefile.objs               |   1 +
 hw/intc/q800_irq.c                  |  73 +++
 hw/m68k/Makefile.objs               |   5 +-
 hw/m68k/bootinfo.h                  | 100 +++++
 hw/m68k/q800.c                      | 356 +++++++++++++++
 hw/misc/Makefile.objs               |   1 +
 hw/misc/mac_via.c                   | 856 ++++++++++++++++++++++++++++++++++++
 hw/net/dp8393x.c                    |  88 ++--
 hw/nubus/Makefile.objs              |   4 +
 hw/nubus/mac-nubus-bridge.c         |  45 ++
 hw/nubus/nubus-bridge.c             |  34 ++
 hw/nubus/nubus-bus.c                | 111 +++++
 hw/nubus/nubus-device.c             | 214 +++++++++
 hw/scsi/esp.c                       | 292 ++++++++++--
 include/hw/audio/asc.h              |  48 ++
 include/hw/block/swim.h             |  76 ++++
 include/hw/char/escc.h              |   1 +
 include/hw/display/macfb.h          |  64 +++
 include/hw/intc/q800_irq.h          |  39 ++
 include/hw/misc/mac_via.h           | 114 +++++
 include/hw/nubus/mac-nubus-bridge.h |  24 +
 include/hw/nubus/nubus.h            |  69 +++
 include/hw/scsi/esp.h               |   7 +
 qemu-options.hx                     |   2 +-
 vl.c                                |   3 +-
 36 files changed, 3964 insertions(+), 70 deletions(-)
 create mode 100644 hw/audio/asc.c
 create mode 100644 hw/block/swim.c
 create mode 100644 hw/display/macfb.c
 create mode 100644 hw/intc/q800_irq.c
 create mode 100644 hw/m68k/bootinfo.h
 create mode 100644 hw/m68k/q800.c
 create mode 100644 hw/misc/mac_via.c
 create mode 100644 hw/nubus/Makefile.objs
 create mode 100644 hw/nubus/mac-nubus-bridge.c
 create mode 100644 hw/nubus/nubus-bridge.c
 create mode 100644 hw/nubus/nubus-bus.c
 create mode 100644 hw/nubus/nubus-device.c
 create mode 100644 include/hw/audio/asc.h
 create mode 100644 include/hw/block/swim.h
 create mode 100644 include/hw/display/macfb.h
 create mode 100644 include/hw/intc/q800_irq.h
 create mode 100644 include/hw/misc/mac_via.h
 create mode 100644 include/hw/nubus/mac-nubus-bridge.h
 create mode 100644 include/hw/nubus/nubus.h

-- 
2.11.0

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?


r~

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?


ATB,

Mark.

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

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.

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.
> 
>> --- 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?

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)

Thanks,
Laurent

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

On 02/11/2018 01:32, Thomas Huth wrote:
> 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
> 

I've found EXCP_UNSUPPORTED is a valid value to softmmu too, only
supported by some coldfire version.

In fact, we don't need the EXCP_UNSUPPORTED, the EXCP_ILLEGAL is used to
call the simcall interface. Before the introduction of m680x0 emulation
, EXCP_ILLEGAL was only used with the "illegal" instruction, other
unsupported instructions triggered the EXCP_UNSUPPORTED. So only the
"illegal" instruction was able to enter in the simcall interface.
As I have changed that, I think it should not work correctly anymore,
and I have no idea how to test that... and I'm pretty sure no one is
using that anymore (and if needed could switch to the standard "trap #0"
linux-user interface)

> 
> If that does not work, I'm also fine if we simply deprecate the simcalls
> (if possible).

I have a patch to deprecate the interface. I will send it once the
release will be done.

Thanks,
Laurent

On 11/2/18 6:25 AM, Laurent Vivier wrote:
>> If that does not work, I'm also fine if we simply deprecate the simcalls
>> (if possible).
> 
> I have a patch to deprecate the interface. I will send it once the
> release will be done.

Did I ever point out that I got m68k running under your q800 emulation in my
https://github.com/landley/mkroot project?

Now that m68k is in musl-libc, you can build
https://github.com/richfelker/musl-cross-make or grab a prebuilt binary a
toolchain from http://b.zv.io/mcm/bin/m68k-linux-musl-cross.tar.gz and then:

  CROSS_COMPILE=/path/to/m68k-linux-musl-cross/bin/m68k-linux-musl- \
    ./mkroot.sh kernel

And then:

  cd output/m68k
  ./qemu-m68k.sh -hda log.txt

The -hda is just so you have a hard drive image you can play with. Cat /dev/?da
should show you the log.txt contents. The network interface works too, although
I haven't got wget in toybox yet but:

  echo GET / | netcat landley.net /

Works. :)

When does this go upstream?

P.S. to build a current kernel:

  cd download
  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
  cd ..

And then mkroot.sh again. I tested with 4.20-rc1 and m68k worked fine.

> Thanks,
> Laurent

Rob