On Dec 29, 2017, at 12:14 AM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2017-Dec-29 00:00 , Jd Lyons wrote:
Segher, do you think I maybe tripping over the “ config-l@“?
Seems to be a few words called next, after the b(>resolve) I’m catching the exception on.
config-l@ config-l! config-w@ config-w!
Those are words to read and write config space on pci cards. I'm pretty sure the words work (otherwise the vendor-id and product-id values wouldn't have been able to be fetched), the question is whether they are being called with unexpected values. The config-l@ must be called with a mod 4 values, the config-w@ must be called with a mod 2 value.
The usual mode of accessing config space is adding your desired offset to my-space, and then call config-l@. That looks to be what you are in the middle of:
8010039 : (compile) [ 0x9bd ] 801003a : (compile) b(lit) [ 0x10 ] 801003f : (compile) and [ 0x23 ] 8010041 : (compile) my-space [ 0x103 ] 8010042 : (compile) + [ 0x1e ] 8010044 : (compile) [ 0xa08 ] <<<<<<< is this config-l@? 8010045 : (compile) b(lit) [ 0x10 ] 801004a : (compile) and [ 0x23 ] 801004b : (compile) b(lit) [ 0x10 ] 8010050 : (compile) = [ 0x3c ]
The above looks to me like he's testing for the presence of 0x10 in a register (0x10 and 0x10 =). If he's looking at a series of BARs, that's the prefetchable bit he's looking for.
Do you think it’s having trouble reading the PCI Configuration registers, it was able to change the subsystem-id from 0x50 to 0x10, so I was hoping it had calculated the base address of the PCI card correctly.
I’m really at a loss, never had to dive this deep into forth when hacking these Rom’s for card flashing. It seemed to me that:
b(>resolve) ( 0x0b2 ) (unnamed-fcode) [0xddf]<————This calls the offset? 0xddf
new-token ( 0x0b5 ) 0xddf b(:) ( 0x0b7 ) b(lit) ( 0x010 ) 0x10 (unnamed-fcode) [0xdde] <——This calls the offset? 0xdde
new-token ( 0x0b5 ) 0xdde b(:) ( 0x0b7 ) my-space ( 0x103 ) + ( 0x01e ) dup ( 0x047 ) (unnamed-fcode) [0xa08]<—— this calls 0xa08
new-token ( 0x0b5 ) 0xa08 b(:) ( 0x0b7 ) b(") ( 0x012 ) ( len=9 ) " config-l@" $call-parent ( 0x209 ) b(;) ( 0x0c2 )
I’m sure I’m being too linear in my thinking, as you’ve already pointed out, my-space and config-l@ were called before my exception.
I just can’t figure out what is throwing the exception?
On 2017-Dec-29 00:40 , Jd Lyons wrote: [...]
b(>resolve) ( 0x0b2 ) (unnamed-fcode) [0xddf]<————This calls the offset? 0xddf
new-token ( 0x0b5 ) 0xddf b(:) ( 0x0b7 ) b(lit) ( 0x010 ) 0x10 (unnamed-fcode) [0xdde] <——This calls the offset? 0xdde
new-token ( 0x0b5 ) 0xdde b(:) ( 0x0b7 ) my-space ( 0x103 ) + ( 0x01e ) dup ( 0x047 ) (unnamed-fcode) [0xa08]<—— this calls 0xa08
new-token ( 0x0b5 ) 0xa08 b(:) ( 0x0b7 ) b(") ( 0x012 ) ( len=9 ) " config-l@" $call-parent ( 0x209 ) b(;) ( 0x0c2 )
Ah! Seeing that structure, the sequence comes down to:
0x10 my-space + dup " config-l@" $call-parent
That looks different than the debug output which seemed to be showing a bunch of extraneous "and"s.
So this is reading the first BAR at PCI config space address 10.
It's calling config-l@ from the parent, because this is a word defined by the PCI node. The code looks entirely reasonable. The questions to pursue: - What is the value of my-space at that time? - What is the value of my-self at that time? (because $call-parent will use my-self to find my-parent and thus the pci instance).
If either of them has something questionable, that's what is blowing up, and we can track back to figure out what happened.
On 2017-Dec-29 01:05 , Tarl Neustaedter wrote:
[...] Ah! Seeing that structure, the sequence comes down to:
0x10 my-space + dup " config-l@" $call-parent
I should mention; that "dup" right before calling " config-l@" suggests he's going to write a value back very shortly.
This is often done during the probe process, where the PCI drivers usually fiddle with the BAR to determine its characteristics. The PCI driver should have already done the write 0xFFFFFFF0 and read it back to determine the size of the BAR before assigning an address to it, but the video driver probably needs to read the BAR to determine 32/64 bit. What it could be expecting to write back is a little confusing to me, at least at Sun/Oracle, device FCodes were not expected to change the contents of BARs. Maybe it's going to determine the BAR size and then put the same value back?
On Dec 29, 2017, at 1:05 AM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2017-Dec-29 00:40 , Jd Lyons wrote: [...]
b(>resolve) ( 0x0b2 ) (unnamed-fcode) [0xddf]<————This calls the offset? 0xddf
new-token ( 0x0b5 ) 0xddf b(:) ( 0x0b7 ) b(lit) ( 0x010 ) 0x10 (unnamed-fcode) [0xdde] <——This calls the offset? 0xdde
new-token ( 0x0b5 ) 0xdde b(:) ( 0x0b7 ) my-space ( 0x103 ) + ( 0x01e ) dup ( 0x047 ) (unnamed-fcode) [0xa08]<—— this calls 0xa08
new-token ( 0x0b5 ) 0xa08 b(:) ( 0x0b7 ) b(") ( 0x012 ) ( len=9 ) " config-l@" $call-parent ( 0x209 ) b(;) ( 0x0c2 )
Ah! Seeing that structure, the sequence comes down to:
0x10 my-space + dup " config-l@" $call-parent
That looks different than the debug output which seemed to be showing a bunch of extraneous "and"s.
So this is reading the first BAR at PCI config space address 10.
It's calling config-l@ from the parent, because this is a word defined by the PCI node. The code looks entirely reasonable. The questions to pursue:
- What is the value of my-space at that time?
- What is the value of my-self at that time? (because $call-parent will use my-self to find my-parent and thus the pci instance).
I’m using:
“ /pci/@2” open-dev to my-self
Not sure how I can get the value of my-self at the time of the exception?
If either of them has something questionable, that's what is blowing up, and we can track back to figure out what happened.
OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 2017-Dec-29 02:01 , Jd Lyons wrote:
“ /pci/@2” open-dev to my-self
Not sure how I can get the value of my-self at the time of the exception?
Well, for a first pass, let's take a look at them before the FCode runs. After the above line, say
my-self . my-parent . my-space .
my-self and my-parent should be similar pointers into the forth dictionary, where the framework has allocated data for the instances of the video card node and the pci node (respectively).
my-space should be the high-order bits of the PCI address space, probably 0x1000 since this is device 2.
On Dec 29, 2017, at 3:27 AM, Tarl Neustaedter tarl-b2@tarl.net wrote:
On 2017-Dec-29 02:01 , Jd Lyons wrote:
“ /pci/@2” open-dev to my-self
Not sure how I can get the value of my-self at the time of the exception?
Well, for a first pass, let's take a look at them before the FCode runs. After the above line, say
my-self . my-parent . my-space .
my-self and my-parent should be similar pointers into the forth dictionary, where the framework has allocated data for the instances of the video card node and the pci node (respectively).
my-space should be the high-order bits of the PCI address space, probably 0x1000 since this is device 2.
C>> annot manage 'VGA controller' PCI device type 'display':
10de 141 (3 0 0)
============================================================= OpenBIOS 1.1 [Dec 29 2017 00:16] 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. ms isn't unique. Welcome to OpenBIOS v1.1 built on Dec 29 2017 00:16
0 > dev /pci ls fff5942c mac-io@c fff5c374 usb@d fff5c6e0 pci10de,141@e fff5ca24 rtl8139@f ok 0 > " /pci/@e" open-dev to my-self ok 0 > my-self . 5fc5ac34 ok 0 > my-parent . 5fc5abfc ok 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? 0 >
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote:
0 > " /pci/@e" open-dev to my-self ok 0 > my-self . 5fc5ac34 ok 0 > my-parent . 5fc5abfc ok 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? 0 >
That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
On Dec 29, 2017, at 8:27 PM, Tarl Neustaedter tarl-b2@tarl.net wrote:
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote:
0 > " /pci/@e" open-dev to my-self ok 0 > my-self . 5fc5ac34 ok 0 > my-parent . 5fc5abfc ok 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? 0 >
That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
Thanks Tarl, SLOF has some code for probing Option Roms, I’ll have to see if it’s anything I can use to hack this together.
I appreciate everyone taking the time to help me with this, just something to pass the time.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Dec 29, 2017, at 8:27 PM, Tarl Neustaedter tarl-b2@tarl.net wrote:
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote:
0 > " /pci/@e" open-dev to my-self ok 0 > my-self . 5fc5ac34 ok 0 > my-parent . 5fc5abfc ok 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? 0 >
That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
Interestingly enough, SLOF has a file called psi-device_10de_0141.fs
\ ***************************************************************************** \ * Copyright (c) 2004, 2008 IBM Corporation \ * All rights reserved. \ * This program and the accompanying materials \ * are made available under the terms of the BSD License \ * which accompanies this distribution, and is available at \ * http://www.opensource.org/licenses/bsd-license.php \ * \ * Contributors: \ * IBM Corporation - initial implementation \ ****************************************************************************/
my-space pci-class-name type
my-space pci-device-generic-setup
pci-io-enable pci-mem-enable
30 config-l@ pci-find-fcode execute-rom-fcode
: check-display ( nodepath len -- true|false ) \ true if display found and "screen" alias set \ check if display available, set screen alias 2dup find-node \ ( path len phandle|0 ) find node ?dup IF \ node found, get "display-type" property s" display-type" rot get-property ( path len true|propaddr proplen 0 ) 0= IF ( path len propaddr proplen ) \ property found, check if the value is not "NONE" s" NONE" 0 char-cat ( path len propaddr proplen str strlen ) \ null-terminated NONE string str= 0= IF ( path len ) \ "display-type" property is not "NONE" so we can set "screen" alias s" screen" 2swap set-alias true ( true ) \ return true ELSE 2drop false ( false ) \ return false THEN THEN THEN ;
get-node node>path s" /NVDA,DISPLAY-A" $cat check-display 0= IF \ no display found on DISPLAY-A ... check DISPLAY-B get-node node>path s" /NVDA,DISPLAY-B" $cat check-display drop \ drop result THEN
s" name" get-my-property drop s" ( " type type s" ) " type cr
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Fri, Dec 29, 2017 at 12:40:21AM -0500, Jd Lyons wrote:
8010041 : (compile) my-space [ 0x103 ] 8010042 : (compile) + [ 0x1e ] 8010044 : (compile) [ 0xa08 ] <<<<<<< is this config-l@?
Not likely, no. It's some word defined in this fcode script.
8010045 : (compile) b(lit) [ 0x10 ] 801004a : (compile) and [ 0x23 ] 801004b : (compile) b(lit) [ 0x10 ] 8010050 : (compile) = [ 0x3c ]
The above looks to me like he's testing for the presence of 0x10 in a register (0x10 and 0x10 =). If he's looking at a series of BARs, that's the prefetchable bit he's looking for.
That's not a bad guess I bet :-)
Do you think it’s having trouble reading the PCI Configuration registers, it was able to change the subsystem-id from 0x50 to 0x10, so I was hoping it had calculated the base address of the PCI card correctly.
It could be anything really. You'll have to figure out where it THROWs from. Can you have it trace a bit? Just dumping the return stack inside THROW itself would be enough.
b(>resolve) ( 0x0b2 ) (unnamed-fcode) [0xddf]<————This calls the offset? 0xddf
This calls the fcode token number ddf, which is defined somewhere earlier in the fcode, with new-token probably.
new-token ( 0x0b5 ) 0xddf b(:) ( 0x0b7 ) b(lit) ( 0x010 ) 0x10 (unnamed-fcode) [0xdde] <——This calls the offset? 0xdde
This one :-) So that was Forth code:
: xddf 10 xdde ;
where xdde is another eralier word.
new-token ( 0x0b5 ) 0xdde b(:) ( 0x0b7 ) my-space ( 0x103 ) + ( 0x01e ) dup ( 0x047 ) (unnamed-fcode) [0xa08]<—— this calls 0xa08
... namely:
: xdde my-space + dup xa08 ;
new-token ( 0x0b5 ) 0xa08 b(:) ( 0x0b7 ) b(") ( 0x012 ) ( len=9 ) " config-l@" $call-parent ( 0x209 ) b(;) ( 0x0c2 )
: xa08 " config-l@" $call-parent ;
So in total:
: xa08 ( addr -- data ) " config-l@" $call-parent ; : xdde ( addr -- data ) my-space + dup xa08 ; : xddf ( -- data ) 10 xdde ;
so xddf reads from PCI BAR 0 of the PCI device the current node is for.
I’m sure I’m being too linear in my thinking, as you’ve already pointed out, my-space and config-l@ were called before my exception.
I just can’t figure out what is throwing the exception?
Yeah that kind of thing can be tricky. Add more tracing :-)
Segher
On Fri, Dec 29, 2017 at 08:27:54PM -0500, Tarl Neustaedter wrote:
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote:
0 > " /pci/@e" open-dev to my-self ok 0 > my-self . 5fc5ac34 ok 0 > my-parent . 5fc5abfc ok 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? 0 >
That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
Or set my-space to return 7000 and keep on fumbling :-)
Segher
On Dec 30, 2017, at 4:21 AM, Segher Boessenkool segher@kernel.crashing.org wrote:
On Fri, Dec 29, 2017 at 08:27:54PM -0500, Tarl Neustaedter wrote:
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote:
0 > " /pci/@e" open-dev to my-self ok 0 > my-self . 5fc5ac34 ok 0 > my-parent . 5fc5abfc ok 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? 0 >
That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
Or set my-space to return 7000 and keep on fumbling :-)
How would I set my-space to 7000?
Is that specific to pci/@e?
I noticed in SLOF that my-space . returned 1800, however the card was pci/@3.
Segher
-- OpenBIOS http://openbios.org/ http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Sat, Dec 30, 2017 at 05:44:10AM -0500, Jd Lyons wrote:
On Dec 30, 2017, at 4:21 AM, Segher Boessenkool segher@kernel.crashing.org wrote: On Fri, Dec 29, 2017 at 08:27:54PM -0500, Tarl Neustaedter wrote:
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote:
0 > " /pci/@e" open-dev to my-self ok 0 > my-self . 5fc5ac34 ok 0 > my-parent . 5fc5abfc ok 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? 0 >
That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
Or set my-space to return 7000 and keep on fumbling :-)
How would I set my-space to 7000?
Is that specific to pci/@e?
I noticed in SLOF that my-space . returned 1800, however the card was pci/@3.
And that is correct :-)
It is @dev,fn or if fn is 0, it is written as @dev . In the encoded representation, it is 800*dev + 100*fn (dev is 5 bits, fn is 3 bits).
In openbios, it looks like my-space gets its data from >dn.probe-addr in the device node... And it is set via set-args... And then I got lost, not sure how that is supposed to be called.
Segher
On Dec 30, 2017, at 6:04 AM, Segher Boessenkool segher@kernel.crashing.org wrote:
On Sat, Dec 30, 2017 at 05:44:10AM -0500, Jd Lyons wrote:
On Dec 30, 2017, at 4:21 AM, Segher Boessenkool segher@kernel.crashing.org wrote: On Fri, Dec 29, 2017 at 08:27:54PM -0500, Tarl Neustaedter wrote:
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote:
0 > " /pci/@e" open-dev to my-self ok 0 > my-self . 5fc5ac34 ok 0 > my-parent . 5fc5abfc ok 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? 0 >
That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
Or set my-space to return 7000 and keep on fumbling :-)
How would I set my-space to 7000?
Is that specific to pci/@e?
I noticed in SLOF that my-space . returned 1800, however the card was pci/@3.
And that is correct :-)
It is @dev,fn or if fn is 0, it is written as @dev . In the encoded representation, it is 800*dev + 100*fn (dev is 5 bits, fn is 3 bits).
In openbios, it looks like my-space gets its data from >dn.probe-addr in the device node... And it is set via set-args... And then I got lost, not sure how that is supposed to be called.
Looks like we need to change the way openbios handles my-space.
SLOF deals with it in the nodes.fs
: (my-phandle) ( -- phandle ) my-self ?dup IF ihandle>phandle ELSE get-node dup 0= ABORT" no active node" THEN ;
: my-space ( -- phys.hi ) (my-phandle) >space ;
I think we also need the >space word, the phandle word, and the ihandle word, I’ll have to track that down too.
John, do you want to take a crack at fixing the >dn.probe-addr, or replacing it with something that returns a correct my-space .?
Segher
On Dec 31, 2017, at 7:59 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 30, 2017, at 6:04 AM, Segher Boessenkool <segher@kernel.crashing.org mailto:segher@kernel.crashing.org> wrote:
On Sat, Dec 30, 2017 at 05:44:10AM -0500, Jd Lyons wrote:
On Dec 30, 2017, at 4:21 AM, Segher Boessenkool <segher@kernel.crashing.org mailto:segher@kernel.crashing.org> wrote: On Fri, Dec 29, 2017 at 08:27:54PM -0500, Tarl Neustaedter wrote:
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote:
0 > " /pci/@e" open-dev to my-self ok 0 > my-self . 5fc5ac34 ok 0 > my-parent . 5fc5abfc ok 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? 0 >
That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
Or set my-space to return 7000 and keep on fumbling :-)
How would I set my-space to 7000?
Is that specific to pci/@e?
I noticed in SLOF that my-space . returned 1800, however the card was pci/@3.
And that is correct :-)
It is @dev,fn or if fn is 0, it is written as @dev . In the encoded representation, it is 800*dev + 100*fn (dev is 5 bits, fn is 3 bits).
In openbios, it looks like my-space gets its data from >dn.probe-addr in the device node... And it is set via set-args... And then I got lost, not sure how that is supposed to be called.
Looks like we need to change the way openbios handles my-space.
SLOF deals with it in the nodes.fs
: (my-phandle) ( -- phandle ) my-self ?dup IF ihandle>phandle ELSE get-node dup 0= ABORT" no active node" THEN ;
: my-space ( -- phys.hi ) (my-phandle) >space ;
I think we also need the >space word, the phandle word, and the ihandle word, I’ll have to track that down too.
John, do you want to take a crack at fixing the >dn.probe-addr, or replacing it with something that returns a correct my-space .?
Looks lie Openbios already deals with ihandle and phandle, they just are not global words, and they may not need to be for my purpose.
They aren’t global words in SLOF, so as long as the compiler understands them a build time, they should work just fine.
Segher
On Dec 31, 2017, at 8:13 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 31, 2017, at 7:59 AM, Jd Lyons <lyons_dj@yahoo.com mailto:lyons_dj@yahoo.com> wrote:
On Dec 30, 2017, at 6:04 AM, Segher Boessenkool <segher@kernel.crashing.org mailto:segher@kernel.crashing.org> wrote:
On Sat, Dec 30, 2017 at 05:44:10AM -0500, Jd Lyons wrote:
On Dec 30, 2017, at 4:21 AM, Segher Boessenkool <segher@kernel.crashing.org mailto:segher@kernel.crashing.org> wrote: On Fri, Dec 29, 2017 at 08:27:54PM -0500, Tarl Neustaedter wrote:
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote: > 0 > " /pci/@e" open-dev to my-self ok > 0 > my-self . 5fc5ac34 ok > 0 > my-parent . 5fc5abfc ok > 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? > 0 > > That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
Or set my-space to return 7000 and keep on fumbling :-)
How would I set my-space to 7000?
Is that specific to pci/@e?
I noticed in SLOF that my-space . returned 1800, however the card was pci/@3.
And that is correct :-)
It is @dev,fn or if fn is 0, it is written as @dev . In the encoded representation, it is 800*dev + 100*fn (dev is 5 bits, fn is 3 bits).
In openbios, it looks like my-space gets its data from >dn.probe-addr in the device node... And it is set via set-args... And then I got lost, not sure how that is supposed to be called.
Looks like we need to change the way openbios handles my-space.
SLOF deals with it in the nodes.fs
: (my-phandle) ( -- phandle ) my-self ?dup IF ihandle>phandle ELSE get-node dup 0= ABORT" no active node" THEN ;
: my-space ( -- phys.hi ) (my-phandle) >space ;
I think we also need the >space word, the phandle word, and the ihandle word, I’ll have to track that down too.
John, do you want to take a crack at fixing the >dn.probe-addr, or replacing it with something that returns a correct my-space .?
Looks lie Openbios already deals with ihandle and phandle, they just are not global words, and they may not need to be for my purpose.
They aren’t global words in SLOF, so as long as the compiler understands them a build time, they should work just fine.
\ Set address and arguments of new device node. : set-args ( arg-str arg-len unit-str unit-len -- ) ?my-self drop
depth 1- >r " decode-unit" ['] $call-parent catch if 2drop 2drop then
my-self ihandle>phandle >dn.probe-addr \ offset begin depth r@ > while dup na1+ >r ! r> repeat r> 2drop
my-self >in.arguments 2@ free-mem strdup my-self >in.arguments 2! ;
Segher
Looks like the >space word is also in the node.fs for SLOF:
: >space node>space @ ; : >space? node>space? @ ;
On Dec 31, 2017, at 7:59 AM, Jd Lyons lyons_dj@yahoo.com wrote:
space
On Dec 31, 2017, at 9:01 AM, Jd Lyons lyons_dj@yahoo.com wrote:
Looks like the >space word is also in the node.fs for SLOF:
: >space node>space @ ; : >space? node>space? @ ;
Yet, I can’t seem to find where the global word my-space is defined in Openbios?
On Dec 31, 2017, at 7:59 AM, Jd Lyons <lyons_dj@yahoo.com mailto:lyons_dj@yahoo.com> wrote:
space
On Dec 31, 2017, at 9:03 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 31, 2017, at 9:01 AM, Jd Lyons lyons_dj@yahoo.com wrote:
Looks like the >space word is also in the node.fs for SLOF:
: >space node>space @ ; : >space? node>space? @ ;
Yet, I can’t seem to find where the global word my-space is defined in Openbios?
It is located here: openbios/forth/device/package.fs
It is defined like this:
: my-space ( -- phys.hi ) ?my-self >in.device-node @
dn.probe-addr @
;
On Dec 31, 2017, at 7:59 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 30, 2017, at 6:04 AM, Segher Boessenkool segher@kernel.crashing.org wrote:
On Sat, Dec 30, 2017 at 05:44:10AM -0500, Jd Lyons wrote:
On Dec 30, 2017, at 4:21 AM, Segher Boessenkool segher@kernel.crashing.org wrote: On Fri, Dec 29, 2017 at 08:27:54PM -0500, Tarl Neustaedter wrote:
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote:
0 > " /pci/@e" open-dev to my-self ok 0 > my-self . 5fc5ac34 ok 0 > my-parent . 5fc5abfc ok 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? 0 >
That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
Or set my-space to return 7000 and keep on fumbling :-)
How would I set my-space to 7000?
Is that specific to pci/@e?
I noticed in SLOF that my-space . returned 1800, however the card was pci/@3.
And that is correct :-)
It is @dev,fn or if fn is 0, it is written as @dev . In the encoded representation, it is 800*dev + 100*fn (dev is 5 bits, fn is 3 bits).
In openbios, it looks like my-space gets its data from >dn.probe-addr in the device node... And it is set via set-args... And then I got lost, not sure how that is supposed to be called.
Looks like we need to change the way openbios handles my-space.
SLOF deals with it in the nodes.fs
: (my-phandle) ( -- phandle ) my-self ?dup IF ihandle>phandle ELSE get-node dup 0= ABORT" no active node" THEN ;
: my-space ( -- phys.hi ) (my-phandle) >space ;
I think we also need the >space word, the phandle word, and the ihandle word, I’ll have to track that down too.
John, do you want to take a crack at fixing the >dn.probe-addr, or replacing it with something that returns a correct my-space .?
I'm not familiar with what >dn.probe-addr is but I did find this code:
struct ( device node ) /n field >dn.isize \ instance size (must go first) /n field >dn.parent /n field >dn.child /n field >dn.peer /n field >dn.properties /n field >dn.methods /n field >dn.priv-methods /n field >dn.#acells /n field >dn.probe-addr inst-node.size field >dn.itemplate constant dev-node.size
I'm guessing it is a field in a structure. This code is found here: openbios/forth/device/structures.fs
On 31/12/17 12:59, Jd Lyons wrote:
On Dec 30, 2017, at 6:04 AM, Segher Boessenkool <segher@kernel.crashing.org mailto:segher@kernel.crashing.org> wrote:
On Sat, Dec 30, 2017 at 05:44:10AM -0500, Jd Lyons wrote:
On Dec 30, 2017, at 4:21 AM, Segher Boessenkool <segher@kernel.crashing.org mailto:segher@kernel.crashing.org> wrote: On Fri, Dec 29, 2017 at 08:27:54PM -0500, Tarl Neustaedter wrote:
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote:
0 > " /pci/@e" open-dev to my-self ok 0 > my-self . 5fc5ac34 ok 0 > my-parent . 5fc5abfc ok 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? 0 >
That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
Or set my-space to return 7000 and keep on fumbling :-)
How would I set my-space to 7000?
Is that specific to pci/@e?
I noticed in SLOF that my-space . returned 1800, however the card was pci/@3.
And that is correct :-)
It is @dev,fn or if fn is 0, it is written as @dev . In the encoded representation, it is 800*dev + 100*fn (dev is 5 bits, fn is 3 bits).
In openbios, it looks like my-space gets its data from >dn.probe-addr in the device node... And it is set via set-args... And then I got lost, not sure how that is supposed to be called.
Looks like we need to change the way openbios handles my-space.
SLOF deals with it in the nodes.fs
: (my-phandle) ( -- phandle ) my-self ?dup IF ihandle>phandle ELSE get-node dup 0= ABORT" no active node" THEN ;
: my-space ( -- phys.hi ) (my-phandle) >space ;
I think we also need the >space word, the phandle word, and the ihandle word, I’ll have to track that down too.
John, do you want to take a crack at fixing the >dn.probe-addr, or replacing it with something that returns a correct my-space .?
After a bit of poking, it appears that the issue is simply that set-args isn't being called for PCI devices.
The attached patch appears to fix the issue for me - can you confirm that it works for you?
0 > " /pci/QEMU,VGA" open-dev to my-self ok 0 > my-space u. 800 ok
ATB,
Mark.
On Dec 31, 2017, at 1:09 PM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 31/12/17 12:59, Jd Lyons wrote:
On Dec 30, 2017, at 6:04 AM, Segher Boessenkool <segher@kernel.crashing.org mailto:segher@kernel.crashing.org> wrote:
On Sat, Dec 30, 2017 at 05:44:10AM -0500, Jd Lyons wrote:
On Dec 30, 2017, at 4:21 AM, Segher Boessenkool <segher@kernel.crashing.org mailto:segher@kernel.crashing.org> wrote: On Fri, Dec 29, 2017 at 08:27:54PM -0500, Tarl Neustaedter wrote:
[re-send, copying the list. For whatever reason, it seems messages aren't getting the reply-to: header.]
On 2017-Dec-29 03:58 , Jd Lyons wrote: > 0 > " /pci/@e" open-dev to my-self ok > 0 > my-self . 5fc5ac34 ok > 0 > my-parent . 5fc5abfc ok > 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? > 0 > > That's the problem. It appears that simply open-dev and assigning my-self isn't enough. my-space (and my-address and my-unit) aren't getting set up, so all config-space accesses are going to do the wrong thing (they'll go to device 0, which may or may not be the root).
In the Sun/Oracle version, select would properly set things up, it appears no equivalent is available under openbios.
I think you'll have to further debug this by getting the FCode to be pulled in at startup in place of the built-in vga fcode, rather than trying to fiddle things this way.
Or set my-space to return 7000 and keep on fumbling :-)
How would I set my-space to 7000?
Is that specific to pci/@e?
I noticed in SLOF that my-space . returned 1800, however the card was pci/@3.
And that is correct :-)
It is @dev,fn or if fn is 0, it is written as @dev . In the encoded representation, it is 800*dev + 100*fn (dev is 5 bits, fn is 3 bits).
In openbios, it looks like my-space gets its data from >dn.probe-addr in the device node... And it is set via set-args... And then I got lost, not sure how that is supposed to be called.
Looks like we need to change the way openbios handles my-space. SLOF deals with it in the nodes.fs : (my-phandle) ( -- phandle ) my-self ?dup IF ihandle>phandle ELSE get-node dup 0= ABORT" no active node" THEN ; : my-space ( -- phys.hi ) (my-phandle) >space ; I think we also need the >space word, the phandle word, and the ihandle word, I’ll have to track that down too. John, do you want to take a crack at fixing the >dn.probe-addr, or replacing it with something that returns a correct my-space .?
After a bit of poking, it appears that the issue is simply that set-args isn't being called for PCI devices.
The attached patch appears to fix the issue for me - can you confirm that it works for you?
0 > " /pci/QEMU,VGA" open-dev to my-self ok 0 > my-space u. 800 ok
Thanks Mark, that seems to work. my-space . now returns 7000 for /pci/@e.
That seems correct to me?
I’m still catching an exception at the same place, but now, at least, I think, we have the correct instance.
Any insight on what I could/should try next Tarl?
<> ( 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 ) <<<————Still catching the exception here 25635: (unnamed-fcode) [0xddf]
ATB,
Mark. <openbios-pci-set-args.patch>
On Jan 1, 2018, at 7:06 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 31, 2017, at 1:09 PM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 31/12/17 12:59, Jd Lyons wrote:
On Dec 30, 2017, at 6:04 AM, Segher Boessenkool <segher@kernel.crashing.org mailto:segher@kernel.crashing.org> wrote:
On Sat, Dec 30, 2017 at 05:44:10AM -0500, Jd Lyons wrote:
On Dec 30, 2017, at 4:21 AM, Segher Boessenkool <segher@kernel.crashing.org mailto:segher@kernel.crashing.org> wrote: On Fri, Dec 29, 2017 at 08:27:54PM -0500, Tarl Neustaedter wrote: > [re-send, copying the list. For whatever reason, it seems messages > aren't getting the reply-to: header.] > > On 2017-Dec-29 03:58 , Jd Lyons wrote: >> 0 > " /pci/@e" open-dev to my-self ok >> 0 > my-self . 5fc5ac34 ok >> 0 > my-parent . 5fc5abfc ok >> 0 > my-space . 0 ok <<---Seems my-space isn't returning a correct value? >> 0 > >> > That's the problem. It appears that simply open-dev and assigning > my-self isn't enough. my-space (and my-address and my-unit) aren't > getting set up, so all config-space accesses are going to do the wrong > thing (they'll go to device 0, which may or may not be the root). > > In the Sun/Oracle version, select would properly set things up, it > appears no equivalent is available under openbios. > > I think you'll have to further debug this by getting the FCode to be > pulled in at startup in place of the built-in vga fcode, rather than > trying to fiddle things this way.
Or set my-space to return 7000 and keep on fumbling :-)
How would I set my-space to 7000?
Is that specific to pci/@e?
I noticed in SLOF that my-space . returned 1800, however the card was pci/@3.
And that is correct :-)
It is @dev,fn or if fn is 0, it is written as @dev . In the encoded representation, it is 800*dev + 100*fn (dev is 5 bits, fn is 3 bits).
In openbios, it looks like my-space gets its data from >dn.probe-addr in the device node... And it is set via set-args... And then I got lost, not sure how that is supposed to be called.
Looks like we need to change the way openbios handles my-space. SLOF deals with it in the nodes.fs : (my-phandle) ( -- phandle ) my-self ?dup IF ihandle>phandle ELSE get-node dup 0= ABORT" no active node" THEN ; : my-space ( -- phys.hi ) (my-phandle) >space ; I think we also need the >space word, the phandle word, and the ihandle word, I’ll have to track that down too. John, do you want to take a crack at fixing the >dn.probe-addr, or replacing it with something that returns a correct my-space .?
After a bit of poking, it appears that the issue is simply that set-args isn't being called for PCI devices.
The attached patch appears to fix the issue for me - can you confirm that it works for you?
0 > " /pci/QEMU,VGA" open-dev to my-self ok 0 > my-space u. 800 ok
Thanks Mark, that seems to work. my-space . now returns 7000 for /pci/@e.
That seems correct to me?
I’m still catching an exception at the same place, but now, at least, I think, we have the correct instance.
Any insight on what I could/should try next Tarl?
<> ( 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 ) <<<————Still catching the exception here 25635: (unnamed-fcode) [0xddf]
ATB,
Mark. <openbios-pci-set-args.patch>
Seems we’re still not getting the correct instance.
https://lists.ozlabs.org/pipermail/slof/2018-January/002023.html
-
Jd Lyons -
Mark Cave-Ayland -
Programmingkid -
Segher Boessenkool -
Tarl Neustaedter