Re: Serial Console Debugging Issue

[Frantisek Rysanek]

On 12 Aug 2022 at 12:12, Federico Vaga wrote:
> [    0.687294] 0000:05:00.0: ttyS0 at I/O 0xcf00 (irq = 16) is a 16C950/954
> 
> $ lspci -s 05:00.0 -vv
> 05:00.0 Serial controller: Oxford Semiconductor Ltd Device c120 (prog-if 02 
> [16550])
>          Subsystem: Oxford Semiconductor Ltd Device c120
>          Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>          Latency: 0
>          Interrupt: pin A routed to IRQ 16
>          Region 0: I/O ports at cf00 [size=8]
>          Capabilities: <access denied>
>          Kernel driver in use: serial
> 
> serial --port=0xfc00 --speed=9600 --word=8 --parity=n --stop=1
> terminal_output console serial
>

You have an OX16PCI95x .
The UART itself (16C950) is very well backwards-compatible with the 
16C550A, and is mapped to port IO, so that should be combatible by a 
standard driver.
I am somewhat surprised that the PCI device is auto-detected by the 
kernel - probably owing to the fact that the SBC vendor has kept the 
vanilla Oxford PCI ID's.

The question to me is, if Grub uses the IRQ. If it does, it may as 
well hang on that. If you need to know the "legacy" IRQ the board 
gets before Linux kernel boots, try booting Linux with the kernel 
cmdline option "noapic". The IRQ should be mapped (and probably 
shared) at some number below 16.
Another potential problem is, if this PCI IRQ will work with the same 
IRQ acking mechanism that the driver is written to apply to native 
ISA-mapped UART's.

If you're able to boot Linux, and just let the IRQ run via APIC i.e. 
IRQ16 level-triggered, which is perfectly allright in Linux, are you 
able to start minicom and try sending some characters back and forth?
Use the opportunity to make sure the wiring is correct, and also 
notice that you probably need to have the "flow control" configured 
correctly at both ends. I recommend to set this to "hardware" (via 
RTS+CTS signals, that need to be in the RS232 cable) or "none", in 
which case you do not need those two extra wires in the cable.
If you have a mismatch of "flow control", the outcome often means "no 
data". If "flow control" is not a configurable option to Grub, try 
both options in turns, in your terminal emulator software.

Generally, PCI-based UART's are less straightforward to get to work 
in DOS and suchlike, because they're not catered for by the BIOS 
services (ISAPnP if memory serves) that can otherwise tell you, 
apparently, the base addresses and IRQ's of individual serial ports 
known to the BIOS. Typically, those serial ports that do have support 
in the BIOS are nowadays implemented by an LPC SuperIO chip - the 
BIOS does have an intimate relationship with that onboard piece of 
chipset.

You've probably read this thread:
https://lists.gnu.org/archive/html/help-grub/2016-10/msg00012.html
In the end, mind the format he uses for the address.
In your case, this would be equal to:

serial --port=0x0fc00

I.e., there's an extra leading "hexa zero", after the 0x preamble.
Not sure if that matters.

Oh wait. I may have spotted something:

>          Region 0: I/O ports at cf00 [size=8]
> serial --port=0xfc00 

I.e. CF00 vs. FC00 - could that be the whole problem?
Or is it just a typo in your e-mail?

Frank