Dear coreboot,
I am trying to finish the port for the Asus F2A85-M Pro (variant of Asus F2A85-M). After getting the serial console working [1], it can be seen, that accessing `DMA1_RESET_REG` in `isa_dma_init()` hangs the system [2].
outb(0, DMA1_RESET_REG);
Commenting this out, coreboot runs through and loads the payload. SeaBIOS has similar code, also hanging the system.
// first reset the DMA controllers outb(0, PORT_DMA1_MASTER_CLEAR);
I am at a loss. If you have an idea, how to fix it, I am all ears.
Kind regards,
Paul
[1]: https://review.coreboot.org/c/coreboot/+/39371/ [2]: https://review.coreboot.org/c/coreboot/+/39377/
Dear coreboot folks,
Am 02.10.20 um 00:50 schrieb Paul Menzel:
I am trying to finish the port for the Asus F2A85-M Pro (variant of Asus F2A85-M). After getting the serial console working [1], it can be seen, that accessing `DMA1_RESET_REG` in `isa_dma_init()` hangs the system [2].
outb(0, DMA1_RESET_REG);
Commenting this out, coreboot runs through and loads the payload. SeaBIOS has similar code, also hanging the system.
// first reset the DMA controllers outb(0, PORT_DMA1_MASTER_CLEAR);
I am at a loss. If you have an idea, how to fix it, I am all ears.
Please find the serial console log attached.
Kind regards,
Paul
Dear coreboot folks,
Am 02.10.20 um 10:34 schrieb Paul Menzel:
Am 02.10.20 um 00:50 schrieb Paul Menzel:
I am trying to finish the port for the Asus F2A85-M Pro (variant of Asus F2A85-M). After getting the serial console working [1], it can be seen, that accessing `DMA1_RESET_REG` in `isa_dma_init()` hangs the system [2].
outb(0, DMA1_RESET_REG);
Commenting this out, coreboot runs through and loads the payload. SeaBIOS has similar code, also hanging the system.
// first reset the DMA controllers outb(0, PORT_DMA1_MASTER_CLEAR);
I am at a loss. If you have an idea, how to fix it, I am all ears.
Please find the serial console log attached.
As the board booted in the past, I found regression note of Denis, the creator of the variant, in the board status repository [3], which was off by one commit.
ust a note, that this caused a regression [1]. Denis had already reported the regression in the board status repository, but was one commit off [2].
Commit 2f8192bc6b (asus/f2a85m_pro: Fix superio type in devicetree) fixed the devicetree, so that the NCT 6779D operations are now actually included, but, as that devicetree configuration was incorrect before, it now causes the hang.
Reverting this commit here on top of master and, to fix the build error about the now caught devicetree error, reverting commit b2a10f8264 (devicetree: Remove weak declarations for ops), Ifb783e2f733d5c65c615e5c1879e3e4c7a83e049 [3], gets rid of the hang.
I’ll try to figure out, what is wrong with the Super I/O settings in the devicetree. Removing the devicetree Super I/O configuration already gets rid of the hang, but causes other problems. Help is appreciated.
Kind regards,
Paul
[3]: https://review.coreboot.org/cgit/board-status.git/commit/asus/f2a85-m/4.10-9... [4]: https://review.coreboot.org/c/coreboot/+/35855 [5]: https://review.coreboot.org/c/coreboot/+/35086
Hi,
Dne 03. 10. 20 v 16:16 Paul Menzel napsal(a):
I’ll try to figure out, what is wrong with the Super I/O settings in the devicetree. Removing the devicetree Super I/O configuration already gets rid of the hang, but causes other problems. Help is appreciated.
Please can you check how the LPC decode registers are setup? The 14.3 device has some registers to setup what is going to be sent to LPC bus. There are bits for fixed legacy regions like COM1 etc, and then there are bigger 3? programmable ranges.
Maybe this is in conflict with legacy I/O which causes the hang.
I don't know the right file, maybe it is in
src/southbridge/amd/agesa/hudson/lpc.c see hudson_lpc_enable_childrens_resources() Maybe booting with debug verbosity would tell.
"hudson lpc decode:%s, base=0x%08x, end=0x%08x\n",
Thanks, Rudolf
Kind regards,
Paul
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Dear Rudolf,
Am 03.10.20 um 20:39 schrieb Rudolf Marek:
Dne 03. 10. 20 v 16:16 Paul Menzel napsal(a):
I’ll try to figure out, what is wrong with the Super I/O settings in the devicetree. Removing the devicetree Super I/O configuration already gets rid of the hang, but causes other problems. Help is appreciated.
Please can you check how the LPC decode registers are setup? The 14.3 device has some registers to setup what is going to be sent to LPC bus. There are bits for fixed legacy regions like COM1 etc, and then there are bigger 3? programmable ranges.
Maybe this is in conflict with legacy I/O which causes the hang.
I don't know the right file, maybe it is in
src/southbridge/amd/agesa/hudson/lpc.c see hudson_lpc_enable_childrens_resources() Maybe booting with debug verbosity would tell.
"hudson lpc decode:%s, base=0x%08x, end=0x%08x\n",
Thank you very much for your help and suggestions. It’s great to know, that you are still reading messages on the mailing list.
It turned out that, that removing `io 0x60 = 0x00` from the devicetree got rid of the hang.
device pnp 2e.8 on # WDT1, GPIO0, GPIO1 io 0x30 = 0x00 io 0x60 = 0x00 io 0x61 = 0x00
With the help of Michael, Nico, and Angel in #coreboot@irc.freenode.net, the problem was further debugged, and Nico explained the weird devicetree semantics (effects of enabling a device with `on`) and noticed that `io` was used mostly incorrectly, and that `irq` had to be used.
Nico was so kind, creating a patch series fixing these issues [7].
Now, only the PCI issues have to be fixed, so the network card is detected. But, if I should fail to fix it myself, I am going to start a new thread for these.
Kind regards,
Paul
[4]: https://review.coreboot.org/c/coreboot/+/35855 >> [5]: https://review.coreboot.org/c/coreboot/+/35086
[6]: https://review.coreboot.org/plugins/gitiles/coreboot/+/06639f2abf86bd0eef9c7... [7]: https://review.coreboot.org/c/coreboot/+/46021/ "mb/asus/f2a85-m_pro: Enable super-i/o LDNs 0x0f and 0x14"
-
Paul Menzel -
Rudolf Marek