On Tue, Mar 24, 2015 at 10:04:40AM +0100, Patrick Agrain wrote:
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 ?
I assume the mem mapped uart is mapped to memory above the first 1 megabyte. When SeaBIOS starts booting, it places the system in 16bit mode - and in 16bit mode any access to "high" memory would cause a system fault. (In contrast, when running option roms SeaBIOS places the system in "big real" mode which is similar to 16bit mode but does have access to "high" memory.) There is some additional info at: http://seabios.org/Memory_Model
-Kevin