OpenBIOS

openbios@openbios.org

4284 discussions

b?branch
by Jd Lyons 28 Dec '17

28 Dec '17

I’ve run into trouble with b?branch not working as expected by the nVidia Option Rom Fcode. What Openbios does now for b?branch is: From fcode.fs: === \ b?branch ( continue? -- ) \ Conditional branch FCode. Followed by FCode-offset. : b?branch fcode-offset 0< if \ if we jump backwards, we can forsee where it goes ['] do?branch , resolve-dest execute-tmp-comp else setup-tmp-comp ['] do?branch , here 0 0 , then- ; immediate === I fond some code from SLOF that may work a little better: : b?branch ( flag -- ) ?compile-mode IF read-fcode-offset ?negative IF dest-on-top postpone until ELSE postpone if THEN ELSE ( flag ) IF fcode-offset jump-n-ip \ Skip over offset value ELSE read-fcode-offset ?jump-direction jump-n-ip THEN THEN ; immediate Unfortunately it’s not just a simple copy and paste, I get errors when trying to compile Openbios with this code. When you have time, could you help me step though it and figure out where it is failing, and how to fix it, I’m just not very good at C and could really use some help from someone that understands what the code is trying to do, and what I need to port over from SLOF to get it to compile. Thanks, James

4 24

[PATCH] libopenbios/bootinfo_load.c: Implement Mac OS 9.2 boot script support
by Programmingkid 25 Dec '17

25 Dec '17

This patch makes booting Mac OS 9.2 possible. It replaces all occurrences of >r and r> with sub_>r and sub_r>. This allows for the return stack to be left alone. This patch also makes it so that the boot script is executed one line at a time. Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> Note: this patch depends on the strstr() and return stack substitution patches. Index: libopenbios/bootinfo_load.c =================================================================== --- libopenbios/bootinfo_load.c (revision 1395) +++ libopenbios/bootinfo_load.c (working copy) @@ -19,6 +19,7 @@ #include "libopenbios/bootinfo_load.h" #include "libopenbios/ofmem.h" #include "libc/vsprintf.h" +#include "libc/string.h" //#define DEBUG_BOOTINFO @@ -116,6 +117,75 @@ return LOADER_NOT_SUPPORT; } +// Replace all occurrences of orig_str in buffer with replace_str +static void replace_string(char *buffer, const char *orig_str, const char *replace_str) +{ + char *ptr; + int index, new_buf_index = 0; + const int max_size = 5000; + char *new_buffer = malloc(max_size * sizeof(char)); + + for (index = 0; index < strlen(buffer); index++) { + if (buffer[index] == orig_str[0]) { + ptr = strstr(buffer + index, orig_str); + + // if we encountered an orig_str in the buffer + if (index == (ptr - buffer)) { + sprintf(new_buffer + new_buf_index, "%s ", replace_str); + new_buf_index += strlen(replace_str) + 1; + index += strlen(orig_str); + continue; + } + } + new_buffer[new_buf_index++] = buffer[index]; + } + + // copy new_buffer into buffer + for (index = 0; index < strlen(new_buffer); index++) { + buffer[index] = new_buffer[index]; + } + buffer[index+1] = '\0'; +} + +/* Replace >r and r> with sub_>r and sub_r> */ +static void replace_return_stack_words(char *bootscript) +{ + const char *find_str1 = ">r"; + const char *replace_str1 = "sub_>r"; + const char *find_str2 = "r>"; + const char *replace_str2 = "sub_r>"; + + replace_string(bootscript, find_str1, replace_str1); + replace_string(bootscript, find_str2, replace_str2); +} + +/* Runs the bootscript one line at a time */ +void run_script(char *bootscript) +{ + int index = 0, buf_index = 0; + char c; + char *buffer = malloc(1000 * sizeof(char)); + + while (1) { + c = bootscript[index]; + + // fill up buffer + while (c != '\n' && c != '\r' && c != '\0') { + buffer[buf_index++] = c; + c = bootscript[++index]; + } + buffer[buf_index] = '\0'; + buf_index = 0; + index++; + DPRINTF("%s\n", buffer); + feval(buffer); + if (c == '\0') { + break; + } + } + free(buffer); +} + /* Parse SGML structure like: <chrp-boot> @@ -209,9 +279,6 @@ script = 0; bootscript[scriptlen] = '\0'; - DPRINTF("got bootscript %s\n", - bootscript); - scriptvalid = -1; break; @@ -261,8 +328,8 @@ /* If the payload is bootinfo then we execute it immediately */ if (scriptvalid) { - DPRINTF("bootscript: %s\n", bootscript); - feval(bootscript); + replace_return_stack_words(bootscript); + run_script(bootscript); } else DPRINTF("Unable to parse bootinfo bootscript\n");

