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

[Rudolf Marek]

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

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

[Jose Trujillo]

Thank you Rudolf for your advise,

I checked the interrupts in Linux and showed me that the interrupts were already in EDGE mode but anyway I changed the interrupt mode in southcluster.c from quiet to edge.

The default PNP configuration for the Winbond SIO was crashing Windows 7 and 10 and then I created a very simple PNP configuration and now both Windows OS boots fine and recognized the UART ports correctly but only COM2 with IRQ3 works correctly.

Tomorrow I will keep testing to try to determine ​the reason but if any of you have any idea how to test or fix I will be glad to hear.

I wish all of you to have a nice day.

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

On June 6, 2018 11:46 PM, Rudolf Marek  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

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

[Jose Trujillo]

Dear Rudolf/All,

Today I tried several things to try to make COM1 to work unsuccessfully.

In my last test today I crossed the COM configuration from:

COM1 (not working)        COM2 (OK)
0x3f8, IRQ4                      0x2f8, IRQ3

to:

0x3f8, IRQ3                     0x2f8, IRQ4      (Both not working)

My conclusion (I coudl be wrong) on this is that both resources 0x3f8, IRQ4 (COM1) are being used by coreboot or FSP.

Anyone could give me a hint how to release those resources to be used by my LPC SIO chip.

Thank you.
J. Trujillo

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

On June 6, 2018 11:46 PM, Rudolf Marek  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

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

[Jose Trujillo]

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