Baytrail issue to communicate with superios.

[Jose Trujillo]

Hello All:
I hope you are doing great.

The system: Baytrail E3845, 4GB DDR3, fintek (f81803a) @0x4e and Winbond (w83627dhg) @0x2e, etc...

I just built coreboot (master) the last few days, everything works wonderfully except 2 things:

- Libgfxinit probably because this board is using the AUX channel instead DDI to communicate with the monitors; seems to me libgfxinit cannot find monitors thru DP ports but I could be wrong because neither VGA gets initialized; and eventually Linux always initialize the video correctly.
- SuperIOs not working; "cat /proc/interrupts" shows not activity from any serial port to any processor, but, I set accordingly (konfig, devicetree and superio.asl) I will check on Monday if the route definitions of "irqroute.h" are ok.

Using "superiotool" to scan for SIO devices finds Winbond W83627DHG and dumped all its registries but doesn't show Fintek f81803 because of lack of support, so, data exchange between the processor and the SIO chips via LPC port seems to be fine, maybe just need to fix the interrupt issues.

Any help will be highly appreciated,

Thank you,
JT

[Rudolf Marek]

Hi,

Dne 01. 12. 23 v 16:04 Jose Trujillo via coreboot napsal(a):
> Using "superiotool" to scan for SIO devices finds Winbond W83627DHG and dumped all its registries but doesn't show Fintek f81803 because of lack of support, so, data exchange between the processor and the SIO chips via LPC port seems to be fine, maybe just need to fix the interrupt issues.

Sorry I don't know much about your particular system. Can you get coreboot serial console on your fintek superio?
If yes, then likely something is wrong with interrupts.

You can use isadump to try to obtain UART1 and UART2 configurations (LDN 1 / LDN 2)

isadump -k 0x87,0x87 0x4e 0x4f 1
isadump -k 0x87,0x87 0x4e 0x4f 2

Says what?

You can also try to setup UART in linux as if those were working, like setting up baudrate / minicom
but then doing:

isaset -f 0x3f8 0x42

Should print "B" on the other side on COM1 (check address where your fintek uart is)

Thanks,
Rudolf

[Jose Trujillo]

Thank you Rudolf,
Good day,
> Can you get coreboot serial console on your fintek superio?

Yes, serial console works fine on fintek.
> If yes, then likely something is wrong with interrupts.

I am thinking about SERIRQ
> You can use isadump to try to obtain UART1 and UART2 configurations (LDN 1 / LDN 2)

sudo isadump -y -k 0x87,0x87 0x4e 0x4f 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: ff ff 00 ff ff ff ff 01 ff ff ff ff ff ff ff ff 
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
20: 12 10 10 19 34 00 00 90 e0 6f 8f 0f 8f 28 00 00 
30: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
60: 03 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
70: 04 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
f0: 00 ff 00 ff 00 00 00 ff ff ff ff ff ff ff ff ff

sudo isadump -y -k 0x87,0x87 0x4e 0x4f 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: ff ff 00 ff ff ff ff 02 ff ff ff ff ff ff ff ff 
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
20: 12 10 10 19 34 00 00 90 e0 6f 8f 0f 8f 28 00 00 
30: 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
60: 02 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
70: 03 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
f0: 00 44 00 ff 00 00 00 ff ff ff ff ff ff ff ff ff
> You can also try to setup UART in linux as if those were working, like setting up baudrate / minicom
> but then doing:

sudo isaset -y -f 0x3f8 0x42
Data mismatch, wrote 0x42, read 0x00 back.
> Should print "B" on the other side on COM1 (check address where your fintek uart is)

Printed "B" on the other side of the RS-232 cable on the ttyS0 port.

Do you know if is possible to enable SERIRQ and set SCNT_CONTINUOUS in the actual baytrail code?

SERIRQ code was supported in fsp_baytrail but not in baytrail, but now, maybe is supported indirectly in "common" code?

Thanks again,
Jose Trujillo.

[Rudolf Marek]

Hi Jose,

Dne 04. 12. 23 v 10:48 Jose Trujillo via coreboot napsal(a):
> Printed "B" on the other side of the RS-232 cable on the ttyS0 port.

OK so it does work.
> Do you know if is possible to enable SERIRQ and set SCNT_CONTINUOUS in the actual baytrail code?

Well sorry I don't know. It has been long time I did something with coreboot. What I do recall is that those Baytrail and later Apollo lake intel atom CPUs have some issue and setting LPC to the "continous" will shorten some life of the transistor driving the LPC bus, thus the system will malfunction sooner than later.
> SERIRQ code was supported in fsp_baytrail but not in baytrail, but now, maybe is supported indirectly in "common" code?

Sorry don't know.

Thanks,
Rudolf
> Thanks again,
> Jose Trujillo.
> _______________________________________________
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Jose Trujillo]

Good day Rudolf/All,
> OK so it does work.

Yesterday I copy/pasted the subroutine and its definitions used to enable SERIRQ and set the mode (sc_enable_serial_irqs) and now I can see serial output but no input on ttyS0.

At this point I am trying to understand what you already told me:

