[SeaBIOS] [Mohon Peak] Console output behavior before and after call to int19h

[Patrick Agrain]

Le 24/03/2015 14:56, Kevin O'Connor a écrit :
> 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.
Yes, of course.
> 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.
I was scared that somebody tells this ... ;-)
> (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.)
So, if I understand well, when performing a network boot (through iPXE, 
for example), the system will have knowledge of "high" memory, and 
therefore, access to the MEM mapped space will be possible ?
>   There is some additional info at:
>    http://seabios.org/Memory_Model
I'll take a look on it. Thanks for the pointer.

PS: Let's imagine that we configure this PCIe board on IO space, do you 
think that redirecting the console output will be then possible ?

Regards,
Patrick Agrain
>
> -Kevin