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

[Patrick Agrain]

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

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

[Kevin O'Connor]

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

[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