
I add the following code to sc_init() in southcluster.c to enable SERIRQ, and it works as expected when doing cold boot. With SERIRQ enabled, the uart in superio can function correctly, and I can login into the linux serial console. But after a reboot initiated from linux cmdline, the linux boot hang in getty serial(same as without SERIRQ enabled), only a power cycle can resolve the issue. I take the following code from coreboot-4.11 fsp-baytrail. I also tried the check_for_warm_reset() in bootblock.c to hardreset the machine, but the check condition in that procedure doesn't catch this situation, linux reset by default use keyboard controller seemingly. u32 *oic = (u32 *)(ILB_BASE_ADDRESS + 0x60); u8 *serirq_cntl = (u8 *)(ILB_BASE_ADDRESS + 0x10); /* Enable SERIRQ */ write32(oic, (read32(oic) | (1 << 12))); /* Enable continuous mode */ write8(serirq_cntl, (1 << 7));

https://review.coreboot.org/c/coreboot/+/29398 Have similar implementation on braswell, so as long as sc_init get executed in ramstage the serial irq mode programming shall be working. Zhiwen Zheng <zhiwen@40701.xyz> 于2021年11月6日周六 下午6:29写道:
I add the following code to sc_init() in southcluster.c to enable SERIRQ, and it works as expected when doing cold boot. With SERIRQ enabled, the uart in superio can function correctly, and I can login into the linux serial console. But after a reboot initiated from linux cmdline, the linux boot hang in getty serial(same as without SERIRQ enabled), only a power cycle can resolve the issue. I take the following code from coreboot-4.11 fsp-baytrail. I also tried the check_for_warm_reset() in bootblock.c to hardreset the machine, but the check condition in that procedure doesn't catch this situation, linux reset by default use keyboard controller seemingly.
u32 *oic = (u32 *)(ILB_BASE_ADDRESS + 0x60); u8 *serirq_cntl = (u8 *)(ILB_BASE_ADDRESS + 0x10);
/* Enable SERIRQ */ write32(oic, (read32(oic) | (1 << 12))); /* Enable continuous mode */ write8(serirq_cntl, (1 << 7)); _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org

Since the hang happens in Linux, can you in some way get Linux kernel log to understand the cause like soft lockup or panic message. Also are you saying irrespective of serirq enable/disable, hang is seen? UART works properly in coreboot stages? On Mon, 8 Nov, 2021, 1:02 pm Lance Zhao, <lance.zhao@gmail.com> wrote:
https://review.coreboot.org/c/coreboot/+/29398 Have similar implementation on braswell, so as long as sc_init get executed in ramstage the serial irq mode programming shall be working.
Zhiwen Zheng <zhiwen@40701.xyz> 于2021年11月6日周六 下午6:29写道:
I add the following code to sc_init() in southcluster.c to enable SERIRQ, and it works as expected when doing cold boot. With SERIRQ enabled, the uart in superio can function correctly, and I can login into the linux serial console. But after a reboot initiated from linux cmdline, the linux boot hang in getty serial(same as without SERIRQ enabled), only a power cycle can resolve the issue. I take the following code from coreboot-4.11 fsp-baytrail. I also tried the check_for_warm_reset() in bootblock.c to hardreset the machine, but the check condition in that procedure doesn't catch this situation, linux reset by default use keyboard controller seemingly.
u32 *oic = (u32 *)(ILB_BASE_ADDRESS + 0x60); u8 *serirq_cntl = (u8 *)(ILB_BASE_ADDRESS + 0x10);
/* Enable SERIRQ */ write32(oic, (read32(oic) | (1 << 12))); /* Enable continuous mode */ write8(serirq_cntl, (1 << 7)); _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org

