qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emulating Solaris 10 on SPARC64 sun4u


From: jasper.lowell
Subject: Re: Emulating Solaris 10 on SPARC64 sun4u
Date: Fri, 8 May 2020 02:55:45 +0000

> 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, address@hidden 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]