[coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)

[Jose Trujillo]

Dear coreboot developers:

The problems with SIO devices were resolved:
I will give you a brief explanation of what I did after my previous mail just for the record, thinking this might be useful for someone else in the future.

The problem was that ttyS0 from W83627DHG was not working properly (details on previous mail).

I did the following:
1.- Did some fixes on my superio.asl that I use.             (Did not fixed my  problem)
2.- Remove IRQs 3 and 4 from irqlinks.asl devices.       (Did not fixed my  problem)

After this I gave up on this issue and decided to add my second SIO on 0x4e FINTEK_F81803 that I modified based on F81866D.

3.- Added FINTEK_F81803 on 0x4e and compiled it.    (Those ports didn't even appear in the OS and I didn't know why)

I ran superiotool to check the state of the registers and discovered that the Fintek SIO had the default values.

4.- Checked the code in devicetree, and superio.c of both SIO devices but everything looked fine.
5.- In terminal I entered into "make menuconfig" and without making any change to the configuration I selected "Save" then enter, exit, exit and recompiled again and flashed and Voila! Fintek UART ports worked fine and ttyS0 from Winbond is just working fine too.

I just need to do some  fine tuning on the UART ports and configure correctly HWMon and Fan control in Fintek.

Thank you All,
J. Trujillo

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On June 15, 2018 6:30 PM, Jose Trujillo via coreboot <coreboot at coreboot.org> wrote:

> Dear All,
> 
> After following the recommendations from Rudolf and other people on this mail list I was able to make the following to make my LPC SIO to work (with issues).
> 
> 1.- Enable SERIRQ in CONTINUOUS_MODE
> 
> 2.- Add SUPERIO_WINBOND_W83627DHG driver to the Konfig file.
> 
> 3.- Add the SIO parametrization in devicetree with 0x3f8,4 and 0x2f8,3 for UARTS.
> 
> 4.- Add the PNP-ACPI information for SIO.
> 
> 5.- Change SOC's 8259 trigger to EDGE.
> 
> 6.- Disable internal (SOC) COM1 with the following code in romstage:
> 
> void late_mainboard_romstage_entry()
> 
> {
> 
> /* Disable the internal COM1 */
> 
> pci_write_config32(PCI_DEV(0, LPC_DEV, 0), UART_CONT, 0);
> 
> u32 *irqen = (u32 )(ILB_BASE_ADDRESS + 0x88);write32(irqen, 0); / Unbind IRQ4 */
> 
> }
> 
> 7.- Release IRQ4 from the PIRQ_PIC_ROUTES in irqroute.h and set IRQ6 instead.
> 
> After all this:
> 
> COM2 (0x2f8,3) works fine
> 
> But:
> 
> I still have an issue:
> 
> COM1 (0x3f8,4) can transmit data correctly but at receiving the port hangs and not showing received string.
> 
> When I make DMESG in terminal i get:
> 
> "do_IRQ: 2.39 No irq handler for vector"
> 
> "serial8250: too much work for irq4"
> 
> What could be wrong?
> 
> What could be missing?
> 
> Let me know if you require more info,
> 
> Any advise on the issue will be highly appreciated,
> 
> Thank you,
> 
> J. Trujillo
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> On June 6, 2018 11:46 PM, Rudolf Marek r.marek at assembler.cz wrote:
> 
> > Hi,
> > 
> > In general I would check ELCR (I/O port register 0x4d0) to check if it is correctly programmed to EDGE/LEVEL (it should be edge)
> > 
> > Also, how the Linux is supposed to detect the I/O port irq? I think you need some PNP device in ACPI to let linux infer the IRQ.
> > 
> > I would also try to disable the IRQ from SoC, you just need to check how they are enabled (sorry not an expert here)
> > 
> > and also I would use the legacy 0x3f8 instead.
> > 
> > Thanks
> > 
> > Rudolf
> 
> --
> 
> coreboot mailing list: coreboot at coreboot.org
> 
> https://mail.coreboot.org/mailman/listinfo/coreboot