4 9

Re: [OpenBIOS] PIC Passthough( VGA )
by Jd Lyons 22 Dec '17

22 Dec '17

Looks like the spot were I’m stuck is: b(;) ( 0x0c2 ) 25612: b(') ( 0x011 ) (unnamed-fcode) [0xc84] 25613: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a9] 25614: (unnamed-fcode) [0xe34] 25615: (unnamed-fcode) [0xdff] 25616: (unnamed-fcode) [0x93d] 25617: b(lit) ( 0x010 ) 0xf 25618: <> ( 0x03d ) 25619: b?branch ( 0x014 ) 0x0026 ( =dec 38) 25620: (unnamed-fcode) [0x9bd] 25621: b(lit) ( 0x010 ) 0xff 25622: and ( 0x023 ) 25623: my-space ( 0x103 ) 25624: + ( 0x01e ) 25625: (unnamed-fcode) [0xa08] 25626: b(lit) ( 0x010 ) 0x6 25627: and ( 0x023 ) 25628: b(lit) ( 0x010 ) 0x4 25629: = ( 0x03c ) 25630: b?branch ( 0x014 ) 0x0009 () 25631: b(') ( 0x011 ) (unnamed-fcode) [0x9c1] 25632: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c0] 25633: b(>resolve) ( 0x0b2 ) 25634: b(>resolve) ( 0x0b2 ) It seems to break right here………………………………. 25635: (unnamed-fcode) [0xddf] 25636: (unnamed-fcode) [0xe04] 25637: (unnamed-fcode) [0xe38] 25638: (unnamed-fcode) [0xe06] 25639: (unnamed-fcode) [0xce5] 25640: (unnamed-fcode) [0xdb0] 25641: (unnamed-fcode) [0xe07] 25642: (unnamed-fcode) [0xe1a] 25643: (unnamed-fcode) [0xc5b] 25644: (unnamed-fcode) [0xe28] 25645: (unnamed-fcode) [0xe20] 25646: (unnamed-fcode) [0xdfa] 25647: (unnamed-fcode) [0xe37] 25648: (unnamed-fcode) [0xe2c] 25649: (unnamed-fcode) [0xe2d] The next thing seems to be: new-token ( 0x0b5 ) 0xddf 21913: b(:) ( 0x0b7 ) 21914: b(lit) ( 0x010 ) 0x10 21915: (unnamed-fcode) [0xdde] 21916: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c3] 21917: b(lit) ( 0x010 ) 0x14 21918: (unnamed-fcode) [0xdde] 21919: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c4] 21920: (unnamed-fcode) [0x9c0] 21921: b(lit) ( 0x010 ) 0xff 21922: and ( 0x023 ) 21923: (unnamed-fcode) [0xdde] 21924: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c6] 21925: b(lit) ( 0x010 ) 0x30 21926: (unnamed-fcode) [0xdde] 21927: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9c5] 21928: (unnamed-fcode) [0x9bf] 21929: (unnamed-fcode) [0xa03] 21930: (unnamed-fcode) [0x9c5] 21931: (unnamed-fcode) [0xa04] 21932: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a5] 21933: (unnamed-fcode) [0x9bc] 21934: (unnamed-fcode) [0xa03] 21935: (unnamed-fcode) [0x9c3] 21936: (unnamed-fcode) [0xa04] 21937: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a3] 21938: (unnamed-fcode) [0x9c0] 21939: (unnamed-fcode) [0xa03] 21940: (unnamed-fcode) [0x9c6] 21941: (unnamed-fcode) [0xa04] 21942: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a6] 21943: (unnamed-fcode) [0x9bd] 21944: (unnamed-fcode) [0xa03] 21945: (unnamed-fcode) [0x9c4] 21946: (unnamed-fcode) [0xa04] 21947: b(to) ( 0x0c3 ) (unnamed-fcode) [0x9a4] 21948: (unnamed-fcode) [0xa3b] 21949: (unnamed-fcode) [0xa3d] 21950: (unnamed-fcode) [0xddd] 21951: b(;) ( 0x0c2 ) I don’t really understand this (unnamed-fcode) [0xddf], or any of the (unnamed-fcode)? Could someone explain that to me.

