Re: [OpenBIOS] PIC Passthough( VGA )

[Jd Lyons]

> On Dec 17, 2017, at 11:42 PM, Tarl Neustaedter  wrote:
>
> On 2017-Dec-17 23:39 , Jd Lyons wrote:
> > It has the open and close words, really two open words now, because we added one.
> >
> > I’ll rebuild Openbios and edit out the:
> >
> > feval("['] vga-driver-fcode 2 cells + 1 byte-load”);
> >
> > That should keep the Fcode for VGA devices from loading…..
>
> If all it has are the open and close, leave it alone.  The newer open
> and close are supposed to replace the earlier ones (it may complain, but
> you can live with that for the moment). You need the open in there so
> that the open-dev works. Try the load/byte-load sequence inside that
> node and see what happens.

Still bombing out at the same place:

C>> annot manage 'VGA controller' PCI device type 'display':
> > 10de 141 (3 0 0)
> > =============================================================
> > OpenBIOS 1.1 [Dec 18 2017 04:42]
> > Configuration device id QEMU version 1 machine id 1
> > CPUs: 1
> > Memory: 1536M
> > UUID: 00000000-0000-0000-0000-000000000000
> > CPU type PowerPC,G4

milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Dec 18 2017 04:42

0 > dev /pci  ok
0 > dev @10  ok
0 > words close open 
 ok
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!
 ok
1 > ls 
 ok
1 > dev /pci ls 
fff8042c mac-io@c
fff8336c usb@d
fff836d8 QEMU,VGA@e
fff83a8c NE2000@f
fff83e3c pci10de,141@10
 ok
1 > dev /pci/@10 .properties 
name                      "pci10de,141"
vendor-id                 10de 
device-id                 141 
revision-id               a2 
class-code                30000 
interrupts                1 
min-grant                 0 
max-latency               0 
devsel-speed              0 
subsystem-vendor-id       10de 
subsystem-id              50 
cache-line-size           10 
assigned-addresses        -- 3c : 02 00 80 10 00 00 00 00 83 00 00 00 00 00 00 00 01 00 00 00 c3 00 80 14 00 00 00 00 90 00 00 00 00 00 00 00 10 00 00 00 83 00 80 1c 00 00 00 00 a0 00 00 00 00 00 00 00 01 00 00 00 
reg                       00008000 00000000 00000000   00000000 00000000
                          02008010 00000000 00000000   00000000 01000000
                          c3008014 00000000 00000000   00000000 10000000
                          8300801c 00000000 00000000   00000000 01000000
 ok
1 > setenv fcode-debug? true  ok
1 > true to ?fcode-verbose  ok
1 > dev /pci/@10 words close open close open 
 ok
1 >

4010009 : (compile) b(endof) [ 0xc6 ]
       (offset) 5 
401000d : (compile)  [ 0xe05 ]
401000e : (compile) b(endcase) [ 0xc5 ]
401000f : (compile) over [ 0x48 ]
4010010 : (compile) b(to) [ 0xc3 ]
4010014 : (compile)  [ 0xe36 ]
4010016 : (compile) encode+ [ 0x112 ]
4010017 : (compile) 2dup [ 0x53 ]
4010018 : (compile) b(to) [ 0xc3 ]
401001b : (compile) b(to) [ 0xc3 ]
401001f : (compile)  [ 0xc7b ]
4010021 : (compile) property [ 0x110 ]
4010022 : (compile) b(;) [ 0xc2 ]
4010023 : b(') [ 0x11 ]
4010026 : b(to) [ 0xc3 ]
401002a :  [ 0xe34 ]

byte-load: exception caught!
 ok
1 >

PIC Passthough( VGA )

[Tarl Neustaedter]

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@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.

PIC Passthough( VGA )

[Jd Lyons]

> On Dec 18, 2017, at 12:20 AM, Tarl Neustaedter  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@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 )
>

PIC Passthough( VGA )

[Segher Boessenkool]

On Mon, Dec 18, 2017 at 12:05:17AM -0500, Jd Lyons wrote:
> Still bombing out at the same place:
> 401002a :  [ 0xe34 ]
>
> byte-load: exception caught!

: xe33  $find invert IF ABORT THEN ;
: xe34
    " us" xe33 TO x9a7
    " case-closed?" $find invert IF 2drop ['] 0 THEN
    TO x9a8 ;

So the thing that throws is fcode e33, when trying to find the word "us".

(Btw, "invert" is weird here; I suppose it was coded as its synonym "not".
In some other Forth systems "not" is a synonym for "0=", which makes more
sense here.  Either works as long as $find returns a canonical true/false,
as it supposed to).

So, implement "us", and you'll get further :-)  It's just like "ms", but
microseconds, instead; so you could do

: us ( n -- )  d# 1000 / 1+ ms ;

(which waits way too long for short timeouts, of course).

Segher

PIC Passthough( VGA )

[Jd Lyons]

> On Dec 18, 2017, at 12:48 AM, Segher Boessenkool  wrote:
>
> On Mon, Dec 18, 2017 at 12:05:17AM -0500, Jd Lyons wrote:
> > Still bombing out at the same place:
> > 401002a :  [ 0xe34 ]
> >
> > byte-load: exception caught!
>
> : xe33  $find invert IF ABORT THEN ;
> : xe34
>    " us" xe33 TO x9a7
>    " case-closed?" $find invert IF 2drop ['] 0 THEN
>    TO x9a8 ;
>
> So the thing that throws is fcode e33, when trying to find the word "us".
>
> (Btw, "invert" is weird here; I suppose it was coded as its synonym "not".
> In some other Forth systems "not" is a synonym for "0=", which makes more
> sense here.  Either works as long as $find returns a canonical true/false,
> as it supposed to).
>
> So, implement "us", and you'll get further :-)  It's just like "ms", but
> microseconds, instead; so you could do
>
> : us ( n -- )  d# 1000 / 1+ ms ;
>
> (which waits way too long for short timeouts, of course).

Ok, thanks, that makes since. I did see the “case-closed?” When I searched for 0xe34 in the detoked rom, but I wan’t sure what to make of it.

So, the “us” word is unimplemented in Openbios, and we need to add it to get past this part?
> Segher