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
On Dec 20, 2017, at 8:53 AM, Jd Lyons lyons_dj@yahoo.com wrote:
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
I tried copying and pasting into OpenBIOS and saw these errors: ?compile-mode: undefined word. read-fcode-offset: undefined word. dest-on-top: undefined word. ?jump-direction: undefined word.
I could not find these words in my openfirmware specification pdf document. My guess is they only exist on SLOF. In general the definition of words tend not to be so portable.
OpenBIOS does come with a built-in debugger that would allow you to see exactly what is executing.
https://docs.oracle.com/cd/E19620-01/805-4436/6j4719ca7/index.html - Webpage on how to use the forth debugger
Here is a quick tutorial:
Lets say you want to debug this simple word:
: myword 1 2 3 4 ;
To indicate that a word is to be debugged type this: debug myword
Then run the word myword by just typing myword and pushing return at the prompt.
You will see something like this next: : myword ( Empty )
To step thru each instruction in myword, push the return key.
You will see this each time the return key is pushed: <adddress>: 1 ( 1 ) <adddress>: 2 ( 1 2 ) <adddress>: 3 ( 1 2 3 ) <adddress>: (lit) (1 2 3 4) <adddress>: (semis) [ Finished myword ] ok
The values in the parentheses indicate what is going into the stack.
I suggest familiarizing yourself with the debugger first before starting on the b?branch word.
One question to answer is are we experiencing problems at compile time or at run-time.
On Dec 20, 2017, at 12:45 PM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 20, 2017, at 8:53 AM, Jd Lyons lyons_dj@yahoo.com wrote:
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
I tried copying and pasting into OpenBIOS and saw these errors: ?compile-mode: undefined word. read-fcode-offset: undefined word. dest-on-top: undefined word. ?jump-direction: undefined word.
I could not find these words in my openfirmware specification pdf document. My guess is they only exist on SLOF. In general the definition of words tend not to be so portable.
OpenBIOS does come with a built-in debugger that would allow you to see exactly what is executing.
https://docs.oracle.com/cd/E19620-01/805-4436/6j4719ca7/index.html
- Webpage on how to use the forth debugger
Here is a quick tutorial:
Lets say you want to debug this simple word:
: myword 1 2 3 4 ;
To indicate that a word is to be debugged type this: debug myword
Then run the word myword by just typing myword and pushing return at the prompt.
You will see something like this next: : myword ( Empty )
To step thru each instruction in myword, push the return key.
You will see this each time the return key is pushed: <adddress>: 1 ( 1 ) <adddress>: 2 ( 1 2 ) <adddress>: 3 ( 1 2 3 ) <adddress>: (lit) (1 2 3 4) <adddress>: (semis) [ Finished myword ] ok
The values in the parentheses indicate what is going into the stack.
I suggest familiarizing yourself with the debugger first before starting on the b?branch word.
One question to answer is are we experiencing problems at compile time or at run-time.
Like Segher said, it’s tricky.
I shamelessly hacked it together, but now it hangs on b?branch around here:
(offset) 1b 400b092 : (compile) [ 0xcfa ] 400b093 : (compile) b(lit) [ 0x10 ] 400b098 : (compile) < [ 0x3a ] 400b099 : (compile) b?branch [ 0x14 ] (offset) f 400b09c : (compile) b(lit) [ 0x10 ] 400b0a1 : (compile) b(lit) [ 0x10 ] 400b0a7 : (compile) [ 0xbd2 ] 400b0a8 : (compile) b(>resolve) [ 0xb2 ] 400b0a9 : (compile) b(>resolve) [ 0xb2 ]
After hanging for 10 min or so, Openbios reboots.diff --git a/Makefile.target b/Makefile.target
So I’m still not getting it right, everyone have a look and see if you can find anything that doesn’t look ok.
diff --git a/Makefile.target b/Makefile.target index 4c54105..4f10714 100644 --- a/Makefile.target +++ b/Makefile.target @@ -29,7 +29,7 @@ CFLAGS+= -Os -g -DNATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH -USWAP_ENDIANNESS CFLAGS+= -Wall -Wredundant-decls -Wshadow -Wpointer-arith CFLAGS+= -Wstrict-prototypes -Wmissing-declarations -Wundef -Wendif-labels CFLAGS+= -Wstrict-aliasing -Wwrite-strings -Wmissing-prototypes -Wnested-externs -CFLAGS+= -Werror +CFLAGS+= # Flags for dependency generation CFLAGS+= -MMD -MP -MT $@ -MF '$(*D)/$(*F).d' INCLUDES := -I$(SRCDIR)/include -I$(SRCDIR)/kernel/include -I$(ODIR)/target/include diff --git a/forth/device/fcode.fs b/forth/device/fcode.fs index 9083ed0..9035654 100644 --- a/forth/device/fcode.fs +++ b/forth/device/fcode.fs @@ -6,7 +6,25 @@ \ \ See the file "COPYING" for further information about \ the copyright and warranty status of this work. -\ +\ + +\ ***************************************************************************** +\ * Copyright (c) 2004, 2011 IBM Corporation +\ * All rights reserved. +\ * This program and the accompanying materials +\ * are made available under the terms of the BSD License +\ * which accompanies this distribution, and is available at +\ * http://www.opensource.org/licenses/bsd-license.php +\ * +\ * Contributors: +\ * IBM Corporation - initial implementation +\ ****************************************************************************/ + + +variable ip +variable fcode-end +variable fcode-num +
hex
@@ -460,24 +478,114 @@ defer fcode-c@ \ get byte 2swap then ; immediate - + + + + + + : get-ip ( -- n ) + ip @ + ; + + : set-ip ( n -- ) + ip ! + ; + + : next-ip ( -- ) + get-ip 1+ set-ip + ; + + : ?compile-mode ( -- on|off ) + state @ + ; + + : ?offset16 ( -- true|false ) + fcode-offset 2 = + ; + + : read-byte ( -- n ) + get-ip + ; + + : ?arch64 ( -- true|false ) + cell 8 = + ; + + + + : read-fcode-num16 ( -- n ) + 0 fcode-num ! + ?arch64 IF + read-byte fcode-num 7 + C! + next-ip + read-byte fcode-num 6 + C! + ELSE + read-byte fcode-num 1 + C! + next-ip + read-byte fcode-num 0 + C! + THEN + fcode-num @ + ; + + : read-fcode# ( -- FCode# ) + read-byte + dup 01 0F between IF drop read-fcode-num16 THEN + ; + + : read-fcode-offset + next-ip + ?offset16 IF + read-fcode-num16 + ELSE + read-byte + dup 80 and IF FF00 or THEN \ Fake 16-bit signed offset + THEN + ; + + : dest-on-top + 0 >r BEGIN dup @ 0= WHILE >r REPEAT + BEGIN r> dup WHILE swap REPEAT + drop + ; + + : ?negative + 8000 and + ; + + : jump-n-ip ( n -- ) + get-ip + set-ip + ; + + : ?jump-direction ( n -- ) + dup 8000 >= IF + 10000 - \ Create cell-sized negative value + THEN + fcode-offset - \ IP is already behind offset, so subtract offset size + ;
\ 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 +: 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
+ + \ b(<mark) ( -- ) \ Target of backward branches.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
I don’t know if this is helpful at all, trying with debug b?branch:
400af3d : (compile) b?branch [ 0x14 ]
: b?branch ( ) fff46cbc: ?compile-mode ( ) fff46cc0: do?branch ( ) fff46cc8: read-fcode-offset (offset) b ( ) fff46ccc: ?negative ( ) fff46cd0: do?branch ( ) fff46cd8: dest-on-top ( ) fff46cdc: (lit) ( ) fff46ce4: , ( ) fff46ce8: dobranch ( ) fff46cf4: dobranch ( ) fff46d20: (semis) [ Finished b?branch ] 400af40 : (compile) b(lit) [ 0x10 ] 400af45 : (compile) bbranch [ 0x13 ] (offset) 5 400af48 : (compile) b(>resolve) [ 0xb2 ] 400af49 : (compile) 0 [ 0xa5 ] 400af4a : (compile) b(>resolve) [ 0xb2 ] 400af4c : (compile) [ 0xda2 ] 400af4d : (compile) b(lit) [ 0x10 ] 400af52 : (compile) and [ 0x23 ] 400af53 : (compile) 3 [ 0xa8 ] 400af54 : (compile) rshift [ 0x28 ] 400af55 : (compile) or [ 0x24 ] 400af57 : (compile) [ 0xcfb ] 400af58 : (compile) 1 [ 0xa6 ] 400af59 : (compile) - [ 0x1f ] 400af5a : (compile) b(lit) [ 0x10 ] 400af5f : (compile) and [ 0x23 ] 400af60 : (compile) b(lit) [ 0x10 ] 400af65 : (compile) rshift [ 0x28 ] 400af66 : (compile) or [ 0x24 ] 400af67 : (compile) b(lit) [ 0x10 ] 400af6d : (compile) [ 0xbd2 ] 400af6f : (compile) [ 0xd00 ] 400af70 : (compile) b(lit) [ 0x10 ] 400af75 : (compile) and [ 0x23 ] 400af76 : (compile) b(lit) [ 0x10 ] 400af7c : (compile) [ 0xbd2 ] 400af7e : (compile) [ 0xd01 ] 400af7f : (compile) b(lit) [ 0x10 ] 400af84 : (compile) and [ 0x23 ] 400af85 : (compile) b(lit) [ 0x10 ] 400af8b : (compile) [ 0xbd2 ] 400af8d : (compile) [ 0xcfb ] 400af8e : (compile) 1 [ 0xa6 ] 400af8f : (compile) - [ 0x1f ] 400af90 : (compile) b(lit) [ 0x10 ] 400af95 : (compile) and [ 0x23 ] 400af96 : (compile) b(lit) [ 0x10 ] 400af9c : (compile) [ 0xbd2 ] 400af9e : (compile) [ 0xb3a ] 400af9f : (compile) b(lit) [ 0x10 ] 400afa4 : (compile) / [ 0x21 ] 400afa6 : (compile) [ 0xcfa ] 400afa7 : (compile) * [ 0x20 ] 400afa9 : (compile) [ 0xdaf ] 400afaa : (compile) b(lit) [ 0x10 ] 400afaf : (compile) / [ 0x21 ] 400afb0 : (compile) b(to) [ 0xc3 ] 400afb4 : (compile) [ 0xb3a ] 400afb5 : (compile) b(lit) [ 0x10 ] 400afba : (compile) = [ 0x3c ] 400afbb : (compile) b?branch [ 0x14 ]
: b?branch ( ) fff46cbc: ?compile-mode ( ) fff46cc0: do?branch ( ) fff46cc8: read-fcode-offset (offset) 7 ( ) fff46ccc: ?negative ( ) fff46cd0: do?branch ( ) fff46cd8: dest-on-top ( ) fff46cdc: (lit) ( ) fff46ce4: , ( ) fff46ce8: dobranch ( ) fff46cf4: dobranch ( ) fff46d20: (semis) [ Finished b?branch ] 400afbe : (compile) 3 [ 0xa8 ] 400afbf : (compile) bbranch [ 0x13 ] (offset) c 400afc2 : (compile) b(>resolve) [ 0xb2 ] 400afc4 : (compile) [ 0xb3a ] 400afc5 : (compile) b(lit) [ 0x10 ] 400afca : (compile) / [ 0x21 ] 400afcb : (compile) b(>resolve) [ 0xb2 ] 400afcc : (compile) b(lit) [ 0x10 ] 400afd2 : (compile) [ 0xbd1 ] 400afd3 : (compile) b(lit) [ 0x10 ] 400afd8 : (compile) and [ 0x23 ] 400afd9 : (compile) or [ 0x24 ] 400afda : (compile) b(lit) [ 0x10 ] 400afe0 : (compile) [ 0xbd2 ] 400afe2 : (compile) [ 0xda3 ] 400afe3 : (compile) b(lit) [ 0x10 ] 400afe8 : (compile) and [ 0x23 ] 400afe9 : (compile) b(lit) [ 0x10 ] 400afef : (compile) [ 0xbd2 ] 400aff0 : (compile) 0 [ 0xa5 ] 400aff1 : (compile) b(lit) [ 0x10 ] 400aff7 : (compile) [ 0xbd2 ] 400aff9 : (compile) [ 0xcfb ] 400affa : (compile) 1 [ 0xa6 ] 400affb : (compile) - [ 0x1f ] 400affc : (compile) b(lit) [ 0x10 ] 400b001 : (compile) and [ 0x23 ] 400b002 : (compile) b(lit) [ 0x10 ] 400b008 : (compile) [ 0xbd2 ] 400b00a : (compile) [ 0xcff ] 400b00b : (compile) 1 [ 0xa6 ] 400b00c : (compile) - [ 0x1f ] 400b00d : (compile) b(lit) [ 0x10 ] 400b012 : (compile) and [ 0x23 ] 400b013 : (compile) b(lit) [ 0x10 ] 400b019 : (compile) [ 0xbd2 ] 400b01a : (compile) b(lit) [ 0x10 ] 400b01f : (compile) b(lit) [ 0x10 ] 400b025 : (compile) [ 0xbd2 ] 400b027 : (compile) [ 0xda2 ] 400b028 : (compile) b(lit) [ 0x10 ] 400b02d : (compile) and [ 0x23 ] 400b02e : (compile) b(lit) [ 0x10 ] 400b034 : (compile) [ 0xbd2 ] 400b036 : (compile) [ 0xda3 ] 400b037 : (compile) b(lit) [ 0x10 ] 400b03c : (compile) and [ 0x23 ] 400b03d : (compile) b(lit) [ 0x10 ] 400b042 : (compile) rshift [ 0x28 ] 400b043 : (compile) b(lit) [ 0x10 ] 400b048 : (compile) lshift [ 0x27 ] 400b049 : (compile) b(lit) [ 0x10 ] 400b04f : (compile) [ 0xbd2 ] 400b051 : (compile) [ 0x93d ] 400b052 : (compile) b(lit) [ 0x10 ] 400b057 : (compile) >= [ 0x42 ] 400b059 : (compile) [ 0x93d ] 400b05a : (compile) b(lit) [ 0x10 ] 400b05f : (compile) <> [ 0x3d ] 400b060 : (compile) and [ 0x23 ] 400b061 : (compile) b?branch [ 0x14 ]
: b?branch ( ) fff46cbc: ?compile-mode ( ) fff46cc0: do?branch ( ) fff46cc8: read-fcode-offset (offset) 18 ( ) fff46ccc: ?negative ( ) fff46cd0: do?branch ( ) fff46cd8: dest-on-top ( ) fff46cdc: (lit) ( ) fff46ce4: , ( ) fff46ce8: dobranch ( ) fff46cf4: dobranch ( ) fff46d20: (semis) [ Finished b?branch ] 400b065 : (compile) [ 0xda3 ] 400b066 : (compile) b(lit) [ 0x10 ] 400b06b : (compile) and [ 0x23 ] 400b06c : (compile) b(lit) [ 0x10 ] 400b071 : (compile) rshift [ 0x28 ] 400b072 : (compile) b(lit) [ 0x10 ] 400b078 : (compile) [ 0xbd2 ] 400b079 : (compile) b(>resolve) [ 0xb2 ] 400b07a : (compile) b(lit) [ 0x10 ] 400b07f : (compile) b(lit) [ 0x10 ] 400b085 : (compile) [ 0xbd2 ] 400b087 : (compile) [ 0xcfb ] 400b088 : (compile) b(lit) [ 0x10 ] 400b08d : (compile) < [ 0x3a ] 400b08e : (compile) b?branch [ 0x14 ]
: b?branch ( ) fff46cbc: ?compile-mode ( ) fff46cc0: do?branch ( ) fff46cc8: read-fcode-offset (offset) 1b ( ) fff46ccc: ?negative ( ) fff46cd0: do?branch ( ) fff46cd8: dest-on-top ( ) fff46cdc: (lit) ( ) fff46ce4: , ( ) fff46ce8: dobranch ( ) fff46cf4: dobranch ( ) fff46d20: (semis) [ Finished b?branch ] 400b092 : (compile) [ 0xcfa ] 400b093 : (compile) b(lit) [ 0x10 ] 400b098 : (compile) < [ 0x3a ] 400b099 : (compile) b?branch [ 0x14 ]
: b?branch ( ) fff46cbc: ?compile-mode ( ) fff46cc0: do?branch ( ) fff46cc8: read-fcode-offset (offset) f ( ) fff46ccc: ?negative ( ) fff46cd0: do?branch ( ) fff46cd8: dest-on-top ( ) fff46cdc: (lit) ( ) fff46ce4: , ( ) fff46ce8: dobranch ( ) fff46cf4: dobranch ( ) fff46d20: (semis) [ Finished b?branch ] 400b09c : (compile) b(lit) [ 0x10 ] 400b0a1 : (compile) b(lit) [ 0x10 ] 400b0a7 : (compile) [ 0xbd2 ] 400b0a8 : (compile) b(>resolve) [ 0xb2 ] 400b0a9 : (compile) b(>resolve) [ 0xb2 ]
We hang here with no further debugging………………………….
I don’t know, this maybe an issue with the way we have defined “us”.
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@?
On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@yahoo.com wrote:
I don’t know, this maybe an issue with the way we have defined “us”.
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.
On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@yahoo.com wrote:
I don’t know, this maybe an issue with the way we have defined “us”.
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 imagine it is difficult to emulate a fixed frequency isolator, or I’m way off base and people should just ignore me;-)
Just spitballing, really.
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 imagine it is difficult to emulate a fixed frequency isolator, or I’m way off base and people should just ignore me;-)
Just spitballing, really.
I tried to implement the us word but I couldn't figure out how to solve the problem of making udelay() work from forth.c. Any hints would be appreciated.
Here is my work-in-progress patch:
From deba6065416cda16198092f4c5dac0ecab8e0f46 Mon Sep 17 00:00:00 2001 From: John Arbuckle programmingkidx@gmail.com Date: Thu, 21 Dec 2017 11:58:10 -0500 Subject: [PATCH] Attempt to implement the us word
--- kernel/bootstrap.c | 2 +- kernel/forth.c | 11 +++++++++++ 2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/kernel/bootstrap.c b/kernel/bootstrap.c index b7658ab..6838b40 100644 --- a/kernel/bootstrap.c +++ b/kernel/bootstrap.c @@ -89,7 +89,7 @@ static const char *wordnames[] = { "here", "here!", "dobranch", "do?branch", "unaligned-w@", "unaligned-w!", "unaligned-l@", "unaligned-l!", "ioc@", "iow@", "iol@", "ioc!", "iow!", "iol!", "i", "j", "call", "sys-debug", - "$include", "$encode-file", "(debug", "(debug-off)" + "$include", "$encode-file", "(debug", "(debug-off)", "us" };
/* diff --git a/kernel/forth.c b/kernel/forth.c index 61dd70d..19df6b2 100644 --- a/kernel/forth.c +++ b/kernel/forth.c @@ -12,6 +12,7 @@ #include "kernel/stack.h" #include "kernel/kernel.h" #include "dict.h" +#include "../drivers/timer.h"
/* * cross platform abstraction @@ -1848,6 +1849,15 @@ static void loop_j(void) PUSH(rstack[rstackcnt - 2]); }
+/* implements the forth word us */ +static void microseconds(void) +{ + int time; /* in microseconds or one millionth of a second */ + time = POP(); + printk("Hello from microseconds: %d\n", time); + //udelay(time); +} + /* words[] is a function array of all native code functions used by * the dictionary, i.e. CFAs and primitives. * Any change here needs a matching change in the primitive word's @@ -1963,4 +1973,5 @@ static forth_word * const words[] = { do_encode_file, /* $encode-file */ do_debug_xt, /* (debug */ do_debug_off, /* (debug-off) */ + microseconds /* us */ };
On Thu, 21 Dec 2017, Jd Lyons wrote:
On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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:
/* * 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.
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.
Regards, BALATON Zoltan
On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 21 Dec 2017, Jd Lyons wrote:
On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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:
- 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.
- 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.
On Thu, 21 Dec 2017, Programmingkid wrote:
On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: On Thu, 21 Dec 2017, Jd Lyons wrote:
On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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:
- 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.
- 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
On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 21 Dec 2017, Programmingkid wrote:
On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: On Thu, 21 Dec 2017, Jd Lyons wrote:
On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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:
- 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.
- 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
Thanks Balaton, that seem pretty clear.
PK, I’ll be heading out for a few days, hope you have a good holiday, we can pick this up latter.
On Dec 21, 2017, at 8:52 PM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 21 Dec 2017, Programmingkid wrote:
On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: On Thu, 21 Dec 2017, Jd Lyons wrote:
On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote: > On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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:
- 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.
- 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
Thanks Balaton, that seem pretty clear.
PK, I’ll be heading out for a few days, hope you have a good holiday, we can pick this up latter.
Ok. Enjoy your break. If I come up with anything I will report it here.
On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 21 Dec 2017, Programmingkid wrote:
On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: On Thu, 21 Dec 2017, Jd Lyons wrote:
On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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:
- 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.
- 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
Ok. I think I can access the CPU's properties using inline assembly language. I will make a patch soon to test this theory soon.
On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 21 Dec 2017, Programmingkid wrote:
On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: On Thu, 21 Dec 2017, Jd Lyons wrote:
On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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:
- 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.
- 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
Ok, I figured out how to implement tbu@ and tbl@. The patch is being sent in to the mailing list. Now we can use the same definition for tb@ that SLOF uses. For tb-frequency I think that is simply a constant. It may need to be calculated.
On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 21 Dec 2017, Programmingkid wrote:
On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: On Thu, 21 Dec 2017, Jd Lyons wrote:
On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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:
- 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.
- 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
Now that tbl@, tbu@, and tb-frequency are done, the code from SLOF will probably work in OpenBIOS.
On Dec 27, 2017, at 5:02 PM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 21 Dec 2017, Programmingkid wrote:
On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: On Thu, 21 Dec 2017, Jd Lyons wrote:
On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote: > On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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:
- 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.
- 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.
Not really sure what this code should do, but, I’m not sure you are aware, qemu's new_world.c and the old_world.c also set the timebase for mac99 and g3biege.
Thanks for putting in this work.
Now that tbl@, tbu@, and tb-frequency are done, the code from SLOF will probably work in OpenBIOS.
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 Dec 28, 2017, at 9:36 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 27, 2017, at 5:02 PM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 21 Dec 2017, Programmingkid wrote:
On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: On Thu, 21 Dec 2017, Jd Lyons wrote:
> On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote: >> On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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:
- 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.
- 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.
Not really sure what this code should do, but, I’m not sure you are aware, qemu's new_world.c and the old_world.c also set the timebase for mac99 and g3biege.
Thanks for putting in this work.
You are welcome. I'm glad to help.
Now that tbl@, tbu@, and tb-frequency are done, the code from SLOF will probably work in OpenBIOS.
OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Dec 28, 2017, at 9:56 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 28, 2017, at 9:36 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 27, 2017, at 5:02 PM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 21 Dec 2017, Programmingkid wrote:
On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: On Thu, 21 Dec 2017, Jd Lyons wrote: >> On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote: >>> On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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:
- 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.
- 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.
Are you trying to get the correct timing for the ms and us words, was that part of the point of your patch?
Not really sure what this code should do, but, I’m not sure you are aware, qemu's new_world.c and the old_world.c also set the timebase for mac99 and g3biege.
Thanks for putting in this work.
You are welcome. I'm glad to help.
Now that tbl@, tbu@, and tb-frequency are done, the code from SLOF will probably work in OpenBIOS.
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
-- 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 Dec 28, 2017, at 10:13 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 28, 2017, at 9:56 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 28, 2017, at 9:36 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 27, 2017, at 5:02 PM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 21 Dec 2017, Programmingkid wrote:
> On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: > On Thu, 21 Dec 2017, Jd Lyons wrote: >>> On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote: >>>> On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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.
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.
On Dec 28, 2017, at 10:20 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 28, 2017, at 10:13 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 28, 2017, at 9:56 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 28, 2017, at 9:36 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 27, 2017, at 5:02 PM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Thu, 21 Dec 2017, Programmingkid wrote: >> On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: >> On Thu, 21 Dec 2017, Jd Lyons wrote: >>>> On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote: >>>>> On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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 tried changing the load-base, as I was getting memory corruption:
setenv load-base 8000000
That seems to fix the memory corruption, but I still can’t debug the us word.
On Dec 28, 2017, at 10:39 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 28, 2017, at 10:20 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 28, 2017, at 10:13 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 28, 2017, at 9:56 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 28, 2017, at 9:36 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 27, 2017, at 5:02 PM, Programmingkid programmingkidx@gmail.com wrote:
> > On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote: > > On Thu, 21 Dec 2017, Programmingkid wrote: >>> On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: >>> On Thu, 21 Dec 2017, Jd Lyons wrote: >>>>> On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote: >>>>>> On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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 tried changing the load-base, as I was getting memory corruption:
setenv load-base 8000000
That seems to fix the memory corruption, but I still can’t debug the us word.
If your video card is using this word, it is probably just waiting for some state in the card to change. I wouldn't worry about it.
On Dec 28, 2017, at 10:47 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 28, 2017, at 10:39 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 28, 2017, at 10:20 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 28, 2017, at 10:13 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 28, 2017, at 9:56 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 28, 2017, at 9:36 AM, Jd Lyons lyons_dj@yahoo.com wrote:
> On Dec 27, 2017, at 5:02 PM, Programmingkid programmingkidx@gmail.com wrote: > >> >> On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote: >> >> On Thu, 21 Dec 2017, Programmingkid wrote: >>>> On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: >>>> On Thu, 21 Dec 2017, Jd Lyons wrote: >>>>>> On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote: >>>>>>> On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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
I tried changing the load-base, as I was getting memory corruption:
setenv load-base 8000000
That seems to fix the memory corruption, but I still can’t debug the us word.
If your video card is using this word, it is probably just waiting for some state in the card to change. I wouldn't worry about it.
On Dec 28, 2017, at 11:01 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 28, 2017, at 10:47 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 28, 2017, at 10:39 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 28, 2017, at 10:20 AM, Programmingkid programmingkidx@gmail.com wrote:
On Dec 28, 2017, at 10:13 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Dec 28, 2017, at 9:56 AM, Programmingkid programmingkidx@gmail.com wrote:
> > On Dec 28, 2017, at 9:36 AM, Jd Lyons lyons_dj@yahoo.com wrote: > > > >> On Dec 27, 2017, at 5:02 PM, Programmingkid programmingkidx@gmail.com wrote: >> >>> >>> On Dec 21, 2017, at 6:51 PM, BALATON Zoltan balaton@eik.bme.hu wrote: >>> >>> On Thu, 21 Dec 2017, Programmingkid wrote: >>>>> On Dec 21, 2017, at 12:56 PM, BALATON Zoltan balaton@eik.bme.hu wrote: >>>>> On Thu, 21 Dec 2017, Jd Lyons wrote: >>>>>>> On Dec 21, 2017, at 9:59 AM, Programmingkid programmingkidx@gmail.com wrote: >>>>>>>> On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@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.
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
This should delay things for 1 second. If it doesn't, feel free to adjust the multiplier variable.
From c33e547fc38f1c8ddb49addb76aa6fc97407a0f6 Mon Sep 17 00:00:00 2001 From: John Arbuckle programmingkidx@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@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 @@ -751,6 +751,73 @@ static void adler32(void) RET(s2 << 16 | s1); }
+/* delays execution for the specified time in microseconds ( us -- ) */ +static void microseconds(void) +{ + uint32_t us_delay; // user specified delay time + uint32_t multiplier; + uint32_t start_tbl, start_tbu; + uint32_t end_tbl, end_tbu; + uint32_t current_tbl, current_tbu; + + multiplier = 100; + us_delay = POP(); + asm volatile("mftb %0" : "=r"(start_tbl)); + asm volatile("mftbu %0" : "=r"(start_tbu)); + end_tbl = start_tbl + us_delay * multiplier; + end_tbu = start_tbu; + if (end_tbl < start_tbl) { // if a low-order to high-order carry happened + end_tbu++; + } + + while (1) { + asm volatile("mftb %0" : "=r"(current_tbl)); + asm volatile("mftbu %0" : "=r"(current_tbu)); + if (end_tbu == current_tbu) { + if ((end_tbl - current_tbl) <= 0 ) { + return; + } + } + else if (end_tbu < current_tbu) { + return; + } + } +} + + +/* delays execution for the specified time in milliseconds ( ms -- ) */ +static void milliseconds(void) +{ + uint32_t ms_delay; // user specified delay time + uint32_t multiplier; + uint32_t start_tbl, start_tbu; + uint32_t end_tbl, end_tbu; + uint32_t current_tbl, current_tbu; + + multiplier = 100000; + ms_delay = POP(); + asm volatile("mftb %0" : "=r"(start_tbl)); + asm volatile("mftbu %0" : "=r"(start_tbu)); + end_tbl = start_tbl + ms_delay * multiplier; + end_tbu = start_tbu; + if (end_tbl < start_tbl) { // if a low-order to high-order carry happened + end_tbu++; + } + + while (1) { + asm volatile("mftb %0" : "=r"(current_tbl)); + asm volatile("mftbu %0" : "=r"(current_tbu)); + if (end_tbu == current_tbu) { + if ((end_tbl - current_tbl) <= 0 ) { + return; + } + } + else if (end_tbu < current_tbu) { + return; + } + } +} + void arch_of_init(void) { @@ -1022,4 +1089,6 @@ arch_of_init(void)
bind_func("platform-boot", boot); bind_func("(arch-go)", arch_go); + bind_func("ms", milliseconds); + bind_func("us", microseconds); }
On 21/12/17 14:59, Programmingkid wrote:
On Dec 21, 2017, at 9:36 AM, Jd Lyons lyons_dj@yahoo.com wrote:
I don’t know, this maybe an issue with the way we have defined “us”.
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.
Yeah... I did start fixing up the timers in OpenBIOS (get-msecs works for SPARC) but didn't get around to finishing it. Another things for the TODO list I guess... implementing udelay() is probably a good starting point, but it has been a while since I looked at that code.
ATB,
Mark.
-
BALATON Zoltan -
Jd Lyons -
Mark Cave-Ayland -
Programmingkid