On Dec 18, 2017, at 12:20 AM, Tarl Neustaedter
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@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
: 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
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 )
Free your System - May the Forth be with you