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