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

Jose Trujillo ce.autom at protonmail.com
Fri Jun 15 17:30:43 CEST 2018

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).

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

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

More information about the coreboot mailing list