[OpenBIOS] PIC Passthough( VGA )
lyons_dj at yahoo.com
Mon Dec 18 07:01:27 CET 2017
> 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
>> 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
\ 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?
r> exit else
." Base address not assigned!" cr
0 0 r> ( 0 0 phys.hi )
( 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 )
\ 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...
More information about the OpenBIOS