Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
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
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.ma...@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@coreboot.org
>
> https://mail.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
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
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
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 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)
Dear coreboot developers: My system is Baytrail FSP E3845 2 LPC SIO WINBOND_W83627DHG and FINTEK_F81803 (disabled at this moment) SERIRQ has been enabled. I have the following issue in the W83627DHG SIO: ttyS2 @ 0x3e8, irq 4 doesn't work. (changing IRQ 4 to 6 does not make any difference) ttyS3 @ 0x2e8, irq 3 works OK. I am not mixing PCI interrupts with PNP ones. irqroute.h * #define PIRQ_PIC_ROUTES \ PIRQ_PIC(A, 5), \ PIRQ_PIC(B, 6), \ PIRQ_PIC(C, 7), \ PIRQ_PIC(D, 10), \ PIRQ_PIC(E, 11), \ PIRQ_PIC(F, 12), \ PIRQ_PIC(G, 14), \ PIRQ_PIC(H, 15) * devicetree.cb * device pci 1f.0 on # 8086 0F1C - LPC bridge chip superio/winbond/w83627dhg device pnp 2e.0 off end # Floppy device pnp 2e.1 off end # Parallel Port device pnp 2e.2 on # Com1 io 0x60 = 0x3e8 irq 0x70 = 4 end device pnp 2e.3 on # Com2 io 0x60 = 0x2e8 irq 0x70 = 3 end device pnp 2e.5 off end # Keyboard device pnp 2e.6 off end # SPI * Mainboard Kconfig * select SOC_INTEL_FSP_BAYTRAIL select SUPERIO_WINBOND_W83627DHG ## select SUPERIO_FINTEK_F81803 select BOARD_ROMSIZE_KB_2048 select HAVE_ACPI_TABLES select HAVE_OPTION_TABLE select TSC_MONOTONIC_TIMER select HAVE_ACPI_RESUME select CONFIG_SERIRQ_CONTINUOUS_MODE * Serial port on SuperIO is disabled in menuconfig ---> Generic Drivers. Coreboot version is 4.8.1. FSP version is Baytrail MR5 superiotool is giving me consistent information about adresses and irqs on the winbond and fintek chips. (but fintek is disabled now) so it means the SOC is communicating correctly with the SIO chips. I still didn't added superio.asl to the winbond SIO because it crash in Windows 7 and 10 with ACPI error. Original AMI firmware works correctly on both SIO chips. There is something I still missing to do? (additional configuration, routing, files like dts?? etc...) Another issue is that no matter I disable SOC legacy COM1 and menuconfig always appear ttyS0 in Linux (A ghost that I am not able to disable yet). Somebody have experience on this issue? Anyone can give me guidance in debugging this? Please tell me if i need to provide you with more information. Thank you in advance, Jose Trujillo.-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
