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
_______________________________________________
SeaBIOS mailing list
[email protected]
http://www.seabios.org/mailman/listinfo/seabios