1.- To dump ELCR (I/O port register 0x4d0) to check if it is correctly programmed to EDGE
2.- To do some PNP device in ACPI to let linux infer the IRQ.
3.- To try to disable the IRQ from SoC internal UART.

For #1 the question is which linux command I can use to dump ELCR registers to check if misconfigured?
For #2 the question is if the linux command "dmesg | grep 'tty'" output which shows the irq set on coreboot devicetree is still not evidence that linux is aware of the port IRQs?

[    2.207098] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    2.208096] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A

I am including fintek's superio.asl which tell linux the resources of this device.
May be I still dont understand #2 or there is something else.

For #3 is straightforward for me and I am working on it.
> What I do recall is that those Baytrail and later Apollo lake intel atom CPUs have some issue and setting LPC to the "continous" will shorten some life of the transistor driving the LPC bus, thus the system will malfunction sooner than later.

I am aware of this and I have been concerned on this issue for a while, but, I think I need to try to make this system functional and suggest the target user not to use this feature.

Thank you,
Jose Trujillo.

[Rudolf Marek]

Hi Jose,

Dne 05. 12. 23 v 11:06 Jose Trujillo via coreboot napsal(a):
> Good day Rudolf/All,
> > OK so it does work.
>
> Yesterday I copy/pasted the subroutine and its definitions used to enable SERIRQ and set the mode (sc_enable_serial_irqs) and now I can see serial output but no input on ttyS0.

Are you sure you got it right in minicom on both sides? For example, you could have a hardware flow control set, which would cause data not to be send/delivered. Second problem would be if you have /dev/ttyS0 device opened multiple times, you will receive data to the random ends...

Do you see in cat /proc/interrupts IRQ 3 or IRQ 4 increasing when you try to send and/or receive data (depends on what UART do you use)

Alternatively you can do isadump -f 0x3f0 16 and check offset 0x3f8 to see if your data was received by the UART but no interrupt was raised.

I'm unsure with isadump syntax, but you get the idea...

If there are other UARTs in the system how they are configured? Do they work if there are connected to something?
The w83627dhg also supports UARTs. Are they present on your system, how they are configured? Is there some potential collision?

I don't have baytrail datasheet. If it has uarts as well how they are connected? Like PCI device? Or somehow those can be living on IRQ4/IRQ3 as well?
> At this point I am trying to understand what you already told me:

The dumps from yesterday from Fintek SIO, confirms that your fintek UARTS have the standard settings,

60: 03 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
70: 04 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [    2.207098] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
> [    2.208096] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A

Which is fine. However maybe the IRQ is wrongly shared with other UARTS?
> 1.- To dump ELCR (I/O port register 0x4d0) to check if it is correctly programmed to EDGE

This is done by Linux, you can likely check it with
isadump -f 0x4d0 16

But It may freeze your machine if the ACPI C2 register is nearby.
> 2.- To do some PNP device in ACPI to let linux infer the IRQ.

I think standard uarts on well known addresses should be discovered even  without ACPI
> 3.- To try to disable the IRQ from SoC internal UART.

Aha so there is more and not only that Winbond.
> For #1 the question is which linux command I can use to dump ELCR registers to check if misconfigured?

isadump -f 0x4d0 16
> For #2 the question is if the linux command "dmesg | grep 'tty'" output which shows the irq set on coreboot devicetree is still not evidence that linux is aware of the port IRQs?
>
> [    2.207098] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
> [    2.208096] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A

This shows that linux is fine with that UARTs.
> I am including fintek's superio.asl which tell linux the resources of this device.
> May be I still dont understand #2 or there is something else.
>
> For #3 is straightforward for me and I am working on it.

OK please check Winbond chip as well.
> I am aware of this and I have been concerned on this issue for a while, but, I think I need to try to make this system functional and suggest the target user not to use this feature.

OK please use continuous mode for now, because I think it needs to first be in this mode before switching to "quiet".
Maybe there is some issue with CLKRUN. Try to disable this feature somehow as well and/or make sure Fintek side is
configured properly as well.

Maybe you can try to do infinite loop to keep the chip busy and see if your serial input works. If yes, I would assume it
is likely CLKRUN.

while true; do sudo isadump -y -k 0x87,0x87 0x4e 0x4f 1 ; done

Sorry so this is probably all I can think of to debug this issue.

Thanks,
Rudolf

[Jose Trujillo]

Dear Rudolf/All,

Today I patched superiotool to add support for Fintek F81803A and dumped both superios, and I found that LPC clock must be set at 24MHz on Fintek global control register #26 from the default 48MHz.

So, now I am working on it, looking how to set correctly this register.

Thank you,
JT.

[Rudolf Marek]

Hi Jose,

Dne 06. 12. 23 v 15:31 Jose Trujillo via coreboot napsal(a):
> Dear Rudolf/All,
>
> Today I patched superiotool to add support for Fintek F81803A and dumped both superios, and I found that LPC clock must be set at 24MHz on Fintek global control register #26 from the default 48MHz.

That is strange. I would expect that this problem is visible already in your little TX test to send 0x42. If the clock
is 2x off the baudrate would be also 2x off.

Thanks,
Rudolf