Hello,
Purpose: Get the output sent through int10h on an external serial link mapped on MEM space (PCIe board with OxPCIe952 from Startech).
Hardware: Mohon Peak CRB with coreboot. PCIe board with OxPCIe952 from Startech. Bootable hard disk with GRUB and Linux.
Code flow: (from my understanding) <...> ./src/post.c: mainint() |--> interactive_bootmenu() | |--> "Press ESC for boot menu." (sent through INT10h calls) | |--> startBoot() |--> "Jump to int19" |--> Call INT19h
<INT19h handler> ./src/boot.c: do_boot() |--> "Booting from Hard Disk..." (sent through INT10h calls) |--> boot_disk() |--> Call INT13h <...>
What works: Modified seabios to initialize PCIe board OxPCIe952. - Add field at the end of BDA to store the u32 base address of the additional UART ports. - Init the bridge after pci_probe(). - Store the base address of the additional UART ports during serial_setup(). Using sgabios with output set to 0x2f8 (uart1) works flawlessly. - All (dprintf-based) messages are sent on second UART port of the Mohon Peak. - All (printf-based, INT10h) messages are also displayed on second UART port of the Mohon Peak. - System boots.
What almost works: Modified sgabios to display INT10h calls on MEM mapped UART port. - All (dprintf-based) messages are still sent on second UART port of the Mohon Peak. - Display of "Press ESC for boot menu." on OxPCIe952 : OK (any previous INT10h-based messages also displayed on OxPCIe952). - After call of INT19h, "Booting from Hard Disk..." is not displayed on OxPCIe952. - Mohon Peak remains in POST code F8h (like as for waiting a selection in the GRUB menu).
Note: reducing debug level (20 -> 2) of int10h shows that the int10h-handler is called with the messages to be displayed, but nothing appears on OxPCIe952 side.
What could be the reason of this behavior ? Any switch between 16-bit and 32-bit code execution ?
Any suggestion is welcome. Regards, Patrick Agrain