OpenBIOS December 2017

openbios@openbios.org

6 participants
18 discussions

Re: [OpenBIOS] b?branch
by Jd Lyons 02 Jan '18

02 Jan '18

> On Dec 29, 2017, at 12:14 AM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: > > On 2017-Dec-29 00:00 , Jd Lyons wrote: >> >> Segher, do you think I maybe tripping over the “ config-l@“? >> >> Seems to be a few words called next, after the b(>resolve) I’m catching the exception on. >> >> config-l@ >> config-l! >> config-w@ >> config-w! > > Those are words to read and write config space on pci cards. I'm pretty … [View More]sure the words work (otherwise the vendor-id and product-id values wouldn't have been able to be fetched), the question is whether they are being called with unexpected values. The config-l@ must be called with a mod 4 values, the config-w@ must be called with a mod 2 value. > > The usual mode of accessing config space is adding your desired offset to my-space, and then call config-l@. That looks to be what you are in the middle of: > > 8010039 : (compile) [ 0x9bd ] > 801003a : (compile) b(lit) [ 0x10 ] > 801003f : (compile) and [ 0x23 ] > 8010041 : (compile) my-space [ 0x103 ] > 8010042 : (compile) + [ 0x1e ] > 8010044 : (compile) [ 0xa08 ] <<<<<<< is this config-l@? > 8010045 : (compile) b(lit) [ 0x10 ] > 801004a : (compile) and [ 0x23 ] > 801004b : (compile) b(lit) [ 0x10 ] > 8010050 : (compile) = [ 0x3c ] > > The above looks to me like he's testing for the presence of 0x10 in a register (0x10 and 0x10 =). If he's looking at a series of BARs, that's the prefetchable bit he's looking for. > Do you think it’s having trouble reading the PCI Configuration registers, it was able to change the subsystem-id from 0x50 to 0x10, so I was hoping it had calculated the base address of the PCI card correctly. I’m really at a loss, never had to dive this deep into forth when hacking these Rom’s for card flashing. It seemed to me that: b(>resolve) ( 0x0b2 ) (unnamed-fcode) [0xddf]<————This calls the offset? 0xddf new-token ( 0x0b5 ) 0xddf b(:) ( 0x0b7 ) b(lit) ( 0x010 ) 0x10 (unnamed-fcode) [0xdde] <——This calls the offset? 0xdde new-token ( 0x0b5 ) 0xdde b(:) ( 0x0b7 ) my-space ( 0x103 ) + ( 0x01e ) dup ( 0x047 ) (unnamed-fcode) [0xa08]<—— this calls 0xa08 new-token ( 0x0b5 ) 0xa08 b(:) ( 0x0b7 ) b(") ( 0x012 ) ( len=9 ) " config-l@" $call-parent ( 0x209 ) b(;) ( 0x0c2 ) I’m sure I’m being too linear in my thinking, as you’ve already pointed out, my-space and config-l@ were called before my exception. I just can’t figure out what is throwing the exception? [View Less]

5 22

[PATCH] Add tbu@ and tbl@ words
by John Arbuckle 30 Dec '17

30 Dec '17

The PowerPC timebase register is made available to forth using the tbu@ and tbl@ words. The tbu@ word pushes the upper 32 bits of this register. The tbl@ word pushes the lower 32 bits of this register. Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> --- arch/ppc/qemu/init.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 5ce080c..d12084c 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -… [View More]

5 13

Re: [OpenBIOS] b?branch
by Jd Lyons 30 Dec '17

30 Dec '17

> On Dec 28, 2017, at 7:08 PM, Programmingkid <programmingkidx(a)gmail.com> wrote: > >> >> On Dec 28, 2017, at 7:05 PM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >> >> >> >>> On Dec 28, 2017, at 3:02 PM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>> >>>> >>>> On Dec 28, 2017, at 11:01 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >>>> >>>> >>>> … [View More]>>>>> On Dec 28, 2017, at 10:47 AM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> On Dec 28, 2017, at 10:39 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Dec 28, 2017, at 10:20 AM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Dec 28, 2017, at 10:13 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Dec 28, 2017, at 9:56 AM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Dec 28, 2017, at 9:36 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Dec 27, 2017, at 5:02 PM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Dec 21, 2017, at 6:51 PM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 21 Dec 2017, Programmingkid wrote: >>>>>>>>>>>>>> On Dec 21, 2017, at 12:56 PM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote: >>>>>>>>>>>>>> On Thu, 21 Dec 2017, Jd Lyons wrote: >>>>>>>>>>>>>>>> On Dec 21, 2017, at 9:59 AM, Programmingkid <programmingkidx(a)gmail.com> wrote: >>>>>>>>>>>>>>>>> On Dec 21, 2017, at 9:36 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote: >>>>>>>>>>>>>>>>> I don’t know, this maybe an issue with the way we have defined “us”. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not sure the us word is related to problems with b?branch but I don't know anything about this other than reading the conversation here. They look unrelated to me but it could well be I did not undersand this at all. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Looking through the SLOF code it seems they call it like this in the timebase.fs: >>>>>>>>>>>>>>>>> : tb@ ( -- tb ) >>>>>>>>>>>>>>>>> BEGIN tbu@ tbl@ tbu@ rot over <> WHILE 2drop REPEAT >>>>>>>>>>>>>>>>> 20 lshift swap ffffffff and or >>>>>>>>>>>>>>>>> ; >>>>>>>>>>>>>>>>> : milliseconds ( -- ms ) tb@ d# 1000 * tb-frequency / ; >>>>>>>>>>>>>>>>> : microseconds ( -- us ) tb@ d# 1000000 * tb-frequency / ; >>>>>>>>>>>>>>>>> : ms ( ms-to-wait -- ) milliseconds + BEGIN milliseconds over >= UNTIL drop ; >>>>>>>>>>>>>>>>> : get-msecs ( -- n ) milliseconds ; >>>>>>>>>>>>>>>>> : us ( us-to-wait -- ) microseconds + BEGIN microseconds over >= UNTIL drop ; >>>>>>>>>>>>>>>>> Not sure if I can port/hack this code over, the copier seems to have trouble with tbu@ tbl@? >>>>>>>>>>>>>>>> The ms and get-msecs words don't appear to be implemented correctly on OpenBIOS. 10000 ms should pause OpenBIOS for 10 seconds. It does not. >>>>>>>>>>>>>>>> I did find a function called udelay() in the drivers/timer.c file. Maybe I can implement the word us using udelay(). Then the ms word could be implemented using the us word. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> See what you can do about : us, but we maybe running into an issue with Qemu/mac99. Every version of the Mac OS reports a different bus and cpu speed, so we maybe having trouble with the way the timebase is calculated in Qemu. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think you have two choices for this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. Either export udelay (or _wait_ticks it's based on) to Forth and implement these words based on that. But this comment in drivers/timer.c: >>>>>>>>>>>>> >>>>>>>>>>>>> How would I do this? >>>>>>>>>>>>> >>>>>>>>>>>>>> /* >>>>>>>>>>>>>> * TODO: pass via lb table >>>>>>>>>>>>>> */ >>>>>>>>>>>>>> unsigned long timer_freq = 10000000 / 4; >>>>>>>>>>>>>> >>>>>>>>>>>>>> suggests you may need to fix this first to take into accound the actual TB frequency from the CPU instead of some hardcoded value. >>>>>>>>>>>>> >>>>>>>>>>>>> This would make a good next step. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2. Alternatively, you could either add new helpers (maybe in arch/ppc/timebase.S) to implement tbl@ and tbu@ which probably should just do mftb and mftbu respectively or export to Forth the already existing _get_ticks which returns these as a combined 64 bit value and derive the lower and upper 32 bits from Forth and then maybe you can use the above implementation from SLOF. >>>>>>>>>>>>> >>>>>>>>>>>>> It is a possibility. >>>>>>>>>>>>> >>>>>>>>>>>>> We still need a way to access any new C function from forth. The only thing that I think would work is implementing the us word in a device node, then make another definition of us that is available to the dictionary. If anyone has a way to do this, an example would be great. >>>>>>>>>>>> >>>>>>>>>>>> I don't know much about this but looking at the code I think _get_ticks is almost equivalent to tb@ above except that _get_ticks returns tbu@ in %r3 and tbl@ in %r4 but tb@ also combines these into one value. Then you can see e.g. in arch/ppc/qemu/init.c that the bind_func() function is used to make C functions available from Forth. So you could make a C function which calls _get_ticks then combines %r3 and %r4 into a 64bit value (so implements what tb@ does in C) then bind this to tb@. Or bind _get_ticks and implement tb@ calling this and combining the upper and lower values from Forth like above (I think this is what '20 lshift swap ffffffff and or' does but I don't know Forth to tell). >>>>>>>>>>>> >>>>>>>>>>>> You'll also need tb-frequency which can be found in the cpu properties (added in arch/ppc/qemu/init.c by reading the correct value from QEMU). SLOF has a function that seems to be called during init but I can't read Forth enough to tell for sure what it actually does: >>>>>>>>>>>> >>>>>>>>>>>> \ Fixup timebase frequency from device-tree >>>>>>>>>>>> : fixup-tbfreq >>>>>>>>>>>> " /cpus/@0" find-device >>>>>>>>>>>> " timebase-frequency" get-node get-package-property IF >>>>>>>>>>>> 2drop >>>>>>>>>>>> ELSE >>>>>>>>>>>> decode-int to tb-frequency 2drop >>>>>>>>>>>> THEN >>>>>>>>>>>> device-end >>>>>>>>>>>> ; >>>>>>>>>>>> fixup-tbfreq >>>>>>>>>>>> >>>>>>>>>>>> But I think this is what sets tb-frequency global value so you'll probably need something similar somewhere (maybe ppc.fs). Then you have tb@ and tb-frequency so the rest should work. >>>>>>>>>>>> >>>>>>>>>>>> Now it's your turn to find out how to do this in OpenBIOS. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> BALATON Zoltan >>>>>>>>>>> >>>>>>>>>>> This code can be directly pasted into OpenBIOS: >>>>>>>>>>> >>>>>>>>>>> 0 value tb-frequency >>>>>>>>>>> >>>>>>>>>>> \ Fixup timebase frequency from device-tree >>>>>>>>>>> : fixup-tbfreq >>>>>>>>>>> " /cpus/@0" find-device >>>>>>>>>>> " timebase-frequency" active-package get-package-property IF >>>>>>>>>>> 2drop >>>>>>>>>>> ELSE >>>>>>>>>>> decode-int to tb-frequency 2drop >>>>>>>>>>> THEN >>>>>>>>>>> device-end >>>>>>>>>>> ; >>>>>>>>>>> fixup-tbfreq >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I applied your patch, and used this code in Openbios, then booted the Mac OS to see if it reported the correct Bus Frequency, but it still reporting 400mhz bus speed. >>>>>>>>> >>>>>>>>> How do you define "correct bus frequency"? >>>>>>>>> >>>>>>>>> From what I remember Mac OS only supports certain bus frequencies. Well I'm not sure if it was bus or CPU frequencies that I am thinking about. >>>>>>>>> >>>>>>>> Seems to be just the ASP getting the Bus Frequency wrong, for mac99. It reposts it correct for g3beige, and skidmarks GT reports the correct Timebase for each. Mac99 isn’t really any one machine, so I’t no wonder we have these odd quirks. >>>>>>> >>>>>>> What is Apple System Profiler reporting as the bus frequency? It is calculating it, looking the value up in a table, or reading the value from hardware. >>>>>> >>>>>> For mac99 it reports 400mhz bus speed, for g3biege it reports 67mhz( This is correct 4x the timebase ) There maybe some code in Qemu that is multiplying the timebase by 4 to set the bus speed, I haven’t looked into it. Really, it doesn’t matter, as long as the timebase is reported correctly, and it is. >>>>>> >>>>>>> >>>>>>>> Are you trying to get the correct timing for the ms and us words, was that part of the point of your patch? >>>>>>> >>>>>>> I was trying to make the words from SLOF work on OpenBIOS. Making the ms and us words work correctly would be an added bonus. I was debating on whether the tb-frequency value should be calculated instead of just copied. If it was calculated, then words like ms and us would work correctly. >>>>>> >>>>>> Yes, I think the issue I’m having with the nVidia option rom is related to the us word, as all the b?branch and b(<resolve) words work correct until us is called. >>>>>> >>>>>> I wish I could be more help, but we’re way over my head now. >>>>>> >>>>>> I can’t seem to debug the us word, when I call debug us, then 4000040 1 byte-load, it just goes right past the us word? >>>>> >>>>> I don't think you need to debug the us word. All it does is delay execution for a specified amount of microseconds. Would it help if I implemented the us word in C instead of forth? >>>> >>>> I’m not sure how long the delay should be: >>>> >>>> : us ( n — ) d# 1000 / 1+ ms ; >>>> >>>> Seems to do the same thing SLOF does: >>>> >>>> >>>> : tb@ ( -- tb ) >>>> BEGIN tbu@ tbl@ tbu@ rot over <> WHILE 2drop REPEAT >>>> 20 lshift swap ffffffff and or >>>> ; >>>> >>>> : milliseconds ( -- ms ) tb@ d# 1000 * tb-frequency / ; >>>> : microseconds ( -- us ) tb@ d# 1000000 * tb-frequency / ; >>>> >>>> : ms ( ms-to-wait -- ) milliseconds + BEGIN milliseconds over >= UNTIL drop ; >>>> : get-msecs ( -- n ) milliseconds ; >>>> : us ( us-to-wait -- ) microseconds + BEGIN microseconds over >= UNTIL drop ; >>>> >>>> But the system doesn’t pause that I can tell, when the us word is called. >>>> >>>> I was just hoping this was the issue I was having, that ms and us were not working the way they should, and the fcode was “trying” to write a register before the state of the card was “ready”, if that makes sense. >>>> >>>> It would be helpful if you could add the us word to openbios, save me from typing it in each time, and it’s always better to have more words in our emulator. >>>> >>>> Thanks >>> >>> Ok this will add the us and ms words to the dictionary. I hand tuned them to actually be accurate on my system. I don't know how accurate they will be on your system. Hopefully it will be enough to move forward with the video card work. >>> <0001-add-support-for-ms-and-us-words.patch> >>> You can adjust the multiplier variable to meet your needs. To test it out you would need a stop watch or a stop watch app. >>> In the openbios terminal type these commands: >>> decimal >>> 10000 ms >>> >>> If this delays openbios by 10 seconds, then the ms word is working on your system. >>> >>> The us word would be tested like this: >>> decimal >>> 1000000 us >>> >> >> Not sure, us is still an undefined word, and: >> >> decimal >> 10000 ms >> >> Just returns OK immediately. >> >> I think I got e patch right? >> >> >> <init.c> > > The file looks correct. Are you sure you using the right openbios file? Did you rebuild openbios after applying the patch? Got the wrong build dir ;-( I can’t seem to apply both patches, assuming the second patch for ms and us relies on the first? patch -p3 < /Users/jam/Desktop/0001-add-support-for-ms-and-us-words.patch can't find file to patch at input line 15 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |From c33e547fc38f1c8ddb49addb76aa6fc97407a0f6 Mon Sep 17 00:00:00 2001 |From: John Arbuckle <programmingkidx(a)gmail.com> |Date: Thu, 28 Dec 2017 14:54:04 -0500 |Subject: [PATCH] add support for ms and us words | |Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> |--- | arch/ppc/qemu/init.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++++ | 1 file changed, 69 insertions(+) | |diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c |index 5ce080c..bbb2c4e 100644 |--- a/arch/ppc/qemu/init.c |+++ b/arch/ppc/qemu/init.c -------------------------- File to patch: /Users/jam/obnew2/master/arch/ppc/qemu/init.c patching file /Users/jam/obnew2/master/arch/ppc/qemu/init.c Jamess-Mac-Pro:master jam$ patch -p3 < /Users/jam/Desktop/0001-Add-tbu-and-tbl-words.patch can't find file to patch at input line 20 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |From 7c267d518a22f7762013da5b5c5d5bbb162ab3ce Mon Sep 17 00:00:00 2001 |From: John Arbuckle <programmingkidx(a)gmail.com> |Date: Wed, 27 Dec 2017 13:28:17 -0500 |Subject: [PATCH] Add tbu@ and tbl@ words | |The PowerPC timebase register is made available to forth using |the tbu@ and tbl@ words. The tbu@ word pushes the upper 32 bits |of this register. The tbl@ word pushes the lower 32 bits of |this register. | |Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> |--- | arch/ppc/qemu/init.c | 20 ++++++++++++++++++++ | 1 file changed, 20 insertions(+) | |diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c |index 5ce080c..d12084c 100644 |--- a/arch/ppc/qemu/init.c |+++ b/arch/ppc/qemu/init.c -------------------------- File to patch: /Users/jam/obnew2/master/arch/ppc/qemu/init.c patching file /Users/jam/obnew2/master/arch/ppc/qemu/init.c Hunk #1 succeeded at 818 with fuzz 1 (offset 67 lines). Hunk #2 FAILED at 1105. 1 out of 2 hunks FAILED -- saving rejects to file /Users/jam/obnew2/master/arch/ppc/qemu/init.c.rej Jamess-Mac-Pro:master jam$ Just applying the us/ms patch did allow me to debug the b(>resolve) word that I am catching the exception on: 8010035 : b?branch [ 0x14 ] (offset) 26 8010039 : (compile) [ 0x9bd ] 801003a : (compile) b(lit) [ 0x10 ] 801003f : (compile) and [ 0x23 ] 8010041 : (compile) my-space [ 0x103 ] 8010042 : (compile) + [ 0x1e ] 8010044 : (compile) [ 0xa08 ] 8010045 : (compile) b(lit) [ 0x10 ] 801004a : (compile) and [ 0x23 ] 801004b : (compile) b(lit) [ 0x10 ] 8010050 : (compile) = [ 0x3c ] 8010051 : (compile) b?branch [ 0x14 ] (offset) 9 8010054 : (compile) b(') [ 0x11 ] 8010057 : (compile) b(to) [ 0xc3 ] 801005a : (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) ] 801005b : (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 [View Less]

3 4

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 … [View More]

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 =============================================================… [View More]====== --- 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"); [View Less]

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: + ( … [View More]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. [View Less]

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/… [View More]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 [View Less]

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: … [View More]

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.… [View More] 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 > [View Less]

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 … [View More]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. [View Less]

4 9