Hi Roman,
Roman Yeryomin wrote:
on system with native bios (tinybios): cat /proc/tty/driver/serial serinfo:1.0 driver revision: 0: uart:16550A port:000003F8 irq:4 tx:945 rx:15 RTS|CTS|DTR|DSR|CD 1: uart:16550A port:000002F8 irq:3 tx:0 rx:0 CTS|DSR|CD
but on system with coreboot: cat /proc/tty/driver/serial serinfo:1.0 driver revision: 0: uart:NS16550A port:000003F8 irq:4 tx:0 rx:0 RTS|DTR 1: uart:unknown port:000002F8 irq:3
Did I overlook this message on the the list? If it wasn't sent to the list, please keep in mind that it's nicer both for you and for others after you to keep discussion on the list, for you because you may get quicker replies and for others because the solutions are archived.
What I find most interesting about the output above is how uart 1 is identified differently when starting with coreboot. It would be good to find out why.
OK, this is kind of the problem I remember. If you have time go into the kernel, IIRC, there is a test for some modem signal and the device is not available otherwise. I am sorry to be so fuzzy but this was seven years ago. It was a weird problem.
you think this is kernel problem?
I don't think serial control signals is the source of your problems. Even if they are, the problem is not in the kernel but in the application. Unless your kernel has a bad bug in the UART layer it will not withhold data based on control signals.
It is much more likely that the hardware is not configured correctly.
It seems whatever you have on that port is not asserting DTR, which is also odd.
Please comment on this. What do you have connected to the serial port? Does DTR on the Geode go high when your terminal software is running?
I've asked Pascal Dornier (pcengines) how he sets up uart in his bios but didn't receive an answer yet.
Please don't ever bother Pascal Dornier with coreboot issues. That is what this mailing list and the #coreboot IRC channel is meant for.
I still think the problem is in coreboot (or libpayload)...
Pascal answered me:
After init -> changes to Linux driver, or does it still use Int 10
- Int 16 ?
My BIOS does a redirect of these BIOS interrupts to the serial console.
You can safely assume that no Linux kernel driver requires real mode interrupts. This is an almost universal truth.
In particular: no, the Linux serial driver does not use BIOS interrupt services.
//Peter