Re: [OpenBIOS] Back at it again( PCI Passthrough )
Ok, I made those changes to openbios, here is the output.
On May 8, 2018, at 6:50 AM, Joe van Tunen <joevt@shaw.ca> wrote:
: (debug-feval) ( fcode# -- fcode# ) \ Address fcode-stream 1 - . here u. ." : "
\ Indicate if word is compiled state @ 0<> if ." (compile) " then dup fcode>xt cell - lfa2name type dup ." [ 0x" . ." ]" cr ;
Had a mild amount of success in SLOF, I know it’s a little of topic, but these are just the ways I work through things I don’t quite understand. Even tho SLOF would execute the Fcode rom to the end, it would only propagate the parent, i.e. NVDA,Parent, but not the children, i.e. NDVA,Display-A, NVDA,Display-B. Seems that doing select-dev twice in a row will fix this trouble: SLOF ********************************************************************** QEMU Starting Build Date = Jul 24 2017 15:15:46 FW Version = git-89f519f09bf85091 Press "s" to enter Open Firmware. Populating /vdevice methods Populating /vdevice/vty@71000000 Populating /vdevice/nvram@71000001 Populating /vdevice/l-lan@71000002 Populating /vdevice/v-scsi@71000003 SCSI: Looking for devices 8000000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" 8100000000000000 DISK : "QEMU QEMU HARDDISK 2.5+" 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.5+" Populating /pci@800000020000000 00 0000 (D) : 10de 0141 vga* Scanning USB Using default console: /vdevice/vty@71000000 Welcome to Open Firmware Copyright (c) 2004, 2017 IBM Corporation All rights reserved. This program and the accompanying materials are made available under the terms of the BSD License available at http://www.opensource.org/licenses/bsd-license.php Type 'boot' and press return to continue booting the system. Type 'reset-all' and press return to reboot the system. Ready! 0 > include evaluator.fs ok 0 > here u. e7825a8 ok 0 > s" /pci/@0" select-dev ok 0 > s" /pci/@0" select-dev ok 0 > here u. e7825a8 ok 0 > load disk1:,\666 Trying to load: from: /vdevice/v-scsi@71000003/disk@8100000000000000:,\666 ... ok 0 > here u. e782748 ok 0 > 4040 1 byte-load ok 0 > .properties VRAM,memsize 10000000 10000000 #size-cells 00000000 #address-cells 00000001 reg 00000000 00000000 00000000 00000000 00000000 02000010 00000000 00000000 00000000 01000000 0200001c 00000000 00000000 00000000 01000000 42000014 00000000 00000000 00000000 10000000 02000030 00000000 00000000 00000000 00020000 NVDA,Level 00000001 NVDA,Features 005002ef rom-revision 2149 32313439 00 name NVDA,Parent 4e564441 2c506172 656e7400 NVCAP 04000100 00100003 001c0000 00000007 000000 NVPM 01000000 00000000 00000000 00000000 00000000 00000000 00000000 device_type NVDA,GeForce 4e564441 2c476546 6f726365 00 NVDA,BMP 55aa7eeb 4b373430 30e94c19 77cc5649 44454f20 0d000000 00005710 00004942 4d205647 4120436f 6d706174 69626c65 01000000 b0100b18 30362f32 342f3035 00000000 00000000 01100000 00000000 e93edd00 00000000 00000000 00004081 efffff7f 10000080 2200a542 e9f5b7e9 fcb7ffb8 42495400 00010c06 10473201 0400de00 42021600 e2004301 0e00f800 44010400 06014901 0e000a01 4c010200 18017401 12001a01 4d010200 2c014e00 00000000 50011900 2e015302 15004701 54010200 5c015501 03005e01 56010600 61016300 00000000 69022300 67010000 00007502 43050000 00000000 a8073030 2f30302f 30300200 00000000 00000000 8a010000 3d020000 00004302 55026102 9102d902 d9025502 2903c803 ce03d403 ec030404 1c043404 4c046404 cc127c04 0000b704 00000f05 00006805 0000a205 000042a7 050000ba 05500a06 19230628 4b06145f 06238206 23a50614 b9060000 00fc0611 07000075 02430500 600140fd 13005743 2e073036 2f32342f 30350000 00000000 00000000 3a072104 23050000 00006400 95019001 e8030300 23001900 640001ff 01ff0119 011f0007 00000000 00204000 00640095 01580278 05030023 00190064 0001ff01 ff011f01 1f000703 00000000 08400000 90012003 90012003 0d000000 32002003 011f011f 01010101 00070000 00000008 05680064 00950190 01e80303 00230019 00640001 ff01ff01 19011f01 07000000 00002005 68006400 95019001 e8030300 23001900 640001ff 01ff0119 011f0107 00000000 00ffff80 05800544 07870b5b 10951173 12000074 12a012cc 12000101 01020103 01040105 01d40210 00010000 001c0210 00010000 00d00210 00010000 00d80210 00010000 00dc0210 00010000 00dc0210 00000000 00001010 00400000 00400000 00000000 000f0000 00020000 00101300 00000100 00000000 00001010 00200000 00200000 00401500 00000001 00000000 00401500 00000002 00000000 00d4033c 70042103 0300d403 3c700421 030301d4 033c7004 21030302 d4033c70 04210303 03d4033c 70042103 4040d403 3c700421 032f21d4 033c7004 21032f23 d4033c70 04210320 00010103 02030101 63301f02 10002823 98139813 bc13bc13 68037403 80038c03 9803a403 b003bc03 00000001 01020103 01040105 01060107 01080109 010a010b 010c010d 010e010f e81cd013 7017d713 0000de13 e81ce513 7017ec13 0000f313 d039fa13 e02e0114 00000814 d0390f14 e02e1614 00001d14 e81c2414 70172b14 00003214 e81c3914 70174014 00004714 d0394e14 e02e5514 00005c14 d0396314 e02e6a14 00007114 04083132 3519007e b4000000 00010203 090a0b0c 0e0f1011 17181e1f 2022292c 33343c3d 21f07c1f 44765700 43034903 8301f400 d2d21620 c04033 model GeForce 6600 4765466f 72636520 36363030 00 revision-id 000000a4 subsystem-id 00000010 assigned-addresses 82000030 00000000 82000000 00000000 00020000 82000010 00000000 80000000 00000000 01000000 c3000014 00002100 00000000 00000000 10000000 8200001c 00000000 81000000 00000000 01000000 ibm,req#msi 00000001 vendor-id 000010de device-id 00000141 class-code 00030000 interrupts 00000001 min-grant 00000000 max-latency 00000000 subsystem-vendor-id 000010de cache-line-size 00000000 devsel-speed 00000000 ibm,loc-code vfio_vfio-pci:0000:00:00.0 7666696f 5f766669 6f2d7063 693a3030 30303a30 303a3030 2e3000 ibm,my-drc-index 40000000 ibm,pci-config-space-type 00000001 ok 0 > ls e72d2e0 : /pci@800000020000000/NVDA,Parent@0 e7c5448 : |-- NVDA,Display-A e7c5f30 : |-- NVDA,Display-B e7c6740 : +-- sensor-parent e7c69d8 : +-- gpu-diode-temperature ok 0 > dev NVDA,Display-A ok 0 > .properties can-hot-plug display-cfg 00360003 display-type LCD 4c434400 EDID 00ffffff ffffff00 593a0410 01010101 0d170103 806e3e78 0a6bf3a6 554d9325 0f4849a5 ce008100 81c00101 01010101 01010101 0101023a 80187138 2d40582c 45004868 4200001e 000000fd 00324d1f 460f000a 20202020 20200000 00ff0055 4b4e5442 50303130 30303031 000000fc 00453530 30692d41 300a2020 2020013c 02032671 4b010304 05902011 1213141f 29090705 15575010 07508301 00006703 0c004000 382d023a 80187138 2d40582c 55004868 4200001e 011d0072 51d01e20 6e285500 48684200 001e0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000036 refresh 0000003c linebytes 00000280 depth 00000008 height 000001e0 width 00000280 character-set ISO8859-1 49534f38 3835392d 3100 connector-type 00000200 compatible NVDA,NVMacNVDA,MultiDisplay 4e564441 2c4e564d 6163004e 5644412c 4d756c74 69446973 706c6179 00 reg 00000000 device_type display 64697370 6c617900 name NVDA,Display-A 4e564441 2c446973 706c6179 2d4100 ok 0 > That’s the properties of a fully working nVidia card with an Fcode ROM, I’ve seen it enough times to know. The display connect to the card did not power on, but I don’t expect it too until I boot an OS, and now I’ll have to find the one I installed for the Pseries machine;-) Now I just got to get this working with Openbios.
On May 8, 2018, at 8:36 AM, Jd Lyons <lyons_dj@yahoo.com> wrote:
Ok, I made those changes to openbios, here is the output.
<6603.txt>
On May 8, 2018, at 6:50 AM, Joe van Tunen <joevt@shaw.ca <mailto:joevt@shaw.ca>> wrote:
: (debug-feval) ( fcode# -- fcode# ) \ Address fcode-stream 1 - . here u. ." : "
\ Indicate if word is compiled state @ 0<> if ." (compile) " then dup fcode>xt cell - lfa2name type dup ." [ 0x" . ." ]" cr ;
On 2018-May-8 11:10 , Jd Lyons via OpenBIOS wrote:
Seems that doing select-dev twice in a row will fix this trouble: [...]
0 > include evaluator.fs ok 0 > here u. e7825a8 ok 0 > s" /pci/@0" select-dev ok 0 > s" /pci/@0" select-dev ok 0 > here u. e7825a8 ok 0 > load disk1:,\666 Trying to load: from: /vdevice/v-scsi@71000003/disk@8100000000000000:,\666 ... ok 0 > here u. e782748 ok 0 > 4040 1 byte-load ok
You might try doing the load before the selects. E.g., 0> load disk1:,\666 0> s" /pci/@0" select-dev 0> 4040 1 byte-load The contents should still be there at 4040 after you do the select(s). I wonder if the load (which will do its own fiddling with device tree) is somehow messing up the state, and that's why you needed two select-devs.
The b?branch command causes the dictionary pointer to change from fff81e54 to fff57240. This behavior is described in fcode.fs where b?branch calls setup-tmp-comp. It's using the tmp-comp-buf which is initialized to a fixed size of 200 in bootstrap.fs. Is 200 enough? Maybe you should test this functionality with a simplified fcode image. Create a fcode image containing the following (tokenize it so it can be loaded with byte-load - add any necessary stuff I didn't include such as start1): ." start test" testa 0= if ." testa is 0" testb 0= if ." testb is also 0" then then ." done test" Test the image by creating the testa and testb values and byte-load the image for each combination of values (add any necessary stuff I didn't include in the byte-load command): 0 value testa 0 value testb byte-load 1 to testa byte-load 1 to testb byte-load 0 to testa byte-load if that all works, then you need to start stepping through the OpenBIOS code to find when the exception is thrown (maybe you can add some ." ..." to the various .fs files to narrow the search). You have all the code to OpenBIOS, so you should be able to find the problem eventually. From: OpenBIOS <openbios-bounces@openbios.org> on behalf of Jd Lyons via OpenBIOS <openbios@openbios.org> Date: Tuesday, May 8, 2018 at 5:36 AM Ok, I made those changes to openbios, here is the output. On May 8, 2018, at 6:50 AM, Joe van Tunen <mailto:joevt@shaw.ca> wrote: : (debug-feval) ( fcode# -- fcode# ) \ Address fcode-stream 1 - . here u. ." : " \ Indicate if word is compiled state @ 0<> if ." (compile) " then dup fcode>xt cell - lfa2name type dup ." [ 0x" . ." ]" cr ;
On 08/05/18 13:36, Jd Lyons via OpenBIOS wrote:
Ok, I made those changes to openbios, here is the output.
Are you able to run the FCode binary through OpenBIOS's detok utility in order to do a side-by-side comparison? ATB, Mark.
On Tue, May 08, 2018 at 12:41:30PM -0700, Joe van Tunen wrote:
The b?branch command causes the dictionary pointer to change from fff81e54 to fff57240. This behavior is described in fcode.fs where b?branch calls setup-tmp-comp. It's using the tmp-comp-buf which is initialized to a fixed size of 200 in bootstrap.fs. Is 200 enough?
Using a temporary compile buffer for b?branch in interpret mode is incorrect. It should be executed in interpret mode directly, as the 1275 specification specifies. This is different from IF in interpret mode, etc. Segher
Yes, I have the Fcode detok(ed), but really I’m muddling around in stuff I don’t understand very well. I have some understanding of C and a pretty good understanding of the nVidia Fdcode Option Roms, but when it comes down to raw forth I still don’t even really understand the basics.
On May 8, 2018, at 5:44 PM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 08/05/18 13:36, Jd Lyons via OpenBIOS wrote:
Ok, I made those changes to openbios, here is the output.
Are you able to run the FCode binary through OpenBIOS's detok utility in order to do a side-by-side comparison?
ATB,
Mark.
On May 8, 2018, at 5:56 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
On Tue, May 08, 2018 at 12:41:30PM -0700, Joe van Tunen wrote:
The b?branch command causes the dictionary pointer to change from fff81e54 to fff57240. This behavior is described in fcode.fs where b?branch calls setup-tmp-comp. It's using the tmp-comp-buf which is initialized to a fixed size of 200 in bootstrap.fs. Is 200 enough?
Using a temporary compile buffer for b?branch in interpret mode is incorrect. It should be executed in interpret mode directly, as the 1275 specification specifies. This is different from IF in interpret mode, etc.
Segher
Yes, that sound about right, we got to maybe b?branch wasn’t working correctly, before. I did a hatchet job, basically just a copy and paste from SLOF into Openbios, and a few “fixes” to make it compile, but I think the result was the Fcode caught an exception earlier. Likely if someone that knew what they were doing takes a swing at it, we could get a little further. https://mail.coreboot.org/pipermail/openbios/2017-December/010071.html
I don’t know if this is helpful, but I did a debug of b?branch and b(>resolve): 4010035 : b?branch [ 0x14 ] : b?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff46930: fcode-offset (offset) 26 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff 26 ) fff46934: 0< ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff 0 ) fff46938: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff4695c: setup-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff46960: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff3d4e4 ) fff46968: , ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff4696c: here ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 ) fff46970: 0 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff46974: 0 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 0 ) fff46978: , ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff4697c: (semis) [ Finished b?branch ] 4010039 : (compile) [ 0x9bd ] 401003a : (compile) b(lit) [ 0x10 ] 401003f : (compile) and [ 0x23 ] 4010041 : (compile) my-space [ 0x103 ] 4010042 : (compile) + [ 0x1e ] 4010044 : (compile) [ 0xa08 ] 4010045 : (compile) b(lit) [ 0x10 ] 401004a : (compile) and [ 0x23 ] 401004b : (compile) b(lit) [ 0x10 ] 4010050 : (compile) = [ 0x3c ] 4010051 : (compile) b?branch [ 0x14 ] : b?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff46930: fcode-offset (offset) 9 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 9 ) fff46934: 0< ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 0 ) fff46938: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff4695c: setup-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff46960: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff3d4e4 ) fff46968: , ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff4696c: here ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff57200 ) fff46970: 0 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff57200 0 ) fff46974: 0 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff57200 0 0 ) fff46978: , ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff57200 0 ) fff4697c: (semis) [ Finished b?branch ] 4010054 : (compile) b(') [ 0x11 ] 4010057 : (compile) b(to) [ 0xc3 ] 401005a : (compile) b(>resolve) [ 0xb2 ] : b(>resolve) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff57200 0 ) fff469bc: resolve-orig ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff469c0: execute-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff469c4: (semis) [ Finished b(>resolve) ] 401005b : (compile) b(>resolve) [ 0xb2 ] : b(>resolve) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff469bc: resolve-orig ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff469c0: execute-tmp-comp byte-load: exception caught! ok
On May 8, 2018, at 6:14 PM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
On May 8, 2018, at 5:56 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
On Tue, May 08, 2018 at 12:41:30PM -0700, Joe van Tunen wrote:
The b?branch command causes the dictionary pointer to change from fff81e54 to fff57240. This behavior is described in fcode.fs where b?branch calls setup-tmp-comp. It's using the tmp-comp-buf which is initialized to a fixed size of 200 in bootstrap.fs. Is 200 enough?
Using a temporary compile buffer for b?branch in interpret mode is incorrect. It should be executed in interpret mode directly, as the 1275 specification specifies. This is different from IF in interpret mode, etc.
Segher
Yes, that sound about right, we got to maybe b?branch wasn’t working correctly, before. I did a hatchet job, basically just a copy and paste from SLOF into Openbios, and a few “fixes” to make it compile, but I think the result was the Fcode caught an exception earlier.
Likely if someone that knew what they were doing takes a swing at it, we could get a little further.
https://mail.coreboot.org/pipermail/openbios/2017-December/010071.html -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
Bear with me, while I try to understand this, but it looks like b?branch sets up some type of temporary buffer, and b(>resolve) try to “flush” that buffer.
On May 9, 2018, at 4:55 AM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
I don’t know if this is helpful, but I did a debug of b?branch and b(>resolve):
4010035 : b?branch [ 0x14 ]
: b?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff46930: fcode-offset (offset) 26 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff 26 ) fff46934: 0< ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff 0 ) fff46938: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff4695c: setup-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff46960: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff3d4e4 ) fff46968: , ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff4696c: here ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 ) fff46970: 0 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff46974: 0 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 0 ) fff46978: , ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff4697c: (semis) [ Finished b?branch ] 4010039 : (compile) [ 0x9bd ] 401003a : (compile) b(lit) [ 0x10 ] 401003f : (compile) and [ 0x23 ] 4010041 : (compile) my-space [ 0x103 ] 4010042 : (compile) + [ 0x1e ] 4010044 : (compile) [ 0xa08 ] 4010045 : (compile) b(lit) [ 0x10 ] 401004a : (compile) and [ 0x23 ] 401004b : (compile) b(lit) [ 0x10 ] 4010050 : (compile) = [ 0x3c ] 4010051 : (compile) b?branch [ 0x14 ]
: b?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff46930: fcode-offset (offset) 9 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 9 ) fff46934: 0< ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 0 ) fff46938: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff4695c: setup-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff46960: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff3d4e4 ) fff46968: , ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff4696c: here ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff57200 ) fff46970: 0 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff57200 0 ) fff46974: 0 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff57200 0 0 ) fff46978: , ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff57200 0 ) fff4697c: (semis) [ Finished b?branch ] 4010054 : (compile) b(') [ 0x11 ] 4010057 : (compile) b(to) [ 0xc3 ] 401005a : (compile) b(>resolve) [ 0xb2 ]
: b(>resolve) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 fff57200 0 ) fff469bc: resolve-orig ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff469c0: execute-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff469c4: (semis) [ Finished b(>resolve) ] 401005b : (compile) b(>resolve) [ 0xb2 ]
: b(>resolve) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff571c4 0 ) fff469bc: resolve-orig ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) <<—Something is going wrong here? I just don’t know what it is? fff469c0: execute-tmp-comp byte-load: exception caught! ok
Just deleting the b(>resolve) I’m hanging on and replacing it with ff gets a little further, and what I’m thinking is these two b(>resolves) and the two b?branch that come before them have something to do with the children, NVDA,Display-A and NVDA,Display-B. Maybe something to do with display detection, or the set-mode command. Here is the result of skipping the last b(>resolve): 8010051 : (compile) b?branch [ 0x14 ] (offset) 9 8010054 : (compile) b(') [ 0x11 ] 8010057 : (compile) b(to) [ 0xc3 ] 801005a : (compile) b(>resolve) [ 0xb2 ] 801005b : (compile) end1 [ 0xff ]<—skipping 801005d : (compile) [ 0xddf ] 801005f : (compile) [ 0xe04 ] 8010061 : (compile) [ 0xe38 ] 8010063 : (compile) [ 0xe06 ] 8010065 : (compile) [ 0xce5 ] 8010067 : (compile) [ 0xdb0 ] 8010069 : (compile) [ 0xe07 ] 801006b : (compile) [ 0xe1a ] 801006d : (compile) [ 0xc5b ] 801006f : (compile) [ 0xe28 ] 8010071 : (compile) [ 0xe20 ] 8010073 : (compile) [ 0xdfa ] 8010075 : (compile) [ 0xe37 ] 8010077 : (compile) [ 0xe2c ] 8010079 : (compile) [ 0xe2d ] 801007a : (compile) b(") [ 0x12 ] (const) NVDA,Parent 8010088 : (compile) device-name [ 0x201 ] 8010089 : (compile) 1 [ 0xa6 ] 801008b : (compile) encode-int [ 0x111 ] 801008c : (compile) b(") [ 0x12 ] (const) #address-cells 801009d : (compile) property [ 0x110 ] 801009e : (compile) 0 [ 0xa5 ] 80100a0 : (compile) encode-int [ 0x111 ] 80100a1 : (compile) b(") [ 0x12 ] (const) #size-cells 80100af : (compile) property [ 0x110 ] 80100b1 : (compile) [ 0x9c7 ] 80100b3 : (compile) [ 0x93d ] 80100b4 : (compile) b(lit) [ 0x10 ] 80100b9 : (compile) >= [ 0x42 ] 80100ba : (compile) b?branch [ 0x14 ] (offset) d 80100bd : (compile) 1 [ 0xa6 ] 80100bf : (compile) [ 0x933 ] 80100c0 : (compile) lshift [ 0x27 ] 80100c2 : (compile) [ 0x935 ] 80100c3 : (compile) or [ 0x24 ] 80100c4 : (compile) b(to) [ 0xc3 ] 80100c7 : (compile) b(>resolve) [ 0xb2 ] 80100c9 : (compile) [ 0x941 ] 80100ca : (compile) b(lit) [ 0x10 ] 80100cf : (compile) lshift [ 0x27 ] 80100d1 : (compile) [ 0x935 ] 80100d2 : (compile) or [ 0x24 ] 80100d4 : (compile) encode-int [ 0x111 ] 80100d5 : (compile) b(") [ 0x12 ] (const) NVDA,Features 80100e5 : (compile) property [ 0x110 ] 80100e6 : (compile) 1 [ 0xa6 ] 80100e8 : (compile) encode-int [ 0x111 ] 80100e9 : (compile) b(") [ 0x12 ] (const) NVDA,Level 80100f6 : (compile) property [ 0x110 ] 80100f7 : (compile) 0 [ 0xa5 ] 80100f8 : (compile) 0 [ 0xa5 ] 80100fa : (compile) [ 0xe2e ] 80100fc : (compile) [ 0x9bc ] 80100fe : (compile) [ 0x9c3 ] 8010100 : (compile) [ 0xe2e ] 8010102 : (compile) encode+ [ 0x112 ] 8010104 : (compile) [ 0x9c0 ] 8010106 : (compile) [ 0x9c6 ] 8010108 : (compile) [ 0xe2e ] 801010a : (compile) encode+ [ 0x112 ] 801010c : (compile) [ 0x9be ] 801010e : (compile) [ 0x9c4 ] 8010110 : (compile) [ 0xe2e ] 8010112 : (compile) encode+ [ 0x112 ] 8010114 : (compile) [ 0x9bf ] 8010116 : (compile) [ 0x9c5 ] 8010118 : (compile) [ 0xe2e ] 801011a : (compile) encode+ [ 0x112 ] 801011b : (compile) b(") [ 0x12 ] (const) reg 8010121 : (compile) property [ 0x110 ] 8010122 : (compile) 1 [ 0xa6 ] 8010124 : (compile) encode-int [ 0x111 ] 8010125 : (compile) b(") [ 0x12 ] (const) #address-cells 8010136 : (compile) property [ 0x110 ] 8010137 : (compile) 0 [ 0xa5 ] 8010139 : (compile) encode-int [ 0x111 ] 801013a : (compile) b(") [ 0x12 ] (const) #size-cells 8010148 : (compile) property [ 0x110 ] 8010149 : (compile) b(") [ 0x12 ] (const) : decode-unit parse-1hex ; 8010165 : (compile) evaluate [ 0xcd ] 8010167 : (compile) [ 0xc7c ] 8010168 : (compile) dup [ 0x47 ] 801016a : (compile) encode-int [ 0x111 ] 801016b : (compile) rot [ 0x4a ] 801016d : (compile) encode-int [ 0x111 ] 801016f : (compile) encode+ [ 0x112 ] 8010170 : (compile) b(") [ 0x12 ] (const) VRAM,memsize 801017f : (compile) property [ 0x110 ] 8010180 : (compile) 0 [ 0xa5 ] 8010181 : (compile) b(to) [ 0xc3 ] 8010185 : (compile) [ 0x951 ] 8010186 : (compile) 0 [ 0xa5 ] 8010187 : (compile) b(?do) [ 0x18 ] (offset) 16 801018a : (compile) i [ 0x19 ] 801018c : (compile) [ 0xa41 ] 801018e : (compile) [ 0xa4a ] 8010190 : (compile) [ 0x8ea ] 8010191 : (compile) <> [ 0x3d ] 8010192 : (compile) b?branch [ 0x14 ] (offset) 8 8010195 : (compile) i [ 0x19 ] 8010196 : (compile) b(to) [ 0xc3 ] 8010199 : (compile) b(leave) [ 0x1b ] 801019a : (compile) b(>resolve) [ 0xb2 ] 801019b : (compile) b(loop) [ 0x15 ] (offset) -12 801019f : (compile) [ 0x946 ] 80101a0 : (compile) 0> [ 0x38 ] 80101a1 : (compile) b?branch [ 0x14 ] (offset) 1b0 80101a5 : (compile) [ 0x952 ] 80101a7 : (compile) [ 0xa41 ] 80101a9 : (compile) new-device [ 0x11f ] 80101ab : (compile) [ 0xe32 ] 80101ac : (compile) new-token [ 0xb5 ] 80101ae : (compile) undefined-fcode [ 0xe39 ] 80101af : (compile) b(:) [ 0xb7 ] 80101b1 : (compile) [ 0x952 ] 80101b3 : (compile) [ 0xa41 ] 80101b5 : (compile) [ 0xdf1 ] 80101b6 : (compile) b(to) [ 0xc3 ] 80101b9 : (compile) b(;) [ 0xc2 ] 80101ba : new-token [ 0xb5 ] (fcode#) e3a 80101bd : b(:) [ 0xb7 ] 80101bf : (compile) [ 0x952 ] 80101c1 : (compile) [ 0xa41 ] 80101c3 : (compile) [ 0xdf2 ] 80101c4 : (compile) b(;) [ 0xc2 ] 80101c5 : named-token [ 0xb6 ] (const) get-mode (fcode#) e3b 80101d1 : b(:) [ 0xb7 ] 80101d3 : (compile) [ 0xdcb ] 80101d4 : (compile) b(;) [ 0xc2 ] 80101d5 : named-token [ 0xb6 ] (const) show-modes (fcode#) e3c 80101e3 : b(:) [ 0xb7 ] 80101e5 : (compile) [ 0xdcc ] 80101e6 : (compile) b(;) [ 0xc2 ] 80101e7 : external-token [ 0xca ] (const) set-mode (fcode#) e3d 80101f3 : b(:) [ 0xb7 ] 80101f5 : (compile) [ 0x952 ] 80101f7 : (compile) [ 0xa41 ] 80101f9 : (compile) [ 0xdca ] 80101fa : (compile) b(;) [ 0xc2 ] 80101fb : external-token [ 0xca ] (const) draw-rectangle (fcode#) e3e 801020d : b(:) [ 0xb7 ] 801020f : (compile) [ 0x952 ] 8010211 : (compile) [ 0xa41 ] 8010213 : (compile) [ 0xdd5 ] 8010214 : (compile) b(;) [ 0xc2 ] 8010215 : external-token [ 0xca ] (const) fill-rectangle (fcode#) e3f 8010227 : b(:) [ 0xb7 ] 8010229 : (compile) [ 0x952 ] 801022b : (compile) [ 0xa41 ] 801022d : (compile) [ 0xdd7 ] 801022e : (compile) b(;) [ 0xc2 ] 801022f : external-token [ 0xca ] (const) read-rectangle (fcode#) e40 8010241 : b(:) [ 0xb7 ] 8010243 : (compile) [ 0x952 ] 8010245 : (compile) [ 0xa41 ] 8010247 : (compile) [ 0xdd6 ] 8010248 : (compile) b(;) [ 0xc2 ] 8010249 : external-token [ 0xca ] (const) color! (fcode#) e41 8010253 : b(:) [ 0xb7 ] 8010255 : (compile) [ 0x952 ] 8010257 : (compile) [ 0xa41 ] 8010259 : (compile) [ 0xcf7 ] 801025a : (compile) b(;) [ 0xc2 ] 801025b : external-token [ 0xca ] (const) color@ (fcode#) e42 8010265 : b(:) [ 0xb7 ] 8010267 : (compile) [ 0x952 ] 8010269 : (compile) [ 0xa41 ] 801026b : (compile) [ 0xcf9 ] 801026c : (compile) b(;) [ 0xc2 ] 801026d : external-token [ 0xca ] (const) set-colors (fcode#) e43 801027b : b(:) [ 0xb7 ] 801027d : (compile) [ 0x952 ] 801027f : (compile) [ 0xa41 ] 8010281 : (compile) [ 0xcf3 ] 8010282 : (compile) b(;) [ 0xc2 ] 8010283 : external-token [ 0xca ] (const) get-colors (fcode#) e44 8010291 : b(:) [ 0xb7 ] 8010293 : (compile) [ 0x952 ] 8010295 : (compile) [ 0xa41 ] 8010297 : (compile) [ 0xcf5 ] 8010298 : (compile) b(;) [ 0xc2 ] 8010299 : external-token [ 0xca ] (const) dimensions (fcode#) e45 80102a7 : b(:) [ 0xb7 ] 80102a9 : (compile) [ 0xb70 ] 80102ab : (compile) [ 0xb71 ] 80102ac : (compile) b(;) [ 0xc2 ] 80102ad : external-token [ 0xca ] (const) ddc2-set-start (fcode#) e46 80102bf : b(:) [ 0xb7 ] 80102c1 : (compile) [ 0x952 ] 80102c3 : (compile) [ 0xa41 ] 80102c5 : (compile) [ 0xdf3 ] 80102c6 : (compile) b(;) [ 0xc2 ] 80102c7 : external-token [ 0xca ] (const) ddc2-set-stop (fcode#) e47 80102d8 : b(:) [ 0xb7 ] 80102da : (compile) [ 0x952 ] 80102dc : (compile) [ 0xa41 ] 80102de : (compile) [ 0xdf4 ] 80102df : (compile) b(;) [ 0xc2 ] 80102e0 : external-token [ 0xca ] (const) ddc2-send-byte (fcode#) e48 80102f2 : b(:) [ 0xb7 ] 80102f4 : (compile) [ 0x952 ] 80102f6 : (compile) [ 0xa41 ] 80102f8 : (compile) [ 0xdf5 ] 80102f9 : (compile) b(;) [ 0xc2 ] 80102fb : [ 0x95f ] 80102fc : 1 [ 0xa6 ] 80102fe : [ 0x952 ] 80102ff : lshift [ 0x27 ] 8010300 : and [ 0x23 ] 8010301 : 0<> [ 0x35 ] 8010302 : b?branch [ 0x14 ] (offset) 42 8010305 : (compile) external-token [ 0xca ] 8010306 : (compile) bbranch [ 0x13 ] (offset) 706f 8010309 : (compile) 2! [ 0x77 ] 801030a : (compile) cell+ [ 0x65 ] 801030b : (compile) ! [ 0x72 ] 801030c : (compile) abs [ 0x2d ] 801030d : (compile) l! [ 0x73 ] 801030e : (compile) 2! [ 0x77 ] 801030f : (compile) cells [ 0x69 ] 8010310 : (compile) w! [ 0x74 ] 8010311 : (compile) wa1+ [ 0x63 ] 8010312 : (compile) /l* [ 0x68 ] 8010313 : (compile) abs [ 0x2d ] 8010314 : (compile) cell+ [ 0x65 ] 8010315 : (compile) l@ [ 0x6e ] 8010316 : (compile) na+ [ 0x61 ] 8010317 : (compile) char+ [ 0x62 ] 8010318 : (compile) +! [ 0x6c ] 8010319 : (compile) cell+ [ 0x65 ] 801031b : (compile) undefined-fcode [ 0xe49 ] 801031c : (compile) b(:) [ 0xb7 ] 801031e : (compile) [ 0x952 ] 8010320 : (compile) [ 0xdd8 ] 8010321 : (compile) b(;) [ 0xc2 ] 8010322 : external-token [ 0xca ] (const) power-switch-disable (fcode#) e4a 801033a : b(:) [ 0xb7 ] 801033c : (compile) [ 0x952 ] 801033e : (compile) [ 0xdd9 ] 801033f : (compile) b(;) [ 0xc2 ] 8010341 : [ 0x952 ] 8010343 : [ 0xdd9 ] 8010344 : b(>resolve) [ 0xb2 ] 8010345 : b(') [ 0x11 ] 8010349 : is-install [ 0x11c ] open isn't unique. 801034a : b(') [ 0x11 ] 801034e : is-remove [ 0x11d ] close isn't unique. 8010350 : finish-device [ 0x127 ] 8010351 : b(>resolve) [ 0xb2 ] 8010353 : [ 0x946 ] 8010354 : 1 [ 0xa6 ] 8010355 : > [ 0x3b ] 8010356 : b?branch [ 0x14 ] (offset) 1dc 8010359 : (compile) -1 [ 0xa4 ] 801035b : (compile) [ 0x951 ] 801035c : (compile) 0 [ 0xa5 ] 801035d : (compile) b(?do) [ 0x18 ] (offset) 25 8010360 : (compile) i [ 0x19 ] 8010362 : (compile) [ 0x952 ] 8010363 : (compile) <> [ 0x3d ] 8010364 : (compile) b?branch [ 0x14 ] (offset) 1b 8010367 : (compile) dup [ 0x47 ] 8010368 : (compile) -1 [ 0xa4 ] 8010369 : (compile) = [ 0x3c ] 801036a : (compile) b?branch [ 0x14 ] (offset) 5 801036d : (compile) drop [ 0x46 ] 801036e : (compile) i [ 0x19 ] 801036f : (compile) b(>resolve) [ 0xb2 ] 8010370 : (compile) i [ 0x19 ] 8010372 : (compile) [ 0xa41 ] 8010374 : (compile) [ 0xa4a ] 8010376 : (compile) [ 0x8ea ] 8010377 : (compile) <> [ 0x3d ] 8010378 : (compile) b?branch [ 0x14 ] (offset) 6 801037b : (compile) drop [ 0x46 ] 801037c : (compile) i [ 0x19 ] 801037d : (compile) b(leave) [ 0x1b ] 801037e : (compile) b(>resolve) [ 0xb2 ] 801037f : (compile) b(>resolve) [ 0xb2 ] 8010380 : (compile) b(loop) [ 0x15 ] (offset) -21 8010383 : (compile) dup [ 0x47 ] 8010384 : (compile) b(to) [ 0xc3 ] 8010388 : (compile) [ 0xa41 ] 801038a : (compile) new-device [ 0x11f ] 801038c : (compile) [ 0xe32 ] 801038d : (compile) new-token [ 0xb5 ] 801038f : (compile) undefined-fcode [ 0xe4b ] 8010390 : (compile) b(:) [ 0xb7 ] 8010392 : (compile) [ 0x953 ] 8010394 : (compile) [ 0xa41 ] 8010396 : (compile) [ 0xdf1 ] 8010397 : (compile) b(to) [ 0xc3 ] 801039a : (compile) b(;) [ 0xc2 ] 801039b : new-token [ 0xb5 ] (fcode#) e4c 801039e : b(:) [ 0xb7 ] 80103a0 : (compile) [ 0x953 ] 80103a2 : (compile) [ 0xa41 ] 80103a4 : (compile) [ 0xdf2 ] 80103a5 : (compile) b(;) [ 0xc2 ] 80103a6 : named-token [ 0xb6 ] (const) get-mode (fcode#) e4d 80103b2 : b(:) [ 0xb7 ] 80103b4 : (compile) [ 0xdcb ] 80103b5 : (compile) b(;) [ 0xc2 ] 80103b6 : named-token [ 0xb6 ] (const) show-modes (fcode#) e4e 80103c4 : b(:) [ 0xb7 ] 80103c6 : (compile) [ 0xdcc ] 80103c7 : (compile) b(;) [ 0xc2 ] 80103c8 : external-token [ 0xca ] (const) set-mode<——We just hang here Get-mode, show-mode, and set-mode are called twice, I assume once for each display node, so something is going wrong with NVDA,Dispaly-A/B, I just don’t know what it is. Something b?branch sets up, but b(>resolve) can’t resolve?
On May 8, 2018, at 6:14 PM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
On May 8, 2018, at 5:56 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
On Tue, May 08, 2018 at 12:41:30PM -0700, Joe van Tunen wrote:
The b?branch command causes the dictionary pointer to change from fff81e54 to fff57240. This behavior is described in fcode.fs where b?branch calls setup-tmp-comp. It's using the tmp-comp-buf which is initialized to a fixed size of 200 in bootstrap.fs. Is 200 enough?
Using a temporary compile buffer for b?branch in interpret mode is incorrect. It should be executed in interpret mode directly, as the 1275 specification specifies. This is different from IF in interpret mode, etc.
Segher
Yes, that sound about right, we got to maybe b?branch wasn’t working correctly, before. I did a hatchet job, basically just a copy and paste from SLOF into Openbios, and a few “fixes” to make it compile, but I think the result was the Fcode caught an exception earlier.
Likely if someone that knew what they were doing takes a swing at it, we could get a little further.
https://mail.coreboot.org/pipermail/openbios/2017-December/010071.html -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Wed, May 09, 2018 at 08:27:14AM -0400, Jd Lyons wrote:
Bear with me, while I try to understand this, but it looks like b?branch sets up some type of temporary buffer, and b(>resolve) try to “flush” that buffer.
Yes; and that is incorrect. b?branch in interpret mode is only allowed for forward branches (which you have here), and it should simply skip that much forward (in the fcode stream) if the top of stack was 0. Not compile anything. Segher
On 08/05/18 22:56, Segher Boessenkool wrote:
On Tue, May 08, 2018 at 12:41:30PM -0700, Joe van Tunen wrote:
The b?branch command causes the dictionary pointer to change from fff81e54 to fff57240. This behavior is described in fcode.fs where b?branch calls setup-tmp-comp. It's using the tmp-comp-buf which is initialized to a fixed size of 200 in bootstrap.fs. Is 200 enough?
Using a temporary compile buffer for b?branch in interpret mode is incorrect. It should be executed in interpret mode directly, as the 1275 specification specifies. This is different from IF in interpret mode, etc.
I'm confused here: b?branch is FCode-only and executed as part of the FCode evaluation. The tmp-comp-buf is used to hold the xts derived from the FCode token stream until the point where the branch is resolved. However I still think for the moment we're digging way to deep here... ATB, Mark.
On 08/05/18 22:57, Jd Lyons via OpenBIOS wrote:
Yes, I have the Fcode detok(ed), but really I’m muddling around in stuff I don’t understand very well.
I have some understanding of C and a pretty good understanding of the nVidia Fdcode Option Roms, but when it comes down to raw forth I still don’t even really understand the basics.
I suspect that it's something within that branch failing which is only visible at the final b(>resolve) once the condition is evaluated, so with indentation: 4010035 fff81e54 : b?branch [ 0x14 ] (offset) 26 4010039 fff57240 : (compile) [ 0x9bd ] 401003a fff57244 : (compile) b(lit) [ 0x10 ] 401003f fff5724c : (compile) and [ 0x23 ] 4010041 fff57250 : (compile) my-space [ 0x103 ] 4010042 fff57254 : (compile) + [ 0x1e ] 4010044 fff57258 : (compile) [ 0xa08 ] 4010045 fff5725c : (compile) b(lit) [ 0x10 ] 401004a fff57264 : (compile) and [ 0x23 ] 401004b fff57268 : (compile) b(lit) [ 0x10 ] 4010050 fff57270 : (compile) = [ 0x3c ] 4010051 fff57274 : (compile) b?branch [ 0x14 ] (offset) 9 4010054 fff5727c : (compile) b(') [ 0x11 ] 4010057 fff57284 : (compile) b(to) [ 0xc3 ] 401005a fff57290 : (compile) b(>resolve) [ 0xb2 ] 401005b fff57290 : (compile) b(>resolve) [ 0xb2 ] Most of that looks fairly normal, so I'd start by looking at the 0x9bd and 0xa08 FCodes which will have been generated further up in your output file. I suspect you'll end up converting chunks of FCode back into Forth to figure out which part is failing. ATB, Mark.
On 09/05/18 15:07, Segher Boessenkool wrote:
On Wed, May 09, 2018 at 08:27:14AM -0400, Jd Lyons wrote:
Bear with me, while I try to understand this, but it looks like b?branch sets up some type of temporary buffer, and b(>resolve) try to “flush” that buffer.
Yes; and that is incorrect. b?branch in interpret mode is only allowed for forward branches (which you have here), and it should simply skip that much forward (in the fcode stream) if the top of stack was 0. Not compile anything.
I'm not sure that's strictly true; certainly this is a difference in how the FCode part of the IEEE-1275 specification is implemented in OpenBIOS compared to others, but I wouldn't classify it outright as wrong. ATB, Mark.
On Wed, May 09, 2018 at 07:51:43PM +0100, Mark Cave-Ayland wrote:
On 09/05/18 15:07, Segher Boessenkool wrote:
On Wed, May 09, 2018 at 08:27:14AM -0400, Jd Lyons wrote:
Bear with me, while I try to understand this, but it looks like b?branch sets up some type of temporary buffer, and b(>resolve) try to “flush” that buffer.
Yes; and that is incorrect. b?branch in interpret mode is only allowed for forward branches (which you have here), and it should simply skip that much forward (in the fcode stream) if the top of stack was 0. Not compile anything.
I'm not sure that's strictly true; certainly this is a difference in how the FCode part of the IEEE-1275 specification is implemented in OpenBIOS compared to others, but I wouldn't classify it outright as wrong.
It can be used for example to conditionally use the 64-bit extensions. This won't work if you try to compile things that are supposed to be stepped over ;-) Not that I see what is exactly going wrong here... Segher
On 5/9/18, 7:07 AM, "Segher Boessenkool" <segher@kernel.crashing.org> wrote: On Wed, May 09, 2018 at 08:27:14AM -0400, Jd Lyons wrote: > Bear with me, while I try to understand this, but it looks like b?branch sets up some type of temporary buffer, and b(>resolve) try to “flush” that buffer. Yes; and that is incorrect. b?branch in interpret mode is only allowed for forward branches (which you have here), and it should simply skip that much forward (in the fcode stream) if the top of stack was 0. Not compile anything. The code in OpenBIOS is currently doing it differently. Someone put some effort in making it this way (though README.device says fcode.fs is partly untested). Before changing it, it should be proven that it can't work that way. This current method means all the bytes in the fcode stream are processed in some way. On May 9, 2018, at 4:55 AM, Jd Lyons via OpenBIOS <mailto:openbios@openbios.org> wrote: I don’t know if this is helpful, but I did a debug of b?branch and b(>resolve): The output is missing the changes you made to (debug-feval). What did you do to get that debug output? Did you just follow the instructions from README.debugger with b?branch and b(>resolve)? The debug output doesn't show what the second execute-tmp-comp is executing (the first execute-tmp-comp does nothing since depth hasn't returned to tmp-comp-depth yet). I don't see anything wrong with the debug output that you have so far. I think you need to look at debugging all the fcodes after the first b?branch. Can you do a debug trace of execute-tmp-comp? Just deleting the b(>resolve) I’m hanging on and replacing it with ff gets a little further, and what I’m thinking is these two b(>resolves) and the two b?branch that come before them have something to do with the children, NVDA,Display-A and NVDA,Display-B. Maybe something to do with display detection, or the set-mode command. If there's a problem with b?branch, then you shouldn't be using the nvidia rom to test it - use a simplified fcode image instead. ff is the fcode for end1, but that does nothing while in compile mode. OpenBIOS won't leave compile mode started by b?branch without a corresponding b(>resolve), and it eventually exceeds the temporary compile buffer size, trashing the dictionary, and then causing a hang. Maybe OpenBIOS needs a guard against that? "here!" should probably take two values, the new "here" value and a "limit". Then anything that adds to the dictionary should use that new limit instead of the usual limit. Get-mode, show-mode, and set-mode are called twice, I assume once for each display node, so something is going wrong with NVDA,Dispaly-A/B, I just don’t know what it is. They are not executed, because OpenBIOS hasn't left compile mode, because you removed (b>resolve). On 5/9/18, 11:34 AM, "Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk> wrote: I'm confused here: b?branch is FCode-only and executed as part of the FCode evaluation. The tmp-comp-buf is used to hold the xts derived from the FCode token stream until the point where the branch is resolved. However I still think for the moment we're digging way to deep here... I agree. We haven't proved there's anything wrong with b?branch (except that the size of the temporary compile buffer could be exceeded but that's not the problem with the nvidia rom). Running that test fcode image that I mentioned would probably have shown that it works. On 5/9/18, 11:45 AM, "OpenBIOS on behalf of Mark Cave-Ayland" <openbios-bounces@openbios.org on behalf of mark.cave-ayland@ilande.co.uk> wrote: I suspect that it's something within that branch failing which is only visible at the final b(>resolve) once the condition is evaluated, so with indentation: ... Most of that looks fairly normal, so I'd start by looking at the 0x9bd and 0xa08 FCodes which will have been generated further up in your output file. I suspect you'll end up converting chunks of FCode back into Forth to figure out which part is failing. I think a debug trace of execute-tmp-comp might work to get to what part of 0x9bd or 0xa08 is causing the exception?
On May 9, 2018, at 4:16 PM, Joe van Tunen <joevt@shaw.ca> wrote:
On 5/9/18, 7:07 AM, "Segher Boessenkool" <segher@kernel.crashing.org> wrote:
On Wed, May 09, 2018 at 08:27:14AM -0400, Jd Lyons wrote:
Bear with me, while I try to understand this, but it looks like b?branch sets up some type of temporary buffer, and b(>resolve) try to “flush” that buffer.
Yes; and that is incorrect. b?branch in interpret mode is only allowed for forward branches (which you have here), and it should simply skip that much forward (in the fcode stream) if the top of stack was 0. Not compile anything.
The code in OpenBIOS is currently doing it differently. Someone put some effort in making it this way (though README.device says fcode.fs is partly untested). Before changing it, it should be proven that it can't work that way. This current method means all the bytes in the fcode stream are processed in some way.
On May 9, 2018, at 4:55 AM, Jd Lyons via OpenBIOS <mailto:openbios@openbios.org> wrote:
I don’t know if this is helpful, but I did a debug of b?branch and b(>resolve):
The output is missing the changes you made to (debug-feval). What did you do to get that debug output? Did you just follow the instructions from README.debugger with b?branch and b(>resolve)?
Just ran debug (word) from the OB command line. I’ll look into the debugger readme and see if I can get some more useful info.
The debug output doesn't show what the second execute-tmp-comp is executing (the first execute-tmp-comp does nothing since depth hasn't returned to tmp-comp-depth yet). I don't see anything wrong with the debug output that you have so far. I think you need to look at debugging all the fcodes after the first b?branch. Can you do a debug trace of execute-tmp-comp?
Just deleting the b(>resolve) I’m hanging on and replacing it with ff gets a little further, and what I’m thinking is these two b(>resolves) and the two b?branch that come before them have something to do with the children, NVDA,Display-A and NVDA,Display-B. Maybe something to do with display detection, or the set-mode command.
If there's a problem with b?branch, then you shouldn't be using the nvidia rom to test it - use a simplified fcode image instead.
ff is the fcode for end1, but that does nothing while in compile mode. OpenBIOS won't leave compile mode started by b?branch without a corresponding b(>resolve), and it eventually exceeds the temporary compile buffer size, trashing the dictionary, and then causing a hang. Maybe OpenBIOS needs a guard against that? "here!" should probably take two values, the new "here" value and a "limit". Then anything that adds to the dictionary should use that new limit instead of the usual limit.
Get-mode, show-mode, and set-mode are called twice, I assume once for each display node, so something is going wrong with NVDA,Dispaly-A/B, I just don’t know what it is.
They are not executed, because OpenBIOS hasn't left compile mode, because you removed (b>resolve).
On 5/9/18, 11:34 AM, "Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk> wrote:
I'm confused here: b?branch is FCode-only and executed as part of the FCode evaluation. The tmp-comp-buf is used to hold the xts derived from the FCode token stream until the point where the branch is resolved.
However I still think for the moment we're digging way to deep here...
I agree. We haven't proved there's anything wrong with b?branch (except that the size of the temporary compile buffer could be exceeded but that's not the problem with the nvidia rom). Running that test fcode image that I mentioned would probably have shown that it works.
On 5/9/18, 11:45 AM, "OpenBIOS on behalf of Mark Cave-Ayland" <openbios-bounces@openbios.org on behalf of mark.cave-ayland@ilande.co.uk> wrote:
I suspect that it's something within that branch failing which is only visible at the final b(>resolve) once the condition is evaluated, so with indentation:
...
Most of that looks fairly normal, so I'd start by looking at the 0x9bd and 0xa08 FCodes which will have been generated further up in your output file.
new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) ------------------------- new-token 0x9bd b(constant) b(lit) 0x42000014 -------------------------- b?branch 0x0026 ( =dec 38) (unnamed-fcode) [0x9bd] b(lit) 0xff and my-space + (unnamed-fcode) [0xa08] b(lit) 0x6 and b(lit) 0x4 = b?branch 0x0009 () b(') (unnamed-fcode) [0x9c1] b(to) (unnamed-fcode) [0x9c0] b(>resolve) b(>resolve) (unnamed-fcode) [0xddf] (unnamed-fcode) [0xe04] (unnamed-fcode) [0xe38] (unnamed-fcode) [0xe06] (unnamed-fcode) [0xce5] (unnamed-fcode) [0xdb0] (unnamed-fcode) [0xe07] (unnamed-fcode) [0xe1a] (unnamed-fcode) [0xc5b] (unnamed-fcode) [0xe28] (unnamed-fcode) [0xe20] (unnamed-fcode) [0xdfa] (unnamed-fcode) [0xe37] (unnamed-fcode) [0xe2c] (unnamed-fcode) [0xe2d] b(") ( len=0xb [11 bytes] )
I suspect you'll end up converting chunks of FCode back into Forth to figure out which part is failing.
I think a debug trace of execute-tmp-comp might work to get to what part of 0x9bd or 0xa08 is causing the exception?
4010035 fff81e54 : b?branch [ 0x14 ] (offset) 26 4010039 fff57240 : (compile) [ 0x9bd ] 401003a fff57244 : (compile) b(lit) [ 0x10 ] 401003f fff5724c : (compile) and [ 0x23 ] 4010041 fff57250 : (compile) my-space [ 0x103 ] 4010042 fff57254 : (compile) + [ 0x1e ] 4010044 fff57258 : (compile) [ 0xa08 ] 4010045 fff5725c : (compile) b(lit) [ 0x10 ] 401004a fff57264 : (compile) and [ 0x23 ] 401004b fff57268 : (compile) b(lit) [ 0x10 ] 4010050 fff57270 : (compile) = [ 0x3c ] 4010051 fff57274 : (compile) b?branch [ 0x14 ] (offset) 9 4010054 fff5727c : (compile) b(') [ 0x11 ] 4010057 fff57284 : (compile) b(to) [ 0xc3 ] 401005a fff57290 : (compile) b(>resolve) [ 0xb2 ] : execute-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 ) fff3de1c: depth ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 11 ) fff3de20: tmp-comp-depth ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 11 fff3dd80 ) fff3de24: @ ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 11 f ) fff3de28: = ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 0 ) fff3de2c: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff5723c 0 ) fff3de78: (semis) [ Finished execute-tmp-comp ] 401005b fff57290 : (compile) b(>resolve) [ 0xb2 ] : execute-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff3de1c: depth ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff f ) fff3de20: tmp-comp-depth ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff f fff3dd80 ) fff3de24: @ ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff f f ) fff3de28: = ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ffffffff ) fff3de2c: do?branch ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff3de34: -1 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ffffffff ) fff3de38: tmp-comp-depth ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ffffffff fff3dd80 ) fff3de3c: ! ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff3de40: (lit) ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff3d0c4 ) fff3de48: , ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff ) fff3de4c: tmp-comp-buf ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff3dd9c ) fff3de50: @ ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 ) fff3de54: dup ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 fff57230 ) fff3de58: @ ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 fff81e54 ) fff3de5c: here! ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 ) fff3de60: 0 ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 0 ) fff3de64: state ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 0 fff3d648 ) fff3de68: ! ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 ) fff3de6c: /n ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57230 4 ) fff3de70: + ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff fff57234 ) fff3de74: execute byte-load: exception caught! ok 0> here u. fff81e54
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
: execute-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff )<—— We should be seeing fff5723c 0 here?
On May 10, 2018, at 6:33 AM, Jd Lyons <lyons_dj@yahoo.com> wrote:
On 10/05/18 11:33, Jd Lyons via OpenBIOS wrote:
On 5/9/18, 11:45 AM, "OpenBIOS on behalf of Mark Cave-Ayland" <openbios-bounces@openbios.org on behalf of mark.cave-ayland@ilande.co.uk> wrote:
I suspect that it's something within that branch failing which is only visible at the final b(>resolve) once the condition is evaluated, so with indentation:
...
Most of that looks fairly normal, so I'd start by looking at the 0x9bd and 0xa08 FCodes which will have been generated further up in your output file.
new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) ------------------------- new-token 0x9bd b(constant) b(lit) 0x42000014 --------------------------
Okay so there's your first issue in 0xa08 - the PCI config words config-*@ and config-*! aren't (yet) implemented in Forth in OpenBIOS so you'll need to wrap the existing pci_config_read/pci_config_write() functions using something similar to the approach here: https://github.com/openbios/openbios/commit/74ee111f1ff64415835c4c43b66b1528... Here you can see that the C function bind_func() to used to call a C function from Forth by binding it to the named Forth word in the dictionary. ATB, Mark.
From: Jd Lyons <lyons_dj@yahoo.com> Date: Thursday, May 10, 2018 at 3:46 AM : execute-tmp-comp ( ffffffff 1 0 ffffffff 0 0 ffffffff fff41a48 0 0 0 0 0 0 ffffffff )<—— We should be seeing fff5723c 0 here? That is the second execute-tmp-comp which is called by the second b(>resolve), but first, b(>resolve) calls resolve-orig. resolve-orig pops the top 2 items from the stack. if you trace it, it will look something like this: fff5723c 0 ) :resolve-orig here fff5723c 0 fff57290 ) nip fff5723c fff57290 ) over fff5723c fff57290 fff5723c ) /n fff5723c fff57290 fff5723c 4 ) + fff5723c fff57290 fff57240 ) - fff5723c 50 ) swap 50 fff5723c ) ! ) resolve-orig is setting the branch offset in the temporary compiled code to 0x50 which b?branch had initialized to 0. The temporary compiled code starts like this: here executing contents@here --------------------------------------------------------- setup-tmp-comp fff57230=tmp-comp-buf here fff57234 1 = DOCOL (start of colon word definition) b?branch fff57238 do?branch fff5723c 0 = don't know the branch offset until b(>resolve) is encountered , in (feval) fff57240 0x9bd ... (feval) executes b?branch and b(>resolve) even while in compile state because their ?flags has immediate (the same is done for compile-only flag?) When you do a debug of a word, OpenBIOS displays this message: Stepper keys: <space>/<enter> Up Down Trace Rstack Forth That means you can press the following keys when debugging: space: Perform a single step return: (supposed to be same as space but just prints the Stepper keys again) U: unmark current word for debug, mark its caller for debugging and finish executing current word D: mark current word for debug and step into it T: Trace mode R: Display rstack F: Start subordinate Forth interpreter. Use resume to get back to where you left off. So when you're debugging b(>resolve) or execute-tmp-comp, press the space bar until you get to execute, then press D to start stepping through execute. That won't work because execute is a primitive word. So try that again, except when you get to execute, press F, then type debug my-space dup (see) \ optional - this should show the contents of the temporary compiled code resume then when you get to my-space, step through it, when you get to (semis) press U to step through the rest of the temporary compiled code (I don't know if U will work here) It may be possible to do it this way: when you get to execute, press F, then type the following: dup (debug dup (see) \ optional - this should show the contents of the temporary compiled code resume Then press space to step through the code. Press D where you want to step into a word (especially 0xa08)
Hmmm…. I think you are on to something there, as I did note that they are words for the device in SLOF, before I execute the FCode. Seems I need to figure out how to add the config* words to Openbios as that must be what 0xa08 is tripping over. 0 > dev /pci/@1 ok 0 > .properties assigned-addresses 82000830 00000000 83000000 00000000 00010000 82000810 00000000 81000000 00000000 01000000 c3000814 00002100 00000000 00000000 10000000 8200081c 00000000 82000000 00000000 01000000 name vga 76676100 ibm,req#msi 00000001 vendor-id 000010de device-id 00000141 revision-id 000000a2 class-code 00030000 interrupts 00000001 min-grant 00000000 max-latency 00000000 subsystem-id 00000050 subsystem-vendor-id 000010de cache-line-size 00000000 devsel-speed 00000000 ibm,loc-code vfio_vfio-pci:0000:00:01.0 7666696f 5f766669 6f2d7063 693a3030 30303a30 303a3031 2e3000 ibm,my-drc-index 40000008 #address-cells 00000003 #size-cells 00000002 reg 00000800 00000000 00000000 00000000 00000000 02000810 00000000 00000000 00000000 01000000 03000814 00000000 00000000 00000000 10000000 0300081c 00000000 00000000 00000000 01000000 02000830 00000000 00000000 00000000 00010000 ibm,pci-config-space-type 00000001 ok 0 > words setup classfile devicefile dma-map-out dma-map-in dma-free dma-alloc close open config-dump config-l! config-w! config-b! config-l@ config-w@ config-b@ my-puid my-phandle encode-unit decode-unit ok 0 >
On May 10, 2018, at 3:13 PM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 10/05/18 11:33, Jd Lyons via OpenBIOS wrote:
On 5/9/18, 11:45 AM, "OpenBIOS on behalf of Mark Cave-Ayland" <openbios-bounces@openbios.org on behalf of mark.cave-ayland@ilande.co.uk> wrote:
I suspect that it's something within that branch failing which is only visible at the final b(>resolve) once the condition is evaluated, so with indentation:
...
Most of that looks fairly normal, so I'd start by looking at the 0x9bd and 0xa08 FCodes which will have been generated further up in your output file.
new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) ------------------------- new-token 0x9bd b(constant) b(lit) 0x42000014 --------------------------
Okay so there's your first issue in 0xa08 - the PCI config words config-*@ and config-*! aren't (yet) implemented in Forth in OpenBIOS so you'll need to wrap the existing pci_config_read/pci_config_write() functions using something similar to the approach here:
https://github.com/openbios/openbios/commit/74ee111f1ff64415835c4c43b66b1528...
Here you can see that the C function bind_func() to used to call a C function from Forth by binding it to the named Forth word in the dictionary.
ATB,
Mark.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
Seems I could add config-1@ as a colon definition, however I’m not sure how too deal with r1@? : rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ; Just can’t figure how r1@ is implemented in SLOF? grep -rnw /Users/jam/Downloads/SLOF-master -e 'rl@' /Users/jam/Downloads/SLOF-master/board-js2x/slof/OF.fs:24:f8000000 rl@ CONSTANT uni-n-version /Users/jam/Downloads/SLOF-master/board-js2x/slof/OF.fs:145:u4? IF f8002100 rl@ 0= ELSE false THEN ?INCLUDE u4-mem.fs /Users/jam/Downloads/SLOF-master/board-js2x/slof/OF.fs:182:f8000050 rl@ CONSTANT master-cpu /Users/jam/Downloads/SLOF-master/board-js2x/slof/OF.fs:271: f8000000 rl@ 4 rshift s" (" type 1 0.r s" ." type /Users/jam/Downloads/SLOF-master/board-js2x/slof/OF.fs:272: f8000000 rl@ f and 1 0.r s" )" type cr /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-bridge_1022_7460.fs:75:: hpet@ >hpet rl@-le ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-bridge_1022_7460.fs:117: dup 30 + rl@ 1 and 1 = IF /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-bridge_1022_7460.fs:118: dup 30 + rl@ 1 or /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-bridge_1022_7460.fs:126: BEGIN dup 34 + rl@ 1000 and 0= 2 ms UNTIL /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-bridge_1022_7460.fs:135: BEGIN dup 30 + rl@ 2 and 0= 2 ms UNTIL drop /Users/jam/Downloads/SLOF-master/board-js2x/slof/citrine.fs:28:: ioa@ >ioa rl@-le ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/ht.fs:46:\ : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/ht.fs:53:: config-l@ >config rl@-le ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/ht.fs:83:f8070200 rl@ fffffff0 and f8070200 rl! /Users/jam/Downloads/SLOF-master/board-js2x/slof/ht.fs:106:: ldtstop f8000840 rl@ 40000 or f8000840 rl! ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/ht.fs:108:: wait-for-done BEGIN f8070110 rl@ 30 and UNTIL /Users/jam/Downloads/SLOF-master/board-js2x/slof/ht.fs:110:: ldtstop1 f8000840 rl@ dup 20000 or f8000840 rl! delay /Users/jam/Downloads/SLOF-master/board-js2x/slof/ht.fs:114:: dumpht cr f8070110 rl@ 8 0.r space 8b4 config-l@ 8 0.r /Users/jam/Downloads/SLOF-master/board-js2x/slof/ht.fs:117:: clearht f8070110 dup rl@ swap rl! /Users/jam/Downloads/SLOF-master/board-js2x/slof/ht.fs:118: f8070120 dup rl@ swap rl! /Users/jam/Downloads/SLOF-master/board-js2x/slof/i2c.fs:23:: i2c@ >i2c rl@ ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-device_1002_515e.fs:35:: reg-rl@ regs-addr + rl@-le ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-device_1002_515e.fs:206: 2 pick dup reg-rl@ /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-device_1002_515e.fs:254:: CLK-CNTL-INDEX@ 8 ( CLK_CNTL_INDEX ) reg-rl@ ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-device_1002_515e.fs:262:: CLKDATA@ h# 0c ( CLK_CNTL_DATA ) reg-rl@ ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-device_1002_515e.fs:330: h# 158 ( MEM_SDRAM_MODE_REG ) reg-rl@ ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-device_1002_515e.fs:336: H# 150 reg-rl@ ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-device_1002_515e.fs:404: h# 50 reg-rl@ H# FEFFFFFF AND h# 02000200 or \ Clear 24 set 25 and 8-11 to 2 /Users/jam/Downloads/SLOF-master/board-js2x/slof/pci-device_1002_515e.fs:410: h# 50 reg-rl@ H# F8FFFFFF AND h# 03000000 or h# 50 reg-rl! /Users/jam/Downloads/SLOF-master/board-js2x/slof/tree.fs:31:: rtas-config-l@ ( config-addr -- value ) >conf-rtas rl@-le ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/attu.fs:24:f8070200 rl@ fffffff0 and f8070200 rl! /Users/jam/Downloads/SLOF-master/board-js2x/slof/attu.fs:42:: config-l@ >config rl@-le ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/u4-mem.fs:22:: i2c@ >i2c rl@ ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/u4-mem.fs:175:f8000860 rl@ 80000000 or f8000860 rl! 10000 0 DO LOOP /Users/jam/Downloads/SLOF-master/board-js2x/slof/u4-mem.fs:178:: mc@ f8002000 + rl@ ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/ioapic.fs:18:: ioapic@ ( offset -- x ) ioapic rb! ioapic 10 + rl@-le ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/memory.fs:22: 4 lshift f8002200 + rl@ dup 1 and 0= IF drop 0 EXIT THEN /Users/jam/Downloads/SLOF-master/board-js2x/slof/memory.fs:27:: mem-speed-u4 f8000800 rl@ 12 rshift 7 and 4 + d# 200 * 3 / ; /Users/jam/Downloads/SLOF-master/board-js2x/slof/memory.fs:28:: mem-speed-u3 f8000f60 rl@ c rshift f and d# 100 * 3 / ; /Users/jam/Downloads/SLOF-master/slof/fs/little-endian.fs:30:: rl@-le rl@ lbflip ; /Users/jam/Downloads/SLOF-master/slof/fs/little-endian.fs:42:: rl@-be rl@ ; /Users/jam/Downloads/SLOF-master/slof/fs/little-endian.fs:60:: rl@-le rl@ ; /Users/jam/Downloads/SLOF-master/slof/fs/little-endian.fs:72:: rl@-be rl@ lbflip ; /Users/jam/Downloads/SLOF-master/slof/fs/ide.fs:276: rl@-le \ read 32-bit as little endian value /Users/jam/Downloads/SLOF-master/slof/fs/fcode/1275.fs:379:: fc-l@ ( addr -- long ) dup MIN-RAM-SIZE > IF rl@ ELSE l@ THEN ; /Users/jam/Downloads/SLOF-master/slof/fs/fcode/tokens.fs:27: ['] rl@-le 0 234 set-token /Users/jam/Downloads/SLOF-master/slof/fs/fcode/tokens.fs:37: ['] rl@ 0 234 set-token /Users/jam/Downloads/SLOF-master/slof/fs/fcode/tokens.fs:433:fc-set-normal-mmio-tokens \ Set rw@, rw!, rl@, rl!, rx@ and rx! Jamess-Mac-Pro:~ jam$
On May 11, 2018, at 2:38 AM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
Hmmm…. I think you are on to something there, as I did note that they are words for the device in SLOF, before I execute the FCode.
Seems I need to figure out how to add the config* words to Openbios as that must be what 0xa08 is tripping over.
0 > dev /pci/@1 ok 0 > .properties assigned-addresses 82000830 00000000 83000000 00000000 00010000 82000810 00000000 81000000 00000000 01000000 c3000814 00002100 00000000 00000000 10000000 8200081c 00000000 82000000 00000000 01000000
name vga 76676100 ibm,req#msi 00000001 vendor-id 000010de device-id 00000141 revision-id 000000a2 class-code 00030000 interrupts 00000001 min-grant 00000000 max-latency 00000000 subsystem-id 00000050 subsystem-vendor-id 000010de cache-line-size 00000000 devsel-speed 00000000 ibm,loc-code vfio_vfio-pci:0000:00:01.0 7666696f 5f766669 6f2d7063 693a3030 30303a30 303a3031 2e3000 ibm,my-drc-index 40000008 #address-cells 00000003 #size-cells 00000002 reg 00000800 00000000 00000000 00000000 00000000 02000810 00000000 00000000 00000000 01000000 03000814 00000000 00000000 00000000 10000000 0300081c 00000000 00000000 00000000 01000000 02000830 00000000 00000000 00000000 00010000 ibm,pci-config-space-type 00000001 ok 0 > words setup classfile devicefile dma-map-out dma-map-in dma-free dma-alloc close open config-dump config-l! config-w! config-b! config-l@ config-w@ config-b@ my-puid my-phandle encode-unit decode-unit ok 0 >
On May 10, 2018, at 3:13 PM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 10/05/18 11:33, Jd Lyons via OpenBIOS wrote:
On 5/9/18, 11:45 AM, "OpenBIOS on behalf of Mark Cave-Ayland" <openbios-bounces@openbios.org on behalf of mark.cave-ayland@ilande.co.uk> wrote:
I suspect that it's something within that branch failing which is only visible at the final b(>resolve) once the condition is evaluated, so with indentation:
...
Most of that looks fairly normal, so I'd start by looking at the 0x9bd and 0xa08 FCodes which will have been generated further up in your output file.
new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) ------------------------- new-token 0x9bd b(constant) b(lit) 0x42000014 --------------------------
Okay so there's your first issue in 0xa08 - the PCI config words config-*@ and config-*! aren't (yet) implemented in Forth in OpenBIOS so you'll need to wrap the existing pci_config_read/pci_config_write() functions using something similar to the approach here:
https://github.com/openbios/openbios/commit/74ee111f1ff64415835c4c43b66b1528...
Here you can see that the C function bind_func() to used to call a C function from Forth by binding it to the named Forth word in the dictionary.
ATB,
Mark.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 11/05/18 08:11, Jd Lyons via OpenBIOS wrote:
Seems I could add config-1@ as a colon definition, however I’m not sure how too deal with r1@?
: rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ;
Just can’t figure how r1@ is implemented in SLOF?
That's definitely the long way around. Attached is a quick and dirty hack for PPC-only that implements config-l@ for reference: $ ./qemu-system-ppc -nographic -bios /home/build/src/openbios/openbios.git/openbios/obj-ppc/openbios-qemu.elf.nostrip
============================================================= OpenBIOS 1.1 [May 11 2018 07:49] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on May 11 2018 07:49 Trying hd:,\\:tbxi... Trying hd:,\ppc\bootinfo.txt... Trying hd:,%BOOT... No valid state has been set by load or init-program
0 > cd /pci/NE2000 ok 0 > .properties name "NE2000" vendor-id 10ec device-id 8029 revision-id 0 class-code 20000 AAPL,interrupts 17 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "network" model "NE2000 PCI" assigned-addresses -- 14 : 01 00 10 10 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 AAPL,address fe001000 reg 00001000 00000000 00000000 00000000 00000000 01001010 00000000 00000000 00000000 00000100 network-type "ethernet" removable "network" category "net" ok 0 > cd .. ok 0 > 1000 config-l@ u. 802910ec ok 0 > My reading of the IEEE-1275 PCI bindings is that you take the first 32-bit word of "reg" for the PCI configuration space address, so as you can see we return the device-id/vendor-id for the NE2000 NIC as above. ATB, Mark.
On Fri, May 11, 2018 at 09:11:40AM +0100, Mark Cave-Ayland wrote:
On 11/05/18 08:11, Jd Lyons via OpenBIOS wrote:
Seems I could add config-1@ as a colon definition, however I’m not sure how too deal with r1@?
: rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ;
Just can’t figure how r1@ is implemented in SLOF?
rl@, not r1@. It is defined in hvcall.code or nativeio.code, depending on what platform you are building for. It does a "raw" cache-inhibited 32-bit read.
That's definitely the long way around.
My reading of the IEEE-1275 PCI bindings is that you take the first 32-bit word of "reg" for the PCI configuration space address, so as you can see we return the device-id/vendor-id for the NE2000 NIC as above.
But the AGP and PCIe buses on a powermac are on separate PCI domains from the other PCI buses, and the PHBs have a different programming interface, too. I don't know how things work in QEMU, but if it emulates the hardware at all, you will have to find the proper config-* to use via walking parents in the device tree, etc., not shortcut to one implementation for all buses. Segher
Thanks Mark, now I’m down to stepping through the ddf word. Are map-in and map-out implemented in forth? Seems the nVidia roms use them, as most option roms would.
On May 11, 2018, at 4:11 AM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 11/05/18 08:11, Jd Lyons via OpenBIOS wrote:
Seems I could add config-1@ as a colon definition, however I’m not sure how too deal with r1@? : rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ; Just can’t figure how r1@ is implemented in SLOF?
That's definitely the long way around. Attached is a quick and dirty hack for PPC-only that implements config-l@ for reference:
$ ./qemu-system-ppc -nographic -bios /home/build/src/openbios/openbios.git/openbios/obj-ppc/openbios-qemu.elf.nostrip
============================================================= OpenBIOS 1.1 [May 11 2018 07:49] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on May 11 2018 07:49 Trying hd:,\\:tbxi... Trying hd:,\ppc\bootinfo.txt... Trying hd:,%BOOT... No valid state has been set by load or init-program
0 > cd /pci/NE2000 ok 0 > .properties name "NE2000" vendor-id 10ec device-id 8029 revision-id 0 class-code 20000 AAPL,interrupts 17 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "network" model "NE2000 PCI" assigned-addresses -- 14 : 01 00 10 10 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 AAPL,address fe001000 reg 00001000 00000000 00000000 00000000 00000000 01001010 00000000 00000000 00000000 00000100 network-type "ethernet" removable "network" category "net" ok 0 > cd .. ok 0 > 1000 config-l@ u. 802910ec ok 0 >
My reading of the IEEE-1275 PCI bindings is that you take the first 32-bit word of "reg" for the PCI configuration space address, so as you can see we return the device-id/vendor-id for the NE2000 NIC as above.
ATB,
Mark. <openbios-config-l-hack.patch>
On May 11, 2018, at 4:11 AM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 11/05/18 08:11, Jd Lyons via OpenBIOS wrote:
Seems I could add config-1@ as a colon definition, however I’m not sure how too deal with r1@? : rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ; Just can’t figure how r1@ is implemented in SLOF?
That's definitely the long way around. Attached is a quick and dirty hack for PPC-only that implements config-l@ for reference:
$ ./qemu-system-ppc -nographic -bios /home/build/src/openbios/openbios.git/openbios/obj-ppc/openbios-qemu.elf.nostrip
============================================================= OpenBIOS 1.1 [May 11 2018 07:49] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on May 11 2018 07:49 Trying hd:,\\:tbxi... Trying hd:,\ppc\bootinfo.txt... Trying hd:,%BOOT... No valid state has been set by load or init-program
0 > cd /pci/NE2000 ok 0 > .properties name "NE2000" vendor-id 10ec device-id 8029 revision-id 0 class-code 20000 AAPL,interrupts 17 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "network" model "NE2000 PCI" assigned-addresses -- 14 : 01 00 10 10 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 AAPL,address fe001000 reg 00001000 00000000 00000000 00000000 00000000 01001010 00000000 00000000 00000000 00000100 network-type "ethernet" removable "network" category "net" ok 0 > cd .. ok 0 > 1000 config-l@ u. 802910ec ok 0 >
My reading of the IEEE-1275 PCI bindings is that you take the first 32-bit word of "reg" for the PCI configuration space address, so as you can see we return the device-id/vendor-id for the NE2000 NIC as above.
ATB,
Mark. <openbios-config-l-hack.patch>
Not working correctly, 1000 config-l@ u. Returns f1001000?
Sorry., it’s returning:
============================================================= OpenBIOS 1.1 [May 11 2018 10:49] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 256M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on May 11 2018 10:49
0 > cd /pci/NE2000 ok 0 > .properties name "NE2000" vendor-id 10ec device-id 8029 revision-id 0 class-code 20000 interrupts 1 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "network" model "NE2000 PCI" assigned-addresses -- 14 : 01 00 70 10 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 reg 00007000 00000000 00000000 00000000 00000000 01007010 00000000 00000000 00000000 00000100 network-type "ethernet" removable "network" category "net" ok 0 > cd .. ok 0 > 1000 config-l@ u. ffffffff ok 0 >
On May 11, 2018, at 10:43 AM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
On May 11, 2018, at 4:11 AM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 11/05/18 08:11, Jd Lyons via OpenBIOS wrote:
Seems I could add config-1@ as a colon definition, however I’m not sure how too deal with r1@? : rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ; Just can’t figure how r1@ is implemented in SLOF?
That's definitely the long way around. Attached is a quick and dirty hack for PPC-only that implements config-l@ for reference:
$ ./qemu-system-ppc -nographic -bios /home/build/src/openbios/openbios.git/openbios/obj-ppc/openbios-qemu.elf.nostrip
============================================================= OpenBIOS 1.1 [May 11 2018 07:49] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on May 11 2018 07:49 Trying hd:,\\:tbxi... Trying hd:,\ppc\bootinfo.txt... Trying hd:,%BOOT... No valid state has been set by load or init-program
0 > cd /pci/NE2000 ok 0 > .properties name "NE2000" vendor-id 10ec device-id 8029 revision-id 0 class-code 20000 AAPL,interrupts 17 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "network" model "NE2000 PCI" assigned-addresses -- 14 : 01 00 10 10 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 AAPL,address fe001000 reg 00001000 00000000 00000000 00000000 00000000 01001010 00000000 00000000 00000000 00000100 network-type "ethernet" removable "network" category "net" ok 0 > cd .. ok 0 > 1000 config-l@ u. 802910ec ok 0 >
My reading of the IEEE-1275 PCI bindings is that you take the first 32-bit word of "reg" for the PCI configuration space address, so as you can see we return the device-id/vendor-id for the NE2000 NIC as above.
ATB,
Mark. <openbios-config-l-hack.patch>
Not working correctly, 1000 config-l@ u. Returns f1001000? -- 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 11/05/18 10:35, Segher Boessenkool wrote:
That's definitely the long way around.
My reading of the IEEE-1275 PCI bindings is that you take the first 32-bit word of "reg" for the PCI configuration space address, so as you can see we return the device-id/vendor-id for the NE2000 NIC as above.
But the AGP and PCIe buses on a powermac are on separate PCI domains from the other PCI buses, and the PHBs have a different programming interface, too.
I don't know how things work in QEMU, but if it emulates the hardware at all, you will have to find the proper config-* to use via walking parents in the device tree, etc., not shortcut to one implementation for all buses.
If you look at the patch you can see that it implements the words on the PCI bus node, so that part is all fine - the main problem with the patch is that it hard-codes the PCI config space address. ATB, Mark.
On 11/05/18 12:46, Jd Lyons via OpenBIOS wrote:
Thanks Mark, now I’m down to stepping through the ddf word.
Are map-in and map-out implemented in forth?
Seems the nVidia roms use them, as most option roms would.
From memory PCI map-in is supported, map-out isn't but could be implemented fairly easily. Do you see that in the NVidia ROM image? ATB, Mark.
On 11/05/18 15:54, Jd Lyons via OpenBIOS wrote:
Sorry., it’s returning:
============================================================= OpenBIOS 1.1 [May 11 2018 10:49] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 256M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on May 11 2018 10:49
0 > cd /pci/NE2000 ok 0 > .properties name "NE2000" vendor-id 10ec device-id 8029 revision-id 0 class-code 20000 interrupts 1 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "network" model "NE2000 PCI" assigned-addresses -- 14 : 01 00 70 10 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 reg 00007000 00000000 00000000 00000000 00000000 01007010 00000000 00000000 00000000 00000100 network-type "ethernet" removable "network" category "net" ok 0 > cd .. ok 0 > 1000 config-l@ u. ffffffff ok 0 >
What command line are you using to launch qemu-system-ppc as the machine configuration looks different to mine? The config space address of a PCI device is the first 32-bit word in the "reg" property so for your machine above you need to do: 7000 config-l@ u. ATB, Mark.
On 2018-May-11 10:54 , Jd Lyons via OpenBIOS wrote:
0 > 1000 config-l@ u. ffffffff ok
That should be normal behaviour for a device not present (in the above case, device 2 on that pci bus). Note that "cd" isn't always sufficient to be able to activate words in a node - many of them require an ihandle, which means you need to select the node, not just cd to it. cd changes your dictionary, but does not set up contexts for path or instance (phandle or ihandle). This will happen during ordinary FCode execution (part of the setup is that the parents have been initialized and the active node is set up by the process that brings in the FCode), but you may get different results from the ok prompt by just cd'ing to a node. Also note, the endianness of rl@/rw@ words may be different at the ok prompt than from a device's FCode. In OpenBoot, the decision was made to literally change the meaning of rl@ to point to le-rl@ or be-rl@ depending on the context of the caller. I don't know if that happens in OpenBios. So if you get something that looks like the wrong endian (you were expecting 01234567 and you got 67452301), make sure the problem persists when you are running the code as FCode, as opposed to at the ok prompt.
Yes, along with some of the other config* words: new-token 0xa00 b(defer) new-token 0xa01 b(defer) new-token 0xa02 b(defer) new-token 0xa03 b(:) my-space or b(") ( len=0x12 [18 bytes] ) " assigned-addresses" get-my-property invert b?branch 0x0033 ( =dec 51) rot >r b(<mark) dup b?branch 0x0029 ( =dec 41) decode-phys b(lit) 0xff and r@ b(lit) 0xff and = b?branch 0x000a ( =dec 10) 2swap 2drop r> exit bbranch 0x0005 () b(>resolve) 2drop b(>resolve) decode-int drop decode-int drop bbranch 0xffd8 ( =dec -40) b(>resolve) 2drop r> b(>resolve) >r my-address r> b(;) new-token 0xa04 b(:) b(") ( len=6 ) " map-in" $call-parent b(;) new-token 0xa05 b(:) b(") ( len=7 ) " map-out" $call-parent b(;) new-token 0xa06 b(:) b(") ( len=9 ) " config-w@" $call-parent b(;) new-token 0xa07 b(:) b(") ( len=9 ) " config-w!" $call-parent b(;) new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) new-token 0xa09 b(:) b(") ( len=9 ) " config-l!" $call-parent b(;) new-token 0xa0a b(:) (unnamed-fcode) [0x9a3] + rb@ b(;) new-token 0xa0b b(:) (unnamed-fcode) [0x9a3] + rb! b(;) new-token 0xa0c b(:) swap (unnamed-fcode) [0xa0b] b(;) new-token 0xa0d b(:) (unnamed-fcode) [0x9a3] + rl@ b(;) new-token 0xa0e b(:) (unnamed-fcode) [0x9a3] + rl! b(;) new-token 0xa0f b(:) (unnamed-fcode) [0x9a3] + rl! b(;)
On May 11, 2018, at 11:31 AM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 11/05/18 12:46, Jd Lyons via OpenBIOS wrote:
Thanks Mark, now I’m down to stepping through the ddf word. Are map-in and map-out implemented in forth? Seems the nVidia roms use them, as most option roms would.
From memory PCI map-in is supported, map-out isn't but could be implemented fairly easily. Do you see that in the NVidia ROM image?
ATB,
Mark.
As far as I can tell, here is a breakdown of 0xddf, I’m getting an exception here now, but I’m not sure where or how to debug it. I did add the other config* words, but I’m unsure I did it correctly, and I can’t seem to debug them when they are called in the Fcode? new-token 0xddf b(:) b(lit) 0x10 (unnamed-fcode) [0xdde] new-token 0xdde b(:) my-space + dup (unnamed-fcode) [0xa08] new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) swap -1 over (unnamed-fcode) [0xa09] new-token 0xa09 b(:) b(") ( len=9 ) " config-l!" $call-parent b(;) dup (unnamed-fcode) [0xa08] new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) b(lit) 0xfffffff0dde and negate -rot (unnamed-fcode) [0xa0 b(;) new-token 0xa0b b(:) (unnamed-fcode) [0x9a3] + rb! b(;) b(to) (unnamed-fcode) [0x9c3] new-token 0x9c3 b(value) 0 b(lit) 0x14 (unnamed-fcode) [0xdde] new-token 0xdde b(:) my-space + dup (unnamed-fcode) [0xa08] new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) swap -1 over (unnamed-fcode) [0xa09] new-token 0xa09 b(:) b(") ( len=9 ) " config-l!" $call-parent b(;) dup (unnamed-fcode) [0xa08] new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) b(lit) 0xfffffff0dde and negate -rot (unnamed-fcode) [0xa0 b(;) new-token 0xa0b b(:) (unnamed-fcode) [0x9a3] + rb! b(;) b(to) (unnamed-fcode) [0x9c4] new-token 0x9c4 b(value) 0 (unnamed-fcode) [0x9c0] new-token 0x9c0 b(defer) b(lit) 0xff and (unnamed-fcode) [0xdde] new-token 0xdde b(:) my-space + dup (unnamed-fcode) [0xa08] new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) swap -1 over (unnamed-fcode) [0xa09] new-token 0xa09 b(:) b(") ( len=9 ) " config-l!" $call-parent b(;) dup (unnamed-fcode) [0xa08] new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) b(lit) 0xfffffff0dde and negate -rot (unnamed-fcode) [0xa0 b(;) new-token 0xa0b b(:) (unnamed-fcode) [0x9a3] + rb! b(;) b(to) (unnamed-fcode) [0x9c6] new-token 0x9c6 b(value) b(lit) 0x30 (unnamed-fcode) [0xdde] new-token 0xdde b(:) my-space + dup (unnamed-fcode) [0xa08] new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) swap -1 over (unnamed-fcode) [0xa09] new-token 0xa09 b(:) b(") ( len=9 ) " config-l!" $call-parent b(;) dup (unnamed-fcode) [0xa08] new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) b(lit) 0xfffffff0dde and negate -rot (unnamed-fcode) [0xa0 b(;) new-token 0xa0b b(:) (unnamed-fcode) [0x9a3] + rb! b(;) b(to) (unnamed-fcode) [0x9c5] new-token 0x9c5 b(value) 0 (unnamed-fcode) [0x9bf] new-token 0x9bf b(constant) (unnamed-fcode) [0xa03] new-token 0xa03 b(:) my-space or b(") ( len=0x12 [18 bytes] ) " assigned-addresses" get-my-property invert b?branch 0x0033 ( =dec 51) rot >r b(<mark) dup b?branch 0x0029 ( =dec 41) decode-phys b(lit) 0xff and r@ b(lit) 0xff and = b?branch 0x000a ( =dec 10) 2swap 2drop r> exit bbranch 0x0005 () b(>resolve) 2drop b(>resolve) decode-int drop decode-int drop bbranch 0xffd8 ( =dec -40) b(>resolve) 2drop r> b(>resolve) >r my-address r> b(;) (unnamed-fcode) [0x9c5] new-token 0x9c5 b(value) 0 (unnamed-fcode) [0xa04] new-token 0xa04 b(:) b(") ( len=6 ) " map-in" $call-parent b(;) b(to) (unnamed-fcode) [0x9a5] new-token 0x9a5 b(value) -1 (unnamed-fcode) [0x9bc] new-token 0x9bc b(constant) b(lit) 0x2000014 (unnamed-fcode) [0xa03] new-token 0xa03 b(:) my-space or b(") ( len=0x12 [18 bytes] ) " assigned-addresses" get-my-property invert b?branch 0x0033 ( =dec 51) rot >r b(<mark) dup b?branch 0x0029 ( =dec 41) decode-phys b(lit) 0xff and r@ b(lit) 0xff and = b?branch 0x000a ( =dec 10) 2swap 2drop r> exit bbranch 0x0005 () b(>resolve) 2drop b(>resolve) decode-int drop decode-int drop bbranch 0xffd8 ( =dec -40) b(>resolve) 2drop r> b(>resolve) >r my-address r> b(;) (unnamed-fcode) [0x9c3] new-token 0x9c3 b(value) 0 (unnamed-fcode) [0xa04] new-token 0xa04 b(:) b(") ( len=6 ) " map-in" $call-parent b(;) b(to) (unnamed-fcode) [0x9a3] new-token 0x9a3 b(value) -1 (unnamed-fcode) [0x9c0] new-token 0x9c0 b(defer) b(lit) 0x200001c (unnamed-fcode) [0xa03] new-token 0xa03 b(:) my-space or b(") ( len=0x12 [18 bytes] ) " assigned-addresses" get-my-property invert b?branch 0x0033 ( =dec 51) rot >r b(<mark) dup b?branch 0x0029 ( =dec 41) decode-phys b(lit) 0xff and r@ b(lit) 0xff and = b?branch 0x000a ( =dec 10) 2swap 2drop r> exit bbranch 0x0005 () b(>resolve) 2drop b(>resolve) decode-int drop decode-int drop bbranch 0xffd8 ( =dec -40) b(>resolve) 2drop r> b(>resolve) >r my-address r> b(;) (unnamed-fcode) [0x9c6] new-token 0x9c6 b(value) (unnamed-fcode) [0xa04] new-token 0xa04 b(:) b(") ( len=6 ) " map-in" $call-parent b(;) b(to) (unnamed-fcode) [0x9a6] new-token 0x9c6 b(value) (unnamed-fcode) [0x9bd] new-token 0x9bd b(constant) b(lit) 0x42000014 (unnamed-fcode) [0xa03] new-token 0xa03 b(:) my-space or b(") ( len=0x12 [18 bytes] ) " assigned-addresses" get-my-property invert b?branch 0x0033 ( =dec 51) rot >r b(<mark) dup b?branch 0x0029 ( =dec 41) decode-phys b(lit) 0xff and r@ b(lit) 0xff and = b?branch 0x000a ( =dec 10) 2swap 2drop r> exit bbranch 0x0005 () b(>resolve) 2drop b(>resolve) decode-int drop decode-int drop bbranch 0xffd8 ( =dec -40) b(>resolve) 2drop r> b(>resolve) >r my-address r> b(;) (unnamed-fcode) [0x9c4] new-token 0x9c4 b(value) 0 (unnamed-fcode) [0xa04] new-token 0xa04 b(:) b(") ( len=6 ) " map-in" $call-parent b(;) b(to) (unnamed-fcode) [0x9a4] new-token 0x9a4 b(value) -1 (unnamed-fcode) [0xa3b] new-token 0xa3b b(:) my-space la1+ dup (unnamed-fcode) [0xa06] 2 or swap (unnamed-fcode) [0xa07] b(;) (unnamed-fcode) [0xa3d] new-token 0xa3d b(:) (unnamed-fcode) [0x949] invert b?branch 0x0013 ( =dec 19) b(lit) 0x1000000 b(lit) 0x4 (unnamed-fcode) [0xa0f] -1 b(to) (unnamed-fcode) [0x949] b(>resolve) b(;) (unnamed-fcode) [0xddd] new-token 0xddd b(:) (unnamed-fcode) [0x93d] b(lit) 0x25 = b?branch 0x0024 ( =dec 36) b(lit) 0x1002c0 dup (unnamed-fcode) [0xb7b] b(lit) 0x100 or (unnamed-fcode) [0xb81] b(lit) 0x1002c0 dup (unnamed-fcode) [0xb7b] b(lit) 0x100 invert and (unnamed-fcode) [0xb81] b(>resolve) b(;) b(;)
On May 11, 2018, at 11:24 PM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
Yes, along with some of the other config* words:
r b(<mark) dup b?branch 0x0029 ( =dec 41) decode-phys b(lit) 0xff and r@ b(lit) 0xff and = b?branch 0x000a ( =dec 10) 2swap 2drop r> exit bbranch 0x0005 () b(>resolve) 2drop b(>resolve) decode-int drop decode-int drop bbranch 0xffd8 ( =dec -40) b(>resolve) 2drop r> b(>resolve) r my-address r> b(;) new-token 0xa04 b(:) b(") ( len=6 ) " map-in" $call-parent b(;) new-token 0xa05 b(:) b(") ( len=7 ) " map-out" $call-parent b(;) new-token 0xa06 b(:) b(") ( len=9 ) " config-w@" $call-parent b(;) new-token 0xa07 b(:) b(") ( len=9 ) " config-w!" $call-parent b(;) new-token 0xa08 b(:) b(") ( len=9 ) " config-l@" $call-parent b(;) new-token 0xa09 b(:) b(") ( len=9 ) " config-l!" $call-parent b(;) new-token 0xa0a b(:) (unnamed-fcode) [0x9a3]
new-token 0xa00 b(defer) new-token 0xa01 b(defer) new-token 0xa02 b(defer) new-token 0xa03 b(:) my-space or b(") ( len=0x12 [18 bytes] ) " assigned-addresses" get-my-property invert b?branch 0x0033 ( =dec 51) rot + rb@ b(;) new-token 0xa0b b(:) (unnamed-fcode) [0x9a3] + rb! b(;) new-token 0xa0c b(:) swap (unnamed-fcode) [0xa0b] b(;) new-token 0xa0d b(:) (unnamed-fcode) [0x9a3] + rl@ b(;) new-token 0xa0e b(:) (unnamed-fcode) [0x9a3] + rl! b(;) new-token 0xa0f b(:) (unnamed-fcode) [0x9a3] + rl! b(;)
On May 11, 2018, at 11:31 AM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 11/05/18 12:46, Jd Lyons via OpenBIOS wrote:
Thanks Mark, now I’m down to stepping through the ddf word. Are map-in and map-out implemented in forth? Seems the nVidia roms use them, as most option roms would.
From memory PCI map-in is supported, map-out isn't but could be implemented fairly easily. Do you see that in the NVidia ROM image?
ATB,
Mark.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 12/05/18 11:47, Jd Lyons wrote:
As far as I can tell, here is a breakdown of 0xddf, I’m getting an exception here now, but I’m not sure where or how to debug it.
I did add the other config* words, but I’m unsure I did it correctly, and I can’t seem to debug them when they are called in the Fcode?
Sorry it has taken me a while to respond to this, it's fairly crazy in the day job right now. From what I can see in the provided output it is just the config-*@, config-*! and map-out words missing from OpenBIOS which shouldn't be too difficult to fix. There also seems to be an assumption that the "assigned-addresses" property is present, or at least I can see FCode that tries to read it but nothing to write it? Hopefully things will start to calm down soon, but in the meantime if you post you patch for the PCI config words I will be happy to take a look and review them. In terms of debugging, once you're in C land it's fairly easy: alter Makefile.target to change -Os to -O0 to enable debugging symbols for the build and then you can single step directly in the guest with sparc64-linux-gdb via QEMU's gdbstub, setting breakpoints as required. ATB, Mark.
On 2018-May-19 04:25 , Mark Cave-Ayland wrote:
From what I can see in the provided output it is just the config-*@, config-*! and map-out words missing from OpenBIOS which shouldn't be too difficult to fix. There also seems to be an assumption that the "assigned-addresses" property is present, or at least I can see FCode that tries to read it but nothing to write it?
That's a reasonable/required assumption. "assigned-addresses" should be produced by the framework during the probe before the FCode runs. In a PCI device, it should have an "assigned-addresses" entry for each BAR. Something like: assigned-addresses 81090110 00000000 00002100 00000000 00000100 82090114 00000000 00604000 00000000 00004000 82090130 00000000 00680000 00000000 00040000 In the above, the first cell of each entry describes the space for each BAR. The first set is IO space for BAR 10, at location 2100 size 100 bytes. The second is memory space for BAR 14 at 604000 (in PCI space), size 4000 bytes. The third entry is for the ROMBAR, BAR 30, assigned to 680000 size 40000.
On May 19, 2018, at 5:16 AM, Tarl Neustaedter <tarl-b2@tarl.net> wrote:
On 2018-May-19 04:25 , Mark Cave-Ayland wrote:
From what I can see in the provided output it is just the config-*@, config-*! and map-out words missing from OpenBIOS which shouldn't be too difficult to fix. There also seems to be an assumption that the "assigned-addresses" property is present, or at least I can see FCode that tries to read it but nothing to write it?
That's a reasonable/required assumption. "assigned-addresses" should be produced by the framework during the probe before the FCode runs. In a PCI device, it should have an "assigned-addresses" entry for each BAR. Something like:
assigned-addresses 81090110 00000000 00002100 00000000 00000100 82090114 00000000 00604000 00000000 00004000 82090130 00000000 00680000 00000000 00040000
In the above, the first cell of each entry describes the space for each BAR. The first set is IO space for BAR 10, at location 2100 size 100 bytes. The second is memory space for BAR 14 at 604000 (in PCI space), size 4000 bytes. The third entry is for the ROMBAR, BAR 30, assigned to 680000 size 40000.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
Hmmm….. Here are the assigned-addresses for both SLOF and Openbios before the Fcode is run: SLOF assigned-addresses 82000830 00000000 83000000 00000000 00010000 82000810 00000000 81000000 00000000 01000000 c3000814 00002100 00000000 00000000 10000000 8200081c 00000000 82000000 00000000 01000000 Openbios: assigned-addresses -- 3c : 02 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01 00 00 00 c3 00 78 14 00 00 00 00 90 00 00 00 00 00 00 00 10 00 00 00 83 00 78 1c 00 00 00 00 a0 00 00 00 00 00 00 00 01 00 00 00 Not real sure what to make of them, Tarl?
On May 19, 2018, at 11:26 AM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
On May 19, 2018, at 5:16 AM, Tarl Neustaedter <tarl-b2@tarl.net> wrote:
On 2018-May-19 04:25 , Mark Cave-Ayland wrote:
From what I can see in the provided output it is just the config-*@, config-*! and map-out words missing from OpenBIOS which shouldn't be too difficult to fix. There also seems to be an assumption that the "assigned-addresses" property is present, or at least I can see FCode that tries to read it but nothing to write it?
That's a reasonable/required assumption. "assigned-addresses" should be produced by the framework during the probe before the FCode runs. In a PCI device, it should have an "assigned-addresses" entry for each BAR. Something like:
assigned-addresses 81090110 00000000 00002100 00000000 00000100 82090114 00000000 00604000 00000000 00004000 82090130 00000000 00680000 00000000 00040000
In the above, the first cell of each entry describes the space for each BAR. The first set is IO space for BAR 10, at location 2100 size 100 bytes. The second is memory space for BAR 14 at 604000 (in PCI space), size 4000 bytes. The third entry is for the ROMBAR, BAR 30, assigned to 680000 size 40000.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
Hmmm…..
Here are the assigned-addresses for both SLOF and Openbios before the Fcode is run:
SLOF
assigned-addresses 82000830 00000000 83000000 00000000 00010000 82000810 00000000 81000000 00000000 01000000 c3000814 00002100 00000000 00000000 10000000 8200081c 00000000 82000000 00000000 01000000
Openbios:
assigned-addresses -- 3c : 02 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01 00 00 00 c3 00 78 14 00 00 00 00 90 00 00 00 00 00 00 00 10 00 00 00 83 00 78 1c 00 00 00 00 a0 00 00 00 00 00 00 00 01 00 00 00
Not real sure what to make of them, Tarl? -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
Here it is again in a format that makes it a little easier to read: SLOF assigned-addresses 82000830 00000000 83000000 00000000 00010000 82000810 00000000 81000000 00000000 01000000 c3000814 00002100 00000000 00000000 10000000 8200081c 00000000 82000000 00000000 01000000 Openbios: assigned-addresses-- 3c : 02007810 00000000 81000000 00000000 01000000 c3007814 00000000 90000000 00000000 10000000 8300781c 00000000 a0000000 00000000 01000000 Obviously Openbios isn’t getting the ROM bar 0x30. I did some hacking a few years back to work on 3dfx Voodoo emulation, I hacked together some code using Qemu’s secondary-vga device as a Voodoo2 and Qemu’s VGA device as a Voodoo5. One thing I noted was that I could only read the ROM offset 0x30 in PCI Peak under OS 9 if I enabled the secondary-vga device. So a little hacking will likely be necessary to get Qeum/Openbios to property assign the ROM BAR.
On 2018-May-19 11:53 , Jd Lyons wrote:
SLOF
assigned-addresses 82000830 00000000 83000000 00000000 00010000 82000810 00000000 81000000 00000000 01000000 c3000814 00002100 00000000 00000000 10000000 8200081c 00000000 82000000 00000000 01000000
That looks reasonable. It's somewhat unusual to have the ROMBAR be the first entry, but not prohibited. I'm a little startled by BAR 14; it's 64-bit memory space, starting at 2100.0000.0000 for length 10000000. Not out of question, but on SPARC I didn't see addresses assigned that high up (I recall we usually started at 2.0000.0000).
Openbios:
assigned-addresses-- 3c : 02007810 00000000 81000000 00000000 01000000 c3007814 00000000 90000000 00000000 10000000 8300781c 00000000 a0000000 00000000 01000000
Obviously Openbios isn’t getting the ROM bar 0x30.
The ROMBAR absence might not be a problem - it has to be manually turned on (low order bit in the address, as I recall), so if you leave it turned off, you don't need to assign it an address. I'd generally have the framework assign it an address anyway, just so you didn't run into allocation problems at the time when you do need to turn it on. BAR 14 is listed as 64-bit memory, starting at 9000.0000 - way down in 32-bit address space. Some FCodes may get confused by that. It generally shouldn't be a problem, but it's something to worry about. BAR 10 in the above is listed starting with 02 instead of 82... My recollection is that the "8" is the "n" (non-relocatable) bit in the descriptor... Ah, yes, see https://www.openfirmware.info/data/docs/bus.pci.pdf section 2.2.1.1 - I'd generally expect that to be set in the assigned-addresses specification (once the framework has assigned an address, the client isn't allowed to relocate it. The bit is more intended for a "reg" specification.) So, Openbios is doing things a bit funky, but not entirely unreasonable. I"d keep in mind the potential confusion with 32/64 bit addressing in the FCode, but aside from that, the only thing I'd worry about is the missing "n" bit on BAR 10.
On May 19, 2018, at 1:02 PM, Tarl Neustaedter <tarl-b2@tarl.net> wrote:
On 2018-May-19 11:53 , Jd Lyons wrote:
SLOF
assigned-addresses 82000830 00000000 83000000 00000000 00010000 82000810 00000000 81000000 00000000 01000000 c3000814 00002100 00000000 00000000 10000000 8200081c 00000000 82000000 00000000 01000000
That looks reasonable. It's somewhat unusual to have the ROMBAR be the first entry, but not prohibited. I'm a little startled by BAR 14; it's 64-bit memory space, starting at 2100.0000.0000 for length 10000000. Not out of question, but on SPARC I didn't see addresses assigned that high up (I recall we usually started at 2.0000.0000).
Thanks Tarl, I think the reason SLOF has the ROM BAR as the first address is the way QEMU handles VGA ROM’s, you have to pass a rom you want to use from the Qemu command line when doing PCI Passthough of a VGA device, Qemu-x86 handles things a little better, however I still have trouble if I don’t pass Qemu a romfile if I reboot my Qemu-x86 system. -device vfio-pci,host=24:00.0,multifunction=on,x-vga=on,romfile=./6600.rom \ I got the 6600 to display video using the pseries machine in qemu-system-ppc64 with the Power8 cpu and SLOF. The nouveau drivers complained that it couldn’t read the cards ROM until I passed the romfile= command argument. However, any graphical display to the card resulted in display corruption. I had no trouble with the text display from the TTY in Fedora 27. I haven’t looked at the NVDA,BMP property to ensure that it is being calculated correctly, as this type of display corruption is normal for the wrong 32 bit words getting written to the graphics card registers. I’m hoping I’m not running into guest to host endianness issues, but I don’t really think that I am.
Openbios:
assigned-addresses-- 3c : 02007810 00000000 81000000 00000000 01000000 c3007814 00000000 90000000 00000000 10000000 8300781c 00000000 a0000000 00000000 01000000
Obviously Openbios isn’t getting the ROM bar 0x30.
The ROMBAR absence might not be a problem - it has to be manually turned on (low order bit in the address, as I recall), so if you leave it turned off, you don't need to assign it an address. I'd generally have the framework assign it an address anyway, just so you didn't run into allocation problems at the time when you do need to turn it on.
I’ll see if I can get the ROM BAR to work first, as I have some idea how to hack that in, then I’ll see if I can address the “n” bit.
BAR 14 is listed as 64-bit memory, starting at 9000.0000 - way down in 32-bit address space. Some FCodes may get confused by that. It generally shouldn't be a problem, but it's something to worry about.
BAR 10 in the above is listed starting with 02 instead of 82... My recollection is that the "8" is the "n" (non-relocatable) bit in the descriptor... Ah, yes, seehttps://www.openfirmware.info/data/docs/bus.pci.pdf <https://www.openfirmware.info/data/docs/bus.pci.pdf> section 2.2.1.1 - I'd generally expect that to be set in the assigned-addresses specification (once the framework has assigned an address, the client isn't allowed to relocate it. The bit is more intended for a "reg" specification.)
So, Openbios is doing things a bit funky, but not entirely unreasonable. I"d keep in mind the potential confusion with 32/64 bit addressing in the FCode, but aside from that, the only thing I'd worry about is the missing "n" bit on BAR 10.
Oops. Just spotted something else weird: On 2018-May-19 11:53 , Jd Lyons via OpenBIOS wrote:
[...] Here it is again in a format that makes it a little easier to read:
SLOF
assigned-addresses 82000830 00000000 83000000 00000000 00010000 82000810 00000000 81000000 00000000 01000000 c3000814 00002100 00000000 00000000 10000000 8200081c 00000000 82000000 00000000 01000000
Openbios:
assigned-addresses-- 3c : 02007810 00000000 81000000 00000000 01000000 c3007814 00000000 90000000 00000000 10000000 8300781c 00000000 a0000000 00000000 01000000
Bar 1c is being assigned 32-bit memory by SLOF, but 64-bit memory by Openbios (albeit in the 32-bit range). By specifying "83" as the first byte, it's saying that both BARs 1C and 20 are being used to address this chunk of memory. Since SLOF thinks it only has BAR 1C (and nothing in BAR 20), that strikes me as unlikely. It's probably worth checking what the cards BARs are actually doing, and figuring out which of those two representations of BAR 1C is wrong.
Thanks Mark, I just defined the other config words as colon definitions, but I’m pretty sure now that isn’t working correctly. dev /pci : rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ; : rl!-le >r lbflip r> rl! ; : rw!-le >r wbflip r> rw! ; : rw@-le rw@ wbflip ; : config-l! >config rl!-le ; : config-w! >config cr ." config-w! " 2dup . space . rw!-le ; : config-w@ >config cr ." config-w@ " dup . rw@-le space dup . ; I hate to be a bother, but when you find the time, if you could try and implement the other config words, that would be great.
On May 19, 2018, at 4:25 AM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 12/05/18 11:47, Jd Lyons wrote:
As far as I can tell, here is a breakdown of 0xddf, I’m getting an exception here now, but I’m not sure where or how to debug it. I did add the other config* words, but I’m unsure I did it correctly, and I can’t seem to debug them when they are called in the Fcode?
Sorry it has taken me a while to respond to this, it's fairly crazy in the day job right now.
From what I can see in the provided output it is just the config-*@, config-*! and map-out words missing from OpenBIOS which shouldn't be too difficult to fix. There also seems to be an assumption that the "assigned-addresses" property is present, or at least I can see FCode that tries to read it but nothing to write it?
Hopefully things will start to calm down soon, but in the meantime if you post you patch for the PCI config words I will be happy to take a look and review them.
In terms of debugging, once you're in C land it's fairly easy: alter Makefile.target to change -Os to -O0 to enable debugging symbols for the build and then you can single step directly in the guest with sparc64-linux-gdb via QEMU's gdbstub, setting breakpoints as required.
ATB,
Mark.
On 20/05/18 16:36, Jd Lyons via OpenBIOS wrote:
Thanks Mark,
I just defined the other config words as colon definitions, but I’m pretty sure now that isn’t working correctly.
dev /pci : rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ; : rl!-le >r lbflip r> rl! ; : rw!-le >r wbflip r> rw! ; : rw@-le rw@ wbflip ; : config-l! >config rl!-le ; : config-w! >config cr ." config-w! " 2dup . space . rw!-le ; : config-w@ >config cr ." config-w@ " dup . rw@-le space dup . ;
I hate to be a bother, but when you find the time, if you could try and implement the other config words, that would be great.
Yes I will try my best, although I still have a backlog from the past few months to get on top of at the same time - any patches appreciated :) One thing I did notice on my travels though: https://git.qemu.org/?p=openbios.git;a=blob;f=forth/device/other.fs;h=b39007... Looks like the r* words are currently missing an implementation. ATB, Mark.
On Mon, May 21, 2018 at 09:20:12PM +0100, Mark Cave-Ayland wrote:
On 20/05/18 16:36, Jd Lyons via OpenBIOS wrote:
Thanks Mark,
I just defined the other config words as colon definitions, but I’m pretty sure now that isn’t working correctly.
dev /pci : rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ; : rl!-le >r lbflip r> rl! ; : rw!-le >r wbflip r> rw! ; : rw@-le rw@ wbflip ; : config-l! >config rl!-le ; : config-w! >config cr ." config-w! " 2dup . space . rw!-le ; : config-w@ >config cr ." config-w@ " dup . rw@-le space dup . ;
I hate to be a bother, but when you find the time, if you could try and implement the other config words, that would be great.
Yes I will try my best, although I still have a backlog from the past few months to get on top of at the same time - any patches appreciated :)
One thing I did notice on my travels though: https://git.qemu.org/?p=openbios.git;a=blob;f=forth/device/other.fs;h=b39007...
Looks like the r* words are currently missing an implementation.
Note that rb@ etc. are bus-specific. h# 230 get-token and all that. Segher
On 21.05.2018 22:31, Segher Boessenkool wrote:
On Mon, May 21, 2018 at 09:20:12PM +0100, Mark Cave-Ayland wrote:
On 20/05/18 16:36, Jd Lyons via OpenBIOS wrote:
Thanks Mark,
I just defined the other config words as colon definitions, but I’m pretty sure now that isn’t working correctly.
dev /pci : rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ; : rl!-le >r lbflip r> rl! ; : rw!-le >r wbflip r> rw! ; : rw@-le rw@ wbflip ; : config-l! >config rl!-le ; : config-w! >config cr ." config-w! " 2dup . space . rw!-le ; : config-w@ >config cr ." config-w@ " dup . rw@-le space dup . ;
I hate to be a bother, but when you find the time, if you could try and implement the other config words, that would be great.
Yes I will try my best, although I still have a backlog from the past few months to get on top of at the same time - any patches appreciated :)
One thing I did notice on my travels though: https://git.qemu.org/?p=openbios.git;a=blob;f=forth/device/other.fs;h=b39007...
Looks like the r* words are currently missing an implementation.
Note that rb@ etc. are bus-specific. h# 230 get-token and all that.
While we're at this topic: Note that there are also some bad fcode ROMs around which use the non-register memory access functions for accessing MMIO memory. SLOF has an ugly work-around included to get these working: https://github.com/aik/SLOF/blob/master/slof/fs/fcode/1275.fs#L371 Note sure whether this is applicable for your PCI card, though. Thomas
On 22/05/18 08:44, Thomas Huth wrote:
On 21.05.2018 22:31, Segher Boessenkool wrote:
On Mon, May 21, 2018 at 09:20:12PM +0100, Mark Cave-Ayland wrote:
On 20/05/18 16:36, Jd Lyons via OpenBIOS wrote:
Thanks Mark,
I just defined the other config words as colon definitions, but I’m pretty sure now that isn’t working correctly.
dev /pci : rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ; : rl!-le >r lbflip r> rl! ; : rw!-le >r wbflip r> rw! ; : rw@-le rw@ wbflip ; : config-l! >config rl!-le ; : config-w! >config cr ." config-w! " 2dup . space . rw!-le ; : config-w@ >config cr ." config-w@ " dup . rw@-le space dup . ;
I hate to be a bother, but when you find the time, if you could try and implement the other config words, that would be great.
Yes I will try my best, although I still have a backlog from the past few months to get on top of at the same time - any patches appreciated :)
One thing I did notice on my travels though: https://git.qemu.org/?p=openbios.git;a=blob;f=forth/device/other.fs;h=b39007...
Looks like the r* words are currently missing an implementation.
Note that rb@ etc. are bus-specific. h# 230 get-token and all that.
While we're at this topic: Note that there are also some bad fcode ROMs around which use the non-register memory access functions for accessing MMIO memory. SLOF has an ugly work-around included to get these working:
https://github.com/aik/SLOF/blob/master/slof/fs/fcode/1275.fs#L371
Note sure whether this is applicable for your PCI card, though.
Meh that's a fairly horrible hack. I'm not quite sure how this will affect OpenBIOS yet simply because all of the current PCI drivers in OpenBIOS fall back to the C bindings rather than using Forth (which is why JD has been the first person to experience these kinds of issues). ATB, Mark.
I picked up a PCI-E 1x to PCI adapter and gave a few cards a go. A Firewire card worked, I was able to use iChat AV with an old FW iSight, both video and Mic worked.
On May 28, 2018, at 3:07 PM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
I picked up a PCI-E 1x to PCI adapter and gave a few cards a go. A Firewire card worked, I was able to use iChat AV with an old FW iSight, both video and Mic worked.
Worked inside a QEMU VM?
Yes qemu-system-ppc on an AMD Ryzen host PCI-E to PCI adapter OS X Tiger PPC.
On May 28, 2018, at 3:30 PM, Programmingkid <programmingkidx@gmail.com> wrote:
On May 28, 2018, at 3:07 PM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
I picked up a PCI-E 1x to PCI adapter and gave a few cards a go. A Firewire card worked, I was able to use iChat AV with an old FW iSight, both video and Mic worked.
Worked inside a QEMU VM? -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
The odd thing PK is the Firewire card worked perfect with qemu-System-ppc in PCI passthrough, but failed to work correct with qemu-system-x86_64 with a OS X guest. The device show up on the PCI bus, but OS X can’t detect anything plugged into it. I’ll have to do a little more hacking and see what I can do. As to the PCI-E 1x to PCI adapter, it didn’t want to work with a Radeon 9200 PCI, the host system wouldn’t boot at all with that card installed. I have an old S3 pic via card and that one seemed to work, however the VGA connector was blocked by my case so I couldn’t test it with qemu_x86 to see if I could get VGA from the card in passthrough. I also tested a sound blaster audigy gold, and the Firewire port works under qemu-ppc, and I tested a USB 1.1 card that had the same issue under OS X intel in a qemu guest, but I assume it would work for qemu-ppc.
On May 28, 2018, at 3:48 PM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
Yes qemu-system-ppc on an AMD Ryzen host PCI-E to PCI adapter OS X Tiger PPC.
On May 28, 2018, at 3:30 PM, Programmingkid <programmingkidx@gmail.com> wrote:
On May 28, 2018, at 3:07 PM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
I picked up a PCI-E 1x to PCI adapter and gave a few cards a go. A Firewire card worked, I was able to use iChat AV with an old FW iSight, both video and Mic worked.
Worked inside a QEMU VM? -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On May 29, 2018, at 7:39 AM, Jd Lyons <lyons_dj@yahoo.com> wrote:
The odd thing PK is the Firewire card worked perfect with qemu-System-ppc in PCI passthrough, but failed to work correct with qemu-system-x86_64 with a OS X guest.
Apple does like taking features away from us. Maybe the removed the Firewire driver from the x86 version of Mac OS X you are using.
The device show up on the PCI bus, but OS X can’t detect anything plugged into it. I’ll have to do a little more hacking and see what I can do.
Which version of Mac OS X has this problem?
As to the PCI-E 1x to PCI adapter, it didn’t want to work with a Radeon 9200 PCI, the host system wouldn’t boot at all with that card installed.
Maybe we can diagnose this issue and figure out a work around. What is your host operating system? Does this card show up in your BIOS setup?
I have an old S3 pic via card and that one seemed to work, however the VGA connector was blocked by my case so I couldn’t test it with qemu_x86 to see if I could get VGA from the card in passthrough.
The only work around for this issue involves using a reciprecating saw on your case. Something I bet you rather not do :)
I also tested a sound blaster audigy gold, and the Firewire port works under qemu-ppc, and I tested a USB 1.1 card that had the same issue under OS X intel in a qemu guest, but I assume it would work for qemu-ppc.
Excellent job with being able to access real hardware from your VM.
On May 28, 2018, at 3:48 PM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
Yes qemu-system-ppc on an AMD Ryzen host PCI-E to PCI adapter OS X Tiger PPC.
On May 28, 2018, at 3:30 PM, Programmingkid <programmingkidx@gmail.com> wrote:
On May 28, 2018, at 3:07 PM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
I picked up a PCI-E 1x to PCI adapter and gave a few cards a go. A Firewire card worked, I was able to use iChat AV with an old FW iSight, both video and Mic worked.
Worked inside a QEMU VM? -- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 28/05/18 20:07, Jd Lyons via OpenBIOS wrote:
I picked up a PCI-E 1x to PCI adapter and gave a few cards a go. A Firewire card worked, I was able to use iChat AV with an old FW iSight, both video and Mic worked.
Oh nice! I presume these don't have FCode ROMs and so appear as unknown devices in OpenBIOS? ATB, Mark.
Just shows up as a generic pic device, the same way it would in Open Firmware on a real PCI slot. pci(vendorID),(deviceID) Firewire card works with OS 9 too, I connected my PowerBook in Target Disk Mode and duplicated a 365MB folder on the drive, worked prefect.
On May 29, 2018, at 5:24 PM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 28/05/18 20:07, Jd Lyons via OpenBIOS wrote:
I picked up a PCI-E 1x to PCI adapter and gave a few cards a go. A Firewire card worked, I was able to use iChat AV with an old FW iSight, both video and Mic worked.
Oh nice! I presume these don't have FCode ROMs and so appear as unknown devices in OpenBIOS?
ATB,
Mark.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
Quickbench under OS 9 shows the PowerBook drive topping our around 12 Megabytes a second. I’ll have to check the native speed of this drive to see how much throughput I’m getting to the PCI Firewire card.
On May 30, 2018, at 8:21 AM, Jd Lyons via OpenBIOS <openbios@openbios.org> wrote:
Just shows up as a generic pic device, the same way it would in Open Firmware on a real PCI slot.
pci(vendorID),(deviceID)
Firewire card works with OS 9 too, I connected my PowerBook in Target Disk Mode and duplicated a 365MB folder on the drive, worked prefect.
On May 29, 2018, at 5:24 PM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 28/05/18 20:07, Jd Lyons via OpenBIOS wrote:
I picked up a PCI-E 1x to PCI adapter and gave a few cards a go. A Firewire card worked, I was able to use iChat AV with an old FW iSight, both video and Mic worked.
Oh nice! I presume these don't have FCode ROMs and so appear as unknown devices in OpenBIOS?
ATB,
Mark.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On May 30, 2018, at 9:11 AM, Jd Lyons <lyons_dj@yahoo.com> wrote:
Quickbench under OS 9 shows the PowerBook drive topping our around 12 Megabytes a second. I’ll have to check the native speed of this drive to see how much throughput I’m getting to the PCI Firewire card.
It would be an interesting experiment if you could try using a USB sound card on a USB card connected to a Mac OS X VM. It might tell us a little about the sound problem.
On May 11, 2018, at 4:11 AM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 11/05/18 08:11, Jd Lyons via OpenBIOS wrote:
Seems I could add config-1@ as a colon definition, however I’m not sure how too deal with r1@? : rl@-le rl@ lbflip ; : >config f1000000 + ; : config-l@ >config cr ." config-l@ " dup . rl@-le space dup . ; Just can’t figure how r1@ is implemented in SLOF?
That's definitely the long way around. Attached is a quick and dirty hack for PPC-only that implements config-l@ for reference:
$ ./qemu-system-ppc -nographic -bios /home/build/src/openbios/openbios.git/openbios/obj-ppc/openbios-qemu.elf.nostrip
============================================================= OpenBIOS 1.1 [May 11 2018 07:49] Configuration device id QEMU version 1 machine id 2 CPUs: 1 Memory: 128M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,750 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on May 11 2018 07:49 Trying hd:,\\:tbxi... Trying hd:,\ppc\bootinfo.txt... Trying hd:,%BOOT... No valid state has been set by load or init-program
0 > cd /pci/NE2000 ok 0 > .properties name "NE2000" vendor-id 10ec device-id 8029 revision-id 0 class-code 20000 AAPL,interrupts 17 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 1af4 subsystem-id 1100 cache-line-size 0 device_type "network" model "NE2000 PCI" assigned-addresses -- 14 : 01 00 10 10 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 AAPL,address fe001000 reg 00001000 00000000 00000000 00000000 00000000 01001010 00000000 00000000 00000000 00000100 network-type "ethernet" removable "network" category "net" ok 0 > cd .. ok 0 > 1000 config-l@ u. 802910ec ok 0 >
My reading of the IEEE-1275 PCI bindings is that you take the first 32-bit word of "reg" for the PCI configuration space address, so as you can see we return the device-id/vendor-id for the NE2000 NIC as above.
ATB,
Mark. <openbios-config-l-hack.patch>-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
participants (7)
-
Jd Lyons -
Joe van Tunen -
Mark Cave-Ayland -
Programmingkid -
Segher Boessenkool -
Tarl Neustaedter -
Thomas Huth