Emulating Solaris 10 on SPARC64 sun4u

Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

[-- Attachment #1: Type: text/plain, Size: 5084 bytes --]

I'm currently working towards emulating Solaris 10 on sun4u.

The Solaris 10 ISO image I am attempting to boot is the one from the Oracle
download page at https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
Image: sol-10-u11-ga-sparc-dvd.iso
MD5:   53e8b066f7f250ce2fd2cef063f8072b

I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.

The command I am using to run QEMU is:
./qemu/sparc64-softmmu/qemu-system-sparc64 -bios ./openbios/obj-sparc64/openbios-builtin.elf -cdrom ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G

```
CPUs: 1 x SUNW,UltraSPARC-IIi
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
  Type 'help' for detailed information
Trying cdrom:f...
Not a bootable ELF image
Not a bootable a.out image

Loading FCode image...
Loaded 7420 bytes
entry point is 0x4000
Evaluating FCode...
Evaluating FCode...
Ignoring failed claim for va 1000000 memsz af6d6!
Ignoring failed claim for va 1402000 memsz 4dcc8!
Ignoring failed claim for va 1800000 memsz 510c8!
SunOS Release 5.10 Version Generic_147147-26 64-bit
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught
interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
\ All rights reserved.
\
\ ident "@(#)data64.fth  1.3     00/07/17 SMI"

hex

only forth also definitions
vocabulary kdbg-words
also kdbg-words definitions

defer p@
defer p!
['] x@ is p@
['] x! is p!

8 constant ptrsize

d# 32 constant nbitsminor
h# ffffffff constant maxmin
\
\ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
\ Use is subject to license terms.
\

\ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"

h# 7ff constant v9bias
h# unix-tte:interpret: exception -13 caught
interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed
WARNING: consconfig: cannot find driver for screen device /pci@1fe,0/pci@1,1/QEMU,VGA@2
Configuring devices.
WARNING: Interrupt not seen after set_features
Using RPC Bootparams for network configuration information.
Attempting to configure interface hme0...
WARNING: Power off requested from power button or SC, powering down the system!
Skipped interface hme0
svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs mount -a failed: one or more file systems failed to mount
Serial console, reverting to text install
Beginning system identification...
Searching for configuration file(s)...
Search complete.
Discovering additional network configuration...
```

The installation menu is shown after but the console is unresponsive.

After some debugging, it looks like the QEMU front-end is correctly filling
the serial receive buffer with characters, and then starts dropping them once
the number of characters in the buffer reach the interrupt level. The interrupt
level happens to be 1 when booting Solaris 10. This looks like normal behaviour
to me.

I started looking at why the serial receive buffer might not be consumed and
considered that interrupts might not be being raised correctly. I ran with
tracing and there were no interrupts for IRQ 0x2b like there are when using
OpenBSD. When inspecting the registers of the serial device it looks like the
Interrupt Enable Register is set to zero.

If Solaris 10 was using the device is polling mode, it should be reading the RBR
or at least the LSR. When tracing serial_ioport_read and serial_ioport_write,
once the menu is hit, I don't see any read or writes to the serial device
registers despite me trying to send characters and use the menu.

The driver Solaris 10 is using for the device appears to be similar/same as
/usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code found at https://github.com/nxmirrors/onnv.

```
asy->asy_hwtype = ASY16550AF;
OUTB(FIFOR, 0x00); /* clear fifo register */
asy->asy_trig_level = 0x00; /* sets the fifo Threshold to 1 */

/* set/Enable FIFO */
OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
(asy->asy_trig_level & 0xff));

if ((INB(ISR) & 0xc0) == 0xc0)
    asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
else {
    asy->asy_hwtype = ASY8250;
    OUTB(FIFOR, 0x00); /* NO FIFOs */
    asy->asy_trig_level = 0;
}
```

From what I can tell when tracing serial_ioport_write and serial_ioport_read,
Solaris 10 correctly identifies the serial device and successfully attaches it.
In the asyattach function (OpenSolaris driver), interrupts are disabled by zeroing the
Interrupt Enable Register. From what I'm reading in OpenSolaris source code, interrupts
are reenabled when the device is "opened". This seems like consistent and
correct behaviour though I'm not sure why the device is not being opened to be
used by the serial console.

Is this an issue anyone else has tried to debug?
Are there any leads that I can follow up on for why the serial console becomes unresponsive
on Solaris 10?

Thanks,
Lowell.

[-- Attachment #2: Type: text/html, Size: 25019 bytes --]

Re: Emulating Solaris 10 on SPARC64 sun4u

[Dr. David Alan Gilbert]

* jasper.lowell@bt.com (jasper.lowell@bt.com) wrote:
> I'm currently working towards emulating Solaris 10 on sun4u.
> 
> The Solaris 10 ISO image I am attempting to boot is the one from the Oracle
> download page at https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
> Image: sol-10-u11-ga-sparc-dvd.iso
> MD5:   53e8b066f7f250ce2fd2cef063f8072b
> 
> I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
> 
> The command I am using to run QEMU is:
> ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios ./openbios/obj-sparc64/openbios-builtin.elf -cdrom ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G
> 
> ```
> CPUs: 1 x SUNW,UltraSPARC-IIi
> UUID: 00000000-0000-0000-0000-000000000000
> Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
>   Type 'help' for detailed information
> Trying cdrom:f...
> Not a bootable ELF image
> Not a bootable a.out image
> 
> Loading FCode image...
> Loaded 7420 bytes
> entry point is 0x4000
> Evaluating FCode...
> Evaluating FCode...
> Ignoring failed claim for va 1000000 memsz af6d6!
> Ignoring failed claim for va 1402000 memsz 4dcc8!
> Ignoring failed claim for va 1800000 memsz 510c8!
> SunOS Release 5.10 Version Generic_147147-26 64-bit
> Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
> could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught
> interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
> \ All rights reserved.
> \
> \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
> 
> hex
> 
> only forth also definitions
> vocabulary kdbg-words
> also kdbg-words definitions
> 
> defer p@
> defer p!
> ['] x@ is p@
> ['] x! is p!
> 
> 8 constant ptrsize
> 
> d# 32 constant nbitsminor
> h# ffffffff constant maxmin
> \
> \ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
> \ Use is subject to license terms.
> \
> 
> \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
> 
> h# 7ff constant v9bias
> h# unix-tte:interpret: exception -13 caught
> interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed
> WARNING: consconfig: cannot find driver for screen device /pci@1fe,0/pci@1,1/QEMU,VGA@2
> Configuring devices.
> WARNING: Interrupt not seen after set_features

GIven that your problem below is looking like an interrupt related
problem, have you figured out where that's coming from?

Dave

--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

RE: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

I haven't figured out where that is coming from.
The error doesn't look like it's in the OpenSolaris source code so I don't have any context behind it.
The error does show up here: https://docs.oracle.com/cd/E23824_01/html/821-1475/uata-7d.html so it might be related to the IDE controller.
The behaviour of Solaris 10 does make me think there is a problem with interrupts but OpenBSD works just fine on this architecture.

I've also tried using kmdb (Solaris kernel debugger) by running using `boot cdrom -kvd` at the OpenBIOS prompt.
I thought this might help diagnose the problem.
After the kernel debugger prompt occurs and I type `::cont` to continue, the system hangs completely.

Thanks,
Lowell.

-----Original Message-----
From: Dr. David Alan Gilbert <dgilbert@redhat.com> 
Sent: Thursday, 6 February 2020 4:33 AM
To: Lowell,J,Jasper,VIM R <jasper.lowell@bt.com>
Cc: qemu-devel@nongnu.org; mark.cave-ayland@ilande.co.uk; atar4qemu@gmail.com
Subject: Re: Emulating Solaris 10 on SPARC64 sun4u

* jasper.lowell@bt.com (jasper.lowell@bt.com) wrote:
> I'm currently working towards emulating Solaris 10 on sun4u.
> 
> The Solaris 10 ISO image I am attempting to boot is the one from the 
> Oracle download page at https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
> Image: sol-10-u11-ga-sparc-dvd.iso
> MD5:   53e8b066f7f250ce2fd2cef063f8072b
> 
> I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
> 
> The command I am using to run QEMU is:
> ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios 
> ./openbios/obj-sparc64/openbios-builtin.elf -cdrom 
> ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G
> 
> ```
> CPUs: 1 x SUNW,UltraSPARC-IIi
> UUID: 00000000-0000-0000-0000-000000000000
> Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
>   Type 'help' for detailed information Trying cdrom:f...
> Not a bootable ELF image
> Not a bootable a.out image
> 
> Loading FCode image...
> Loaded 7420 bytes
> entry point is 0x4000
> Evaluating FCode...
> Evaluating FCode...
> Ignoring failed claim for va 1000000 memsz af6d6!
> Ignoring failed claim for va 1402000 memsz 4dcc8!
> Ignoring failed claim for va 1800000 memsz 510c8!
> SunOS Release 5.10 Version Generic_147147-26 64-bit Copyright (c) 
> 1983, 2013, Oracle and/or its affiliates. All rights reserved.
> could not find debugger-vocabulary-hook>threads:interpret: exception 
> -13 caught interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
> \ All rights reserved.
> \
> \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
> 
> hex
> 
> only forth also definitions
> vocabulary kdbg-words
> also kdbg-words definitions
> 
> defer p@
> defer p!
> ['] x@ is p@
> ['] x! is p!
> 
> 8 constant ptrsize
> 
> d# 32 constant nbitsminor
> h# ffffffff constant maxmin
> \
> \ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
> \ Use is subject to license terms.
> \
> 
> \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
> 
> h# 7ff constant v9bias
> h# unix-tte:interpret: exception -13 caught interpret ' unix-tte is 
> va>tte-data failed with error ffffffffffffffed
> WARNING: consconfig: cannot find driver for screen device 
> /pci@1fe,0/pci@1,1/QEMU,VGA@2 Configuring devices.
> WARNING: Interrupt not seen after set_features

GIven that your problem below is looking like an interrupt related problem, have you figured out where that's coming from?

Dave

--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

RE: Emulating Solaris 10 on SPARC64 sun4u

[BALATON Zoltan]

Hello,

On Fri, 7 Feb 2020, jasper.lowell@bt.com wrote:
> I haven't figured out where that is coming from.
> The error doesn't look like it's in the OpenSolaris source code so I don't have any context behind it.
> The error does show up here: https://docs.oracle.com/cd/E23824_01/html/821-1475/uata-7d.html so it might be related to the IDE controller.
> The behaviour of Solaris 10 does make me think there is a problem with interrupts but OpenBSD works just fine on this architecture.

Not sure if my problem I see on other machine emulation I'm working on is 
related at all but there's a possibility it might be. I got this with 
different arch (ppc but could also reproduce something similar with mips) 
and ide controller emulation (via-ide) but the PCI bmdma code is shared by 
CMD646, via-ide and sii3112 and also the ide-cdrom emulation is the same 
so if there's a bug in these that could cause similar problems for 
different components. Or it could be that we get similar symptoms due to 
different reasons in which case sorry for the distracion but maybe we can 
learn from the experience of each other even in that case.

What I get is tracked here:

https://osdn.net/projects/qmiga/ticket/38949

(background on emulated machine: https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 )

Originally I had both Linux and MorphOS fail after enabling BMDMA before I 
had interrupt controller emulation (so that means it could be a problem 
with that in your case as well so something to check). Now that I've 
implemented interrupts Linux boots with DMA from CDROM but MorphOS is 
still not happy. You saw OpenBSD work but Solaris not so that could be 
similar in case the drivers do something differently or one relies on 
something the other does not care about. It could also be that since Linux 
is working, BMDMA and/or ide-cdrom may not emulate something other drivers 
may need which could cause simlar problems on multiple archs/emulations 
but I could be wrong about that.

An advice I got before to debug this is to try enabling ide traces:

https://lists.nongnu.org/archive/html/qemu-devel/2019-03/msg05656.html

I've tried that but lacking detailed knowledge about ide controllers I 
could not make much sense of the results so far.

Not sure how much help this is but maybe if more people are looking at it 
we might find something out. I've cc'd the IDE maintainer in case he has 
something more useful to add.

Regards,
BALATON Zoltan

> I've also tried using kmdb (Solaris kernel debugger) by running using `boot cdrom -kvd` at the OpenBIOS prompt.
> I thought this might help diagnose the problem.
> After the kernel debugger prompt occurs and I type `::cont` to continue, the system hangs completely.
>
> Thanks,
> Lowell.
>
> -----Original Message-----
> From: Dr. David Alan Gilbert <dgilbert@redhat.com>
> Sent: Thursday, 6 February 2020 4:33 AM
> To: Lowell,J,Jasper,VIM R <jasper.lowell@bt.com>
> Cc: qemu-devel@nongnu.org; mark.cave-ayland@ilande.co.uk; atar4qemu@gmail.com
> Subject: Re: Emulating Solaris 10 on SPARC64 sun4u
>
> * jasper.lowell@bt.com (jasper.lowell@bt.com) wrote:
>> I'm currently working towards emulating Solaris 10 on sun4u.
>>
>> The Solaris 10 ISO image I am attempting to boot is the one from the
>> Oracle download page at https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
>> Image: sol-10-u11-ga-sparc-dvd.iso
>> MD5:   53e8b066f7f250ce2fd2cef063f8072b
>>
>> I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
>>
>> The command I am using to run QEMU is:
>> ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios
>> ./openbios/obj-sparc64/openbios-builtin.elf -cdrom
>> ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G
>>
>> ```
>> CPUs: 1 x SUNW,UltraSPARC-IIi
>> UUID: 00000000-0000-0000-0000-000000000000
>> Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
>>   Type 'help' for detailed information Trying cdrom:f...
>> Not a bootable ELF image
>> Not a bootable a.out image
>>
>> Loading FCode image...
>> Loaded 7420 bytes
>> entry point is 0x4000
>> Evaluating FCode...
>> Evaluating FCode...
>> Ignoring failed claim for va 1000000 memsz af6d6!
>> Ignoring failed claim for va 1402000 memsz 4dcc8!
>> Ignoring failed claim for va 1800000 memsz 510c8!
>> SunOS Release 5.10 Version Generic_147147-26 64-bit Copyright (c)
>> 1983, 2013, Oracle and/or its affiliates. All rights reserved.
>> could not find debugger-vocabulary-hook>threads:interpret: exception
>> -13 caught interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
>> \ All rights reserved.
>> \
>> \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
>>
>> hex
>>
>> only forth also definitions
>> vocabulary kdbg-words
>> also kdbg-words definitions
>>
>> defer p@
>> defer p!
>> ['] x@ is p@
>> ['] x! is p!
>>
>> 8 constant ptrsize
>>
>> d# 32 constant nbitsminor
>> h# ffffffff constant maxmin
>> \
>> \ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
>> \ Use is subject to license terms.
>> \
>>
>> \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
>>
>> h# 7ff constant v9bias
>> h# unix-tte:interpret: exception -13 caught interpret ' unix-tte is
>> va>tte-data failed with error ffffffffffffffed
>> WARNING: consconfig: cannot find driver for screen device
>> /pci@1fe,0/pci@1,1/QEMU,VGA@2 Configuring devices.
>> WARNING: Interrupt not seen after set_features
>
> GIven that your problem below is looking like an interrupt related problem, have you figured out where that's coming from?
>
> Dave
>
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
>
>

RE: Emulating Solaris 10 on SPARC64 sun4u

[BALATON Zoltan]

On Sat, 8 Feb 2020, BALATON Zoltan wrote:
> Not sure if my problem I see on other machine emulation I'm working on is 
> related at all but there's a possibility it might be. I got this with 
> different arch (ppc but could also reproduce something similar with mips) and 
> ide controller emulation (via-ide) but the PCI bmdma code is shared by 
> CMD646, via-ide and sii3112 and also the ide-cdrom emulation is the same so 
> if there's a bug in these that could cause similar problems for different 
> components. Or it could be that we get similar symptoms due to different 
> reasons in which case sorry for the distracion but maybe we can learn from 
> the experience of each other even in that case.
>
> What I get is tracked here:
>
> https://osdn.net/projects/qmiga/ticket/38949
>
> (background on emulated machine: 
> https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 )
>
> Originally I had both Linux and MorphOS fail after enabling BMDMA before I 
> had interrupt controller emulation (so that means it could be a problem with 
> that in your case as well so something to check). Now that I've implemented 
> interrupts Linux boots with DMA from CDROM but MorphOS is still not happy.

I could now also reproduce the same with AmigaOS4 on pegasos2 where I got 
same missing interrupt problem:

---> Port 1
IOBase 00001010, AltBase 0000101E
bmcr_base 00001028
MMIOBase 00000000
Config not forced, scanning ...
1 device(s) on port
  0 Master : 'ATAPI'
  1 Slave  : 'unknown type'
Starting 'peg2ide.device - chip 0 port 1' task
bmdma_addr_write data: 0x0000000002290000
Trying to configure unit 2

Hangs here waiting for interrupt which does not seem to arrive, then:

[peg2ide/irq_wait] timed out
[peg2ide/exec_pio_data_in_cmd] <- here
[peg2ide/ata_read_drive_properties] unit 2 returned error 255, failbits 00000000h, timeout 0
Trying to configure unit 3
[peg2ide/ata_read_drive_properties] After-reset signature invalid for unit 3

So there's definitely a problem with interrupts but not sure where. Also 
don't know why it detects an unknown slave device which then it decides is 
invalid. Maybe this is normal on an IDE bus with only one device or is it 
a problem in emulation?

To locate the problem further I've then tried the same with ide-cd 
connected to the sii3112 SATA emulation that also shares the same IDE 
BMDMA code with CMD646 and via-ide but as a PCI card the interrupt routing 
is different. So if I don't get the problem with it then that can prove 
common code is correct. If I get the problem it may come from common code 
or be another interrupt routing problem.

I did not have PCI interrupts correctly implemented in pegasos2 yet so I 
had to fix that first but I'm not sure it's correct yet. I got similar 
results but the interrupt seems to fire in this case but does not get to 
the CPU as it does not seem to be enabled:

sii3112ide.device 53.3 (05.02.2009)
Found chip #0
---> Port 0
IOBase 00001030, AltBase 0000103A
bmcr_base 00001090
MMIOBase 81004000
Config not forced, scanning ...
sii3112_write bmdma: write (size 1) 0x8a : 0x02
sii3112_write bmdma: write (size 1) 0x86 : 0x00
sii3112_write bmdma: write (size 1) 0x82 : 0x55
sii3112_write bmdma: write (size 1) 0x83 : 0xaa
sii3112_write bmdma: write (size 1) 0x82 : 0xaa
sii3112_write bmdma: write (size 1) 0x83 : 0x55
sii3112_write bmdma: write (size 1) 0x82 : 0x55
sii3112_write bmdma: write (size 1) 0x83 : 0xaa
sii3112_read bmdma: read (size 1) 0x82 : 0x55
sii3112_read bmdma: read (size 1) 0x83 : 0xaa
sii3112_write bmdma: write (size 1) 0x86 : 0x00
sii3112_write bmdma: write (size 1) 0x8a : 0x06
sii3112_write bmdma: write (size 1) 0x8a : 0x02
sii3112_set_irq channel 0 level 0
sii3112_read bmdma: read (size 1) 0x87 : 0x00
sii3112_write bmdma: write (size 1) 0x86 : 0x00
sii3112_write bmdma: write (size 1) 0x86 : 0x00
sii3112_write bmdma: write (size 1) 0x86 : 0x00
sii3112_read bmdma: read (size 1) 0x82 : 0x01
sii3112_read bmdma: read (size 1) 0x83 : 0x01
sii3112_read bmdma: read (size 1) 0x84 : 0x14
sii3112_read bmdma: read (size 1) 0x85 : 0xeb
sii3112_set_irq channel 0 level 0
sii3112_read bmdma: read (size 1) 0x87 : 0x00
sii3112_write bmdma: write (size 1) 0x86 : 0x00
1 device(s) on port
  0 Master : 'ATAPI'
Starting 'sii3112ide.device - chip 0 port 0' task
sii3112_write bmdma: write (size 4) 0x4 : 0x22c0000
bmdma_addr_write data: 0x00000000022c0000
Installing handler for irq 25
mv64361_gpp_irq(0x5654b950c1a0, 31, 1) levels=80000000 mask=80000000
mv64361_update_irq(0x5654b950c1a0, 59, 1)
mv64361_gpp_irq(0x5654b950c1a0, 31, 0) levels=0
mv64361_update_irq(0x5654b950c1a0, 59, 0)
Unassigned mem read 00000000810040a1
Trying to configure unit 0
sii3112_write bmdma: write (size 1) 0x86 : 0x00
sii3112_set_irq channel 0 level 0
sii3112_read bmdma: read (size 1) 0x87 : 0x00
sii3112_write bmdma: write (size 1) 0x8a : 0x00
sii3112_write bmdma: write (size 1) 0x81 : 0x00
sii3112_write bmdma: write (size 1) 0x82 : 0x00
sii3112_write bmdma: write (size 1) 0x83 : 0x00
sii3112_write bmdma: write (size 1) 0x84 : 0x00
sii3112_write bmdma: write (size 1) 0x85 : 0x00
sii3112_write bmdma: write (size 1) 0x86 : 0x40
sii3112_write bmdma: write (size 1) 0x87 : 0xa1
sii3112_set_irq channel 0 level 1
mv64361_pcihost_set_irq(0x5654b950ce00, 1, 1)
mv64361_gpp_irq(0x5654b950c1a0, 13, 1) levels=2000 mask=80000000

[sii3112ide/irq_wait] timed out
[sii3112ide/exec_pio_data_in_cmd] <- here
sii3112_set_irq channel 0 level 0
mv64361_pcihost_set_irq(0x5654b950ce00, 1, 0)
mv64361_gpp_irq(0x5654b950c1a0, 13, 0) levels=0
mv64361_update_irq(0x5654b950c1a0, 57, 0)
sii3112_read bmdma: read (size 1) 0x87 : 0x58
[sii3112ide/ata_read_drive_properties] unit 0 returned error 255, failbits 00000000h, timeout 0

So here I see there's an interrupt raised by the card which does also get 
to the mv64361 system controller that's also the interrupt controller on 
pegasos2 but CPU IRQ is not raised because the corresponding mask bit is 
not set for some reason.

This suggests the common IDE bmdma and ide-cd code is likely OK and 
problem is somewhere in irq routing. What's relevant for this thread and 
sparc64 is that then you should also check interrupt controller and 
routing if an interrupt raised by the IDE controller could get to the CPU 
in your case as that could be where the problem is and maybe not in 
common code as I've suspected before.

For my case I'm not sure. On pegasos2 irqs come in via the mv64361 gpio 
ports, the irq pin of the VIA south bridge (containing via-ide and the 16 
isa interrupts) is connected to gpp_irq 31 while the PCI INTA-D lines are 
connected to gpp_irq 12-15. These are mapped to interrupt cause bits 56-59 
so that gpp0-7 gets 56, gpp8-15 57, gpp16-23 58 and gpp 24-31 gets 59. 
Thus the IRQ numbers seem correct in the above but the expected interrupt 
on 59 is only raised when the sii3112 driver is insalling its interrupt 
handler (not sure why does it call that irq 25?). This should have been 
raised when talking to device on via-ide much earlier. Then when talking 
to device on sii3112 the interrupt arrives from PCI on the expected 57 but 
CPU IRQ is not raised because it is masked, only gpp 31 is enabled. This 
supposedly works on real hardware but don't get why it doesn't on my 
emulation. It's probably a bug in the IRQ controller emulation then and 
topic for another thread and other platforms that similar error happens 
may also have bugs in their IRQ routing.

Regards,
BALATON Zoltan

Re: Emulating Solaris 10 on SPARC64 sun4u

[John Snow]

On 2/10/20 10:38 AM, BALATON Zoltan wrote:
> On Sat, 8 Feb 2020, BALATON Zoltan wrote:
>> Not sure if my problem I see on other machine emulation I'm working on
>> is related at all but there's a possibility it might be. I got this
>> with different arch (ppc but could also reproduce something similar
>> with mips) and ide controller emulation (via-ide) but the PCI bmdma
>> code is shared by CMD646, via-ide and sii3112 and also the ide-cdrom
>> emulation is the same so if there's a bug in these that could cause
>> similar problems for different components. Or it could be that we get
>> similar symptoms due to different reasons in which case sorry for the
>> distracion but maybe we can learn from the experience of each other
>> even in that case.
>>
>> What I get is tracked here:
>>
>> https://osdn.net/projects/qmiga/ticket/38949
>>
>> (background on emulated machine:
>> https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 )
>>
>> Originally I had both Linux and MorphOS fail after enabling BMDMA
>> before I had interrupt controller emulation (so that means it could be
>> a problem with that in your case as well so something to check). Now
>> that I've implemented interrupts Linux boots with DMA from CDROM but
>> MorphOS is still not happy.
> 
> I could now also reproduce the same with AmigaOS4 on pegasos2 where I
> got same missing interrupt problem:
> 
> ---> Port 1
> IOBase 00001010, AltBase 0000101E
> bmcr_base 00001028
> MMIOBase 00000000
> Config not forced, scanning ...
> 1 device(s) on port
>  0 Master : 'ATAPI'

"unit 2", I assume

>  1 Slave  : 'unknown type'

"unit 3", I assume

> Starting 'peg2ide.device - chip 0 port 1' task
> bmdma_addr_write data: 0x0000000002290000
> Trying to configure unit 2
> 
> Hangs here waiting for interrupt which does not seem to arrive, then:
> 
> [peg2ide/irq_wait] timed out
> [peg2ide/exec_pio_data_in_cmd] <- here
> [peg2ide/ata_read_drive_properties] unit 2 returned error 255, failbits
> 00000000h, timeout 0
> Trying to configure unit 3
> [peg2ide/ata_read_drive_properties] After-reset signature invalid for
> unit 3
> 
> So there's definitely a problem with interrupts but not sure where. Also
> don't know why it detects an unknown slave device which then it decides
> is invalid. Maybe this is normal on an IDE bus with only one device or
> is it a problem in emulation?
> 

I don't actually know myself. We *do* always have two IDEState objects
per port, but maybe we're letting some unknown state sneak through --
filling in a register improperly, perhaps?

It's probably not ide_ioport_read -- but I see complaints about the
reset signature too, so maybe we've gotten that wrong.

You can look at ide_set_signature to see how we set the drive
signatures; called from ide_reset (and many other places too)

I think ide_init_drive is only meant to be called on devices that
actually exist and are plugged in. It initializes drive_kind to one of
IDE_HD, IDE_CD, or IDE_CFATA -- empty or missing isn't an option here.

(Hm, this means it defaults to IDE_HD actually.)

The tricky thing is that IDEState belongs to the parent bus -- not the
drive object itself -- and the bus always has two slots.

We select between the two by setting bus->unit; and we don't appear to
do any kind of actual guarding that the drive actually exists.

(I suppose guests are free to issue commands to non-existant drives if
they want to, but they're not going to be able to perform work.)

...but ide_reset_bus calls ide_reset on both slots regardless of the
presence of a device or not.

(This is probably just a side effect of the interrupt getting lost and
having the guest try to reset the controller, then noticing weird state
after the reset.)

It sounds like the real problem is either in the bmdma controller (or
its unique interaction with hw/ide/core.c -- which is possible) or in
the interrupt routing somewhere else.

If you have any IDE traces from a hang, feel free to throw them up on a
pastebin for me to take a peek at; it might help for me to see the exact
sequence that causes a hang in QEMU's IDE terms to see if I can't
"reverse engineer" what the guest is hoping to have happen. Maybe I can
trace this to a bad register value.

(Hm, it's failing on pio_in? It's using PIO on an IDE drive with a DMA
controller? Is it failing to enable DMA and then failing to use PIO as a
backup too? Maybe there are two bugs.)

--js

> To locate the problem further I've then tried the same with ide-cd
> connected to the sii3112 SATA emulation that also shares the same IDE
> BMDMA code with CMD646 and via-ide but as a PCI card the interrupt
> routing is different. So if I don't get the problem with it then that
> can prove common code is correct. If I get the problem it may come from
> common code or be another interrupt routing problem.
> 
> I did not have PCI interrupts correctly implemented in pegasos2 yet so I
> had to fix that first but I'm not sure it's correct yet. I got similar
> results but the interrupt seems to fire in this case but does not get to
> the CPU as it does not seem to be enabled:
> 
> sii3112ide.device 53.3 (05.02.2009)
> Found chip #0
> ---> Port 0
> IOBase 00001030, AltBase 0000103A
> bmcr_base 00001090
> MMIOBase 81004000
> Config not forced, scanning ...
> sii3112_write bmdma: write (size 1) 0x8a : 0x02
> sii3112_write bmdma: write (size 1) 0x86 : 0x00
> sii3112_write bmdma: write (size 1) 0x82 : 0x55
> sii3112_write bmdma: write (size 1) 0x83 : 0xaa
> sii3112_write bmdma: write (size 1) 0x82 : 0xaa
> sii3112_write bmdma: write (size 1) 0x83 : 0x55
> sii3112_write bmdma: write (size 1) 0x82 : 0x55
> sii3112_write bmdma: write (size 1) 0x83 : 0xaa
> sii3112_read bmdma: read (size 1) 0x82 : 0x55
> sii3112_read bmdma: read (size 1) 0x83 : 0xaa
> sii3112_write bmdma: write (size 1) 0x86 : 0x00
> sii3112_write bmdma: write (size 1) 0x8a : 0x06
> sii3112_write bmdma: write (size 1) 0x8a : 0x02
> sii3112_set_irq channel 0 level 0
> sii3112_read bmdma: read (size 1) 0x87 : 0x00
> sii3112_write bmdma: write (size 1) 0x86 : 0x00
> sii3112_write bmdma: write (size 1) 0x86 : 0x00
> sii3112_write bmdma: write (size 1) 0x86 : 0x00
> sii3112_read bmdma: read (size 1) 0x82 : 0x01
> sii3112_read bmdma: read (size 1) 0x83 : 0x01
> sii3112_read bmdma: read (size 1) 0x84 : 0x14
> sii3112_read bmdma: read (size 1) 0x85 : 0xeb
> sii3112_set_irq channel 0 level 0
> sii3112_read bmdma: read (size 1) 0x87 : 0x00
> sii3112_write bmdma: write (size 1) 0x86 : 0x00
> 1 device(s) on port
>  0 Master : 'ATAPI'
> Starting 'sii3112ide.device - chip 0 port 0' task
> sii3112_write bmdma: write (size 4) 0x4 : 0x22c0000
> bmdma_addr_write data: 0x00000000022c0000
> Installing handler for irq 25
> mv64361_gpp_irq(0x5654b950c1a0, 31, 1) levels=80000000 mask=80000000
> mv64361_update_irq(0x5654b950c1a0, 59, 1)
> mv64361_gpp_irq(0x5654b950c1a0, 31, 0) levels=0
> mv64361_update_irq(0x5654b950c1a0, 59, 0)
> Unassigned mem read 00000000810040a1
> Trying to configure unit 0
> sii3112_write bmdma: write (size 1) 0x86 : 0x00
> sii3112_set_irq channel 0 level 0
> sii3112_read bmdma: read (size 1) 0x87 : 0x00
> sii3112_write bmdma: write (size 1) 0x8a : 0x00
> sii3112_write bmdma: write (size 1) 0x81 : 0x00
> sii3112_write bmdma: write (size 1) 0x82 : 0x00
> sii3112_write bmdma: write (size 1) 0x83 : 0x00
> sii3112_write bmdma: write (size 1) 0x84 : 0x00
> sii3112_write bmdma: write (size 1) 0x85 : 0x00
> sii3112_write bmdma: write (size 1) 0x86 : 0x40
> sii3112_write bmdma: write (size 1) 0x87 : 0xa1
> sii3112_set_irq channel 0 level 1
> mv64361_pcihost_set_irq(0x5654b950ce00, 1, 1)
> mv64361_gpp_irq(0x5654b950c1a0, 13, 1) levels=2000 mask=80000000
> 
> [sii3112ide/irq_wait] timed out
> [sii3112ide/exec_pio_data_in_cmd] <- here
> sii3112_set_irq channel 0 level 0
> mv64361_pcihost_set_irq(0x5654b950ce00, 1, 0)
> mv64361_gpp_irq(0x5654b950c1a0, 13, 0) levels=0
> mv64361_update_irq(0x5654b950c1a0, 57, 0)
> sii3112_read bmdma: read (size 1) 0x87 : 0x58
> [sii3112ide/ata_read_drive_properties] unit 0 returned error 255,
> failbits 00000000h, timeout 0
> 
> So here I see there's an interrupt raised by the card which does also
> get to the mv64361 system controller that's also the interrupt
> controller on pegasos2 but CPU IRQ is not raised because the
> corresponding mask bit is not set for some reason.
> 
> This suggests the common IDE bmdma and ide-cd code is likely OK and
> problem is somewhere in irq routing. What's relevant for this thread and
> sparc64 is that then you should also check interrupt controller and
> routing if an interrupt raised by the IDE controller could get to the
> CPU in your case as that could be where the problem is and maybe not in
> common code as I've suspected before.
> 
> For my case I'm not sure. On pegasos2 irqs come in via the mv64361 gpio
> ports, the irq pin of the VIA south bridge (containing via-ide and the
> 16 isa interrupts) is connected to gpp_irq 31 while the PCI INTA-D lines
> are connected to gpp_irq 12-15. These are mapped to interrupt cause bits
> 56-59 so that gpp0-7 gets 56, gpp8-15 57, gpp16-23 58 and gpp 24-31 gets
> 59. Thus the IRQ numbers seem correct in the above but the expected
> interrupt on 59 is only raised when the sii3112 driver is insalling its
> interrupt handler (not sure why does it call that irq 25?). This should
> have been raised when talking to device on via-ide much earlier. Then
> when talking to device on sii3112 the interrupt arrives from PCI on the
> expected 57 but CPU IRQ is not raised because it is masked, only gpp 31
> is enabled. This supposedly works on real hardware but don't get why it
> doesn't on my emulation. It's probably a bug in the IRQ controller
> emulation then and topic for another thread and other platforms that
> similar error happens may also have bugs in their IRQ routing.
> 

Missing IRQ with bmdma on ppc/mips/sparc? (was: Re: Emulating Solaris 10 on SPARC64 sun4u)

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 9392 bytes --]

I've changed title to avoid derailing the original thread as this is more 
about pegasos2 issue now but left cc list for now. Let me know if you 
don't want to be cc'd.

On Mon, 10 Feb 2020, John Snow wrote:
> On 2/10/20 10:38 AM, BALATON Zoltan wrote:
>> On Sat, 8 Feb 2020, BALATON Zoltan wrote:
>>> Not sure if my problem I see on other machine emulation I'm working on
>>> is related at all but there's a possibility it might be. I got this
>>> with different arch (ppc but could also reproduce something similar
>>> with mips) and ide controller emulation (via-ide) but the PCI bmdma
>>> code is shared by CMD646, via-ide and sii3112 and also the ide-cdrom
>>> emulation is the same so if there's a bug in these that could cause
>>> similar problems for different components. Or it could be that we get
>>> similar symptoms due to different reasons in which case sorry for the
>>> distracion but maybe we can learn from the experience of each other
>>> even in that case.
>>>
>>> What I get is tracked here:
>>>
>>> https://osdn.net/projects/qmiga/ticket/38949

I've updated this ticket now with more detailed AmigaOS4 logs that also 
contains PIO regs except ide_data* to keep it managable. I've lost some of 
the driver debug messages as it seems QEMU debug messages overwrite those 
when both are directed to stdout so I can't capture them both but added 
comments to explain what stage they are at.

>>> (background on emulated machine:
>>> https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2 )

(There's also board schematics linked from that page in case someone is 
interested about how IRQs are connected, it's not impossible I've got that 
wrong in my model as I don't really know what real hardware does. The 
work in progress patches implementing pegasos2 are in the git branch also 
linked from above.)

>>> Originally I had both Linux and MorphOS fail after enabling BMDMA
>>> before I had interrupt controller emulation (so that means it could be
>>> a problem with that in your case as well so something to check). Now
>>> that I've implemented interrupts Linux boots with DMA from CDROM but
>>> MorphOS is still not happy.
>>
>> I could now also reproduce the same with AmigaOS4 on pegasos2 where I
>> got same missing interrupt problem:
>>
>> ---> Port 1
>> IOBase 00001010, AltBase 0000101E
>> bmcr_base 00001028
>> MMIOBase 00000000
>> Config not forced, scanning ...
>> 1 device(s) on port
>>  0 Master : 'ATAPI'
>
> "unit 2", I assume
>
>>  1 Slave  : 'unknown type'
>
> "unit 3", I assume

Yes, there was also a "---> Port 0" before that, checking for primary 
master and slave devices that were unit 0 and 1 but I did not include that 
for brevity. Thus secondary master and slave devices are numbered 2 and 3.

>> So there's definitely a problem with interrupts but not sure where. Also
>> don't know why it detects an unknown slave device which then it decides
>> is invalid. Maybe this is normal on an IDE bus with only one device or
>> is it a problem in emulation?
>>
>
> I don't actually know myself. We *do* always have two IDEState objects
> per port, but maybe we're letting some unknown state sneak through --
> filling in a register improperly, perhaps?

To make it clear, the problem I have that prevents it from working is the 
missing interrupt after switching to UDMA. The unknown slave device is 
only causing a delay in detection but then it determines that the 
secondary device is not working and goes further so I've only reported 
that as a potential problem in emulation that could be investigated and 
fixed but it's not the main problem that prevents working.

> It's probably not ide_ioport_read -- but I see complaints about the
> reset signature too, so maybe we've gotten that wrong.
>
> You can look at ide_set_signature to see how we set the drive
> signatures; called from ide_reset (and many other places too)

Unfortunately I don't know much about IDE so likely I would not find 
out much there.

> I think ide_init_drive is only meant to be called on devices that
> actually exist and are plugged in. It initializes drive_kind to one of
> IDE_HD, IDE_CD, or IDE_CFATA -- empty or missing isn't an option here.
>
> (Hm, this means it defaults to IDE_HD actually.)

From the logs I've seen it does seem to expect an ATA device i.e. HDD as 
unit 3 but after trying to identify it it gets an error and finds that 
there's no working device there and goes with just the CD drive. MorphOS 
does the same but trying a few times before giving up, there are some logs 
showing that in the above ticket,

> The tricky thing is that IDEState belongs to the parent bus -- not the
> drive object itself -- and the bus always has two slots.
>
> We select between the two by setting bus->unit; and we don't appear to
> do any kind of actual guarding that the drive actually exists.
>
> (I suppose guests are free to issue commands to non-existant drives if
> they want to, but they're not going to be able to perform work.)
>
> ...but ide_reset_bus calls ide_reset on both slots regardless of the
> presence of a device or not.

I remember seeing log messages from guest that said it reset the ide bus 
before trying to probe to avoid hangs that probably happen on real 
hardware but I don't find them now. But it's possible there was a bus 
reset before the above probing. I think it wants to get the bus to a known 
state to avoid problems due to firmware or something else leaving the bus 
and devices in some weird state.

> (This is probably just a side effect of the interrupt getting lost and
> having the guest try to reset the controller, then noticing weird state
> after the reset.)
>
> It sounds like the real problem is either in the bmdma controller (or
> its unique interaction with hw/ide/core.c -- which is possible) or in
> the interrupt routing somewhere else.

Despite being able to reproduce similar problems on ppc mips and sparc64 
emulations with two different ide controllers (sharing bmdma code) it 
could well be that all of these have some kind of IRQ routing problem as 
neither of these are finished and stable yet so I'm not sure the missing 
IRQ is coming from IDE code. Especially because in the sii3112 case it 
seems to be generated and only get lost in the last step in the IRQ 
conroller but don't see why. The guest should have enabled the 
corresponding interrupt I think. For via-ide it's not obvious where the 
IRQ gets lost, it seems to be generated later so I don't understand that 
completely either.

> If you have any IDE traces from a hang, feel free to throw them up on a
> pastebin for me to take a peek at; it might help for me to see the exact
> sequence that causes a hang in QEMU's IDE terms to see if I can't
> "reverse engineer" what the guest is hoping to have happen. Maybe I can
> trace this to a bad register value.

See more logs in the ticket, let me know if you'd need me to check 
something else. Thanks a lot for looking into this, I'd need to look up 
all of these IDE interactions to try to make sense of the logs which would 
take too much time. Maybe you can spot something easier.

> (Hm, it's failing on pio_in? It's using PIO on an IDE drive with a DMA
> controller? Is it failing to enable DMA and then failing to use PIO as a
> backup too? Maybe there are two bugs.)

Before getting to this point where it hangs waiting for the IRQ after 
switching on UDMA the firmware did find all devices and loaded the OS from 
the CD all right and the OS also can talk to ide devices as long as it 
uses only PIO. The IRQ problem only happens after DMA is enabled but I'm 
not sure it uses IRQ in PIO at all.

AmigaOS and MorphOS really want to use UDMA only (or highest DMA mode the 
device reports) as otherwise it would be too slow on real hardware so I 
don't think it wants to fall back, just failing the drive if it does not 
work in the DMA mode it reports.

Linux may do fallback I'm not sure but booting from a 
debian-8.11.0-powerpc-netinst.iso seems to work even after it says 
enabling DMA, whereas I got the same problem with Linux before I hooked up 
IRQs correctly. Linux logs I get now with via-ide:

[    0.858497] pata_via 0000:00:0c.1: version 0.3.4

[    0.905257] scsi0 : pata_via

[    0.925207] scsi1 : pata_via
[    0.925722] ata1: PATA max UDMA/100 cmd 0x1000 ctl 0x100c bmdma 0x1020 irq 9
[    0.925906] ata2: PATA max UDMA/100 cmd 0x1010 ctl 0x101c bmdma 0x1028 irq 9

[    1.297537] ata2.01: NODEV after polling detection
[    1.298650] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
[    1.318205] ata2.00: configured for UDMA/100
[    1.330427] scsi 1:0:0:0: CD-ROM            QEMU     QEMU DVD-ROM     2.5+ PQ: 0 ANSI: 5
[    1.401652] sr0: scsi3-mmc drive: 4x/4x cd/rw xa/form2 tray
[    1.401851] cdrom: Uniform CD-ROM driver Revision: 3.20
[    1.404116] sr 1:0:0:0: Attached scsi CD-ROM sr0
[    1.410853] sr 1:0:0:0: Attached scsi generic sg0 type 5

And if boots all right. I think Linux can use DMA and I see interrupts 
with Linux so maybe the drivers work differently and only the 
AmigaOS/MorphOS drivers do something that does not work with QEMU or 
depend on some features on hardware that I did not model correctly.

Regards,
BALATON Zoltan

IDE IRQ problem after UDMA enabled (was: Re: Emulating Solaris 10 on SPARC64 sun4u)

[BALATON Zoltan]

Hello,

On Mon, 10 Feb 2020, John Snow wrote:
> It sounds like the real problem is either in the bmdma controller (or
> its unique interaction with hw/ide/core.c -- which is possible) or in
> the interrupt routing somewhere else.
>
> If you have any IDE traces from a hang, feel free to throw them up on a
> pastebin for me to take a peek at; it might help for me to see the exact
> sequence that causes a hang in QEMU's IDE terms to see if I can't
> "reverse engineer" what the guest is hoping to have happen. Maybe I can
> trace this to a bad register value.

I've got some traces from Linux and MorphOS (both on my work in progress 
pegasos2 emulation using via-ide where I can most easily reproduce this) 
but I'm not sure what to look for in these. MorphOS starts booting, so 
firmware can read ide-cd connected to via-ide as well as MorphOS can 
before enabling UDMA 5 mode but stops after that and cannot read the drive 
any more. Linux works even after enabling DMA. I've gathered some logs in 
https://osdn.net/projects/qmiga/ticket/38949 previously but now I try to 
list here the part in more detail where drive is detected, enabling DMA 
and first command after that in case you can spot something in these that 
could explain why it fails with MorphOS driver.

First the working Linux case:

pci_cfg_read via-ide 12:1 @0x4 -> 0x87
pci_cfg_read via-ide 12:1 @0x3d -> 0x1
pci_cfg_read via-ide 12:1 @0x4 -> 0x87
pci_cfg_read via-ide 12:1 @0x40 -> 0xb
pci_cfg_read via-ide 12:1 @0x40 -> 0xb
bmdma_read_via bmdma: readb 0x2 : 0x00
bmdma_read_via bmdma: readb 0x2 : 0x00
pci_cfg_read via-ide 12:1 @0x4 -> 0x87
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x0a; bus 0x56229cb35600
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x00; bus 0x56229cb35600 IDEState 0x56229cb35a58
bmdma_read_via bmdma: readb 0x2 : 0x00
bmdma_write_via bmdma: writeb 0x2 : 0x00
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x0a; bus 0x56229cb35ef0
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
bmdma_read_via bmdma: readb 0x2 : 0x00
bmdma_write_via bmdma: writeb 0x2 : 0x00
pci_cfg_read via-ide 12:1 @0x9 -> 0x8f
[    2.589547] scsi0 : pata_via
[    2.590949] scsi1 : pata_via
[    2.591488] ata1: PATA max UDMA/100 cmd 0x1000 ctl 0x100c bmdma 0x1020 irq 9
[    2.591652] ata2: PATA max UDMA/100 cmd 0x1010 ctl 0x101c bmdma 0x1028 irq 9

[...]

[    2.938174] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
pci_cfg_read via-ide 12:1 @0x4c -> 0xaa
pci_cfg_write via-ide 12:1 @0x4c <- 0xa2
pci_cfg_write via-ide 12:1 @0x4e <- 0x31
pci_cfg_write via-ide 12:1 @0x49 <- 0x31
pci_cfg_read via-ide 12:1 @0x51 -> 0x17
pci_cfg_write via-ide 12:1 @0x51 <- 0x17
pci_cfg_read via-ide 12:1 @0x4c -> 0xa2
pci_cfg_write via-ide 12:1 @0x4c <- 0xa2
pci_cfg_write via-ide 12:1 @0x4e <- 0x31
pci_cfg_write via-ide 12:1 @0x49 <- 0x31
pci_cfg_read via-ide 12:1 @0x51 -> 0x17
pci_cfg_write via-ide 12:1 @0x51 <- 0xf0
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0xa0; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_status_read IDE PIO rd @ 0x4 (Alt Status); val 0x50; bus 0x56229cb35ef0; IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x0a; bus 0x56229cb35ef0
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0xa0; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x1 (Features); val 0x03; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x2 (Sector Count); val 0x45; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x3 (Sector Number); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x4 (Cylinder Low); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x5 (Cylinder High); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x7 (Command); val 0xef; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_exec_cmd IDE exec cmd: bus 0x56229cb35ef0; state 0x56229cb35f78; cmd 0xef
ide_status_read IDE PIO rd @ 0x4 (Alt Status); val 0x50; bus 0x56229cb35ef0; IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x08; bus 0x56229cb35ef0
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
bmdma_read_via bmdma: readb 0x2 : 0x00
bmdma_write_via bmdma: writeb 0x2 : 0x00
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x1 (Error); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x2 (Sector Count); val 0x45; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x3 (Sector Number); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x4 (Cylinder Low); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x5 (Cylinder High); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x6 (Device/Head); val 0x20; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0xa0; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_status_read IDE PIO rd @ 0x4 (Alt Status); val 0x50; bus 0x56229cb35ef0; IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x0a; bus 0x56229cb35ef0
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0xa0; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x1 (Features); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x2 (Sector Count); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x3 (Sector Number); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x4 (Cylinder Low); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x5 (Cylinder High); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x7 (Command); val 0xa1; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_exec_cmd IDE exec cmd: bus 0x56229cb35ef0; state 0x56229cb35f78; cmd 0xa1
ide_status_read IDE PIO rd @ 0x4 (Alt Status); val 0x58; bus 0x56229cb35ef0; IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x58; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_status_read IDE PIO rd @ 0x4 (Alt Status); val 0x50; bus 0x56229cb35ef0; IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x08; bus 0x56229cb35ef0
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
bmdma_read_via bmdma: readb 0x2 : 0x00
bmdma_write_via bmdma: writeb 0x2 : 0x00
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x1 (Error); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x2 (Sector Count); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x3 (Sector Number); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x4 (Cylinder Low); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x5 (Cylinder High); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x6 (Device/Head); val 0x20; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
[    2.953806] ata2.00: configured for UDMA/100
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0xa0; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_status_read IDE PIO rd @ 0x4 (Alt Status); val 0x50; bus 0x56229cb35ef0; IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0xa0; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x1 (Features); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x2 (Sector Count); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x3 (Sector Number); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x4 (Cylinder Low); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x5 (Cylinder High); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_write IDE PIO wr @ 0x7 (Command); val 0xa0; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_exec_cmd IDE exec cmd: bus 0x56229cb35ef0; state 0x56229cb35f78; cmd 0xa0
ide_status_read IDE PIO rd @ 0x4 (Alt Status); val 0x58; bus 0x56229cb35ef0; IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x58; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_atapi_cmd IDEState: 0x56229cb35f78; cmd: 0x00
ide_atapi_cmd_packet IDEState: 0x56229cb35f78; limit=0x0 packet: 00 00 00 00 00 00 00 00 00 00 00 00
mv64361_gpp_irq(0x56229c93a230, 31, 1) 80000000 80000000
mv64361_update_irq(0x56229c93a230, 59, 1)
ide_status_read IDE PIO rd @ 0x4 (Alt Status); val 0x50; bus 0x56229cb35ef0; IDEState 0x56229cb35f78
mv64361_gpp_irq(0x56229c93a230, 31, 0) 0
mv64361_update_irq(0x56229c93a230, 59, 0)
ide_status_read IDE PIO rd @ 0x4 (Alt Status); val 0x50; bus 0x56229cb35ef0; IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
bmdma_read_via bmdma: readb 0x2 : 0x04
bmdma_write_via bmdma: writeb 0x2 : 0x04
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x56229cb35ef0 IDEState 0x56229cb35f78
ide_ioport_read IDE PIO rd @ 0x1 (Error); val 0x00; bus 0x56229cb35ef0 IDEState 0x56229cb35f78

While MorphOS stops after enabling DMA:

PCI ATA/ATAPI Driver-Driver_ScanBus@1: Identify succeed
PCI ATA/ATAPI Driver-Driver_ScanBus@1: Signature 0x0
PCI ATA/ATAPI Driver-Driver_ScanBus@1: Config 0x85c0
PCI ATA/ATAPI Driver-Driver_SetParam@2: Type 0x4
PCI ATA/ATAPI Driver-Driver_SetParam@2: Capabilities 0x300
PCI ATA/ATAPI Driver-Driver_SetParam@2: PIOMode 0x0
PCI ATA/ATAPI Driver-Driver_SetParam@2: ATAPI supports at least PioMode 3
PCI ATA/ATAPI Driver-Driver_SetParam@2: Old PIOMode 0x3 DMAMode 0x0
PCI ATA/ATAPI Driver-Driver_SetParam@2: New PIOMode/DMAMode fields are valid
PCI ATA/ATAPI Driver-Driver_SetParam@2: PIOMask 0x3 DMAMask 0x7
PCI ATA/ATAPI Driver-Driver_SetParam@2: Supported PIOMode 4 DMAMode 2 UDMAMode 5
PCI ATA/ATAPI Driver-Driver_SetParam@2: Version 30 Revision 0
PCI ATA/ATAPI Driver-Driver_SetParam@2: 12 byte cmds
PCI ATA/ATAPI Driver-Driver_SetParam@2: Max PIOMode 4
PCI ATA/ATAPI Driver-Driver_SetParam@2: Set PioMode 4
PCI ATA/ATAPI Driver-Driver_SetFeature@2: Code 0x3 SubCode 0xc
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x0a; bus 0x562c141a9840
ide_ioport_write IDE PIO wr @ 0x1 (Features); val 0x03; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x2 (Sector Count); val 0x0c; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x3 (Sector Number); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x4 (Cylinder Low); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x5 (Cylinder High); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0xa0; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x7 (Command); val 0xef; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_exec_cmd IDE exec cmd: bus 0x562c141a9840; state 0x562c141a98c8; cmd 0xef
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x2 (Sector Count); val 0x0c; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x3 (Sector Number); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x4 (Cylinder Low); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x5 (Cylinder High); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x6 (Device/Head); val 0xa0; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x00; bus 0x562c141a9840
PCI ATA/ATAPI Driver-Driver_SetFeature@2: done
PCI ATA/ATAPI Driver@2: PIO Mode 4
pci_cfg_write via-ide 12:1 @0x49 <- 0x20
PCI ATA/ATAPI Driver-Driver_SetParam@2: Set DmaMode 2
PCI ATA/ATAPI Driver-Driver_SetFeature@2: Code 0x3 SubCode 0x22
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x0a; bus 0x562c141a9840
ide_ioport_write IDE PIO wr @ 0x1 (Features); val 0x03; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x2 (Sector Count); val 0x22; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x3 (Sector Number); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x4 (Cylinder Low); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x5 (Cylinder High); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0xa0; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x7 (Command); val 0xef; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_exec_cmd IDE exec cmd: bus 0x562c141a9840; state 0x562c141a98c8; cmd 0xef
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x2 (Sector Count); val 0x22; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x3 (Sector Number); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x4 (Cylinder Low); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x5 (Cylinder High); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x6 (Device/Head); val 0xa0; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x00; bus 0x562c141a9840
PCI ATA/ATAPI Driver-Driver_SetFeature@2: done
bmdma_read_via bmdma: readb 0x2 : 0x00
bmdma_write_via bmdma: writeb 0x2 : 0x26
PCI ATA/ATAPI Driver-Driver_SetParam@2: Set UDmaMode 5
PCI ATA/ATAPI Driver-Driver_SetFeature@2: Code 0x3 SubCode 0x45
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x0a; bus 0x562c141a9840
ide_ioport_write IDE PIO wr @ 0x1 (Features); val 0x03; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x2 (Sector Count); val 0x45; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x3 (Sector Number); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x4 (Cylinder Low); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x5 (Cylinder High); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0xa0; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x7 (Command); val 0xef; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_exec_cmd IDE exec cmd: bus 0x562c141a9840; state 0x562c141a98c8; cmd 0xef
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x50; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x2 (Sector Count); val 0x45; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x3 (Sector Number); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x4 (Cylinder Low); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x5 (Cylinder High); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x6 (Device/Head); val 0xa0; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_cmd_write IDE PIO wr @ 0x4 (Device Control); val 0x00; bus 0x562c141a9840
PCI ATA/ATAPI Driver-Driver_SetFeature@2: done
PCI ATA/ATAPI Driver@2: UDMA Mode 5
pci_cfg_write via-ide 12:1 @0x51 <- 0xe0
bmdma_read_via bmdma: readb 0x2 : 0x20
bmdma_write_via bmdma: writeb 0x2 : 0x26
PCI ATA/ATAPI Driver-Driver_SetParam@2: CDROM..Set no WriteCache
PCI ATA/ATAPI Driver-Driver_SetParam@2: Cylinders 0
PCI ATA/ATAPI Driver-Driver_SetParam@2: Heads 0
PCI ATA/ATAPI Driver-Driver_SetParam@2: Sectors/Cyl 0
PCI ATA/ATAPI Driver-Driver_SetParam@2: TotalSectors 0
PCI ATA/ATAPI Driver-Driver_SetParam@2: TotalSectors48 0
PCI ATA/ATAPI Driver-Driver_SetParam@2: Support.Flags 0x200003

Then it tries to identify the phantom ATA drive that seems to be present 
on other port but not working; this was discussed before. Finally tries to 
read CD drive:
[...]

Dev_Inquiry@ide.device-2: DiskPort 0x140f8890
Dev_Inquiry@ide.device-2: ATAPI
Dev_InquirySCSI@ide.device-2:
Dev_InquirySCSI@ide.device-2: Send TestDrive
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a9c98
ide_ioport_write IDE PIO wr @ 0x1 (Features); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x2 (Sector Count); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x3 (Sector Number); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x4 (Cylinder Low); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x5 (Cylinder High); val 0x80; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x6 (Device/Head); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_write IDE PIO wr @ 0x7 (Command); val 0xa0; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_exec_cmd IDE exec cmd: bus 0x562c141a9840; state 0x562c141a98c8; cmd 0xa0
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x58; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x58; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x58; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x2 (Sector Count); val 0x01; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x5 (Cylinder High); val 0x80; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x4 (Cylinder Low); val 0x00; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x58; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x58; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x58; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x58; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x58; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_ioport_read IDE PIO rd @ 0x7 (Status); val 0x58; bus 0x562c141a9840 IDEState 0x562c141a98c8
ide_atapi_cmd IDEState: 0x562c141a98c8; cmd: 0x00
ide_atapi_cmd_packet IDEState: 0x562c141a98c8; limit=0x8000 packet: 00 00 00 00 00 00 00 00 00 00 00 00
mv64361_gpp_irq(0x562c13faea60, 31, 1) 80000000 80000000
mv64361_update_irq(0x562c13faea60, 59, 1)
mv64361_gpp_irq(0x562c13faea60, 31, 0) 0
mv64361_update_irq(0x562c13faea60, 59, 0)
mv64361_gpp_irq(0x562c13faea60, 31, 1) 80000000 80000000
mv64361_update_irq(0x562c13faea60, 59, 1)
mv64361_gpp_irq(0x562c13faea60, 31, 0) 0
mv64361_update_irq(0x562c13faea60, 59, 0)

Then it stucks here not sending any more ATAPI commands despite interrupt 
is raised and lowered a few times afterwards but I don't see any more ide 
commands issued so it seems it may not get the expected interrupt? Do you 
see anything in the above logs that could explain this?

Thank you,
BALATON Zoltan

Re: IDE IRQ problem after UDMA enabled (was: Re: Emulating Solaris 10 on SPARC64 sun4u)

[BALATON Zoltan]

On Tue, 25 Feb 2020, BALATON Zoltan wrote:
> On Mon, 10 Feb 2020, John Snow wrote:
>> It sounds like the real problem is either in the bmdma controller (or
>> its unique interaction with hw/ide/core.c -- which is possible) or in
>> the interrupt routing somewhere else.
>> 
>> If you have any IDE traces from a hang, feel free to throw them up on a
>> pastebin for me to take a peek at; it might help for me to see the exact
>> sequence that causes a hang in QEMU's IDE terms to see if I can't
>> "reverse engineer" what the guest is hoping to have happen. Maybe I can
>> trace this to a bad register value.
>
> I've got some traces from Linux and MorphOS (both on my work in progress 
> pegasos2 emulation using via-ide where I can most easily reproduce this) but 
> I'm not sure what to look for in these. MorphOS starts booting, so firmware 
> can read ide-cd connected to via-ide as well as MorphOS can before enabling 
> UDMA 5 mode but stops after that and cannot read the drive any more. Linux 
> works even after enabling DMA. I've gathered some logs in 
> https://osdn.net/projects/qmiga/ticket/38949 previously but now I try to list 
> here the part in more detail where drive is detected, enabling DMA and first 
> command after that in case you can spot something in these that could explain 
> why it fails with MorphOS driver.

Never mind, I've found a clue in NetBSD's driver:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/viaide.c?rev=1.89&content-type=text/x-cvsweb-markup&only_with_tag=MAIN

which has a comment that says:

/*
  * At least under certain (mis)configurations (e.g. on the "Pegasos" board)
  * the VT8231-IDE's native mode only works with irq 14/15, and cannot be
  * programmed to use a single native PCI irq alone. So we install an interrupt
  * handler for each channel, as in compatibility mode.
  */

If I change via-ide to use ISA IRQ14 and 15 and ignore what's programmed 
in the PCI config reg then MorphOS works with UDMA so it expects that. 
This change however breaks Linux which still boots after getting some 
errors but maybe it downgrades to PIO mode then. I'll need to find out 
more about how is this broken on real hardware and how can we emulate it.

So you don't need to look at the logs unless you want to check why it sees 
a non working ATA device after resetting the bus but logs in the ticket 
above may be more useful for that as I did not include that part in this 
email.

Thank you,
BALATON Zoltan

RE: Emulating Solaris 10 on SPARC64 sun4u

[BALATON Zoltan]

On Mon, 10 Feb 2020, BALATON Zoltan wrote:
> This suggests the common IDE bmdma and ide-cd code is likely OK and problem 
> is somewhere in irq routing. What's relevant for this thread and sparc64 is 
> that then you should also check interrupt controller and routing if an 
> interrupt raised by the IDE controller could get to the CPU in your case as 
> that could be where the problem is and maybe not in common code as I've 
> suspected before.

I can now confirm that my problem was related to IRQ routing as noted 
here:

https://lists.nongnu.org/archive/html/qemu-devel/2020-02/msg07225.html

so any similar problem for Solaris is not related to this and common IDE 
and BMDMA code are likely OK so you may want to check IRQ handling in 
board and chipset emulation in case the cause is similar to what I had.

Regards,
BALATON Zoltan

Re: Emulating Solaris 10 on SPARC64 sun4u

[Mark Cave-Ayland]

On 05/02/2020 06:31, jasper.lowell@bt.com wrote:

> I'm currently working towards emulating Solaris 10 on sun4u.
> 
>  
> 
> The Solaris 10 ISO image I am attempting to boot is the one from the Oracle
> 
> download page at
> https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
> 
> Image: sol-10-u11-ga-sparc-dvd.iso
> 
> MD5:   53e8b066f7f250ce2fd2cef063f8072b
> 
>  
> 
> I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
> 
>  
> 
> The command I am using to run QEMU is:
> 
> ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios
> ./openbios/obj-sparc64/openbios-builtin.elf -cdrom
> ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G
> 
>  
> 
> ```
> 
> CPUs: 1 x SUNW,UltraSPARC-IIi
> 
> UUID: 00000000-0000-0000-0000-000000000000
> 
> Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
> 
>   Type 'help' for detailed information
> 
> Trying cdrom:f...
> 
> Not a bootable ELF image
> 
> Not a bootable a.out image
> 
>  
> 
> Loading FCode image...
> 
> Loaded 7420 bytes
> 
> entry point is 0x4000
> 
> Evaluating FCode...
> 
> Evaluating FCode...
> 
> Ignoring failed claim for va 1000000 memsz af6d6!
> 
> Ignoring failed claim for va 1402000 memsz 4dcc8!
> 
> Ignoring failed claim for va 1800000 memsz 510c8!
> 
> SunOS Release 5.10 Version Generic_147147-26 64-bit
> 
> Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
> 
> could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught
> 
> interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
> 
> \ All rights reserved.
> 
> \
> 
> \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
> 
>  
> 
> hex
> 
>  
> 
> only forth also definitions
> 
> vocabulary kdbg-words
> 
> also kdbg-words definitions
> 
>  
> 
> defer p@
> 
> defer p!
> 
> ['] x@ is p@
> 
> ['] x! is p!
> 
>  
> 
> 8 constant ptrsize
> 
>  
> 
> d# 32 constant nbitsminor
> 
> h# ffffffff constant maxmin
> 
> \
> 
> \ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
> 
> \ Use is subject to license terms.
> 
> \
> 
>  
> 
> \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
> 
>  
> 
> h# 7ff constant v9bias
> 
> h# unix-tte:interpret: exception -13 caught
> 
> interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed
> 
> WARNING: consconfig: cannot find driver for screen device /pci@1fe,0/pci@1,1/QEMU,VGA@2
> 
> Configuring devices.
> 
> WARNING: Interrupt not seen after set_features
> 
> Using RPC Bootparams for network configuration information.
> 
> Attempting to configure interface hme0...
> 
> WARNING: Power off requested from power button or SC, powering down the system!
> 
> Skipped interface hme0
> 
> svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs mount -a failed: one or
> more file systems failed to mount
> 
> Serial console, reverting to text install
> 
> Beginning system identification...
> 
> Searching for configuration file(s)...
> 
> Search complete.
> 
> Discovering additional network configuration...
> 
> ```
> 
>  
> 
> The installation menu is shown after but the console is unresponsive.
> 
>  
> 
> After some debugging, it looks like the QEMU front-end is correctly filling
> 
> the serial receive buffer with characters, and then starts dropping them once
> 
> the number of characters in the buffer reach the interrupt level. The interrupt
> 
> level happens to be 1 when booting Solaris 10. This looks like normal behaviour
> 
> to me.
> 
>  
> 
> I started looking at why the serial receive buffer might not be consumed and
> 
> considered that interrupts might not be being raised correctly. I ran with
> 
> tracing and there were no interrupts for IRQ 0x2b like there are when using
> 
> OpenBSD. When inspecting the registers of the serial device it looks like the
> 
> Interrupt Enable Register is set to zero.
> 
>  
> 
> If Solaris 10 was using the device is polling mode, it should be reading the RBR
> 
> or at least the LSR. When tracing serial_ioport_read and serial_ioport_write,
> 
> once the menu is hit, I don't see any read or writes to the serial device
> 
> registers despite me trying to send characters and use the menu.
> 
>  
> 
> The driver Solaris 10 is using for the device appears to be similar/same as
> 
> /usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code found at
> https://github.com/nxmirrors/onnv.
> 
>  
> 
> ```
> 
> asy->asy_hwtype = ASY16550AF;
> 
> OUTB(FIFOR, 0x00); /* clear fifo register */
> 
> asy->asy_trig_level = 0x00; /* sets the fifo Threshold to 1 */
> 
>  
> 
> /* set/Enable FIFO */
> 
> OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
> 
> (asy->asy_trig_level & 0xff));
> 
>  
> 
> if ((INB(ISR) & 0xc0) == 0xc0)
> 
>     asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
> 
> else {
> 
>     asy->asy_hwtype = ASY8250;
> 
>     OUTB(FIFOR, 0x00); /* NO FIFOs */
> 
>     asy->asy_trig_level = 0;
> 
> }
> 
> ```
> 
>  
> 
> From what I can tell when tracing serial_ioport_write and serial_ioport_read,
> 
> Solaris 10 correctly identifies the serial device and successfully attaches it.
> 
> In the asyattach function (OpenSolaris driver), interrupts are disabled by zeroing the
> 
> Interrupt Enable Register. From what I'm reading in OpenSolaris source code, interrupts
> 
> are reenabled when the device is "opened". This seems like consistent and
> 
> correct behaviour though I'm not sure why the device is not being opened to be
> 
> used by the serial console.
> 
>  
> 
> Is this an issue anyone else has tried to debug?
> 
> Are there any leads that I can follow up on for why the serial console becomes
> unresponsive
> 
> on Solaris 10?

It has been a while since I've looked at booting Solaris >= 10 but certainly the
messages above about set_features and the frozen console suggest that something is
going amiss with interrupt routing, although since Linux and NetBSD were fine the
last time I ran my OpenBIOS release tests then Solaris must be doing something
different here.

Note that the serial interrupts are routed from the ebus into sabre so the first
thing to check would be that the end-to-end routing from device to CPU looks correct
when using Solaris.


ATB,

Mark.

RE: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

Excuse the delay. I believe the reason why I am unable to locate the error string "Interrupt not seen after set_features" in the OpenSolaris source code is because it belongs to a proprietary driver that was not distributed with OpenSolaris. Rather than rely on source code I've had to debug this problem by observing Solaris 10's behaviour.

I previously linked https://docs.oracle.com/cd/E23824_01/html/821-1475/uata-7d.html that seems to indicate that this error is fatal.
Considering that the CMD646 IDE controller driver experiences a fatal error during the bootstrapping of the system, I suspect that the file system on the CDROM might not be accessible.
I'm not sure if this is directly related to the unresponsive serial console but I wouldn't be surprised.

When configuring devices, Solaris 10 uses the SET_FEATURE command on the CMD646 to set the transfer mode to MDMA mode.
From what I can tell, this is successful and the emulated IDE controller raises an interrupt acknowledging that the command was completed successfully. To determine whether or not this interrupt was successfully propagated to Solaris 10, I made manual changes to ensure that the interrupt was not raised for this event at this specific time. This resulted in a new error from Solaris 10 regarding "set_features".
- Solaris 10 appears to be able to see the interrupt from the completion of the SET_FEATURE command.
- Solaris 10 appears to then perform two reads on the status register. From what I understand, this has the side effect of clearing interrupts.
- Solaris 10 then writes to the device/head register.
- Solaris 10 then spins on ARTTIM23_INTR_CH1 expecting it to be set. When it is not set, the operation times out and we are presented with the fatal error regarding set_features.

I am not intimately familiar with the workings of the CMD646 or the ATA specification so I can only speculate.
- If the interrupt that Solaris 10 expects is the one from the SET_FEATURE command, then Solaris 10 is not expecting reading from the status register to clear ARTTIM23_INTR_CH1.
- If the interrupt that Solaris 10 expects is not the one from the SET_FEATURE command, then it must expect an interrupt to occur from writing to the device/head register.

I found it strange that Solaris 10 was spinning on ARTTIM23_INTR_CH1. Is it possible that Solaris 10 is not expecting the values of ARTTIM23_INTR_CH1 and MRDMODE_INTR_CH1 to be synced? I made changes to disable the syncing and the fatal error from Solaris 10 disappeared. Unfortunately, I can't tell whether or not this actually improved the emulation of Solaris 10 as the serial console is still unresponsive.

If there is a bug in the Solaris 10 driver I would expect this error to be more widely referenced online. I suspect that the emulated CMD646 is not perfectly faithful to the hardware and this is causing problems for Solaris 10.
I am not convinced that this problem is related to IRQ routing as Solaris 10 appears to recognise interrupts when they happen (or don't). Because of this, I don't think this error is related  to the DMA problem under MorphOS but I could be wrong.

Does anyone have any ideas that might explain why Solaris 10 insists that ARTTIM23_INTR_CH1 is set despite two previous reads of the status register?

Thanks,
Jasper Lowell.

-----Original Message-----
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> 
Sent: Sunday, 9 February 2020 10:26 PM
To: Lowell,J,Jasper,VIM R <jasper.lowell@bt.com>; qemu-devel@nongnu.org
Cc: atar4qemu@gmail.com
Subject: Re: Emulating Solaris 10 on SPARC64 sun4u

On 05/02/2020 06:31, jasper.lowell@bt.com wrote:

> I'm currently working towards emulating Solaris 10 on sun4u.
> 
>  
> 
> The Solaris 10 ISO image I am attempting to boot is the one from the 
> Oracle
> 
> download page at
> https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
> 
> Image: sol-10-u11-ga-sparc-dvd.iso
> 
> MD5:   53e8b066f7f250ce2fd2cef063f8072b
> 
>  
> 
> I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
> 
>  
> 
> The command I am using to run QEMU is:
> 
> ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios 
> ./openbios/obj-sparc64/openbios-builtin.elf -cdrom 
> ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G
> 
>  
> 
> ```
> 
> CPUs: 1 x SUNW,UltraSPARC-IIi
> 
> UUID: 00000000-0000-0000-0000-000000000000
> 
> Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
> 
>   Type 'help' for detailed information
> 
> Trying cdrom:f...
> 
> Not a bootable ELF image
> 
> Not a bootable a.out image
> 
>  
> 
> Loading FCode image...
> 
> Loaded 7420 bytes
> 
> entry point is 0x4000
> 
> Evaluating FCode...
> 
> Evaluating FCode...
> 
> Ignoring failed claim for va 1000000 memsz af6d6!
> 
> Ignoring failed claim for va 1402000 memsz 4dcc8!
> 
> Ignoring failed claim for va 1800000 memsz 510c8!
> 
> SunOS Release 5.10 Version Generic_147147-26 64-bit
> 
> Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
> 
> could not find debugger-vocabulary-hook>threads:interpret: exception 
> -13 caught
> 
> interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
> 
> \ All rights reserved.
> 
> \
> 
> \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
> 
>  
> 
> hex
> 
>  
> 
> only forth also definitions
> 
> vocabulary kdbg-words
> 
> also kdbg-words definitions
> 
>  
> 
> defer p@
> 
> defer p!
> 
> ['] x@ is p@
> 
> ['] x! is p!
> 
>  
> 
> 8 constant ptrsize
> 
>  
> 
> d# 32 constant nbitsminor
> 
> h# ffffffff constant maxmin
> 
> \
> 
> \ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
> 
> \ Use is subject to license terms.
> 
> \
> 
>  
> 
> \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
> 
>  
> 
> h# 7ff constant v9bias
> 
> h# unix-tte:interpret: exception -13 caught
> 
> interpret ' unix-tte is va>tte-data failed with error ffffffffffffffed
> 
> WARNING: consconfig: cannot find driver for screen device 
> /pci@1fe,0/pci@1,1/QEMU,VGA@2
> 
> Configuring devices.
> 
> WARNING: Interrupt not seen after set_features
> 
> Using RPC Bootparams for network configuration information.
> 
> Attempting to configure interface hme0...
> 
> WARNING: Power off requested from power button or SC, powering down the system!
> 
> Skipped interface hme0
> 
> svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs mount -a 
> failed: one or more file systems failed to mount
> 
> Serial console, reverting to text install
> 
> Beginning system identification...
> 
> Searching for configuration file(s)...
> 
> Search complete.
> 
> Discovering additional network configuration...
> 
> ```
> 
>  
> 
> The installation menu is shown after but the console is unresponsive.
> 
>  
> 
> After some debugging, it looks like the QEMU front-end is correctly 
> filling
> 
> the serial receive buffer with characters, and then starts dropping 
> them once
> 
> the number of characters in the buffer reach the interrupt level. The 
> interrupt
> 
> level happens to be 1 when booting Solaris 10. This looks like normal 
> behaviour
> 
> to me.
> 
>  
> 
> I started looking at why the serial receive buffer might not be 
> consumed and
> 
> considered that interrupts might not be being raised correctly. I ran 
> with
> 
> tracing and there were no interrupts for IRQ 0x2b like there are when 
> using
> 
> OpenBSD. When inspecting the registers of the serial device it looks 
> like the
> 
> Interrupt Enable Register is set to zero.
> 
>  
> 
> If Solaris 10 was using the device is polling mode, it should be 
> reading the RBR
> 
> or at least the LSR. When tracing serial_ioport_read and 
> serial_ioport_write,
> 
> once the menu is hit, I don't see any read or writes to the serial 
> device
> 
> registers despite me trying to send characters and use the menu.
> 
>  
> 
> The driver Solaris 10 is using for the device appears to be 
> similar/same as
> 
> /usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code found at 
> https://github.com/nxmirrors/onnv.
> 
>  
> 
> ```
> 
> asy->asy_hwtype = ASY16550AF;
> 
> OUTB(FIFOR, 0x00); /* clear fifo register */
> 
> asy->asy_trig_level = 0x00; /* sets the fifo Threshold to 1 */
> 
>  
> 
> /* set/Enable FIFO */
> 
> OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
> 
> (asy->asy_trig_level & 0xff));
> 
>  
> 
> if ((INB(ISR) & 0xc0) == 0xc0)
> 
>     asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
> 
> else {
> 
>     asy->asy_hwtype = ASY8250;
> 
>     OUTB(FIFOR, 0x00); /* NO FIFOs */
> 
>     asy->asy_trig_level = 0;
> 
> }
> 
> ```
> 
>  
> 
> From what I can tell when tracing serial_ioport_write and 
> serial_ioport_read,
> 
> Solaris 10 correctly identifies the serial device and successfully attaches it.
> 
> In the asyattach function (OpenSolaris driver), interrupts are 
> disabled by zeroing the
> 
> Interrupt Enable Register. From what I'm reading in OpenSolaris source 
> code, interrupts
> 
> are reenabled when the device is "opened". This seems like consistent 
> and
> 
> correct behaviour though I'm not sure why the device is not being 
> opened to be
> 
> used by the serial console.
> 
>  
> 
> Is this an issue anyone else has tried to debug?
> 
> Are there any leads that I can follow up on for why the serial console 
> becomes unresponsive
> 
> on Solaris 10?

It has been a while since I've looked at booting Solaris >= 10 but certainly the messages above about set_features and the frozen console suggest that something is going amiss with interrupt routing, although since Linux and NetBSD were fine the last time I ran my OpenBIOS release tests then Solaris must be doing something different here.

Note that the serial interrupts are routed from the ebus into sabre so the first thing to check would be that the end-to-end routing from device to CPU looks correct when using Solaris.


ATB,

Mark.

RE: Emulating Solaris 10 on SPARC64 sun4u

[BALATON Zoltan]

On Wed, 19 Feb 2020, jasper.lowell@bt.com wrote:
> When configuring devices, Solaris 10 uses the SET_FEATURE command on the CMD646 to set the transfer mode to MDMA mode.
> From what I can tell, this is successful and the emulated IDE controller 
> raises an interrupt acknowledging that the command was completed 
> successfully. To determine whether or not this interrupt was 
> successfully propagated to Solaris 10, I made manual changes to ensure 
> that the interrupt was not raised for this event at this specific time. 
> This resulted in a new error from Solaris 10 regarding "set_features".
> - Solaris 10 appears to be able to see the interrupt from the completion of the SET_FEATURE command.
> - Solaris 10 appears to then perform two reads on the status register. From what I understand, this has the side effect of clearing interrupts.
> - Solaris 10 then writes to the device/head register.
> - Solaris 10 then spins on ARTTIM23_INTR_CH1 expecting it to be set. 
> When it is not set, the operation times out and we are presented with 
> the fatal error regarding set_features.
>
> I am not intimately familiar with the workings of the CMD646 or the ATA specification so I can only speculate.
> - If the interrupt that Solaris 10 expects is the one from the 
> SET_FEATURE command, then Solaris 10 is not expecting reading from the 
> status register to clear ARTTIM23_INTR_CH1.
> - If the interrupt that Solaris 10 expects is not the one from the 
> SET_FEATURE command, then it must expect an interrupt to occur from 
> writing to the device/head register.

I don't have definitive answers so these are some ideas but I may be 
completely wrong.

I don't know about Solaris but what I've seen on PPC and via-ide is that 
it works until switched to UDMA mode then it freezes on the first command 
issued after switching to UDMA so it seems like it expects an interrupt 
that's not generated or not routed correctly but only in DMA mode, in the 
initial PIO mode it works. Not sure if this is useful at all for your case 
though so you may just disregard it.

> I found it strange that Solaris 10 was spinning on ARTTIM23_INTR_CH1. Is 
> it possible that Solaris 10 is not expecting the values of 
> ARTTIM23_INTR_CH1 and MRDMODE_INTR_CH1 to be synced? I made changes to 
> disable the syncing and the fatal error from Solaris 10 disappeared. 
> Unfortunately, I can't tell whether or not this actually improved the 
> emulation of Solaris 10 as the serial console is still unresponsive.

I think the syncing was added in commit 271dddd1 and the commit log:

https://lists.gnu.org/archive/html/qemu-devel/2014-08/msg02644.html

cites the data sheet for that and there were other commits around it that 
were changing similar things as well. I guess this was fixing some problem 
at the time (Mark may remember more) so maybe these are correct but I 
don't know what actual hardware does. I also remember this IDE controller 
chip had different versions with early ones having implementation bugs 
that could cause problems so people generally avoided it or drivers may 
have hacks to fix those so it's possible that this tries to work around 
some hardware bug? I don't remember the details but maybe Linux kernel 
source has some history on this.

> If there is a bug in the Solaris 10 driver I would expect this error to 
> be more widely referenced online. I suspect that the emulated CMD646 is 
> not perfectly faithful to the hardware and this is causing problems for 
> Solaris 10.
> I am not convinced that this problem is related to IRQ routing as 
> Solaris 10 appears to recognise interrupts when they happen (or don't). 
> Because of this, I don't think this error is related to the DMA problem 
> under MorphOS but I could be wrong.

I'm not sure either because during testing I've seen two cases and in one 
IRQ was raised but did not reach CPU due to being masked in interrupt 
controller so that suggests it's not a problem with generating the IRQ in 
IDE code but problem is afterwards but still could not understand why it 
fails. (Seems to work on Linux though so maybe understanding what the 
working and non-working cases do differently could get closer to the 
answer.)

> Does anyone have any ideas that might explain why Solaris 10 insists 
> that ARTTIM23_INTR_CH1 is set despite two previous reads of the status 
> register?

I can only guess. The data sheet says that in PCI native mode these bits 
should be checked to determine if an interrupt on PCI INTA is coming from 
this controller (but for PIO mode, for DMA it just refers to Intel's spec 
without any more info). Specifically:

"When an IDE port is in PCI IDE Native Mode, the IDE task file registers 
may be mapped to non-standard port addresses, and IDE drive interrupts 
occur at PCI INTA. [As opposed to Legacy mode when it uses standard ISA 
IDE port numbers and IRQ14 and 15.] Therefore, if both IDE ports are in 
PCI IDE Native Mode, drive interrupts from both IDE ports are multiplexed 
into PCI INTA. In this case, the interrupt status bits must be polled to 
determine which IDE port generated the interrupt, or whether the interrupt 
was generated by another PCI device sharing INTA on the bus.

1) The host reads CFR (index 50h). If bit 2 is set, then the interrupt 
occurred on the primary IDE port.

2) The host reads ARTTIM23. If bit 4 is set, then the interrupt occurred 
on the secondary IDE port.

3) If 1) and 2) are both false, then the interrupt was generated by 
another PCI device sharing INTA with the PCI0646."

As for why it polls this reg, if it's not expecting interrupt on primary 
port and just reading both as described above, it may be expecting more 
interrupts than QEMU is generating or it may expect them to arrive with 
some delay or after previous one is cleared that QEMU could just raise 
once due to being faster or doing something differently? Does someone know 
what interrupts are generated on real hardware in DMA mode so we can 
compare that to what we see with QEMU?

Regards,
BALATON Zoltan

RE: Emulating Solaris 10 on SPARC64 sun4u

[BALATON Zoltan]

On Wed, 19 Feb 2020, BALATON Zoltan wrote:
> faster or doing something differently? Does someone know what interrupts are 
> generated on real hardware in DMA mode so we can compare that to what we see 
> with QEMU?

The document Programming Interface for Bus Master IDE Controller, Revision 
1.0 (5/16/94) has some info on this. AFAIU it says that after DMA 
operation is completed an IRQ should be raised. On page 5, section 3.1. 
Data Synchronization it says:

"Another way to view this requirement is that the first read to the 
controller Status register in response to the IDE device interrupt must 
return with the Interrupt bit set and with the guarantee that all buffered 
data has been written to memory."

Not sure if this is relevant but how is it handled in QEMU? Is the right 
interrupt bit set after DMA transfer is done? If so is it the one that's 
checked by the OS driver?

Regards,
BALATON Zoltan

Re: Emulating Solaris 10 on SPARC64 sun4u

[Dr. David Alan Gilbert]

* BALATON Zoltan (balaton@eik.bme.hu) wrote:
> On Wed, 19 Feb 2020, BALATON Zoltan wrote:
> > faster or doing something differently? Does someone know what interrupts
> > are generated on real hardware in DMA mode so we can compare that to
> > what we see with QEMU?
> 
> The document Programming Interface for Bus Master IDE Controller, Revision
> 1.0 (5/16/94) has some info on this. AFAIU it says that after DMA operation
> is completed an IRQ should be raised. On page 5, section 3.1. Data
> Synchronization it says:
> 
> "Another way to view this requirement is that the first read to the
> controller Status register in response to the IDE device interrupt must
> return with the Interrupt bit set and with the guarantee that all buffered
> data has been written to memory."
> 
> Not sure if this is relevant but how is it handled in QEMU? Is the right
> interrupt bit set after DMA transfer is done? If so is it the one that's
> checked by the OS driver?

One thing to be a little careful of is I remember the 646 was always
known for having a few quirks (I've not got a SPARC64 ith one, but I
think my Alpha has it).  So whether you're chasing a generic IDE BM
problem or a 646 special is fun.

Dave

> Regards,
> BALATON Zoltan
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

RE: Emulating Solaris 10 on SPARC64 sun4u

[BALATON Zoltan]

On Wed, 19 Feb 2020, BALATON Zoltan wrote:
> On Wed, 19 Feb 2020, BALATON Zoltan wrote:
>> faster or doing something differently? Does someone know what interrupts 
>> are generated on real hardware in DMA mode so we can compare that to what 
>> we see with QEMU?
>
> The document Programming Interface for Bus Master IDE Controller, Revision 
> 1.0 (5/16/94) has some info on this. AFAIU it says that after DMA operation 
> is completed an IRQ should be raised. On page 5, section 3.1. Data 
> Synchronization it says:
>
> "Another way to view this requirement is that the first read to the 
> controller Status register in response to the IDE device interrupt must 
> return with the Interrupt bit set and with the guarantee that all buffered 
> data has been written to memory."
>
> Not sure if this is relevant but how is it handled in QEMU? Is the right 
> interrupt bit set after DMA transfer is done? If so is it the one that's 
> checked by the OS driver?

I think I now understand the problem with via-ide at least and the 
following is true for that case. I'm not sure about the CMD646 but it may 
be similar as these seem to be similar designs or maybe even related 
somehow. The problem in my case stems from that the device has two modes 
documented: legacy where it uses standard ISA ioports and INT14 and 15 for 
the two channels and native mode in which it uses PCI BARs for io address 
and an IRQ configurable via PCI_INTERRUPT_LINE (config reg 9). It seems 
the IRQ in native mode is still not a PCI INT line but an ISA IRQ, however 
it can be selected by config reg and it's a single interrupt instead of 
two for separate channels (Linux prints these during boot so that's a good 
way to check which mode it thinks it's using). That's so far is complex 
enough to not be easy to emulate in QEMU as we can set up legacy ISA ports 
with ide_init_ioport() but there's no way then to switch it off so via-ide 
either implemented legacy or native mode but can't correctly switch 
between those. This may not be a problem most of the time for Linux at 
least which tries to check which mode the controller is in and use that so 
it would work with whatever is there as long as the regs match what's 
emulated so we can just emulate one mode and still work.

But all of the above is further complicated by that on some (most?) boards 
there's also a "non 100% native mode" in which the io addresses are taken 
from the PCI BARs but still using hardcoded INT14 and 15, ignoring the 
setting in PCI_INTERRUPT_LINE. So guest drivers may assume this without 
checking regs and not care about what's set in PCI_INTERRUPT_LINE just 
expect interrupts on INT14 and 15. If the emulation raises PCI INT or some 
other isa interrupt it won't work, even if config regs correctly describe 
the difference following the docs but guest drivers don't care about the 
chip spec only the implementation on the board they meant to run on. 
Unfortunately different guests use different heuristics and workarounds 
(even Linux does so on different archs) so it's not easy to make an 
emulation that works with all. The pegasos2 firmware for example sets 
via-ide in native mode and assigns interrupt 9 but on real hardware this 
reg seems to be hardcoded to 14 and Linux uses this to detect if it needs 
to use the half-native mode but sets the mode reg to legacy to note this 
despite then using PCI BARs (so we can't hardcode mode reg to always 
native without breaking this but have to force int reg and emulate half 
native mode to work with other guests). Linux would also work with 100% 
native mode with IRQ9 but Amiga like OSes don't seem to care and just use 
hardcoded half-native mode regardless of config regs and expect interrupt 
on IRQ14 and 15. I could make a patch to work with all these on pegasos2 
but the via-ide is also used on a mips board where the corresponding Linux 
version also applies its own (different) workarounds corresponding to the 
quirks of that board and ends up either trying to use legacy mode (which 
is not emulated as io is only on PCI BARs) or trying to use 100% native 
mode which does not work with half-native interrupts. I think I'll need to 
add a special property to the device to set it to half-native for pegasos2 
and leave it 100% native for mips, otherwise there may not be a 
combination which works with all these firmwares and guests on both 
machines. (We still can avoid having to implement native mode as well but 
I can imagine if some PC guests were involved we may need that too but on 
these ppc and mips boards and also in your case I think native and 
half-native modes should be enough as that's all guests use.)

The CMD646 case might be similar and that's also used on a hppa board so 
you may need to check with that too if you make changes. To check this 
theory you might try forcing ide interrupts to be IRQ14 and 15 via 
something like:

qemu_set_irq(isa_get_irq(NULL, (channel ? 15 : 14)), level);

instead of using PCI interrupt or configured ISA interrupt in native mode 
and see if Solaris likes it better. If so then go on a quest to find a 
combination that works with at least Linux on both the sparc and hppa 
boards and Solaris (if that's not enough you can also try NeXTSTEP :-) ). 
So I think after all the common ide and bmdma code is probably OK and we 
have problems in individual controller emulations which is made difficult 
because of different hardware quirks and assumptions of guest sofware.

Regards,
BALATON Zoltan

RE: Emulating Solaris 10 on SPARC64 sun4u

[BALATON Zoltan]

On Fri, 28 Feb 2020, BALATON Zoltan wrote:
> I think I now understand the problem with via-ide at least and the following

FYI, I came up with this patch:

http://patchwork.ozlabs.org/project/qemu-devel/list/?series=161714

that fixes my problem with via-ide. The first patch also touches CMD646 to 
allow reusing a field in PCIIDEState for flags but I did not change 
anything else for CMD646.

Regards,
BALATON Zoltan

Re: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

Just thought I'd chime in with an update.

We are currently emulating a 16550A UART. The guest sees this as the SU
device, referring to the SuperIO port (a pair of 16550A UARTs). On the
Ultra 5, the machine that Sun4u is modelled against, SuperIO was used
for the keyboard and mouse. The Ultra 5 also had a DB25 (ttya default)
and a DB9 (ttyb default) with a SAB82532 ESSC2.

Using tracing, I've looked through how the 16550A UART is touched and
it looks like Solaris 10 has no issues identifying the device. I've
matched register accesses with driver code in OpenSolaris and I'm
pretty sure the device is attached successfully. Also, if you boot
Solaris 10 with debugging output, you can see that the device gets
labelled as su0. The only time Solaris is capable of writing to the
console is when OpenBIOS is used as a proxy.

Rather than Solaris deciding against using SuperIO as a tty, I don't
think there was ever any support for doing so (at least on SPARC
machines). This could be an explanation for why the system appears to
be trucking along just fine despite a seemingly frozen console - there
is no console. I don't think the frozen console is the fault of broken
interrupt routing as the 16550A UART is never programmed to generate
them.

I've started work on emulating the SAB 82532 ESSC2 but it's
unfortunately way more complex than than the 16550A. For instance, it's
possible to configure different baudrates for receiving and
transmitting. QEMU's chardev interface doesn't appear to handle that.
QEMUSerialSetParams has a single speed value that is passed to
cfsetispeed and cfsetospeed. The chip also has support for stick parity
, which aren't valid options right now either. If I'm wrong on either
of those points please correct me. Unless there is an alternative,
changes to the interface may need to be made if adding this device is
to be considered.


Jasper Lowell.


On Sun, 2020-02-09 at 11:26 +0000, Mark Cave-Ayland wrote:
> On 05/02/2020 06:31, jasper.lowell@bt.com wrote:
> 
> > I'm currently working towards emulating Solaris 10 on sun4u.
> > 
> >  
> > 
> > The Solaris 10 ISO image I am attempting to boot is the one from
> > the Oracle
> > 
> > download page at
> > https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
> > 
> > Image: sol-10-u11-ga-sparc-dvd.iso
> > 
> > MD5:   53e8b066f7f250ce2fd2cef063f8072b
> > 
> >  
> > 
> > I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
> > 
> >  
> > 
> > The command I am using to run QEMU is:
> > 
> > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios
> > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom
> > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G
> > 
> >  
> > 
> > ```
> > 
> > CPUs: 1 x SUNW,UltraSPARC-IIi
> > 
> > UUID: 00000000-0000-0000-0000-000000000000
> > 
> > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
> > 
> >   Type 'help' for detailed information
> > 
> > Trying cdrom:f...
> > 
> > Not a bootable ELF image
> > 
> > Not a bootable a.out image
> > 
> >  
> > 
> > Loading FCode image...
> > 
> > Loaded 7420 bytes
> > 
> > entry point is 0x4000
> > 
> > Evaluating FCode...
> > 
> > Evaluating FCode...
> > 
> > Ignoring failed claim for va 1000000 memsz af6d6!
> > 
> > Ignoring failed claim for va 1402000 memsz 4dcc8!
> > 
> > Ignoring failed claim for va 1800000 memsz 510c8!
> > 
> > SunOS Release 5.10 Version Generic_147147-26 64-bit
> > 
> > Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights
> > reserved.
> > 
> > could not find debugger-vocabulary-hook>threads:interpret:
> > exception -13 caught
> > 
> > interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
> > 
> > \ All rights reserved.
> > 
> > \
> > 
> > \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
> > 
> >  
> > 
> > hex
> > 
> >  
> > 
> > only forth also definitions
> > 
> > vocabulary kdbg-words
> > 
> > also kdbg-words definitions
> > 
> >  
> > 
> > defer p@
> > 
> > defer p!
> > 
> > ['] x@ is p@
> > 
> > ['] x! is p!
> > 
> >  
> > 
> > 8 constant ptrsize
> > 
> >  
> > 
> > d# 32 constant nbitsminor
> > 
> > h# ffffffff constant maxmin
> > 
> > \
> > 
> > \ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
> > 
> > \ Use is subject to license terms.
> > 
> > \
> > 
> >  
> > 
> > \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
> > 
> >  
> > 
> > h# 7ff constant v9bias
> > 
> > h# unix-tte:interpret: exception -13 caught
> > 
> > interpret ' unix-tte is va>tte-data failed with error
> > ffffffffffffffed
> > 
> > WARNING: consconfig: cannot find driver for screen device /pci@1fe,
> > 0/pci@1,1/QEMU,VGA@2
> > 
> > Configuring devices.
> > 
> > WARNING: Interrupt not seen after set_features
> > 
> > Using RPC Bootparams for network configuration information.
> > 
> > Attempting to configure interface hme0...
> > 
> > WARNING: Power off requested from power button or SC, powering down
> > the system!
> > 
> > Skipped interface hme0
> > 
> > svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs mount
> > -a failed: one or
> > more file systems failed to mount
> > 
> > Serial console, reverting to text install
> > 
> > Beginning system identification...
> > 
> > Searching for configuration file(s)...
> > 
> > Search complete.
> > 
> > Discovering additional network configuration...
> > 
> > ```
> > 
> >  
> > 
> > The installation menu is shown after but the console is
> > unresponsive.
> > 
> >  
> > 
> > After some debugging, it looks like the QEMU front-end is correctly
> > filling
> > 
> > the serial receive buffer with characters, and then starts dropping
> > them once
> > 
> > the number of characters in the buffer reach the interrupt level.
> > The interrupt
> > 
> > level happens to be 1 when booting Solaris 10. This looks like
> > normal behaviour
> > 
> > to me.
> > 
> >  
> > 
> > I started looking at why the serial receive buffer might not be
> > consumed and
> > 
> > considered that interrupts might not be being raised correctly. I
> > ran with
> > 
> > tracing and there were no interrupts for IRQ 0x2b like there are
> > when using
> > 
> > OpenBSD. When inspecting the registers of the serial device it
> > looks like the
> > 
> > Interrupt Enable Register is set to zero.
> > 
> >  
> > 
> > If Solaris 10 was using the device is polling mode, it should be
> > reading the RBR
> > 
> > or at least the LSR. When tracing serial_ioport_read and
> > serial_ioport_write,
> > 
> > once the menu is hit, I don't see any read or writes to the serial
> > device
> > 
> > registers despite me trying to send characters and use the menu.
> > 
> >  
> > 
> > The driver Solaris 10 is using for the device appears to be
> > similar/same as
> > 
> > /usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code found at
> > https://github.com/nxmirrors/onnv.
> > 
> >  
> > 
> > ```
> > 
> > asy->asy_hwtype = ASY16550AF;
> > 
> > OUTB(FIFOR, 0x00); /* clear fifo register */
> > 
> > asy->asy_trig_level = 0x00; /* sets the fifo Threshold to 1 */
> > 
> >  
> > 
> > /* set/Enable FIFO */
> > 
> > OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
> > 
> > (asy->asy_trig_level & 0xff));
> > 
> >  
> > 
> > if ((INB(ISR) & 0xc0) == 0xc0)
> > 
> >     asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
> > 
> > else {
> > 
> >     asy->asy_hwtype = ASY8250;
> > 
> >     OUTB(FIFOR, 0x00); /* NO FIFOs */
> > 
> >     asy->asy_trig_level = 0;
> > 
> > }
> > 
> > ```
> > 
> >  
> > 
> > From what I can tell when tracing serial_ioport_write and
> > serial_ioport_read,
> > 
> > Solaris 10 correctly identifies the serial device and successfully
> > attaches it.
> > 
> > In the asyattach function (OpenSolaris driver), interrupts are
> > disabled by zeroing the
> > 
> > Interrupt Enable Register. From what I'm reading in OpenSolaris
> > source code, interrupts
> > 
> > are reenabled when the device is "opened". This seems like
> > consistent and
> > 
> > correct behaviour though I'm not sure why the device is not being
> > opened to be
> > 
> > used by the serial console.
> > 
> >  
> > 
> > Is this an issue anyone else has tried to debug?
> > 
> > Are there any leads that I can follow up on for why the serial
> > console becomes
> > unresponsive
> > 
> > on Solaris 10?
> 
> It has been a while since I've looked at booting Solaris >= 10 but
> certainly the
> messages above about set_features and the frozen console suggest that
> something is
> going amiss with interrupt routing, although since Linux and NetBSD
> were fine the
> last time I ran my OpenBIOS release tests then Solaris must be doing
> something
> different here.
> 
> Note that the serial interrupts are routed from the ebus into sabre
> so the first
> thing to check would be that the end-to-end routing from device to
> CPU looks correct
> when using Solaris.
> 
> 
> ATB,
> 
> Mark.

Re: Emulating Solaris 10 on SPARC64 sun4u

[Artyom Tarasenko]

On Thu, May 7, 2020 at 4:29 PM <jasper.lowell@bt.com> wrote:
>
> Just thought I'd chime in with an update.
>
> We are currently emulating a 16550A UART. The guest sees this as the SU
> device, referring to the SuperIO port (a pair of 16550A UARTs). On the
> Ultra 5, the machine that Sun4u is modelled against, SuperIO was used
> for the keyboard and mouse. The Ultra 5 also had a DB25 (ttya default)
> and a DB9 (ttyb default) with a SAB82532 ESSC2.
>
> Using tracing, I've looked through how the 16550A UART is touched and
> it looks like Solaris 10 has no issues identifying the device. I've
> matched register accesses with driver code in OpenSolaris and I'm
> pretty sure the device is attached successfully. Also, if you boot
> Solaris 10 with debugging output, you can see that the device gets
> labelled as su0. The only time Solaris is capable of writing to the
> console is when OpenBIOS is used as a proxy.
>
> Rather than Solaris deciding against using SuperIO as a tty, I don't
> think there was ever any support for doing so (at least on SPARC
> machines). This could be an explanation for why the system appears to
> be trucking along just fine despite a seemingly frozen console - there
> is no console. I don't think the frozen console is the fault of broken
> interrupt routing as the 16550A UART is never programmed to generate
> them.

At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the
16550A UART. I think there were more such machines. I don't expect
there is anything in the Solaris kernel which would prevent any serial
device known to it to be used as a tty.

> I've started work on emulating the SAB 82532 ESSC2 but it's
> unfortunately way more complex than than the 16550A. For instance, it's
> possible to configure different baudrates for receiving and
> transmitting. QEMU's chardev interface doesn't appear to handle that.
> QEMUSerialSetParams has a single speed value that is passed to
> cfsetispeed and cfsetospeed. The chip also has support for stick parity
> , which aren't valid options right now either. If I'm wrong on either
> of those points please correct me. Unless there is an alternative,
> changes to the interface may need to be made if adding this device is
> to be considered.

Well, theoretically yes, but practically there is just one baudrate
which can be specified in the OBP. I think it's perfectly safe to use
max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer.

Regards,
Artyom
>
> On Sun, 2020-02-09 at 11:26 +0000, Mark Cave-Ayland wrote:
> > On 05/02/2020 06:31, jasper.lowell@bt.com wrote:
> >
> > > I'm currently working towards emulating Solaris 10 on sun4u.
> > >
> > >
> > >
> > > The Solaris 10 ISO image I am attempting to boot is the one from
> > > the Oracle
> > >
> > > download page at
> > > https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
> > >
> > > Image: sol-10-u11-ga-sparc-dvd.iso
> > >
> > > MD5:   53e8b066f7f250ce2fd2cef063f8072b
> > >
> > >
> > >
> > > I am using QEMU commit 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
> > >
> > >
> > >
> > > The command I am using to run QEMU is:
> > >
> > > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios
> > > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom
> > > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m 3G
> > >
> > >
> > >
> > > ```
> > >
> > > CPUs: 1 x SUNW,UltraSPARC-IIi
> > >
> > > UUID: 00000000-0000-0000-0000-000000000000
> > >
> > > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
> > >
> > >   Type 'help' for detailed information
> > >
> > > Trying cdrom:f...
> > >
> > > Not a bootable ELF image
> > >
> > > Not a bootable a.out image
> > >
> > >
> > >
> > > Loading FCode image...
> > >
> > > Loaded 7420 bytes
> > >
> > > entry point is 0x4000
> > >
> > > Evaluating FCode...
> > >
> > > Evaluating FCode...
> > >
> > > Ignoring failed claim for va 1000000 memsz af6d6!
> > >
> > > Ignoring failed claim for va 1402000 memsz 4dcc8!
> > >
> > > Ignoring failed claim for va 1800000 memsz 510c8!
> > >
> > > SunOS Release 5.10 Version Generic_147147-26 64-bit
> > >
> > > Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights
> > > reserved.
> > >
> > > could not find debugger-vocabulary-hook>threads:interpret:
> > > exception -13 caught
> > >
> > > interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
> > >
> > > \ All rights reserved.
> > >
> > > \
> > >
> > > \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
> > >
> > >
> > >
> > > hex
> > >
> > >
> > >
> > > only forth also definitions
> > >
> > > vocabulary kdbg-words
> > >
> > > also kdbg-words definitions
> > >
> > >
> > >
> > > defer p@
> > >
> > > defer p!
> > >
> > > ['] x@ is p@
> > >
> > > ['] x! is p!
> > >
> > >
> > >
> > > 8 constant ptrsize
> > >
> > >
> > >
> > > d# 32 constant nbitsminor
> > >
> > > h# ffffffff constant maxmin
> > >
> > > \
> > >
> > > \ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
> > >
> > > \ Use is subject to license terms.
> > >
> > > \
> > >
> > >
> > >
> > > \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
> > >
> > >
> > >
> > > h# 7ff constant v9bias
> > >
> > > h# unix-tte:interpret: exception -13 caught
> > >
> > > interpret ' unix-tte is va>tte-data failed with error
> > > ffffffffffffffed
> > >
> > > WARNING: consconfig: cannot find driver for screen device /pci@1fe,
> > > 0/pci@1,1/QEMU,VGA@2
> > >
> > > Configuring devices.
> > >
> > > WARNING: Interrupt not seen after set_features
> > >
> > > Using RPC Bootparams for network configuration information.
> > >
> > > Attempting to configure interface hme0...
> > >
> > > WARNING: Power off requested from power button or SC, powering down
> > > the system!
> > >
> > > Skipped interface hme0
> > >
> > > svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs mount
> > > -a failed: one or
> > > more file systems failed to mount
> > >
> > > Serial console, reverting to text install
> > >
> > > Beginning system identification...
> > >
> > > Searching for configuration file(s)...
> > >
> > > Search complete.
> > >
> > > Discovering additional network configuration...
> > >
> > > ```
> > >
> > >
> > >
> > > The installation menu is shown after but the console is
> > > unresponsive.
> > >
> > >
> > >
> > > After some debugging, it looks like the QEMU front-end is correctly
> > > filling
> > >
> > > the serial receive buffer with characters, and then starts dropping
> > > them once
> > >
> > > the number of characters in the buffer reach the interrupt level.
> > > The interrupt
> > >
> > > level happens to be 1 when booting Solaris 10. This looks like
> > > normal behaviour
> > >
> > > to me.
> > >
> > >
> > >
> > > I started looking at why the serial receive buffer might not be
> > > consumed and
> > >
> > > considered that interrupts might not be being raised correctly. I
> > > ran with
> > >
> > > tracing and there were no interrupts for IRQ 0x2b like there are
> > > when using
> > >
> > > OpenBSD. When inspecting the registers of the serial device it
> > > looks like the
> > >
> > > Interrupt Enable Register is set to zero.
> > >
> > >
> > >
> > > If Solaris 10 was using the device is polling mode, it should be
> > > reading the RBR
> > >
> > > or at least the LSR. When tracing serial_ioport_read and
> > > serial_ioport_write,
> > >
> > > once the menu is hit, I don't see any read or writes to the serial
> > > device
> > >
> > > registers despite me trying to send characters and use the menu.
> > >
> > >
> > >
> > > The driver Solaris 10 is using for the device appears to be
> > > similar/same as
> > >
> > > /usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code found at
> > > https://github.com/nxmirrors/onnv.
> > >
> > >
> > >
> > > ```
> > >
> > > asy->asy_hwtype = ASY16550AF;
> > >
> > > OUTB(FIFOR, 0x00); /* clear fifo register */
> > >
> > > asy->asy_trig_level = 0x00; /* sets the fifo Threshold to 1 */
> > >
> > >
> > >
> > > /* set/Enable FIFO */
> > >
> > > OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
> > >
> > > (asy->asy_trig_level & 0xff));
> > >
> > >
> > >
> > > if ((INB(ISR) & 0xc0) == 0xc0)
> > >
> > >     asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
> > >
> > > else {
> > >
> > >     asy->asy_hwtype = ASY8250;
> > >
> > >     OUTB(FIFOR, 0x00); /* NO FIFOs */
> > >
> > >     asy->asy_trig_level = 0;
> > >
> > > }
> > >
> > > ```
> > >
> > >
> > >
> > > From what I can tell when tracing serial_ioport_write and
> > > serial_ioport_read,
> > >
> > > Solaris 10 correctly identifies the serial device and successfully
> > > attaches it.
> > >
> > > In the asyattach function (OpenSolaris driver), interrupts are
> > > disabled by zeroing the
> > >
> > > Interrupt Enable Register. From what I'm reading in OpenSolaris
> > > source code, interrupts
> > >
> > > are reenabled when the device is "opened". This seems like
> > > consistent and
> > >
> > > correct behaviour though I'm not sure why the device is not being
> > > opened to be
> > >
> > > used by the serial console.
> > >
> > >
> > >
> > > Is this an issue anyone else has tried to debug?
> > >
> > > Are there any leads that I can follow up on for why the serial
> > > console becomes
> > > unresponsive
> > >
> > > on Solaris 10?
> >
> > It has been a while since I've looked at booting Solaris >= 10 but
> > certainly the
> > messages above about set_features and the frozen console suggest that
> > something is
> > going amiss with interrupt routing, although since Linux and NetBSD
> > were fine the
> > last time I ran my OpenBIOS release tests then Solaris must be doing
> > something
> > different here.
> >
> > Note that the serial interrupts are routed from the ebus into sabre
> > so the first
> > thing to check would be that the end-to-end routing from device to
> > CPU looks correct
> > when using Solaris.
> >
> >
> > ATB,
> >
> > Mark.



-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu

Re: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

There are two different drivers for the 16550A in OpenSolaris.

There is a generic driver in /usr/src/uts/common/io/asy.c. This driver
clearly states in comments that it is assigning the device to tty[a-d]. 
It's really obvious to me that there is support in this driver for
using the device for a tty.

There is another driver at /usr/src/uts/sun4/io/su_driver.c. Judging
from the name this is specific for SuperIO. This driver is more than
1000 lines shorter than the other driver and contains a note at the top
of the file that it is "modified as sparc keyboard/mouse driver." I
don't have much experience with Solaris internals but I can't see any
obvious signs that this can be used as a tty. I'd also question why
there are two drivers if they have the same purpose/capability. If the
su_driver exists to only add support for the keyboard/mouse I'm not
sure why it would be shorter rather than longer. It would be helpful if
someone with Solaris experience, that knows what they're doing (I do
not), can take a look at this driver and give a better opinion.

When emulating Sun4u, the su driver is used. If you misconfigure the
serial device in QEMU, you can trigger errors that are unique to the
driver. Also, Solaris attaches the device as su0.

Solaris can access the registers, identify/attach the device, but it
just never attempts to use it. Interrupts are explicitly disabled and
the device is never polled. I don't think asyopen in su_driver.c is
ever called. I've thoroughly stepped through every register access for
the 16550A and nothing seems out of the ordinary to me. Something I've
considered is that OpenBIOS is not setting properties for the device in
a way that Solaris expects but I'm not familiar enough with Sun's
OpenBOOT to make progress here. I've read through the PROM functions
that Solaris calls when choosing what device to use as a console and
nothing seemed inconsistent with what OpenBIOS does. Unfortunately,
OpenBIOS seems to crash or hang when using the kernel debugger module,
so dynamic analysis using breakpoints isn't an option.

I don't have any concrete explanations for the broken console but
rather than do nothing I figured I'd see what happens by emulating the
SAB 82532.

> At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the
> 16550A UART. I think there were more such machines. I don't expect
> there is anything in the Solaris kernel which would prevent any
> serial
> device known to it to be used as a tty.

Do you happen to know if this was over SuperIO? If this machine was
using the same su_driver for a serial console it would rule out
emulating the hardware-faithful SAB 82532 as being a possible
improvement. I can't find anything online about someone using SuperIO
for a ttya on an Ultra 5 running Solaris.

> Well, theoretically yes, but practically there is just one baudrate
> which can be specified in the OBP. I think it's perfectly safe to use
> max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer.

I'll do this while looking at whether or not the different chip fixes
the console problems on Sun4u. I'd personally like to avoid introducing
a device to QEMU that makes assumptions about how the guest may
configure the chip.

Thanks,
Jasper Lowell.


On Thu, 2020-05-07 at 17:02 +0200, Artyom Tarasenko wrote:
> On Thu, May 7, 2020 at 4:29 PM <jasper.lowell@bt.com> wrote:
> > Just thought I'd chime in with an update.
> > 
> > We are currently emulating a 16550A UART. The guest sees this as
> > the SU
> > device, referring to the SuperIO port (a pair of 16550A UARTs). On
> > the
> > Ultra 5, the machine that Sun4u is modelled against, SuperIO was
> > used
> > for the keyboard and mouse. The Ultra 5 also had a DB25 (ttya
> > default)
> > and a DB9 (ttyb default) with a SAB82532 ESSC2.
> > 
> > Using tracing, I've looked through how the 16550A UART is touched
> > and
> > it looks like Solaris 10 has no issues identifying the device. I've
> > matched register accesses with driver code in OpenSolaris and I'm
> > pretty sure the device is attached successfully. Also, if you boot
> > Solaris 10 with debugging output, you can see that the device gets
> > labelled as su0. The only time Solaris is capable of writing to the
> > console is when OpenBIOS is used as a proxy.
> > 
> > Rather than Solaris deciding against using SuperIO as a tty, I
> > don't
> > think there was ever any support for doing so (at least on SPARC
> > machines). This could be an explanation for why the system appears
> > to
> > be trucking along just fine despite a seemingly frozen console -
> > there
> > is no console. I don't think the frozen console is the fault of
> > broken
> > interrupt routing as the 16550A UART is never programmed to
> > generate
> > them.
> 
> At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the
> 16550A UART. I think there were more such machines. I don't expect
> there is anything in the Solaris kernel which would prevent any
> serial
> device known to it to be used as a tty.
> 
> > I've started work on emulating the SAB 82532 ESSC2 but it's
> > unfortunately way more complex than than the 16550A. For instance,
> > it's
> > possible to configure different baudrates for receiving and
> > transmitting. QEMU's chardev interface doesn't appear to handle
> > that.
> > QEMUSerialSetParams has a single speed value that is passed to
> > cfsetispeed and cfsetospeed. The chip also has support for stick
> > parity
> > , which aren't valid options right now either. If I'm wrong on
> > either
> > of those points please correct me. Unless there is an alternative,
> > changes to the interface may need to be made if adding this device
> > is
> > to be considered.
> 
> Well, theoretically yes, but practically there is just one baudrate
> which can be specified in the OBP. I think it's perfectly safe to use
> max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer.
> 
> Regards,
> Artyom
> > On Sun, 2020-02-09 at 11:26 +0000, Mark Cave-Ayland wrote:
> > > On 05/02/2020 06:31, jasper.lowell@bt.com wrote:
> > > 
> > > > I'm currently working towards emulating Solaris 10 on sun4u.
> > > > 
> > > > 
> > > > 
> > > > The Solaris 10 ISO image I am attempting to boot is the one
> > > > from
> > > > the Oracle
> > > > 
> > > > download page at
> > > > https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
> > > > 
> > > > Image: sol-10-u11-ga-sparc-dvd.iso
> > > > 
> > > > MD5:   53e8b066f7f250ce2fd2cef063f8072b
> > > > 
> > > > 
> > > > 
> > > > I am using QEMU commit
> > > > 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
> > > > 
> > > > 
> > > > 
> > > > The command I am using to run QEMU is:
> > > > 
> > > > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios
> > > > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom
> > > > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m
> > > > 3G
> > > > 
> > > > 
> > > > 
> > > > ```
> > > > 
> > > > CPUs: 1 x SUNW,UltraSPARC-IIi
> > > > 
> > > > UUID: 00000000-0000-0000-0000-000000000000
> > > > 
> > > > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
> > > > 
> > > >   Type 'help' for detailed information
> > > > 
> > > > Trying cdrom:f...
> > > > 
> > > > Not a bootable ELF image
> > > > 
> > > > Not a bootable a.out image
> > > > 
> > > > 
> > > > 
> > > > Loading FCode image...
> > > > 
> > > > Loaded 7420 bytes
> > > > 
> > > > entry point is 0x4000
> > > > 
> > > > Evaluating FCode...
> > > > 
> > > > Evaluating FCode...
> > > > 
> > > > Ignoring failed claim for va 1000000 memsz af6d6!
> > > > 
> > > > Ignoring failed claim for va 1402000 memsz 4dcc8!
> > > > 
> > > > Ignoring failed claim for va 1800000 memsz 510c8!
> > > > 
> > > > SunOS Release 5.10 Version Generic_147147-26 64-bit
> > > > 
> > > > Copyright (c) 1983, 2013, Oracle and/or its affiliates. All
> > > > rights
> > > > reserved.
> > > > 
> > > > could not find debugger-vocabulary-hook>threads:interpret:
> > > > exception -13 caught
> > > > 
> > > > interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
> > > > 
> > > > \ All rights reserved.
> > > > 
> > > > \
> > > > 
> > > > \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
> > > > 
> > > > 
> > > > 
> > > > hex
> > > > 
> > > > 
> > > > 
> > > > only forth also definitions
> > > > 
> > > > vocabulary kdbg-words
> > > > 
> > > > also kdbg-words definitions
> > > > 
> > > > 
> > > > 
> > > > defer p@
> > > > 
> > > > defer p!
> > > > 
> > > > ['] x@ is p@
> > > > 
> > > > ['] x! is p!
> > > > 
> > > > 
> > > > 
> > > > 8 constant ptrsize
> > > > 
> > > > 
> > > > 
> > > > d# 32 constant nbitsminor
> > > > 
> > > > h# ffffffff constant maxmin
> > > > 
> > > > \
> > > > 
> > > > \ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
> > > > 
> > > > \ Use is subject to license terms.
> > > > 
> > > > \
> > > > 
> > > > 
> > > > 
> > > > \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
> > > > 
> > > > 
> > > > 
> > > > h# 7ff constant v9bias
> > > > 
> > > > h# unix-tte:interpret: exception -13 caught
> > > > 
> > > > interpret ' unix-tte is va>tte-data failed with error
> > > > ffffffffffffffed
> > > > 
> > > > WARNING: consconfig: cannot find driver for screen device 
> > > > /pci@1fe,
> > > > 0/pci@1,1/QEMU,VGA@2
> > > > 
> > > > Configuring devices.
> > > > 
> > > > WARNING: Interrupt not seen after set_features
> > > > 
> > > > Using RPC Bootparams for network configuration information.
> > > > 
> > > > Attempting to configure interface hme0...
> > > > 
> > > > WARNING: Power off requested from power button or SC, powering
> > > > down
> > > > the system!
> > > > 
> > > > Skipped interface hme0
> > > > 
> > > > svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs
> > > > mount
> > > > -a failed: one or
> > > > more file systems failed to mount
> > > > 
> > > > Serial console, reverting to text install
> > > > 
> > > > Beginning system identification...
> > > > 
> > > > Searching for configuration file(s)...
> > > > 
> > > > Search complete.
> > > > 
> > > > Discovering additional network configuration...
> > > > 
> > > > ```
> > > > 
> > > > 
> > > > 
> > > > The installation menu is shown after but the console is
> > > > unresponsive.
> > > > 
> > > > 
> > > > 
> > > > After some debugging, it looks like the QEMU front-end is
> > > > correctly
> > > > filling
> > > > 
> > > > the serial receive buffer with characters, and then starts
> > > > dropping
> > > > them once
> > > > 
> > > > the number of characters in the buffer reach the interrupt
> > > > level.
> > > > The interrupt
> > > > 
> > > > level happens to be 1 when booting Solaris 10. This looks like
> > > > normal behaviour
> > > > 
> > > > to me.
> > > > 
> > > > 
> > > > 
> > > > I started looking at why the serial receive buffer might not be
> > > > consumed and
> > > > 
> > > > considered that interrupts might not be being raised correctly.
> > > > I
> > > > ran with
> > > > 
> > > > tracing and there were no interrupts for IRQ 0x2b like there
> > > > are
> > > > when using
> > > > 
> > > > OpenBSD. When inspecting the registers of the serial device it
> > > > looks like the
> > > > 
> > > > Interrupt Enable Register is set to zero.
> > > > 
> > > > 
> > > > 
> > > > If Solaris 10 was using the device is polling mode, it should
> > > > be
> > > > reading the RBR
> > > > 
> > > > or at least the LSR. When tracing serial_ioport_read and
> > > > serial_ioport_write,
> > > > 
> > > > once the menu is hit, I don't see any read or writes to the
> > > > serial
> > > > device
> > > > 
> > > > registers despite me trying to send characters and use the
> > > > menu.
> > > > 
> > > > 
> > > > 
> > > > The driver Solaris 10 is using for the device appears to be
> > > > similar/same as
> > > > 
> > > > /usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code found
> > > > at
> > > > https://github.com/nxmirrors/onnv.
> > > > 
> > > > 
> > > > 
> > > > ```
> > > > 
> > > > asy->asy_hwtype = ASY16550AF;
> > > > 
> > > > OUTB(FIFOR, 0x00); /* clear fifo register */
> > > > 
> > > > asy->asy_trig_level = 0x00; /* sets the fifo Threshold to 1 */
> > > > 
> > > > 
> > > > 
> > > > /* set/Enable FIFO */
> > > > 
> > > > OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
> > > > 
> > > > (asy->asy_trig_level & 0xff));
> > > > 
> > > > 
> > > > 
> > > > if ((INB(ISR) & 0xc0) == 0xc0)
> > > > 
> > > >     asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
> > > > 
> > > > else {
> > > > 
> > > >     asy->asy_hwtype = ASY8250;
> > > > 
> > > >     OUTB(FIFOR, 0x00); /* NO FIFOs */
> > > > 
> > > >     asy->asy_trig_level = 0;
> > > > 
> > > > }
> > > > 
> > > > ```
> > > > 
> > > > 
> > > > 
> > > > From what I can tell when tracing serial_ioport_write and
> > > > serial_ioport_read,
> > > > 
> > > > Solaris 10 correctly identifies the serial device and
> > > > successfully
> > > > attaches it.
> > > > 
> > > > In the asyattach function (OpenSolaris driver), interrupts are
> > > > disabled by zeroing the
> > > > 
> > > > Interrupt Enable Register. From what I'm reading in OpenSolaris
> > > > source code, interrupts
> > > > 
> > > > are reenabled when the device is "opened". This seems like
> > > > consistent and
> > > > 
> > > > correct behaviour though I'm not sure why the device is not
> > > > being
> > > > opened to be
> > > > 
> > > > used by the serial console.
> > > > 
> > > > 
> > > > 
> > > > Is this an issue anyone else has tried to debug?
> > > > 
> > > > Are there any leads that I can follow up on for why the serial
> > > > console becomes
> > > > unresponsive
> > > > 
> > > > on Solaris 10?
> > > 
> > > It has been a while since I've looked at booting Solaris >= 10
> > > but
> > > certainly the
> > > messages above about set_features and the frozen console suggest
> > > that
> > > something is
> > > going amiss with interrupt routing, although since Linux and
> > > NetBSD
> > > were fine the
> > > last time I ran my OpenBIOS release tests then Solaris must be
> > > doing
> > > something
> > > different here.
> > > 
> > > Note that the serial interrupts are routed from the ebus into
> > > sabre
> > > so the first
> > > thing to check would be that the end-to-end routing from device
> > > to
> > > CPU looks correct
> > > when using Solaris.
> > > 
> > > 
> > > ATB,
> > > 
> > > Mark.
> 
> 

Re: Emulating Solaris 10 on SPARC64 sun4u

[Peter Tribble]

[-- Attachment #1: Type: text/plain, Size: 15686 bytes --]

I see the same behaviour as reported here when booting current SPARC illumos
(illumos is the ongoing fork of OpenSolaris) under qemu - looks like it's
booted
up fine, but I can't type anything on the console.

While I'm an illumos developer, and maintain it on SPARC, I'm unfamiliar
with
most of the internals. We'll try and have a poke around, though.

(The aim would be to use qemu to allow illumos developers to test changes
on SPARC
without requiring them to have SPARC hardware, hence my interest.)

On Fri, May 8, 2020 at 3:40 AM <jasper.lowell@bt.com> wrote:

> There are two different drivers for the 16550A in OpenSolaris.
>
> There is a generic driver in /usr/src/uts/common/io/asy.c. This driver
> clearly states in comments that it is assigning the device to tty[a-d].
> It's really obvious to me that there is support in this driver for
> using the device for a tty.
>
> There is another driver at /usr/src/uts/sun4/io/su_driver.c. Judging
> from the name this is specific for SuperIO. This driver is more than
> 1000 lines shorter than the other driver and contains a note at the top
> of the file that it is "modified as sparc keyboard/mouse driver." I
> don't have much experience with Solaris internals but I can't see any
> obvious signs that this can be used as a tty. I'd also question why
> there are two drivers if they have the same purpose/capability. If the
> su_driver exists to only add support for the keyboard/mouse I'm not
> sure why it would be shorter rather than longer. It would be helpful if
> someone with Solaris experience, that knows what they're doing (I do
> not), can take a look at this driver and give a better opinion.
>
> When emulating Sun4u, the su driver is used. If you misconfigure the
> serial device in QEMU, you can trigger errors that are unique to the
> driver. Also, Solaris attaches the device as su0.
>
> Solaris can access the registers, identify/attach the device, but it
> just never attempts to use it. Interrupts are explicitly disabled and
> the device is never polled. I don't think asyopen in su_driver.c is
> ever called. I've thoroughly stepped through every register access for
> the 16550A and nothing seems out of the ordinary to me. Something I've
> considered is that OpenBIOS is not setting properties for the device in
> a way that Solaris expects but I'm not familiar enough with Sun's
> OpenBOOT to make progress here. I've read through the PROM functions
> that Solaris calls when choosing what device to use as a console and
> nothing seemed inconsistent with what OpenBIOS does. Unfortunately,
> OpenBIOS seems to crash or hang when using the kernel debugger module,
> so dynamic analysis using breakpoints isn't an option.
>
> I don't have any concrete explanations for the broken console but
> rather than do nothing I figured I'd see what happens by emulating the
> SAB 82532.
>
> > At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the
> > 16550A UART. I think there were more such machines. I don't expect
> > there is anything in the Solaris kernel which would prevent any
> > serial
> > device known to it to be used as a tty.
>
> Do you happen to know if this was over SuperIO? If this machine was
> using the same su_driver for a serial console it would rule out
> emulating the hardware-faithful SAB 82532 as being a possible
> improvement. I can't find anything online about someone using SuperIO
> for a ttya on an Ultra 5 running Solaris.
>
> > Well, theoretically yes, but practically there is just one baudrate
> > which can be specified in the OBP. I think it's perfectly safe to use
> > max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer.
>
> I'll do this while looking at whether or not the different chip fixes
> the console problems on Sun4u. I'd personally like to avoid introducing
> a device to QEMU that makes assumptions about how the guest may
> configure the chip.
>
> Thanks,
> Jasper Lowell.
>
>
> On Thu, 2020-05-07 at 17:02 +0200, Artyom Tarasenko wrote:
> > On Thu, May 7, 2020 at 4:29 PM <jasper.lowell@bt.com> wrote:
> > > Just thought I'd chime in with an update.
> > >
> > > We are currently emulating a 16550A UART. The guest sees this as
> > > the SU
> > > device, referring to the SuperIO port (a pair of 16550A UARTs). On
> > > the
> > > Ultra 5, the machine that Sun4u is modelled against, SuperIO was
> > > used
> > > for the keyboard and mouse. The Ultra 5 also had a DB25 (ttya
> > > default)
> > > and a DB9 (ttyb default) with a SAB82532 ESSC2.
> > >
> > > Using tracing, I've looked through how the 16550A UART is touched
> > > and
> > > it looks like Solaris 10 has no issues identifying the device. I've
> > > matched register accesses with driver code in OpenSolaris and I'm
> > > pretty sure the device is attached successfully. Also, if you boot
> > > Solaris 10 with debugging output, you can see that the device gets
> > > labelled as su0. The only time Solaris is capable of writing to the
> > > console is when OpenBIOS is used as a proxy.
> > >
> > > Rather than Solaris deciding against using SuperIO as a tty, I
> > > don't
> > > think there was ever any support for doing so (at least on SPARC
> > > machines). This could be an explanation for why the system appears
> > > to
> > > be trucking along just fine despite a seemingly frozen console -
> > > there
> > > is no console. I don't think the frozen console is the fault of
> > > broken
> > > interrupt routing as the 16550A UART is never programmed to
> > > generate
> > > them.
> >
> > At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the
> > 16550A UART. I think there were more such machines. I don't expect
> > there is anything in the Solaris kernel which would prevent any
> > serial
> > device known to it to be used as a tty.
> >
> > > I've started work on emulating the SAB 82532 ESSC2 but it's
> > > unfortunately way more complex than than the 16550A. For instance,
> > > it's
> > > possible to configure different baudrates for receiving and
> > > transmitting. QEMU's chardev interface doesn't appear to handle
> > > that.
> > > QEMUSerialSetParams has a single speed value that is passed to
> > > cfsetispeed and cfsetospeed. The chip also has support for stick
> > > parity
> > > , which aren't valid options right now either. If I'm wrong on
> > > either
> > > of those points please correct me. Unless there is an alternative,
> > > changes to the interface may need to be made if adding this device
> > > is
> > > to be considered.
> >
> > Well, theoretically yes, but practically there is just one baudrate
> > which can be specified in the OBP. I think it's perfectly safe to use
> > max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer.
> >
> > Regards,
> > Artyom
> > > On Sun, 2020-02-09 at 11:26 +0000, Mark Cave-Ayland wrote:
> > > > On 05/02/2020 06:31, jasper.lowell@bt.com wrote:
> > > >
> > > > > I'm currently working towards emulating Solaris 10 on sun4u.
> > > > >
> > > > >
> > > > >
> > > > > The Solaris 10 ISO image I am attempting to boot is the one
> > > > > from
> > > > > the Oracle
> > > > >
> > > > > download page at
> > > > >
> https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html
> .
> > > > >
> > > > > Image: sol-10-u11-ga-sparc-dvd.iso
> > > > >
> > > > > MD5:   53e8b066f7f250ce2fd2cef063f8072b
> > > > >
> > > > >
> > > > >
> > > > > I am using QEMU commit
> > > > > 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
> > > > >
> > > > >
> > > > >
> > > > > The command I am using to run QEMU is:
> > > > >
> > > > > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios
> > > > > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom
> > > > > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m
> > > > > 3G
> > > > >
> > > > >
> > > > >
> > > > > ```
> > > > >
> > > > > CPUs: 1 x SUNW,UltraSPARC-IIi
> > > > >
> > > > > UUID: 00000000-0000-0000-0000-000000000000
> > > > >
> > > > > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
> > > > >
> > > > >   Type 'help' for detailed information
> > > > >
> > > > > Trying cdrom:f...
> > > > >
> > > > > Not a bootable ELF image
> > > > >
> > > > > Not a bootable a.out image
> > > > >
> > > > >
> > > > >
> > > > > Loading FCode image...
> > > > >
> > > > > Loaded 7420 bytes
> > > > >
> > > > > entry point is 0x4000
> > > > >
> > > > > Evaluating FCode...
> > > > >
> > > > > Evaluating FCode...
> > > > >
> > > > > Ignoring failed claim for va 1000000 memsz af6d6!
> > > > >
> > > > > Ignoring failed claim for va 1402000 memsz 4dcc8!
> > > > >
> > > > > Ignoring failed claim for va 1800000 memsz 510c8!
> > > > >
> > > > > SunOS Release 5.10 Version Generic_147147-26 64-bit
> > > > >
> > > > > Copyright (c) 1983, 2013, Oracle and/or its affiliates. All
> > > > > rights
> > > > > reserved.
> > > > >
> > > > > could not find debugger-vocabulary-hook>threads:interpret:
> > > > > exception -13 caught
> > > > >
> > > > > interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
> > > > >
> > > > > \ All rights reserved.
> > > > >
> > > > > \
> > > > >
> > > > > \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
> > > > >
> > > > >
> > > > >
> > > > > hex
> > > > >
> > > > >
> > > > >
> > > > > only forth also definitions
> > > > >
> > > > > vocabulary kdbg-words
> > > > >
> > > > > also kdbg-words definitions
> > > > >
> > > > >
> > > > >
> > > > > defer p@
> > > > >
> > > > > defer p!
> > > > >
> > > > > ['] x@ is p@
> > > > >
> > > > > ['] x! is p!
> > > > >
> > > > >
> > > > >
> > > > > 8 constant ptrsize
> > > > >
> > > > >
> > > > >
> > > > > d# 32 constant nbitsminor
> > > > >
> > > > > h# ffffffff constant maxmin
> > > > >
> > > > > \
> > > > >
> > > > > \ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
> > > > >
> > > > > \ Use is subject to license terms.
> > > > >
> > > > > \
> > > > >
> > > > >
> > > > >
> > > > > \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
> > > > >
> > > > >
> > > > >
> > > > > h# 7ff constant v9bias
> > > > >
> > > > > h# unix-tte:interpret: exception -13 caught
> > > > >
> > > > > interpret ' unix-tte is va>tte-data failed with error
> > > > > ffffffffffffffed
> > > > >
> > > > > WARNING: consconfig: cannot find driver for screen device
> > > > > /pci@1fe,
> > > > > 0/pci@1,1/QEMU,VGA@2
> > > > >
> > > > > Configuring devices.
> > > > >
> > > > > WARNING: Interrupt not seen after set_features
> > > > >
> > > > > Using RPC Bootparams for network configuration information.
> > > > >
> > > > > Attempting to configure interface hme0...
> > > > >
> > > > > WARNING: Power off requested from power button or SC, powering
> > > > > down
> > > > > the system!
> > > > >
> > > > > Skipped interface hme0
> > > > >
> > > > > svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs
> > > > > mount
> > > > > -a failed: one or
> > > > > more file systems failed to mount
> > > > >
> > > > > Serial console, reverting to text install
> > > > >
> > > > > Beginning system identification...
> > > > >
> > > > > Searching for configuration file(s)...
> > > > >
> > > > > Search complete.
> > > > >
> > > > > Discovering additional network configuration...
> > > > >
> > > > > ```
> > > > >
> > > > >
> > > > >
> > > > > The installation menu is shown after but the console is
> > > > > unresponsive.
> > > > >
> > > > >
> > > > >
> > > > > After some debugging, it looks like the QEMU front-end is
> > > > > correctly
> > > > > filling
> > > > >
> > > > > the serial receive buffer with characters, and then starts
> > > > > dropping
> > > > > them once
> > > > >
> > > > > the number of characters in the buffer reach the interrupt
> > > > > level.
> > > > > The interrupt
> > > > >
> > > > > level happens to be 1 when booting Solaris 10. This looks like
> > > > > normal behaviour
> > > > >
> > > > > to me.
> > > > >
> > > > >
> > > > >
> > > > > I started looking at why the serial receive buffer might not be
> > > > > consumed and
> > > > >
> > > > > considered that interrupts might not be being raised correctly.
> > > > > I
> > > > > ran with
> > > > >
> > > > > tracing and there were no interrupts for IRQ 0x2b like there
> > > > > are
> > > > > when using
> > > > >
> > > > > OpenBSD. When inspecting the registers of the serial device it
> > > > > looks like the
> > > > >
> > > > > Interrupt Enable Register is set to zero.
> > > > >
> > > > >
> > > > >
> > > > > If Solaris 10 was using the device is polling mode, it should
> > > > > be
> > > > > reading the RBR
> > > > >
> > > > > or at least the LSR. When tracing serial_ioport_read and
> > > > > serial_ioport_write,
> > > > >
> > > > > once the menu is hit, I don't see any read or writes to the
> > > > > serial
> > > > > device
> > > > >
> > > > > registers despite me trying to send characters and use the
> > > > > menu.
> > > > >
> > > > >
> > > > >
> > > > > The driver Solaris 10 is using for the device appears to be
> > > > > similar/same as
> > > > >
> > > > > /usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code found
> > > > > at
> > > > > https://github.com/nxmirrors/onnv.
> > > > >
> > > > >
> > > > >
> > > > > ```
> > > > >
> > > > > asy->asy_hwtype = ASY16550AF;
> > > > >
> > > > > OUTB(FIFOR, 0x00); /* clear fifo register */
> > > > >
> > > > > asy->asy_trig_level = 0x00; /* sets the fifo Threshold to 1 */
> > > > >
> > > > >
> > > > >
> > > > > /* set/Enable FIFO */
> > > > >
> > > > > OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
> > > > >
> > > > > (asy->asy_trig_level & 0xff));
> > > > >
> > > > >
> > > > >
> > > > > if ((INB(ISR) & 0xc0) == 0xc0)
> > > > >
> > > > >     asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
> > > > >
> > > > > else {
> > > > >
> > > > >     asy->asy_hwtype = ASY8250;
> > > > >
> > > > >     OUTB(FIFOR, 0x00); /* NO FIFOs */
> > > > >
> > > > >     asy->asy_trig_level = 0;
> > > > >
> > > > > }
> > > > >
> > > > > ```
> > > > >
> > > > >
> > > > >
> > > > > From what I can tell when tracing serial_ioport_write and
> > > > > serial_ioport_read,
> > > > >
> > > > > Solaris 10 correctly identifies the serial device and
> > > > > successfully
> > > > > attaches it.
> > > > >
> > > > > In the asyattach function (OpenSolaris driver), interrupts are
> > > > > disabled by zeroing the
> > > > >
> > > > > Interrupt Enable Register. From what I'm reading in OpenSolaris
> > > > > source code, interrupts
> > > > >
> > > > > are reenabled when the device is "opened". This seems like
> > > > > consistent and
> > > > >
> > > > > correct behaviour though I'm not sure why the device is not
> > > > > being
> > > > > opened to be
> > > > >
> > > > > used by the serial console.
> > > > >
> > > > >
> > > > >
> > > > > Is this an issue anyone else has tried to debug?
> > > > >
> > > > > Are there any leads that I can follow up on for why the serial
> > > > > console becomes
> > > > > unresponsive
> > > > >
> > > > > on Solaris 10?
> > > >
> > > > It has been a while since I've looked at booting Solaris >= 10
> > > > but
> > > > certainly the
> > > > messages above about set_features and the frozen console suggest
> > > > that
> > > > something is
> > > > going amiss with interrupt routing, although since Linux and
> > > > NetBSD
> > > > were fine the
> > > > last time I ran my OpenBIOS release tests then Solaris must be
> > > > doing
> > > > something
> > > > different here.
> > > >
> > > > Note that the serial interrupts are routed from the ebus into
> > > > sabre
> > > > so the first
> > > > thing to check would be that the end-to-end routing from device
> > > > to
> > > > CPU looks correct
> > > > when using Solaris.
> > > >
> > > >
> > > > ATB,
> > > >
> > > > Mark.
> >
> >
>


-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

[-- Attachment #2: Type: text/html, Size: 22769 bytes --]

Re: Emulating Solaris 10 on SPARC64 sun4u

[Artyom Tarasenko]

On Fri, May 8, 2020 at 10:51 AM Peter Tribble <peter.tribble@gmail.com> wrote:
>
> I see the same behaviour as reported here when booting current SPARC illumos
> (illumos is the ongoing fork of OpenSolaris) under qemu - looks like it's booted
> up fine, but I can't type anything on the console.

There is one more option which can be relatively easily tested:
you can add two more ports (or replace the existing ttya/ttyb) to the
qemu's ultra5 model: the escc (aka zs) ports.
They definitely work under Solaris (Ultra-1, Ultra-2, E3000,
E3500...), I've seen it.
OpenBIOS already has a driver for them which is used for sun4m (and
some ppc) targets. So no new devices have to be implemented.
If your and Jasper's theory proofs to be correct, we can think of
replacing ttya/ttyb su with zs.
I guess the other sun4u operating systems do support zs as well. (This
has to be tested though)


> While I'm an illumos developer, and maintain it on SPARC, I'm unfamiliar with
> most of the internals. We'll try and have a poke around, though.
>
> (The aim would be to use qemu to allow illumos developers to test changes on SPARC
> without requiring them to have SPARC hardware, hence my interest.)

I think I managed booting Tribblix under the QEMU niagara target. It
has less devices than sun4u, but the console was working.

Regards,
Artyom

> On Fri, May 8, 2020 at 3:40 AM <jasper.lowell@bt.com> wrote:
>>
>> There are two different drivers for the 16550A in OpenSolaris.
>>
>> There is a generic driver in /usr/src/uts/common/io/asy.c. This driver
>> clearly states in comments that it is assigning the device to tty[a-d].
>> It's really obvious to me that there is support in this driver for
>> using the device for a tty.
>>
>> There is another driver at /usr/src/uts/sun4/io/su_driver.c. Judging
>> from the name this is specific for SuperIO. This driver is more than
>> 1000 lines shorter than the other driver and contains a note at the top
>> of the file that it is "modified as sparc keyboard/mouse driver." I
>> don't have much experience with Solaris internals but I can't see any
>> obvious signs that this can be used as a tty. I'd also question why
>> there are two drivers if they have the same purpose/capability. If the
>> su_driver exists to only add support for the keyboard/mouse I'm not
>> sure why it would be shorter rather than longer. It would be helpful if
>> someone with Solaris experience, that knows what they're doing (I do
>> not), can take a look at this driver and give a better opinion.
>>
>> When emulating Sun4u, the su driver is used. If you misconfigure the
>> serial device in QEMU, you can trigger errors that are unique to the
>> driver. Also, Solaris attaches the device as su0.
>>
>> Solaris can access the registers, identify/attach the device, but it
>> just never attempts to use it. Interrupts are explicitly disabled and
>> the device is never polled. I don't think asyopen in su_driver.c is
>> ever called. I've thoroughly stepped through every register access for
>> the 16550A and nothing seems out of the ordinary to me. Something I've
>> considered is that OpenBIOS is not setting properties for the device in
>> a way that Solaris expects but I'm not familiar enough with Sun's
>> OpenBOOT to make progress here. I've read through the PROM functions
>> that Solaris calls when choosing what device to use as a console and
>> nothing seemed inconsistent with what OpenBIOS does. Unfortunately,
>> OpenBIOS seems to crash or hang when using the kernel debugger module,
>> so dynamic analysis using breakpoints isn't an option.
>>
>> I don't have any concrete explanations for the broken console but
>> rather than do nothing I figured I'd see what happens by emulating the
>> SAB 82532.
>>
>> > At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the
>> > 16550A UART. I think there were more such machines. I don't expect
>> > there is anything in the Solaris kernel which would prevent any
>> > serial
>> > device known to it to be used as a tty.
>>
>> Do you happen to know if this was over SuperIO? If this machine was
>> using the same su_driver for a serial console it would rule out
>> emulating the hardware-faithful SAB 82532 as being a possible
>> improvement. I can't find anything online about someone using SuperIO
>> for a ttya on an Ultra 5 running Solaris.
>>
>> > Well, theoretically yes, but practically there is just one baudrate
>> > which can be specified in the OBP. I think it's perfectly safe to use
>> > max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer.
>>
>> I'll do this while looking at whether or not the different chip fixes
>> the console problems on Sun4u. I'd personally like to avoid introducing
>> a device to QEMU that makes assumptions about how the guest may
>> configure the chip.
>>
>> Thanks,
>> Jasper Lowell.
>>
>>
>> On Thu, 2020-05-07 at 17:02 +0200, Artyom Tarasenko wrote:
>> > On Thu, May 7, 2020 at 4:29 PM <jasper.lowell@bt.com> wrote:
>> > > Just thought I'd chime in with an update.
>> > >
>> > > We are currently emulating a 16550A UART. The guest sees this as
>> > > the SU
>> > > device, referring to the SuperIO port (a pair of 16550A UARTs). On
>> > > the
>> > > Ultra 5, the machine that Sun4u is modelled against, SuperIO was
>> > > used
>> > > for the keyboard and mouse. The Ultra 5 also had a DB25 (ttya
>> > > default)
>> > > and a DB9 (ttyb default) with a SAB82532 ESSC2.
>> > >
>> > > Using tracing, I've looked through how the 16550A UART is touched
>> > > and
>> > > it looks like Solaris 10 has no issues identifying the device. I've
>> > > matched register accesses with driver code in OpenSolaris and I'm
>> > > pretty sure the device is attached successfully. Also, if you boot
>> > > Solaris 10 with debugging output, you can see that the device gets
>> > > labelled as su0. The only time Solaris is capable of writing to the
>> > > console is when OpenBIOS is used as a proxy.
>> > >
>> > > Rather than Solaris deciding against using SuperIO as a tty, I
>> > > don't
>> > > think there was ever any support for doing so (at least on SPARC
>> > > machines). This could be an explanation for why the system appears
>> > > to
>> > > be trucking along just fine despite a seemingly frozen console -
>> > > there
>> > > is no console. I don't think the frozen console is the fault of
>> > > broken
>> > > interrupt routing as the 16550A UART is never programmed to
>> > > generate
>> > > them.
>> >
>> > At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to the
>> > 16550A UART. I think there were more such machines. I don't expect
>> > there is anything in the Solaris kernel which would prevent any
>> > serial
>> > device known to it to be used as a tty.
>> >
>> > > I've started work on emulating the SAB 82532 ESSC2 but it's
>> > > unfortunately way more complex than than the 16550A. For instance,
>> > > it's
>> > > possible to configure different baudrates for receiving and
>> > > transmitting. QEMU's chardev interface doesn't appear to handle
>> > > that.
>> > > QEMUSerialSetParams has a single speed value that is passed to
>> > > cfsetispeed and cfsetospeed. The chip also has support for stick
>> > > parity
>> > > , which aren't valid options right now either. If I'm wrong on
>> > > either
>> > > of those points please correct me. Unless there is an alternative,
>> > > changes to the interface may need to be made if adding this device
>> > > is
>> > > to be considered.
>> >
>> > Well, theoretically yes, but practically there is just one baudrate
>> > which can be specified in the OBP. I think it's perfectly safe to use
>> > max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer.
>> >
>> > Regards,
>> > Artyom
>> > > On Sun, 2020-02-09 at 11:26 +0000, Mark Cave-Ayland wrote:
>> > > > On 05/02/2020 06:31, jasper.lowell@bt.com wrote:
>> > > >
>> > > > > I'm currently working towards emulating Solaris 10 on sun4u.
>> > > > >
>> > > > >
>> > > > >
>> > > > > The Solaris 10 ISO image I am attempting to boot is the one
>> > > > > from
>> > > > > the Oracle
>> > > > >
>> > > > > download page at
>> > > > > https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
>> > > > >
>> > > > > Image: sol-10-u11-ga-sparc-dvd.iso
>> > > > >
>> > > > > MD5:   53e8b066f7f250ce2fd2cef063f8072b
>> > > > >
>> > > > >
>> > > > >
>> > > > > I am using QEMU commit
>> > > > > 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
>> > > > >
>> > > > >
>> > > > >
>> > > > > The command I am using to run QEMU is:
>> > > > >
>> > > > > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios
>> > > > > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom
>> > > > > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d -nographic -m
>> > > > > 3G
>> > > > >
>> > > > >
>> > > > >
>> > > > > ```
>> > > > >
>> > > > > CPUs: 1 x SUNW,UltraSPARC-IIi
>> > > > >
>> > > > > UUID: 00000000-0000-0000-0000-000000000000
>> > > > >
>> > > > > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
>> > > > >
>> > > > >   Type 'help' for detailed information
>> > > > >
>> > > > > Trying cdrom:f...
>> > > > >
>> > > > > Not a bootable ELF image
>> > > > >
>> > > > > Not a bootable a.out image
>> > > > >
>> > > > >
>> > > > >
>> > > > > Loading FCode image...
>> > > > >
>> > > > > Loaded 7420 bytes
>> > > > >
>> > > > > entry point is 0x4000
>> > > > >
>> > > > > Evaluating FCode...
>> > > > >
>> > > > > Evaluating FCode...
>> > > > >
>> > > > > Ignoring failed claim for va 1000000 memsz af6d6!
>> > > > >
>> > > > > Ignoring failed claim for va 1402000 memsz 4dcc8!
>> > > > >
>> > > > > Ignoring failed claim for va 1800000 memsz 510c8!
>> > > > >
>> > > > > SunOS Release 5.10 Version Generic_147147-26 64-bit
>> > > > >
>> > > > > Copyright (c) 1983, 2013, Oracle and/or its affiliates. All
>> > > > > rights
>> > > > > reserved.
>> > > > >
>> > > > > could not find debugger-vocabulary-hook>threads:interpret:
>> > > > > exception -13 caught
>> > > > >
>> > > > > interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
>> > > > >
>> > > > > \ All rights reserved.
>> > > > >
>> > > > > \
>> > > > >
>> > > > > \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
>> > > > >
>> > > > >
>> > > > >
>> > > > > hex
>> > > > >
>> > > > >
>> > > > >
>> > > > > only forth also definitions
>> > > > >
>> > > > > vocabulary kdbg-words
>> > > > >
>> > > > > also kdbg-words definitions
>> > > > >
>> > > > >
>> > > > >
>> > > > > defer p@
>> > > > >
>> > > > > defer p!
>> > > > >
>> > > > > ['] x@ is p@
>> > > > >
>> > > > > ['] x! is p!
>> > > > >
>> > > > >
>> > > > >
>> > > > > 8 constant ptrsize
>> > > > >
>> > > > >
>> > > > >
>> > > > > d# 32 constant nbitsminor
>> > > > >
>> > > > > h# ffffffff constant maxmin
>> > > > >
>> > > > > \
>> > > > >
>> > > > > \ Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
>> > > > >
>> > > > > \ Use is subject to license terms.
>> > > > >
>> > > > > \
>> > > > >
>> > > > >
>> > > > >
>> > > > > \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
>> > > > >
>> > > > >
>> > > > >
>> > > > > h# 7ff constant v9bias
>> > > > >
>> > > > > h# unix-tte:interpret: exception -13 caught
>> > > > >
>> > > > > interpret ' unix-tte is va>tte-data failed with error
>> > > > > ffffffffffffffed
>> > > > >
>> > > > > WARNING: consconfig: cannot find driver for screen device
>> > > > > /pci@1fe,
>> > > > > 0/pci@1,1/QEMU,VGA@2
>> > > > >
>> > > > > Configuring devices.
>> > > > >
>> > > > > WARNING: Interrupt not seen after set_features
>> > > > >
>> > > > > Using RPC Bootparams for network configuration information.
>> > > > >
>> > > > > Attempting to configure interface hme0...
>> > > > >
>> > > > > WARNING: Power off requested from power button or SC, powering
>> > > > > down
>> > > > > the system!
>> > > > >
>> > > > > Skipped interface hme0
>> > > > >
>> > > > > svc:/system/filesystem/local:default: WARNING: /usr/sbin/zfs
>> > > > > mount
>> > > > > -a failed: one or
>> > > > > more file systems failed to mount
>> > > > >
>> > > > > Serial console, reverting to text install
>> > > > >
>> > > > > Beginning system identification...
>> > > > >
>> > > > > Searching for configuration file(s)...
>> > > > >
>> > > > > Search complete.
>> > > > >
>> > > > > Discovering additional network configuration...
>> > > > >
>> > > > > ```
>> > > > >
>> > > > >
>> > > > >
>> > > > > The installation menu is shown after but the console is
>> > > > > unresponsive.
>> > > > >
>> > > > >
>> > > > >
>> > > > > After some debugging, it looks like the QEMU front-end is
>> > > > > correctly
>> > > > > filling
>> > > > >
>> > > > > the serial receive buffer with characters, and then starts
>> > > > > dropping
>> > > > > them once
>> > > > >
>> > > > > the number of characters in the buffer reach the interrupt
>> > > > > level.
>> > > > > The interrupt
>> > > > >
>> > > > > level happens to be 1 when booting Solaris 10. This looks like
>> > > > > normal behaviour
>> > > > >
>> > > > > to me.
>> > > > >
>> > > > >
>> > > > >
>> > > > > I started looking at why the serial receive buffer might not be
>> > > > > consumed and
>> > > > >
>> > > > > considered that interrupts might not be being raised correctly.
>> > > > > I
>> > > > > ran with
>> > > > >
>> > > > > tracing and there were no interrupts for IRQ 0x2b like there
>> > > > > are
>> > > > > when using
>> > > > >
>> > > > > OpenBSD. When inspecting the registers of the serial device it
>> > > > > looks like the
>> > > > >
>> > > > > Interrupt Enable Register is set to zero.
>> > > > >
>> > > > >
>> > > > >
>> > > > > If Solaris 10 was using the device is polling mode, it should
>> > > > > be
>> > > > > reading the RBR
>> > > > >
>> > > > > or at least the LSR. When tracing serial_ioport_read and
>> > > > > serial_ioport_write,
>> > > > >
>> > > > > once the menu is hit, I don't see any read or writes to the
>> > > > > serial
>> > > > > device
>> > > > >
>> > > > > registers despite me trying to send characters and use the
>> > > > > menu.
>> > > > >
>> > > > >
>> > > > >
>> > > > > The driver Solaris 10 is using for the device appears to be
>> > > > > similar/same as
>> > > > >
>> > > > > /usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code found
>> > > > > at
>> > > > > https://github.com/nxmirrors/onnv.
>> > > > >
>> > > > >
>> > > > >
>> > > > > ```
>> > > > >
>> > > > > asy->asy_hwtype = ASY16550AF;
>> > > > >
>> > > > > OUTB(FIFOR, 0x00); /* clear fifo register */
>> > > > >
>> > > > > asy->asy_trig_level = 0x00; /* sets the fifo Threshold to 1 */
>> > > > >
>> > > > >
>> > > > >
>> > > > > /* set/Enable FIFO */
>> > > > >
>> > > > > OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
>> > > > >
>> > > > > (asy->asy_trig_level & 0xff));
>> > > > >
>> > > > >
>> > > > >
>> > > > > if ((INB(ISR) & 0xc0) == 0xc0)
>> > > > >
>> > > > >     asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
>> > > > >
>> > > > > else {
>> > > > >
>> > > > >     asy->asy_hwtype = ASY8250;
>> > > > >
>> > > > >     OUTB(FIFOR, 0x00); /* NO FIFOs */
>> > > > >
>> > > > >     asy->asy_trig_level = 0;
>> > > > >
>> > > > > }
>> > > > >
>> > > > > ```
>> > > > >
>> > > > >
>> > > > >
>> > > > > From what I can tell when tracing serial_ioport_write and
>> > > > > serial_ioport_read,
>> > > > >
>> > > > > Solaris 10 correctly identifies the serial device and
>> > > > > successfully
>> > > > > attaches it.
>> > > > >
>> > > > > In the asyattach function (OpenSolaris driver), interrupts are
>> > > > > disabled by zeroing the
>> > > > >
>> > > > > Interrupt Enable Register. From what I'm reading in OpenSolaris
>> > > > > source code, interrupts
>> > > > >
>> > > > > are reenabled when the device is "opened". This seems like
>> > > > > consistent and
>> > > > >
>> > > > > correct behaviour though I'm not sure why the device is not
>> > > > > being
>> > > > > opened to be
>> > > > >
>> > > > > used by the serial console.
>> > > > >
>> > > > >
>> > > > >
>> > > > > Is this an issue anyone else has tried to debug?
>> > > > >
>> > > > > Are there any leads that I can follow up on for why the serial
>> > > > > console becomes
>> > > > > unresponsive
>> > > > >
>> > > > > on Solaris 10?
>> > > >
>> > > > It has been a while since I've looked at booting Solaris >= 10
>> > > > but
>> > > > certainly the
>> > > > messages above about set_features and the frozen console suggest
>> > > > that
>> > > > something is
>> > > > going amiss with interrupt routing, although since Linux and
>> > > > NetBSD
>> > > > were fine the
>> > > > last time I ran my OpenBIOS release tests then Solaris must be
>> > > > doing
>> > > > something
>> > > > different here.
>> > > >
>> > > > Note that the serial interrupts are routed from the ebus into
>> > > > sabre
>> > > > so the first
>> > > > thing to check would be that the end-to-end routing from device
>> > > > to
>> > > > CPU looks correct
>> > > > when using Solaris.
>> > > >
>> > > >
>> > > > ATB,
>> > > >
>> > > > Mark.
>> >
>> >
>
>
>
> --
> -Peter Tribble
> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/



-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu

Re: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

Good idea.

The ESCC device looks like it's written as a sysbus device. I think the
Ultra 5 has no devices on the root sabre bus. The serial controller is
behind the ebus (essentially isa). I'm guessing I would need to write a
wrapper device around the memory io functions so that it can be used
under the ebus - judging from the serial-isa implementation.

I think it might be possible to leave the ESCC as a sysbus device but
I'm not familiar enough with OpenBIOS to expose the right information
to Solaris and reason about what's happening confidentally. I don't
expect writing a wrapper for isa to be difficult so I'll give that a
go. Do you think it would be fine to just choose an arbitrary ioport
address for the device?

Thanks,
Jasper Lowell.


On Fri, 2020-05-08 at 15:45 +0200, Artyom Tarasenko wrote:
> On Fri, May 8, 2020 at 10:51 AM Peter Tribble <
> peter.tribble@gmail.com> wrote:
> > I see the same behaviour as reported here when booting current
> > SPARC illumos
> > (illumos is the ongoing fork of OpenSolaris) under qemu - looks
> > like it's booted
> > up fine, but I can't type anything on the console.
> 
> There is one more option which can be relatively easily tested:
> you can add two more ports (or replace the existing ttya/ttyb) to the
> qemu's ultra5 model: the escc (aka zs) ports.
> They definitely work under Solaris (Ultra-1, Ultra-2, E3000,
> E3500...), I've seen it.
> OpenBIOS already has a driver for them which is used for sun4m (and
> some ppc) targets. So no new devices have to be implemented.
> If your and Jasper's theory proofs to be correct, we can think of
> replacing ttya/ttyb su with zs.
> I guess the other sun4u operating systems do support zs as well.
> (This
> has to be tested though)
> 
> 
> > While I'm an illumos developer, and maintain it on SPARC, I'm
> > unfamiliar with
> > most of the internals. We'll try and have a poke around, though.
> > 
> > (The aim would be to use qemu to allow illumos developers to test
> > changes on SPARC
> > without requiring them to have SPARC hardware, hence my interest.)
> 
> I think I managed booting Tribblix under the QEMU niagara target. It
> has less devices than sun4u, but the console was working.
> 
> Regards,
> Artyom
> 
> > On Fri, May 8, 2020 at 3:40 AM <jasper.lowell@bt.com> wrote:
> > > There are two different drivers for the 16550A in OpenSolaris.
> > > 
> > > There is a generic driver in /usr/src/uts/common/io/asy.c. This
> > > driver
> > > clearly states in comments that it is assigning the device to
> > > tty[a-d].
> > > It's really obvious to me that there is support in this driver
> > > for
> > > using the device for a tty.
> > > 
> > > There is another driver at /usr/src/uts/sun4/io/su_driver.c.
> > > Judging
> > > from the name this is specific for SuperIO. This driver is more
> > > than
> > > 1000 lines shorter than the other driver and contains a note at
> > > the top
> > > of the file that it is "modified as sparc keyboard/mouse driver."
> > > I
> > > don't have much experience with Solaris internals but I can't see
> > > any
> > > obvious signs that this can be used as a tty. I'd also question
> > > why
> > > there are two drivers if they have the same purpose/capability.
> > > If the
> > > su_driver exists to only add support for the keyboard/mouse I'm
> > > not
> > > sure why it would be shorter rather than longer. It would be
> > > helpful if
> > > someone with Solaris experience, that knows what they're doing (I
> > > do
> > > not), can take a look at this driver and give a better opinion.
> > > 
> > > When emulating Sun4u, the su driver is used. If you misconfigure
> > > the
> > > serial device in QEMU, you can trigger errors that are unique to
> > > the
> > > driver. Also, Solaris attaches the device as su0.
> > > 
> > > Solaris can access the registers, identify/attach the device, but
> > > it
> > > just never attempts to use it. Interrupts are explicitly disabled
> > > and
> > > the device is never polled. I don't think asyopen in su_driver.c
> > > is
> > > ever called. I've thoroughly stepped through every register
> > > access for
> > > the 16550A and nothing seems out of the ordinary to me. Something
> > > I've
> > > considered is that OpenBIOS is not setting properties for the
> > > device in
> > > a way that Solaris expects but I'm not familiar enough with Sun's
> > > OpenBOOT to make progress here. I've read through the PROM
> > > functions
> > > that Solaris calls when choosing what device to use as a console
> > > and
> > > nothing seemed inconsistent with what OpenBIOS does.
> > > Unfortunately,
> > > OpenBIOS seems to crash or hang when using the kernel debugger
> > > module,
> > > so dynamic analysis using breakpoints isn't an option.
> > > 
> > > I don't have any concrete explanations for the broken console but
> > > rather than do nothing I figured I'd see what happens by
> > > emulating the
> > > SAB 82532.
> > > 
> > > > At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to
> > > > the
> > > > 16550A UART. I think there were more such machines. I don't
> > > > expect
> > > > there is anything in the Solaris kernel which would prevent any
> > > > serial
> > > > device known to it to be used as a tty.
> > > 
> > > Do you happen to know if this was over SuperIO? If this machine
> > > was
> > > using the same su_driver for a serial console it would rule out
> > > emulating the hardware-faithful SAB 82532 as being a possible
> > > improvement. I can't find anything online about someone using
> > > SuperIO
> > > for a ttya on an Ultra 5 running Solaris.
> > > 
> > > > Well, theoretically yes, but practically there is just one
> > > > baudrate
> > > > which can be specified in the OBP. I think it's perfectly safe
> > > > to use
> > > > max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer.
> > > 
> > > I'll do this while looking at whether or not the different chip
> > > fixes
> > > the console problems on Sun4u. I'd personally like to avoid
> > > introducing
> > > a device to QEMU that makes assumptions about how the guest may
> > > configure the chip.
> > > 
> > > Thanks,
> > > Jasper Lowell.
> > > 
> > > 
> > > On Thu, 2020-05-07 at 17:02 +0200, Artyom Tarasenko wrote:
> > > > On Thu, May 7, 2020 at 4:29 PM <jasper.lowell@bt.com> wrote:
> > > > > Just thought I'd chime in with an update.
> > > > > 
> > > > > We are currently emulating a 16550A UART. The guest sees this
> > > > > as
> > > > > the SU
> > > > > device, referring to the SuperIO port (a pair of 16550A
> > > > > UARTs). On
> > > > > the
> > > > > Ultra 5, the machine that Sun4u is modelled against, SuperIO
> > > > > was
> > > > > used
> > > > > for the keyboard and mouse. The Ultra 5 also had a DB25 (ttya
> > > > > default)
> > > > > and a DB9 (ttyb default) with a SAB82532 ESSC2.
> > > > > 
> > > > > Using tracing, I've looked through how the 16550A UART is
> > > > > touched
> > > > > and
> > > > > it looks like Solaris 10 has no issues identifying the
> > > > > device. I've
> > > > > matched register accesses with driver code in OpenSolaris and
> > > > > I'm
> > > > > pretty sure the device is attached successfully. Also, if you
> > > > > boot
> > > > > Solaris 10 with debugging output, you can see that the device
> > > > > gets
> > > > > labelled as su0. The only time Solaris is capable of writing
> > > > > to the
> > > > > console is when OpenBIOS is used as a proxy.
> > > > > 
> > > > > Rather than Solaris deciding against using SuperIO as a tty,
> > > > > I
> > > > > don't
> > > > > think there was ever any support for doing so (at least on
> > > > > SPARC
> > > > > machines). This could be an explanation for why the system
> > > > > appears
> > > > > to
> > > > > be trucking along just fine despite a seemingly frozen
> > > > > console -
> > > > > there
> > > > > is no console. I don't think the frozen console is the fault
> > > > > of
> > > > > broken
> > > > > interrupt routing as the 16550A UART is never programmed to
> > > > > generate
> > > > > them.
> > > > 
> > > > At least Fujitsu Siemens PRIMEPOWER250 had a tty attached to
> > > > the
> > > > 16550A UART. I think there were more such machines. I don't
> > > > expect
> > > > there is anything in the Solaris kernel which would prevent any
> > > > serial
> > > > device known to it to be used as a tty.
> > > > 
> > > > > I've started work on emulating the SAB 82532 ESSC2 but it's
> > > > > unfortunately way more complex than than the 16550A. For
> > > > > instance,
> > > > > it's
> > > > > possible to configure different baudrates for receiving and
> > > > > transmitting. QEMU's chardev interface doesn't appear to
> > > > > handle
> > > > > that.
> > > > > QEMUSerialSetParams has a single speed value that is passed
> > > > > to
> > > > > cfsetispeed and cfsetospeed. The chip also has support for
> > > > > stick
> > > > > parity
> > > > > , which aren't valid options right now either. If I'm wrong
> > > > > on
> > > > > either
> > > > > of those points please correct me. Unless there is an
> > > > > alternative,
> > > > > changes to the interface may need to be made if adding this
> > > > > device
> > > > > is
> > > > > to be considered.
> > > > 
> > > > Well, theoretically yes, but practically there is just one
> > > > baudrate
> > > > which can be specified in the OBP. I think it's perfectly safe
> > > > to use
> > > > max(rxrate,txrate), or min(rxrate,txrate), whatever you prefer.
> > > > 
> > > > Regards,
> > > > Artyom
> > > > > On Sun, 2020-02-09 at 11:26 +0000, Mark Cave-Ayland wrote:
> > > > > > On 05/02/2020 06:31, jasper.lowell@bt.com wrote:
> > > > > > 
> > > > > > > I'm currently working towards emulating Solaris 10 on
> > > > > > > sun4u.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > The Solaris 10 ISO image I am attempting to boot is the
> > > > > > > one
> > > > > > > from
> > > > > > > the Oracle
> > > > > > > 
> > > > > > > download page at
> > > > > > > https://www.oracle.com/solaris/solaris10/downloads/solaris10-get-jsp-downloads.html.
> > > > > > > 
> > > > > > > Image: sol-10-u11-ga-sparc-dvd.iso
> > > > > > > 
> > > > > > > MD5:   53e8b066f7f250ce2fd2cef063f8072b
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > I am using QEMU commit
> > > > > > > 7bd9d0a9e26c7a3c67c0f174f0009ba19969b158.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > The command I am using to run QEMU is:
> > > > > > > 
> > > > > > > ./qemu/sparc64-softmmu/qemu-system-sparc64 -bios
> > > > > > > ./openbios/obj-sparc64/openbios-builtin.elf -cdrom
> > > > > > > ./iso/solaris/sol-10-u11-ga-sparc-dvd.iso -boot d
> > > > > > > -nographic -m
> > > > > > > 3G
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ```
> > > > > > > 
> > > > > > > CPUs: 1 x SUNW,UltraSPARC-IIi
> > > > > > > 
> > > > > > > UUID: 00000000-0000-0000-0000-000000000000
> > > > > > > 
> > > > > > > Welcome to OpenBIOS v1.1 built on Feb 5 2020 19:15
> > > > > > > 
> > > > > > >   Type 'help' for detailed information
> > > > > > > 
> > > > > > > Trying cdrom:f...
> > > > > > > 
> > > > > > > Not a bootable ELF image
> > > > > > > 
> > > > > > > Not a bootable a.out image
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Loading FCode image...
> > > > > > > 
> > > > > > > Loaded 7420 bytes
> > > > > > > 
> > > > > > > entry point is 0x4000
> > > > > > > 
> > > > > > > Evaluating FCode...
> > > > > > > 
> > > > > > > Evaluating FCode...
> > > > > > > 
> > > > > > > Ignoring failed claim for va 1000000 memsz af6d6!
> > > > > > > 
> > > > > > > Ignoring failed claim for va 1402000 memsz 4dcc8!
> > > > > > > 
> > > > > > > Ignoring failed claim for va 1800000 memsz 510c8!
> > > > > > > 
> > > > > > > SunOS Release 5.10 Version Generic_147147-26 64-bit
> > > > > > > 
> > > > > > > Copyright (c) 1983, 2013, Oracle and/or its affiliates.
> > > > > > > All
> > > > > > > rights
> > > > > > > reserved.
> > > > > > > 
> > > > > > > could not find debugger-vocabulary-
> > > > > > > hook>threads:interpret:
> > > > > > > exception -13 caught
> > > > > > > 
> > > > > > > interpret \ Copyright (c) 1995-1999 by Sun Microsystems,
> > > > > > > Inc.
> > > > > > > 
> > > > > > > \ All rights reserved.
> > > > > > > 
> > > > > > > \
> > > > > > > 
> > > > > > > \ ident "@(#)data64.fth  1.3     00/07/17 SMI"
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > hex
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > only forth also definitions
> > > > > > > 
> > > > > > > vocabulary kdbg-words
> > > > > > > 
> > > > > > > also kdbg-words definitions
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > defer p@
> > > > > > > 
> > > > > > > defer p!
> > > > > > > 
> > > > > > > ['] x@ is p@
> > > > > > > 
> > > > > > > ['] x! is p!
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 8 constant ptrsize
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > d# 32 constant nbitsminor
> > > > > > > 
> > > > > > > h# ffffffff constant maxmin
> > > > > > > 
> > > > > > > \
> > > > > > > 
> > > > > > > \ Copyright 2008 Sun Microsystems, Inc.  All rights
> > > > > > > reserved.
> > > > > > > 
> > > > > > > \ Use is subject to license terms.
> > > > > > > 
> > > > > > > \
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > \ #pragma ident  "@(#)kdbg.fth    1.20    08/06/06 SMI"
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > h# 7ff constant v9bias
> > > > > > > 
> > > > > > > h# unix-tte:interpret: exception -13 caught
> > > > > > > 
> > > > > > > interpret ' unix-tte is va>tte-data failed with error
> > > > > > > ffffffffffffffed
> > > > > > > 
> > > > > > > WARNING: consconfig: cannot find driver for screen device
> > > > > > > /pci@1fe,
> > > > > > > 0/pci@1,1/QEMU,VGA@2
> > > > > > > 
> > > > > > > Configuring devices.
> > > > > > > 
> > > > > > > WARNING: Interrupt not seen after set_features
> > > > > > > 
> > > > > > > Using RPC Bootparams for network configuration
> > > > > > > information.
> > > > > > > 
> > > > > > > Attempting to configure interface hme0...
> > > > > > > 
> > > > > > > WARNING: Power off requested from power button or SC,
> > > > > > > powering
> > > > > > > down
> > > > > > > the system!
> > > > > > > 
> > > > > > > Skipped interface hme0
> > > > > > > 
> > > > > > > svc:/system/filesystem/local:default: WARNING:
> > > > > > > /usr/sbin/zfs
> > > > > > > mount
> > > > > > > -a failed: one or
> > > > > > > more file systems failed to mount
> > > > > > > 
> > > > > > > Serial console, reverting to text install
> > > > > > > 
> > > > > > > Beginning system identification...
> > > > > > > 
> > > > > > > Searching for configuration file(s)...
> > > > > > > 
> > > > > > > Search complete.
> > > > > > > 
> > > > > > > Discovering additional network configuration...
> > > > > > > 
> > > > > > > ```
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > The installation menu is shown after but the console is
> > > > > > > unresponsive.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > After some debugging, it looks like the QEMU front-end is
> > > > > > > correctly
> > > > > > > filling
> > > > > > > 
> > > > > > > the serial receive buffer with characters, and then
> > > > > > > starts
> > > > > > > dropping
> > > > > > > them once
> > > > > > > 
> > > > > > > the number of characters in the buffer reach the
> > > > > > > interrupt
> > > > > > > level.
> > > > > > > The interrupt
> > > > > > > 
> > > > > > > level happens to be 1 when booting Solaris 10. This looks
> > > > > > > like
> > > > > > > normal behaviour
> > > > > > > 
> > > > > > > to me.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > I started looking at why the serial receive buffer might
> > > > > > > not be
> > > > > > > consumed and
> > > > > > > 
> > > > > > > considered that interrupts might not be being raised
> > > > > > > correctly.
> > > > > > > I
> > > > > > > ran with
> > > > > > > 
> > > > > > > tracing and there were no interrupts for IRQ 0x2b like
> > > > > > > there
> > > > > > > are
> > > > > > > when using
> > > > > > > 
> > > > > > > OpenBSD. When inspecting the registers of the serial
> > > > > > > device it
> > > > > > > looks like the
> > > > > > > 
> > > > > > > Interrupt Enable Register is set to zero.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > If Solaris 10 was using the device is polling mode, it
> > > > > > > should
> > > > > > > be
> > > > > > > reading the RBR
> > > > > > > 
> > > > > > > or at least the LSR. When tracing serial_ioport_read and
> > > > > > > serial_ioport_write,
> > > > > > > 
> > > > > > > once the menu is hit, I don't see any read or writes to
> > > > > > > the
> > > > > > > serial
> > > > > > > device
> > > > > > > 
> > > > > > > registers despite me trying to send characters and use
> > > > > > > the
> > > > > > > menu.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > The driver Solaris 10 is using for the device appears to
> > > > > > > be
> > > > > > > similar/same as
> > > > > > > 
> > > > > > > /usr/src/uts/sun4/io/su_driver.c in the OpenSolaris code
> > > > > > > found
> > > > > > > at
> > > > > > > https://github.com/nxmirrors/onnv.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > ```
> > > > > > > 
> > > > > > > asy->asy_hwtype = ASY16550AF;
> > > > > > > 
> > > > > > > OUTB(FIFOR, 0x00); /* clear fifo register */
> > > > > > > 
> > > > > > > asy->asy_trig_level = 0x00; /* sets the fifo Threshold to
> > > > > > > 1 */
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > /* set/Enable FIFO */
> > > > > > > 
> > > > > > > OUTB(FIFOR, FIFO_ON | FIFODMA | FIFOTXFLSH | FIFORXFLSH |
> > > > > > > 
> > > > > > > (asy->asy_trig_level & 0xff));
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > if ((INB(ISR) & 0xc0) == 0xc0)
> > > > > > > 
> > > > > > >     asy->asy_use_fifo = FIFO_ON; /* QEMU REACHES HERE. */
> > > > > > > 
> > > > > > > else {
> > > > > > > 
> > > > > > >     asy->asy_hwtype = ASY8250;
> > > > > > > 
> > > > > > >     OUTB(FIFOR, 0x00); /* NO FIFOs */
> > > > > > > 
> > > > > > >     asy->asy_trig_level = 0;
> > > > > > > 
> > > > > > > }
> > > > > > > 
> > > > > > > ```
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > From what I can tell when tracing serial_ioport_write and
> > > > > > > serial_ioport_read,
> > > > > > > 
> > > > > > > Solaris 10 correctly identifies the serial device and
> > > > > > > successfully
> > > > > > > attaches it.
> > > > > > > 
> > > > > > > In the asyattach function (OpenSolaris driver),
> > > > > > > interrupts are
> > > > > > > disabled by zeroing the
> > > > > > > 
> > > > > > > Interrupt Enable Register. From what I'm reading in
> > > > > > > OpenSolaris
> > > > > > > source code, interrupts
> > > > > > > 
> > > > > > > are reenabled when the device is "opened". This seems
> > > > > > > like
> > > > > > > consistent and
> > > > > > > 
> > > > > > > correct behaviour though I'm not sure why the device is
> > > > > > > not
> > > > > > > being
> > > > > > > opened to be
> > > > > > > 
> > > > > > > used by the serial console.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Is this an issue anyone else has tried to debug?
> > > > > > > 
> > > > > > > Are there any leads that I can follow up on for why the
> > > > > > > serial
> > > > > > > console becomes
> > > > > > > unresponsive
> > > > > > > 
> > > > > > > on Solaris 10?
> > > > > > 
> > > > > > It has been a while since I've looked at booting Solaris >=
> > > > > > 10
> > > > > > but
> > > > > > certainly the
> > > > > > messages above about set_features and the frozen console
> > > > > > suggest
> > > > > > that
> > > > > > something is
> > > > > > going amiss with interrupt routing, although since Linux
> > > > > > and
> > > > > > NetBSD
> > > > > > were fine the
> > > > > > last time I ran my OpenBIOS release tests then Solaris must
> > > > > > be
> > > > > > doing
> > > > > > something
> > > > > > different here.
> > > > > > 
> > > > > > Note that the serial interrupts are routed from the ebus
> > > > > > into
> > > > > > sabre
> > > > > > so the first
> > > > > > thing to check would be that the end-to-end routing from
> > > > > > device
> > > > > > to
> > > > > > CPU looks correct
> > > > > > when using Solaris.
> > > > > > 
> > > > > > 
> > > > > > ATB,
> > > > > > 
> > > > > > Mark.
> > 
> > 
> > --
> > -Peter Tribble
> > http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
> 
> 

Re: Emulating Solaris 10 on SPARC64 sun4u

[Mark Cave-Ayland]

On 10/05/2020 03:46, jasper.lowell@bt.com wrote:

> Good idea.
> 
> The ESCC device looks like it's written as a sysbus device. I think the
> Ultra 5 has no devices on the root sabre bus. The serial controller is
> behind the ebus (essentially isa). I'm guessing I would need to write a
> wrapper device around the memory io functions so that it can be used
> under the ebus - judging from the serial-isa implementation.
> 
> I think it might be possible to leave the ESCC as a sysbus device but
> I'm not familiar enough with OpenBIOS to expose the right information
> to Solaris and reason about what's happening confidentally. I don't
> expect writing a wrapper for isa to be difficult so I'll give that a
> go. Do you think it would be fine to just choose an arbitrary ioport
> address for the device?
> 
> Thanks,
> Jasper Lowell.

I'm not overly keen on this approach, because it's just swapping out one incorrect
device for another. The existing sun4u machine is fairly close to an ultra5 and I'd
prefer to move towards emulating the real machine rather than keep swapping out
random bits of hardware.

The main reason I added the sunhme emulation to QEMU was because I found that across
all my test images different OSs had different bugs in their NIC drivers/IRQ
handling, and this was the only solution that would work for all of them. My fear
with going the ESCC route is that you'll end up in exactly the same situation.


ATB,

Mark.

Re: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

I've written up a basic implementation of the SAB 82532 ESCC2 device
and have written a patch for OpenBIOS to add it to the device tree. I
still have the 16550A UART acting as ttya to avoid having to write an
OpenBIOS device driver.

OpenBSD and Solaris both identify the device correctly and attach it.

Interestingly, it looks like Solaris entered an interrupt handler to
deal with an event for the SAB 82532 and it probed a few status
registers. Given that I couldn't encourage Solaris to do anything
outside of attach the device for the 16550A, I was thinking this might
be a good sign.

There really shouldn't be an interrupt though as the reset state of the
SAB 82532 is to have all interrupts masked. Solaris probes these
interrupt status registers while "configuring" the sunhme device.

Attempting to configure interface hme0...
140070@1589698603.268942:escc2_mem_read channel a addr 0x38 value 0x4
140070@1589698603.269011:escc2_irq_update value 0x0
140070@1589698603.269015:escc2_mem_read channel a addr 0x3a value 0x80
140070@1589698603.269017:escc2_irq_update value 0x0
140070@1589698603.269018:escc2_mem_read channel a addr 0x3b value 0x0
140070@1589698603.269076:escc2_mem_read channel a addr 0x38 value 0x0
WARNING: Power off requested from power button or SC, powering down the
system!
140070@1589698611.270845:escc2_mem_read channel a addr 0x38 value 0x0
140070@1589698619.271758:escc2_mem_read channel a addr 0x38 value 0x0

I've noticed that removing the sunhme code for sun4u.c in QEMU prevents
the spurious interrupt from happening for the serial device along with
prevent the unexpected power off request (the power off request was not
introduced by my code). I haven't investigated why the presence of
sunhme causes these events.

I modified OpenBIOS to use ttyb for stdin/stdout and assigned that to
the 16550A so that ttya could be aliased to the SAB 82532. Outside of
the spurious interrupt handler being called, I'm getting the same
behaviour where Solaris identifies, attaches, and then ignores the
device. Doesn't look like my guess was on the mark.

I'll be looking at getting an OpenSolaris-like kernel built with prom
debugging output for console/tty related files like
usr/src/uts/common/io/consconfig_dacf.c. The illumos kernel is probably
suitable for this because it's still maintained and appears to be
suffering from the same console problems. I don't have a SPARC64
machine immediately available and I'm unfamiliar with the build system
behind these distributions, so it might be a while before this happens.

I'm out of ideas.


Thanks,
Jasper Lowell.


On Sun, 2020-05-10 at 10:22 +0100, Mark Cave-Ayland wrote:
> On 10/05/2020 03:46, jasper.lowell@bt.com wrote:
> 
> > Good idea.
> > 
> > The ESCC device looks like it's written as a sysbus device. I think
> > the
> > Ultra 5 has no devices on the root sabre bus. The serial controller
> > is
> > behind the ebus (essentially isa). I'm guessing I would need to
> > write a
> > wrapper device around the memory io functions so that it can be
> > used
> > under the ebus - judging from the serial-isa implementation.
> > 
> > I think it might be possible to leave the ESCC as a sysbus device
> > but
> > I'm not familiar enough with OpenBIOS to expose the right
> > information
> > to Solaris and reason about what's happening confidentally. I don't
> > expect writing a wrapper for isa to be difficult so I'll give that
> > a
> > go. Do you think it would be fine to just choose an arbitrary
> > ioport
> > address for the device?
> > 
> > Thanks,
> > Jasper Lowell.
> 
> I'm not overly keen on this approach, because it's just swapping out
> one incorrect
> device for another. The existing sun4u machine is fairly close to an
> ultra5 and I'd
> prefer to move towards emulating the real machine rather than keep
> swapping out
> random bits of hardware.
> 
> The main reason I added the sunhme emulation to QEMU was because I
> found that across
> all my test images different OSs had different bugs in their NIC
> drivers/IRQ
> handling, and this was the only solution that would work for all of
> them. My fear
> with going the ESCC route is that you'll end up in exactly the same
> situation.
> 
> 
> ATB,
> 
> Mark.

Re: Emulating Solaris 10 on SPARC64 sun4u

[Artyom Tarasenko]

On Sun, May 17, 2020 at 9:57 AM <jasper.lowell@bt.com> wrote:
>
> I've written up a basic implementation of the SAB 82532 ESCC2 device
> and have written a patch for OpenBIOS to add it to the device tree. I
> still have the 16550A UART acting as ttya to avoid having to write an
> OpenBIOS device driver.

Great progress! Are you planning to contribute your escc2 to the upstream?

> OpenBSD and Solaris both identify the device correctly and attach it.
>
> Interestingly, it looks like Solaris entered an interrupt handler to
> deal with an event for the SAB 82532 and it probed a few status
> registers. Given that I couldn't encourage Solaris to do anything
> outside of attach the device for the 16550A, I was thinking this might
> be a good sign.
>
> There really shouldn't be an interrupt though as the reset state of the
> SAB 82532 is to have all interrupts masked. Solaris probes these
> interrupt status registers while "configuring" the sunhme device.
>
> Attempting to configure interface hme0...
> 140070@1589698603.268942:escc2_mem_read channel a addr 0x38 value 0x4
> 140070@1589698603.269011:escc2_irq_update value 0x0
> 140070@1589698603.269015:escc2_mem_read channel a addr 0x3a value 0x80
> 140070@1589698603.269017:escc2_irq_update value 0x0
> 140070@1589698603.269018:escc2_mem_read channel a addr 0x3b value 0x0
> 140070@1589698603.269076:escc2_mem_read channel a addr 0x38 value 0x0
> WARNING: Power off requested from power button or SC, powering down the
> system!
> 140070@1589698611.270845:escc2_mem_read channel a addr 0x38 value 0x0
> 140070@1589698619.271758:escc2_mem_read channel a addr 0x38 value 0x0
>
> I've noticed that removing the sunhme code for sun4u.c in QEMU prevents
> the spurious interrupt from happening for the serial device along with
> prevent the unexpected power off request (the power off request was not
> introduced by my code). I haven't investigated why the presence of
> sunhme causes these events.
>
> I modified OpenBIOS to use ttyb for stdin/stdout and assigned that to
> the 16550A so that ttya could be aliased to the SAB 82532. Outside of
> the spurious interrupt handler being called, I'm getting the same
> behaviour where Solaris identifies, attaches, and then ignores the
> device. Doesn't look like my guess was on the mark.
>
> I'll be looking at getting an OpenSolaris-like kernel built with prom
> debugging output for console/tty related files like
> usr/src/uts/common/io/consconfig_dacf.c. The illumos kernel is probably
> suitable for this because it's still maintained and appears to be
> suffering from the same console problems. I don't have a SPARC64
> machine immediately available and I'm unfamiliar with the build system
> behind these distributions, so it might be a while before this happens.
>
> I'm out of ideas.

We can use the strategy I used 10 years back for sun4m: boot the
proprietary firmware first to reduce the number of possible emulation
bugs. The proprietary firmware is known to boot Solaris.

Regards,
Artyom

Re: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

> Great progress! Are you planning to contribute your escc2 to the
> upstream?

I would like to. While it didn't solve the console difficulties on
OpenSolaris variants, it's probably still a good idea to increment
Sun4u emulation towards being more faithful to hardware. It will take
me a few weeks to clean up and test but I'll make an RFC once I have a
patch to discuss. It's unlikely that the patch will be feature complete
but I'll aim for it to be enough to satisfy the Linux/OpenBSD drivers.

> We can use the strategy I used 10 years back for sun4m: boot the
> proprietary firmware first to reduce the number of possible emulation
> bugs. The proprietary firmware is known to boot Solaris.

Using the proprietary firmware for this would be ideal. It would also
provide reliable access to the kernel debugger which would be extremely
helpful for diagnosing what's going wrong with the console. I'm not
sure how I would go about making progress on this though. I know there
are binaries of the BIOS for Sun4m machines floating around but I'm not
aware of any for Sun4u machines.

Thanks,
Jasper Lowell.

On Sun, 2020-05-17 at 14:37 +0200, Artyom Tarasenko wrote:
> On Sun, May 17, 2020 at 9:57 AM <jasper.lowell@bt.com> wrote:
> > I've written up a basic implementation of the SAB 82532 ESCC2
> > device
> > and have written a patch for OpenBIOS to add it to the device tree.
> > I
> > still have the 16550A UART acting as ttya to avoid having to write
> > an
> > OpenBIOS device driver.
> 
> Great progress! Are you planning to contribute your escc2 to the
> upstream?
> 
> > OpenBSD and Solaris both identify the device correctly and attach
> > it.
> > 
> > Interestingly, it looks like Solaris entered an interrupt handler
> > to
> > deal with an event for the SAB 82532 and it probed a few status
> > registers. Given that I couldn't encourage Solaris to do anything
> > outside of attach the device for the 16550A, I was thinking this
> > might
> > be a good sign.
> > 
> > There really shouldn't be an interrupt though as the reset state of
> > the
> > SAB 82532 is to have all interrupts masked. Solaris probes these
> > interrupt status registers while "configuring" the sunhme device.
> > 
> > Attempting to configure interface hme0...
> > 140070@1589698603.268942:escc2_mem_read channel a addr 0x38 value
> > 0x4
> > 140070@1589698603.269011:escc2_irq_update value 0x0
> > 140070@1589698603.269015:escc2_mem_read channel a addr 0x3a value
> > 0x80
> > 140070@1589698603.269017:escc2_irq_update value 0x0
> > 140070@1589698603.269018:escc2_mem_read channel a addr 0x3b value
> > 0x0
> > 140070@1589698603.269076:escc2_mem_read channel a addr 0x38 value
> > 0x0
> > WARNING: Power off requested from power button or SC, powering down
> > the
> > system!
> > 140070@1589698611.270845:escc2_mem_read channel a addr 0x38 value
> > 0x0
> > 140070@1589698619.271758:escc2_mem_read channel a addr 0x38 value
> > 0x0
> > 
> > I've noticed that removing the sunhme code for sun4u.c in QEMU
> > prevents
> > the spurious interrupt from happening for the serial device along
> > with
> > prevent the unexpected power off request (the power off request was
> > not
> > introduced by my code). I haven't investigated why the presence of
> > sunhme causes these events.
> > 
> > I modified OpenBIOS to use ttyb for stdin/stdout and assigned that
> > to
> > the 16550A so that ttya could be aliased to the SAB 82532. Outside
> > of
> > the spurious interrupt handler being called, I'm getting the same
> > behaviour where Solaris identifies, attaches, and then ignores the
> > device. Doesn't look like my guess was on the mark.
> > 
> > I'll be looking at getting an OpenSolaris-like kernel built with
> > prom
> > debugging output for console/tty related files like
> > usr/src/uts/common/io/consconfig_dacf.c. The illumos kernel is
> > probably
> > suitable for this because it's still maintained and appears to be
> > suffering from the same console problems. I don't have a SPARC64
> > machine immediately available and I'm unfamiliar with the build
> > system
> > behind these distributions, so it might be a while before this
> > happens.
> > 
> > I'm out of ideas.
> 
> We can use the strategy I used 10 years back for sun4m: boot the
> proprietary firmware first to reduce the number of possible emulation
> bugs. The proprietary firmware is known to boot Solaris.
> 
> Regards,
> Artyom

Re: Emulating Solaris 10 on SPARC64 sun4u

[Mike Russo]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

> Using the proprietary firmware for this would be ideal. It would also
> provide reliable access to the kernel debugger which would be
> extremely
> helpful for diagnosing what's going wrong with the console. I'm not
> sure how I would go about making progress on this though. I know there
> are binaries of the BIOS for Sun4m machines floating around but I'm
> not
> aware of any for Sun4u machines.
> 

I haven't been able to find any of this firmware either. Not sure if
this helps but someone says they've got the Ultra 1 firmware (along with
cgsix and cgthree) available here:
https://people.csail.mit.edu/fredette/tme/sun-u1-nbsd.html

[-- Attachment #2: Type: text/html, Size: 1007 bytes --]

Re: Emulating Solaris 10 on SPARC64 sun4u

[BALATON Zoltan]

On Thu, 7 May 2020, jasper.lowell@bt.com wrote:
> I've started work on emulating the SAB 82532 ESSC2 but it's
> unfortunately way more complex than than the 16550A. For instance, it's

I don't know anything about this chip so don't know if it helps but if 
it's any way similar to ESCC (and the ESCC2 name is not just marketing) 
then there's some emulation of that in hw/char/escc.c that you may want to 
look at.

> possible to configure different baudrates for receiving and
> transmitting. QEMU's chardev interface doesn't appear to handle that.
> QEMUSerialSetParams has a single speed value that is passed to
> cfsetispeed and cfsetospeed. The chip also has support for stick parity
> , which aren't valid options right now either. If I'm wrong on either
> of those points please correct me. Unless there is an alternative,
> changes to the interface may need to be made if adding this device is
> to be considered.

Maybe you can get away with setting these to the values the driver would 
set and hard coding it for now just to get some output. Then you can 
ignore the corresponding registers which could simplify initial device 
model.

Regards,
BALATON Zoltan

Re: Emulating Solaris 10 on SPARC64 sun4u

[jasper.lowell]

> I don't know anything about this chip so don't know if it helps but
> if 
> it's any way similar to ESCC (and the ESCC2 name is not just
> marketing) 
> then there's some emulation of that in hw/char/escc.c that you may
> want to 
> look at.

From what I can tell, the SAB 82532 is a bit more complex than the ESCC
ones. It's not difficult to implement but a complete solution will be
lengthy because of the large combination of configuration options the
chip supports.

> Maybe you can get away with setting these to the values the driver
> would 
> set and hard coding it for now just to get some output. Then you can 
> ignore the corresponding registers which could simplify initial
> device 
> model.

I'll take this approach.

Thanks,
Jasper Lowell.

On Thu, 2020-05-07 at 20:54 +0200, BALATON Zoltan wrote:
> On Thu, 7 May 2020, jasper.lowell@bt.com wrote:
> > I've started work on emulating the SAB 82532 ESSC2 but it's
> > unfortunately way more complex than than the 16550A. For instance,
> > it's
> 
> I don't know anything about this chip so don't know if it helps but
> if 
> it's any way similar to ESCC (and the ESCC2 name is not just
> marketing) 
> then there's some emulation of that in hw/char/escc.c that you may
> want to 
> look at.
> 
> > possible to configure different baudrates for receiving and
> > transmitting. QEMU's chardev interface doesn't appear to handle
> > that.
> > QEMUSerialSetParams has a single speed value that is passed to
> > cfsetispeed and cfsetospeed. The chip also has support for stick
> > parity
> > , which aren't valid options right now either. If I'm wrong on
> > either
> > of those points please correct me. Unless there is an alternative,
> > changes to the interface may need to be made if adding this device
> > is
> > to be considered.
> 
> Maybe you can get away with setting these to the values the driver
> would 
> set and hard coding it for now just to get some output. Then you can 
> ignore the corresponding registers which could simplify initial
> device 
> model.
> 
> Regards,
> BALATON Zoltan