> 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:
>>>>
>>>>
>>>>
>>>>> 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
