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 <[email protected]> 于2021年11月8日周一 下午7:31写道： > Add gpio.c from > https://u8209486.ct.sendgrid.net/ls/click?upn=5-2BjrOL6Sde2a9aQLMiEgaLzceDV6ek3hr5PekV6loyqk65QWgl6iFUXTzf0xmiYdaz1dP39rwh5BPgTpUyb-2Bsg-3D-3DxXBW_L-2FDzr14mnrsJO5b1wX1hp9b1MAQygl7x-2B74RAaH2cn2wBxw68JrPs9IxSJmJXQAva-2BUY65aZPvVauIf67M-2FgY9v12g9aQMGCk5eA9Kfw56r9XM2u-2FaXeM-2BCATfg8F03n6hRRS2ALwig078oKTn98eD3mF3Nc4exuyMJHuj8HL7ofdtZVNmKCRPZMP4f4iftjmAtZ5uqmqkFdpVYLpOPb8A-3D-3D > solve the problem. > SMbus also works. > > > On Mon, 08 Nov 2021 08:54:39 +0000 (UTC) > Zhiwen Zheng <[email protected]> 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 <[email protected]> wrote: > > > > > > https://u8209486.ct.sendgrid.net/ls/click?upn=5-2BjrOL6Sde2a9aQLMiEgaNTszOAtW4XhTn6W2SA205kvAu3ZGQzvptG1uDSnI8JF7kkyk2JqFP7dBXWpdpeHv9Yv-2Fvss-2FV2wjt8sgJcQOIRkU0sHSj-2FWobKz5LhWN4ga49r7nWEe-2FvDvFIiuR4qVBf8HfzR11G-2BtZUn0u3kqyGWm4TfcRW9S7sGaAG69IJDqo3EBcC80PXmq6K-2Bph6bMX780-2B18A1TkGpLJwNSXYKHcE8-2BfSsFMU0HhvOuAC1zDktawL3GzsuPoXKWM-2FOO2SIdUTU58yYVXPmgTv-2BR9fR4WOBGFVLDlTaxGZZcnOlXYyai5ctsO8XNSyLlCi2nDOqnNyZglcwgz7x1aCj1iDSzmwFM36PJ-2BK96mWStSy27LqhQYJVTJeDLpjCzyPwrKO-2FonlRHrBOKXg0IqBkNb59fPdYBlsq-2FbPrYTbOeR1mYj9DqMb8xLZ8Uyf3kXr9s5XY-2BFN0lVlvZr1k1t-2F-2FZybX0UIxYiJ3UA3SkAzKKCkgD6UpwvBFXrbYS0m-2B-2Bb-2BQKZuL9wHKC7NC6p2ojmkVh4cRts-3DcgJN_L-2FDzr14mnrsJO5b1wX1hp9b1MAQygl7x-2B74RAaH2cn2wBxw68JrPs9IxSJmJXQAvCYx6XXmU-2FGiLdxAtU9IExnHLs-2FVK4Y7Al7Jsuft6zvEeA59g-2Fe7YNYwPZpihMxhi87O-2F0wsxDfYcmxFQqag-2BZwwqZQBQW1LkKW17E6-2B-2FDzENuZdz15TTGE5sZ2z9y3CtZm7vT7NDMScTSUSkWRTueg-3D-3D > > > 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 <[email protected]> 于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 -- [email protected] > > > > To unsubscribe send an email to [email protected] > > > > > > _______________________________________________ > > coreboot mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > _______________________________________________ > coreboot mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