I just looked at the patch, it does not reenable continuous mode in ramstage. So what I do is basically the same with that patch, but that doesn't work after a warm reset for me. I am wondering whether the gpio configuration of the soc is related to this issue, I don't have access to the BWG doc, can anybody send me a copy? SMbus also doesn't working, don't know if it is related to the gpio setting. On Mon, 8 Nov 2021 15:31:34 +0800 Lance Zhao <lance.zhao@gmail.com> wrote:
https://u8209486.ct.sendgrid.net/ls/click?upn=5-2BjrOL6Sde2a9aQLMiEgaLzceDV6... Have similar implementation on braswell, so as long as sc_init get executed in ramstage the serial irq mode programming shall be working.
Zhiwen Zheng <zhiwen@40701.xyz> 于2021年11月6日周六 下午6:29写道:
I add the following code to sc_init() in southcluster.c to enable SERIRQ, and it works as expected when doing cold boot. With SERIRQ enabled, the uart in superio can function correctly, and I can login into the linux serial console. But after a reboot initiated from linux cmdline, the linux boot hang in getty serial(same as without SERIRQ enabled), only a power cycle can resolve the issue. I take the following code from coreboot-4.11 fsp-baytrail. I also tried the check_for_warm_reset() in bootblock.c to hardreset the machine, but the check condition in that procedure doesn't catch this situation, linux reset by default use keyboard controller seemingly.
u32 *oic = (u32 *)(ILB_BASE_ADDRESS + 0x60); u8 *serirq_cntl = (u8 *)(ILB_BASE_ADDRESS + 0x10);
/* Enable SERIRQ */ write32(oic, (read32(oic) | (1 << 12))); /* Enable continuous mode */ write8(serirq_cntl, (1 << 7)); _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org

On Mon, 8 Nov 2021 13:18:07 +0530 "Naresh G. Solanki" <naresh.solanki.2011@gmail.com> wrote:
Since the hang happens in Linux, can you in some way get Linux kernel log to understand the cause like soft lockup or panic message.
No.
Also are you saying irrespective of serirq enable/disable, hang is seen?
UART works properly in coreboot stages?
Everyting works in cold boot or after a power cycle. UART tx does not need irq, codeboot doesn't read uart, so it works. Seabios and syslinux do polls, so they can work.
On Mon, 8 Nov, 2021, 1:02 pm Lance Zhao, <lance.zhao@gmail.com> wrote:
https://u8209486.ct.sendgrid.net/ls/click?upn=5-2BjrOL6Sde2a9aQLMiEgaLzceDV6... Have similar implementation on braswell, so as long as sc_init get executed in ramstage the serial irq mode programming shall be working.
Zhiwen Zheng <zhiwen@40701.xyz> 于2021年11月6日周六 下午6:29写道:
I add the following code to sc_init() in southcluster.c to enable SERIRQ, and it works as expected when doing cold boot. With SERIRQ enabled, the uart in superio can function correctly, and I can login into the linux serial console. But after a reboot initiated from linux cmdline, the linux boot hang in getty serial(same as without SERIRQ enabled), only a power cycle can resolve the issue. I take the following code from coreboot-4.11 fsp-baytrail. I also tried the check_for_warm_reset() in bootblock.c to hardreset the machine, but the check condition in that procedure doesn't catch this situation, linux reset by default use keyboard controller seemingly.
u32 *oic = (u32 *)(ILB_BASE_ADDRESS + 0x60); u8 *serirq_cntl = (u8 *)(ILB_BASE_ADDRESS + 0x10);
/* Enable SERIRQ */ write32(oic, (read32(oic) | (1 << 12))); /* Enable continuous mode */ write8(serirq_cntl, (1 << 7)); _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org

