[OpenBIOS] PIC Passthough( VGA )

Jd Lyons lyons_dj at yahoo.com
Fri Dec 22 12:51:46 CET 2017



> On Dec 22, 2017, at 6:11 AM, Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk> wrote:
> 
> On 19/12/17 16:20, Jd Lyons wrote:
> 
>>> On Dec 19, 2017, at 10:56 AM, Segher Boessenkool <segher at kernel.crashing.org> wrote:
>>> 
>>> On Tue, Dec 19, 2017 at 10:40:08AM -0500, Jd Lyons wrote:
>>>> Looks like the spot were I’m stuck is:
>>>> 
>>>> b(;) ( 0x0c2 )
>>>> 25612: b(') ( 0x011 ) (unnamed-fcode) [0xc84]
>>>> 25613: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a9]
>>>> 25614: (unnamed-fcode) [0xe34]
>>>> 25615: (unnamed-fcode) [0xdff]
>>>> 25616: (unnamed-fcode) [0x93d]
>>>> 25617: b(lit) ( 0x010 ) 0xf
>>>> 25618: <> ( 0x03d )
>>>> 25619: b?branch ( 0x014 ) 0x0026 ( =dec 38)
>>>> 25620:     (unnamed-fcode) [0x9bd]
>>>> 25621:     b(lit) ( 0x010 ) 0xff
>>>> 25622:     and ( 0x023 )
>>>> 25623:     my-space ( 0x103 )
>>>> 25624:     + ( 0x01e )
>>>> 25625:     (unnamed-fcode) [0xa08]
>>>> 25626:     b(lit) ( 0x010 ) 0x6
>>>> 25627:     and ( 0x023 )
>>>> 25628:     b(lit) ( 0x010 ) 0x4
>>>> 25629:     = ( 0x03c )
>>>> 25630:     b?branch ( 0x014 ) 0x0009 ()
>>>> 25631:         b(') ( 0x011 ) (unnamed-fcode) [0x9c1]
>>>> 25632:         b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c0]
>>>> 25633:     b(>resolve) ( 0x0b2 )
>>>> 25634: b(>resolve) ( 0x0b2 )
>>>> 
>>>> It seems to break right here……………………………….
>>> 
>>> Those b?branch are in interpret mode, I don't know if that is handled
>>> correctly (it is tricky to get right).
>>> 
>> So, is it hanging at b(>resolve) ( 0x0b2 ) or (unnamed-fcode) [0xddf] ?
>> Do we need to work on how Openbios handles  b?branch?
> 
> Are you sure that b?branch is the culprit here? A b?branch...b(>resolve) is a representation of a if() { ... } block which means as soon as you hit the b(>resolve) then you execute the contents of the buffer generated between b?branch and b(>resolve) if you match the condition.
> 
> Now the Solaris/SPARC boot blocks do some really crazy stuff in Forth which to the best of my knowledge flushed out all the FCode branch bugs - not that there couldn't be a bug remaining, but it's much more likely that something in the b?branch...b(>resolve) is throwing an exception.
> 

The changes I made to Openbios b?(branch) and later b(>resolve) resulted in system hangs in the Fcode, before the offset I was getting to before. So it’s really tricky, I know the nVida Rom reads some resisters on the card and reads an and/or mask at 0x58 in the Rom, then calculates some stuff for the NVDA,BMP. I’m not sure I’m even getting to that point it the code. Just from running the debug word on b?branch and b(>resolve) that are quite a few calls to it in the Rom before I hit the exception point, and Openbios seems to handle those fine, until “us” is called, then things seem to fall apart.

b(>resolve) seems to be really tricky, as changes I made there resulted in no input or output devices unless booted with -noghrphic, and trying to boot the Mac OS resulted in an out of bounds Rom/Ram exception.

I’m thinking it maybe a timebase issue, and that code in both Openbios and Qemu-PPC seems to need a little work anyway. If we can come up with some better methods of calculation : ms and : us that may help the issue, or may not, but we’ll likely end up with a little better emulator, so that’s the fun part.

 


> 
> ATB,
> 
> Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/openbios/attachments/20171222/536d8687/attachment.html>


More information about the OpenBIOS mailing list