Dear coreboot engineers & enthusiasts:
Doing dmesg: [X@localhost ~]$ dmesg | grep "tty" [ 0.336779] printk: console [tty0] enabled [ 1.521090] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A [ 1.542192] 00:05: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A [ 1.563264] 00:08: ttyS2 at I/O 0x3e8 (irq = 5, base_baud = 115200) is a 16550A [ 1.584268] 00:09: ttyS4 at I/O 0x2e0 (irq = 6, base_baud = 115200) is a 16550A
The problem I have is that only ttyS0 works (the communication with other PC).
Attached files: superio.c Slightly modified to initialize 2 more serial ports from 2 to 4. devicetree.cb Shows the forwarding of the I/O ranges for ttyS2 and ttyS4 also the smscsuperio tree with addresses and IRQs. superio.asl The ACPI code.
I suspect is an IRQ issue. Using minicom trying to send a byte out there is no signal shown on the oscilloscope. I asked (on #coreboot) if is required to route IRQs for the serial ports but nico answered "no but you need to tell the OS if the interrupt is level or edge" but I don't know how to do that. Anybody had experience making this kind of superio to work please give me a hint on how to resolve this. What additional work do I need to do?
Thank you, Jose Trujillo
I have worked on a port of SMSC SCH5545 on a Dell machine. These chips are quite different than others. What I have learnt is that despite you configure the SIO LDNs well, it may not be sufficient. I suggest you to look at table 13-1 of the datasheet of SCH3114: http://ww1.microchip.com/downloads/en/DeviceDoc/00001872A.pdf
You may need to configure the GPIOs alternate functions to work as serial port pins. From what I can see, the defautl configuration is not set for serial port 3 and 4 for GPIOs: GP10, GP11, GP64 and GP65. At a minimum, you should configure these to see anything on oscilloscope. I had similar issue with SCH5545 and had to configure the GPIOs for serial port as well.
The files you have attached seem to be well written, so I would have a look at GPIO configuration only.