Add gpio.c from https://u8209486.ct.sendgrid.net/ls/click?upn=5-2BjrOL6Sde2a9aQLMiEgaLzceDV6... solve the problem. SMbus also works. On Mon, 08 Nov 2021 08:54:39 +0000 (UTC) Zhiwen Zheng <zhiwen@40701.xyz> wrote:
I just looked at the patch, it does not reenable continuous mode in ramstage. So what I do is basically the same with that patch, but that doesn't work after a warm reset for me.
I am wondering whether the gpio configuration of the soc is related to this issue, I don't have access to the BWG doc, can anybody send me a copy?
SMbus also doesn't working, don't know if it is related to the gpio setting.
On Mon, 8 Nov 2021 15:31:34 +0800 Lance Zhao <lance.zhao@gmail.com> wrote:
https://u8209486.ct.sendgrid.net/ls/click?upn=5-2BjrOL6Sde2a9aQLMiEgaNTszOAt... Have similar implementation on braswell, so as long as sc_init get executed in ramstage the serial irq mode programming shall be working.
Zhiwen Zheng <zhiwen@40701.xyz> 于2021年11月6日周六 下午6:29写道:
I add the following code to sc_init() in southcluster.c to enable SERIRQ, and it works as expected when doing cold boot. With SERIRQ enabled, the uart in superio can function correctly, and I can login into the linux serial console. But after a reboot initiated from linux cmdline, the linux boot hang in getty serial(same as without SERIRQ enabled), only a power cycle can resolve the issue. I take the following code from coreboot-4.11 fsp-baytrail. I also tried the check_for_warm_reset() in bootblock.c to hardreset the machine, but the check condition in that procedure doesn't catch this situation, linux reset by default use keyboard controller seemingly.
u32 *oic = (u32 *)(ILB_BASE_ADDRESS + 0x60); u8 *serirq_cntl = (u8 *)(ILB_BASE_ADDRESS + 0x10);
/* Enable SERIRQ */ write32(oic, (read32(oic) | (1 << 12))); /* Enable continuous mode */ write8(serirq_cntl, (1 << 7)); _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org

Thanks for let us know the result. But the explanation will be the warm reboot path will modify the GPIO setting? Or the GPIO setting is floating at the moment? Lance Zhiwen Zheng <zhiwen@40701.xyz> 于2021年11月8日周一 下午7:31写道:
Add gpio.c from https://u8209486.ct.sendgrid.net/ls/click?upn=5-2BjrOL6Sde2a9aQLMiEgaLzceDV6... solve the problem. SMbus also works.
On Mon, 08 Nov 2021 08:54:39 +0000 (UTC) Zhiwen Zheng <zhiwen@40701.xyz> wrote:
I just looked at the patch, it does not reenable continuous mode in ramstage. So what I do is basically the same with that patch, but that doesn't work after a warm reset for me.
I am wondering whether the gpio configuration of the soc is related to this issue, I don't have access to the BWG doc, can anybody send me a copy?
SMbus also doesn't working, don't know if it is related to the gpio setting.
On Mon, 8 Nov 2021 15:31:34 +0800 Lance Zhao <lance.zhao@gmail.com> wrote:
https://u8209486.ct.sendgrid.net/ls/click?upn=5-2BjrOL6Sde2a9aQLMiEgaNTszOAt...
Have similar implementation on braswell, so as long as sc_init get executed in ramstage the serial irq mode programming shall be working.
Zhiwen Zheng <zhiwen@40701.xyz> 于2021年11月6日周六 下午6:29写道:
I add the following code to sc_init() in southcluster.c to enable SERIRQ, and it works as expected when doing cold boot. With SERIRQ enabled, the uart in superio can function correctly, and I can login into the linux serial console. But after a reboot initiated from linux cmdline, the linux boot hang in getty serial(same as without SERIRQ enabled), only a power cycle can resolve the issue. I take the following code from coreboot-4.11 fsp-baytrail. I also tried the check_for_warm_reset() in bootblock.c to hardreset the machine, but the check condition in that procedure doesn't catch this situation, linux reset by default use keyboard controller seemingly.
u32 *oic = (u32 *)(ILB_BASE_ADDRESS + 0x60); u8 *serirq_cntl = (u8 *)(ILB_BASE_ADDRESS + 0x10);
/* Enable SERIRQ */ write32(oic, (read32(oic) | (1 << 12))); /* Enable continuous mode */ write8(serirq_cntl, (1 << 7)); _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
participants (3)
-
Lance Zhao
-
Naresh G. Solanki
-
Zhiwen Zheng