3 10

Re: [OpenBIOS] PIC Passthough( VGA )
by Jd Lyons 19 Dec '17

19 Dec '17

> On Dec 18, 2017, at 7:29 PM, Segher Boessenkool <segher(a)kernel.crashing.org> wrote: > > Hi! > > On Mon, Dec 18, 2017 at 06:37:54PM -0500, Jd Lyons wrote: >> I must not be doing init correct >> >> “ /pci/pci10de,141,@f” open-dev” >> >> But my-self . Returns 0? > > Something like > > “ /pci/pci10de,141,@f” open-dev to my-self > > is all you need :-) > > But, I think you mistyped it, it is > > “ /pci/pci10de,141@f” open-dev to my-self > > (or even just > > “ /pci/@f” open-dev to my-self > > if you are just as lazy as I am). > Thanks, Segher, I was missing the "to my-self”. I think we’re almost to the end of the file, and it’s at least changing the value of the subsystem ID. C>> annot manage 'VGA controller' PCI device type 'display': >> 10de 141 (3 0 0) >> ============================================================= >> OpenBIOS 1.1 [Dec 17 2017 13:36] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 1536M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Dec 17 2017 13:36 0 > dev /pci/@f .properties name "pci10de,141" vendor-id 10de device-id 141 revision-id a2 class-code 30000 interrupts 1 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 10de subsystem-id 50 cache-line-size 10 assigned-addresses -- 3c : 02 00 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 reg 00007800 00000000 00000000 00000000 00000000 02007810 00000000 00000000 00000000 01000000 c3007814 00000000 00000000 00000000 10000000 8300781c 00000000 00000000 00000000 01000000 ok 0 > : us ( n -- ) d# 1000 / 1+ ms ; ok 0 > " /pci/@f" open-dev to my-self ok 0 > load hd:,\ppc\6600.fcode ok 0 > 4000040 1 byte-load (offset) 26 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 ] (offset) 9 4010054 : (compile) b(') [ 0x11 ] 4010057 : (compile) b(to) [ 0xc3 ] 401005a : (compile) b(>resolve) [ 0xb2 ] 401005b : (compile) b(>resolve) [ 0xb2 ] byte-load: exception caught! ok 0 > here 200 - 400 dump fffcd7d0 50 80 08 00 93 01 6c 02 12 05 6e 29 60 2a 00 2e P�..�.l...n)`*.. fffcd7e0 00 2f 20 74 80 3e 71 50 80 08 00 93 ff f6 e2 b0 ./ t�>qP�..�� fffcd7f0 ff f6 e2 e4 ff f6 6c 78 00 00 00 fc 01 6c 02 12 ��lx...�.l.. fffcd800 05 6e 29 60 2a 00 2e 00 2f 20 74 80 3e 71 50 80 .n)`*.../ t�>qP� fffcd810 08 00 93 01 6b 02 12 05 6e 29 60 2a 00 2e 00 2f ..�.k...n)`*.../ fffcd820 20 50 81 08 00 93 01 6b 02 12 05 6e 29 60 2a 00 P�..�.k...n)`*. fffcd830 2e 00 2f 20 74 80 3e 71 50 80 08 00 93 01 6c 02 ../ t�>qP�..�.l. fffcd840 12 05 6e 29 60 2a 00 2e 00 2f 20 50 81 08 00 93 ..n)`*.../ P�..� fffcd850 01 6c 02 12 05 6e 29 60 2a 00 2e 00 2f 20 74 80 .l...n)`*.../ t� fffcd860 3e 71 50 80 08 00 93 01 6c 02 12 05 6e 29 60 2a >qP�..�.l...n)`* fffcd870 00 2e 00 2f 20 50 81 08 00 93 01 6c 02 12 05 6e .../ P�..�.l...n fffcd880 29 60 2a 00 2e 00 2f 20 74 80 3e 71 50 80 09 00 )`*.../ t�>qP�.. fffcd890 93 01 6c 02 12 04 89 05 6e 31 00 32 00 33 00 2e �.l...�.n1.2.3.. fffcd8a0 15 74 50 c3 74 50 c3 50 80 01 01 62 50 81 06 3b .tP�tP�P�..bP�.; fffcd8b0 00 3c 00 3d 00 3e 00 3f 00 3a 81 71 50 80 09 00 .<.=.>.?.:�qP�.. fffcd8c0 13 01 71 02 32 04 89 05 6e 30 00 31 00 32 00 33 ..q.2.�.n0.1.2.3 fffcd8d0 00 50 81 0a 00 13 01 71 02 32 04 81 05 2e 30 00 .P�....q.2.�..0. fffcd8e0 31 00 32 00 33 00 3a 80 74 50 c3 74 50 c3 71 50 1.2.3.:�tP�tP�qP fffcd8f0 80 06 00 93 01 6b 02 52 ff f6 e2 b0 ff f6 e2 e4 �..�.k.R�� fffcd900 ff f6 6c 78 00 00 00 6b 04 81 05 6e 3a 80 6e 88 ��lx...k.�.n:�n� fffcd910 15 00 00 00 00 00 00 25 20 00 00 71 71 6e 80 08 .......% ..qqn�. fffcd920 68 00 ff ff ff df 00 00 00 00 71 6e 80 28 68 00 h.��....qn�(h. fffcd930 ff ff ff cf 00 00 00 00 71 7a 04 13 00 00 00 08 ��....qz...... fffcd940 00 00 58 00 14 00 00 04 a2 1d a8 a9 23 1e b7 7f ..X.....�.��#.� fffcd950 d7 25 c8 c9 16 c2 27 7f 6e 98 10 00 00 f7 ff ff �%��.�'n�...�� fffcd960 ff 00 00 00 00 6e 10 13 00 00 ff ff ff ff 00 00 �....n....��.. fffcd970 00 00 71 00 ff f6 e2 b0 ff f6 e2 e4 ff f6 44 d0 ..q.��D� fffcd980 00 00 00 08 ff fc 8f c0 ff f6 41 88 ff f6 41 58 ....��A��AX fffcd990 ff f6 40 d4 ff fa c9 58 ff f6 4b c0 ff fc b6 7c ��@��X��K��| fffcd9a0 ff f6 e2 e4 ff f6 41 38 ff f6 40 d4 ff fa c9 68 ��A8��@��h fffcd9b0 ff f6 4b c0 ff f6 40 d4 ff fa c9 58 ff f6 4b c0 ��K��@��X��K� fffcd9c0 ff fb 65 24 ff f6 e4 bc ff f6 40 c4 00 00 00 10 ��e$��@�.... fffcd9d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcd9e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcd9f0 00 34 30 30 66 34 30 30 66 34 30 30 66 66 31 32 .400f400f400ff12 fffcda00 ff fc d9 fe 00 00 00 00 00 00 00 00 00 00 00 00 ��............ fffcda10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcda20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcda30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcda40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcda50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcda60 00 00 00 00 00 00 00 00 00 00 00 00 00 34 30 31 .............401 fffcda70 30 34 30 31 30 34 30 31 30 30 63 35 ff 34 30 31 0401040100c5�401 fffcda80 30 34 30 31 30 34 30 31 30 34 30 31 30 30 63 33 04010401040100c3 fffcda90 ff fc da 8e 00 34 30 31 30 34 30 31 30 34 30 31 ��ڎ.40104010401 fffcdaa0 30 34 30 31 30 30 63 33 ff fc da a6 00 34 30 31 040100c3��ڦ.401 fffcdab0 30 30 63 33 ff fc da b2 00 34 30 31 30 34 30 31 00c3��ڲ.4010401 fffcdac0 30 34 30 31 30 34 30 31 66 66 66 63 64 61 63 30 04010401fffcdac0 fffcdad0 ff fc da c8 00 00 00 00 00 00 00 00 00 00 00 00 ��............ fffcdae0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdaf0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdb90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdba0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdbb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ fffcdbc0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ok 0 > my-self . 5fc5ac34 ok 0 > dev /pci/@f .properties name "pci10de,141" vendor-id 10de device-id 141 revision-id a2 class-code 30000 interrupts 1 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 10de subsystem-id 10 cache-line-size 10 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 reg 00007800 00000000 00000000 00000000 00000000 02007810 00000000 00000000 00000000 01000000 c3007814 00000000 00000000 00000000 10000000 8300781c 00000000 00000000 00000000 01000000 ok 0 > > > Segher

