[OpenBIOS] PIC Passthough( VGA )

[Jd Lyons]

> On Dec 18, 2017, at 12:20 AM, Tarl Neustaedter <tarl-b2 at tarl.net> wrote:
> 
> On 2017-Dec-18 00:05 , Jd Lyons wrote:
> [...]
>> 0 > dev /pci  ok
>> 0 > dev @10  ok
>> 0 > words close open 
>> ok
>> 0 > " /pci/pci10de,141 at 10" open-dev  ok
>> 1 > load hd:,\ppc\6600.fcode  ok
>> 1 > 4000040 1 byte-load open isn't unique.
>> close isn't unique.
>> 
>> byte-load: exception caught!
> 
> Well, the good news is that you're getting far enough into the fcode
> that it is clearly creating the open and close words (the complaint that
> they aren't unique means something is overwriting them).
> 
> So we know it's happy with what it's been able to read from the card and
> it's been creating properties.
> 
> Unfortunately, now it's going to be a matter of trying to debug the
> nvidia fcode to figure out what's blowing up. All we know is that
> byte-load is getting an exception, and that almost certainly means the
> FCode did something to cause a throw.
> 
> 

I maybe off base here, just taking a shot in the dark, the place where it catching the exception seems to point to 0xe34, that pretty close to the map-in function in the Rom. Just after the assigned address function.

Old World Mac’s had a bug in the map-in function, and both nVidia/ATI FCode Option Roms include a workaround for it.

So, and I’m just guessing here, it maybe the map-in workaround that we’re tripping over?

13. Example of use of add-ranges check

\ Flag is true if the parent's map-in method doesn't work with \ relocatable addresses.

: map-in-broken? ( -- flag )
\ Look for the method that is present when the bug is present

;

;

" add-range" my-parent ihandle>phandle find-method dup if nip then

( adr len phandle )
( flag ) \ Discard xt if present

\ Return phys.lo and phys.mid of the address assigned to the PCI base address \ register indicated by phys.hi .

: get-base-address ( phys.hi -- phys.lo phys.mid phys.hi )

" assigned-addresses" get-my-property if ." No address property found!" cr
0 0 rot exit

then

rot>r
\ Found assigned-addresses, get address
begin dup while ( adr len' ) \ Loop over entries

decode-phys ( adr len' phys.lo phys.mid phys.hi )
h# ff and r@ h# ff and = if ( adr len' phys.lo phys.mid ) \ This one?

2swap 2drop

r> exit else

repeat
2drop ()

." Base address not assigned!" cr
0 0 r> ( 0 0 phys.hi )

2drop then

( phys.lo phys.mid ) \ This is the one ( phys.lo phys.mid phys.hi )
( adr len' phys.lo phys.mid ) \ Not this one (adrlen')

(adrlen') decode-int drop decode-int drop

\ Discard boring fields

\ Error exit ( phys.hi adr len )

(adrlen) (r:phys.hi)

\ Example code to compute the phys.lo..hi arguments for "map-in", using the \ above functions so that the code works both on systems that implement
\ map-in according to the PCI binding document, and also on systems whose \ PCI map-in method requires phys.lo,phys.mid to contain the assigned base \ address.

\ Compute entire phys.lo..hi address for base address register 10 map-in-broken? if

my-space h# 8200.0010 + get-base-address else

0 0 my-space h# 200.0010 + then

( phys.lo,mid,hi )

( phys.lo,mid,hi ) ( phys.lo,mid,hi )

\ An FCode driver that need not work on systems with the map-in bug could \ use the following code, omitting the definitions of "map-in-broken?"
\ and "get-base-address".
\

\ 0 0 my-space h# 200.0010 +

( phys.lo,mid,hi ) 

> -- 
> OpenBIOS                 http://openbios.org/
> Mailinglist:  http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/openbios/attachments/20171218/3766dfb9/attachment.html>