> 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.low...@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