1 0

Re: [OpenBIOS] PIC Passthough( VGA )
by Jd Lyons 18 Dec '17

18 Dec '17

> On Dec 18, 2017, at 2:44 AM, Segher Boessenkool <segher(a)kernel.crashing.org> wrote: > > On Mon, Dec 18, 2017 at 01:13:49AM -0500, Jd Lyons wrote: >>> On Dec 18, 2017, at 12:48 AM, Segher Boessenkool <segher(a)kernel.crashing.org> wrote: >>> On Mon, Dec 18, 2017 at 12:05:17AM -0500, Jd Lyons wrote: >>>> Still bombing out at the same place: >>> >>>> 401002a : [ 0xe34 ] >>>> >>>> byte-load: exception caught! >>> >>> : xe33 $find invert IF ABORT THEN ; >>> : xe34 >>> " us" xe33 TO x9a7 >>> " case-closed?" $find invert IF 2drop ['] 0 THEN >>> TO x9a8 ; >>> >>> So the thing that throws is fcode e33, when trying to find the word "us". >>> >>> (Btw, "invert" is weird here; I suppose it was coded as its synonym "not". >>> In some other Forth systems "not" is a synonym for "0=", which makes more >>> sense here. Either works as long as $find returns a canonical true/false, >>> as it supposed to). >>> >>> So, implement "us", and you'll get further :-) It's just like "ms", but >>> microseconds, instead; so you could do >>> >>> : us ( n -- ) d# 1000 / 1+ ms ; >>> >>> (which waits way too long for short timeouts, of course). >>> >> >> Ok, thanks, that makes since. I did see the “case-closed?” When I searched for 0xe34 in the detoked rom, but I wan’t sure what to make of it. >> >> So, the “us” word is unimplemented in Openbios, and we need to add it to get past this part? > > Exactly. And I gave a (not super great) implementation above, enough to > see if you get further :-) Ok, I see, the code you gave was a command for Openbios, I kept trying to find where to add it to the source, thinking it was C code;-) Only got one byte further: (offset) 5 401000d : (compile) [ 0xe05 ] 401000e : (compile) b(endcase) [ 0xc5 ] 401000f : (compile) over [ 0x48 ] 4010010 : (compile) b(to) [ 0xc3 ] 4010014 : (compile) [ 0xe36 ] 4010016 : (compile) encode+ [ 0x112 ] 4010017 : (compile) 2dup [ 0x53 ] 4010018 : (compile) b(to) [ 0xc3 ] 401001b : (compile) b(to) [ 0xc3 ] 401001f : (compile) [ 0xc7b ] 4010021 : (compile) property [ 0x110 ] 4010022 : (compile) b(;) [ 0xc2 ] 4010023 : b(') [ 0x11 ] 4010026 : b(to) [ 0xc3 ] 401002a : [ 0xe34 ] 401002c : [ 0xdff ] byte-load: exception caught! ok 1 > > > > Segher

