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
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