2 5

Re: [OpenBIOS] PIC Passthough( VGA )
by Jd Lyons 18 Dec '17

18 Dec '17

> On Dec 17, 2017, at 11:42 PM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: > > On 2017-Dec-17 23:39 , Jd Lyons wrote: >> It has the open and close words, really two open words now, because we added one. >> >> I’ll rebuild Openbios and edit out the: >> >> feval("['] vga-driver-fcode 2 cells + 1 byte-load”); >> >> That should keep the Fcode for VGA devices from loading….. > > If all it has are the open and close, leave it alone. The newer open > and close are supposed to replace the earlier ones (it may complain, but > you can live with that for the moment). You need the open in there so > that the open-dev works. Try the load/byte-load sequence inside that > node and see what happens. > Still bombing out at the same place: C>> annot manage 'VGA controller' PCI device type 'display': >> 10de 141 (3 0 0) >> ============================================================= >> OpenBIOS 1.1 [Dec 18 2017 04:42] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 1536M >> UUID: 00000000-0000-0000-0000-000000000000 >> CPU type PowerPC,G4 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Dec 18 2017 04:42 0 > dev /pci ok 0 > dev @10 ok 0 > words close open ok 0 > " /pci/pci10de,141@10" open-dev ok 1 > load hd:,\ppc\6600.fcode ok 1 > 4000040 1 byte-load open isn't unique. close isn't unique. byte-load: exception caught! ok 1 > ls ok 1 > dev /pci ls fff8042c mac-io@c fff8336c usb@d fff836d8 QEMU,VGA@e fff83a8c NE2000@f fff83e3c pci10de,141@10 ok 1 > dev /pci/@10 .properties name "pci10de,141" vendor-id 10de device-id 141 revision-id a2 class-code 30000 interrupts 1 min-grant 0 max-latency 0 devsel-speed 0 subsystem-vendor-id 10de subsystem-id 50 cache-line-size 10 assigned-addresses -- 3c : 02 00 80 10 00 00 00 00 83 00 00 00 00 00 00 00 01 00 00 00 c3 00 80 14 00 00 00 00 90 00 00 00 00 00 00 00 10 00 00 00 83 00 80 1c 00 00 00 00 a0 00 00 00 00 00 00 00 01 00 00 00 reg 00008000 00000000 00000000 00000000 00000000 02008010 00000000 00000000 00000000 01000000 c3008014 00000000 00000000 00000000 10000000 8300801c 00000000 00000000 00000000 01000000 ok 1 > setenv fcode-debug? true ok 1 > true to ?fcode-verbose ok 1 > dev /pci/@10 words close open close open ok 1 > 4010009 : (compile) b(endof) [ 0xc6 ] (offset) 5 401000d : (compile) [ 0xe05 ] 401000e : (compile) b(endcase) [ 0xc5 ] 401000f : (compile) over [ 0x48 ] 4010010 : (compile) b(to) [ 0xc3 ] 4010014 : (compile) [ 0xe36 ] 4010016 : (compile) encode+ [ 0x112 ] 4010017 : (compile) 2dup [ 0x53 ] 4010018 : (compile) b(to) [ 0xc3 ] 401001b : (compile) b(to) [ 0xc3 ] 401001f : (compile) [ 0xc7b ] 4010021 : (compile) property [ 0x110 ] 4010022 : (compile) b(;) [ 0xc2 ] 4010023 : b(') [ 0x11 ] 4010026 : b(to) [ 0xc3 ] 401002a : [ 0xe34 ] byte-load: exception caught! ok 1 >

3 4

Re: [OpenBIOS] PIC Passthough( VGA )
by Jd Lyons 18 Dec '17

18 Dec '17

Thanks Mark, I’m unsure how to get Openbios to execute the Fcode, I can load it to the correct address on my PCI card, via a little hack to Openbios. I’d really like to just go ahead and fix the fact that Openbios doesn’t probe for Fcode Rom’s on PCI devices. I know this will likely break a few things, requiring other fixes. If I had some idea of where to start, some sample code I maybe able to hack something together, but it would likely break more than it fixes. I’m sure you're busy, I’m retired and this is just something to keep my occupied, tho I’m not really qualified to do it. If it could be added as a priority to Openbios, to probe and execute FCode Rom’s on PCI devices, that would be great. I’m sure someone will take it up when they have a little spare time. I’m having trouble CC ing the list, I know stupid of me. Any idea what the unnamed FCode in the detok is? Does detok just not understand it, or is it words or methods? > On Dec 15, 2017, at 4:08 PM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> wrote: > > On 12/12/17 09:06, Jd Lyons wrote: >>> On Dec 12, 2017, at 3:24 AM, Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk <mailto:mark.cave-ayland@ilande.co.uk>> wrote: >>> >>> On 12/12/17 03:24, Jd Lyons wrote: >>> >>>>>> I’m assuming that Openbios is not reading the Option Rom of the card, but I’m not sure why. >>>>> >>>>> Well... at the moment we actually cheat ;) Instead of reading the VGA FCode ROM from the virtual display adapter, OpenBIOS embeds its own copy of the FCode ROM and executes it unconditionally when it detects a VGA display device. I must admit I hadn't considered that someone would be interested in legacy device passthough to enable a device that isn't the standard QEMU display adapter. >>>> Are we talking about the ‘NDRV’ patch? >>>> I noticed that the ‘NDRV’ for the QEMU,VGA loads to any VGA card in the system. Yet the vga-pci.c loads a PC Video bios for the qemu,vga device, tho I’m pretty sure Openbios doesn’t use it. I’m having trouble locating how the QEMU,VGA device is able to be used by Openbios, how does it “init” the device? >>> >>> The NDRV driver is loaded into the "driver,AAPL..." property after the device node has been created by the FCode device so that occurs later in the process. >>> >>> OpenBIOS creates a basic PCI device node for every device it finds during a PCI bus scan and then executes a callback depending upon the resulting vendorid/deviceid. The code in OpenBIOS is in vga_config_cb() and as you can see, it currently executes the in-built FCode directly rather than trying to map the ROM using the process documented at http://mirror.informatimago.com/next/developer.apple.com/technotes/tn/tn200…. >>> >>>>> As a starting point I'd suggest that if you still have the old hardware lying around, you can use the article above to extract the ROM from a real Mac and then run the resulting code through fcode-utils detok which effectively "decompiles" the ROM and therefore give us an idea as to how many Forth words need to be implemented. >>>>> >>>> Ok, I’ve done some detok of nVidia Fcode Rom’s before, and I know about words that Openfirmware doesn’t understand, years ago I wanted two get an nVidia card to work in my Old World PM8600, and I figured it was the “map-in” bug, but as it turns out, it was some words in nVidia's FCode Rom that my version of OF didn’t have. >>>> Atriu Itra was able to get an nVidia card to work in OpenFimware on an Old World machine, but it wouldn’t boot the OS, however if he had stayed at it, I’m sure he’d have figured it out. He did basically what you are preposing. Guy was an Fcode master, we could really use him on this project. >>> >>> Sounds like someone has already done some of the work here - do you have a copy of the detok FCode or any emails related to the subject at all? >>> >>> Otherwise I would say the first step would be to hack OpenBIOS to expose the passthrough ROM and then dump it out from within QEMU. >> We had an online forum were we discussed hacking Fcode Roms, all gone now tho, but a lot of info, and Rom still at: >> http://themacelite.wikidot.com >> Most of all the old Fcode Roms in the downloads section, I don’t think anyone added the old 3dfx Roms for Powermac’s, but they can be extracted from the 3dfx control panel. I did some work emulating the Voodoo cards for Openbios/Qemu_PPC, really I’m just wanting to emulate a Voodo2, so I’m playing around with PCI Passthough while waiting to find an affordable Voodoo2, you wouldn’t believe what they sell for these days. >> The 6600 was only a few bucks, so I got it, but I was hoping to lighten the Emulated cpu load, as screen redraws seem to suck up all the CPU cycles under OS X. So a little QE may help there. >> Anyway, the Voodoo2 didn’t have a rom, and it wasn’t really a VGA card, those some people have hacked it to display the desktop, it was really a 3D Accelerator with VGA Passthough for the main system display card. So I don’t think I’ll have any trouble with PCI Passthrough with that. >> Anyway, I think we may want to work on some code for Openbios that detects vfio-pci and reads the rom for the device and tries to execute the Fcode, rather than what we have now, it’s not really a workable solution for PCI Passthrough of VGA. The pseries firmware is aware of a vfio-pci device, but it doesn’t seem to be aware of the Rom on the card either. >> I did some hacks to Openbios and got the rom mapped in @0x30 for the 6600, but Openbios still does not try and execute the rom. >> A quick look at the detok Fcode: > > Thanks for the dump of the ROM. At first glance I don't see anything too unusual in there - the main culprits to look at will be map-in, my-address and the config-* words for accessing PCI config space... > > Once you're able to run the FCode you can also do: > > true to fcode-debug? > > which should dump out the FCode tokens on the console as they are being debugged. > > > ATB, > > Mark.

4 9

Suggestion - add minor version number to banner
by Programmingkid 17 Dec '17

17 Dec '17

I was wondering if we could add a minor version number to the banner. It would mean instead of see "OpenBIOS v1.1", what would be printed is "OpenBIOS v1.1.x". I think this would help distinguish added features to a particular binary easier than how we do things now.

1 0

Re: [OpenBIOS] Loading a PCI Option rom.
by Programmingkid 17 Dec '17

17 Dec '17

> On Dec 17, 2017, at 1:28 PM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: > > From what I remember, there are a bunch of properties, the most important is the NVDA,BMP that’s where the GPU and Memory Registers get written. There is a Strap, the NVStrap near the beginning of the Rom, and one part of the NVStrap sets up how the NVDA,BMP is read and written. The BMP is common between PC and FCode Option Roms, as is the strap. In the BMP there are a series of tables 0-7 and one offset of the strap determines what table gets loaded. It was a throwback to a program nVidia gave to it board partners. The NVStap Editor, I think it was called, it allowed them to use a reference Bios and plug in some values depending on how they deviated from the reference PCB. The NVStrap has and And/Or mask, So you can append the resistors on the PCB, or just read them as they are, and you can change the last byte of the Device ID. > > So if one of there board partners used some cheap memory they could get a ready supply of, they could just plug the memory specs into the BMP Editor and set the Soft Strap(NVStrap) without the need to make a new Bios in assembly. > > We got lucky, and they used the BMP in the Fcode Rom too, and that allowed us to figure out how to edit it to flash PC cards for use in PPC systems. > > There is a GPU check in the Fcode rom too, so you have to bypass that check, if you want to use a GPU the Rom wasn’t made for. This is how we made the Geforce 6200 Rom from the Apple OEM Geforce 6600 Rom. Thank you for the info. You know a lot of Nvidia cards. Still there is the exception that we see when executing the card's Fcode. Finding out what is causing the exception would be very helpful. Were there any values in the stack that might mean anything when the exception happened? Did you see any other messages? The serial console may have something printed there. I found the definition to byte-load in the forth/device/feval.fs file. This is part of it: : byte-load ( addr xt -- ) ?fcode-verbose if cr ." byte-load: evaluating fcode at 0x" over . cr then \ save state >r >r fcode-push-state r> r> \ set fcode-c@ defer dup 1 = if drop ['] c@ then \ FIXME: uses c@ rather than rb@ for now... to fcode-c@ dup to fcode-stream-start to fcode-stream 1 to fcode-spread false to ?fcode-offset16 alloc-fcode-table false fcode-end ! \ protect against stack overflow/underflow 0 0 0 0 0 0 depth >r ['] (feval) catch if cr ." byte-load: exception caught!" cr then You see the message "exception caught!" takes place because the (feval) word has a problem with something. Looking at the (feval) word I see it has a (debug-feval) word that might be helpful. This word is also located in the feval.fs file. As an experiment could you set the ?fcode-verbose to true when running QEMU? I think this QEMU option would help: -prom-env ?fcode-verbose=true If this doesn't work, then maybe we should redefine the " word to print out what it finds to the serial console. That might tell us what is wrong.

1 0

Re: [OpenBIOS] Loading a PCI Option rom.
by Programmingkid 17 Dec '17

17 Dec '17

https://nouveau.freedesktop.org/wiki/DumpingVideoBios/ I found this really helpful page on obtaining information on properties. If you have Linux installed on a PowerPC Macintosh, then finding the properties is as simple as typing this command in the terminal: cd "/proc/device-tree/pci@f0000000/NVDA,Parent@10" Just checked my PowerPC iMac. It has an ATI Radeon video card, so it won't be much help. I think the reason why OpenBIOS fails to make the property is because there is something interesting about the name. Maybe an unhandled character type like unicode is used. Having a list of all the properties that this card has would be very helpful.

1 0

Jump to page: