OpenBIOS

openbios@openbios.org

4289 discussions

Re: [OpenBIOS] failed to build
by Mark Cave-Ayland 12 Jan '18

12 Jan '18

On 12/01/18 11:03, Jens Bauernfeind wrote: > Hi Mark, > > I installed coreboot succesfully on my t430. > I build openbios in the x86 version and added the openbios-bultin.elf as addtional payload to the image (with seabios as primary, so i could easily test openbios ) > Unfortunately when I start it, it doesn't recognize the keyboard and several messages "cannot manage <device name>...." > I know that the laptop keyboard is attached via PS/2, and in the drivers/pci.c is a PS2 Keyboard block. > Is there anything I can debug? > > Best Regards, > Jens Fascinating, thanks for the screenshot! I suspect the issue with the keyboard is because it exists behind the PCI-ISA bridge, and since OpenBIOS isn't able to match your particular bridge against its internal list then it never generates the appropriate DT nodes. Now it appears that OpenBIOS does have a default set of legacy devices for the i82378 PCI-ISA bridge, however they should be equally valid for your QM77 PCI-ISA bridge and fairly standard. How about the attached patch which renames i82378_config_cb() to isa_bridge_config_cb() and also adds in the PCI device and vendor ids for your particular PCI-ISA bridge into the OpenBIOS configuration? If this is able to get your keyboard working, a photo of the output of "show-devs" would be quite helpful :) ATB, Mark.

2 1

failed to build
by mr.jb＠gmx.de 12 Jan '18

12 Jan '18

Hello, I want to build the openbios image for use in coreboot, but it fails. I am running a 32bit debian 8.10 vm. $ make /usr/bin/xsltproc Building OpenBIOS for x86 Building... error: AR libfs.a CC target/libgcc/ashldi3.o CC target/libgcc/ashrdi3.o CC target/libgcc/__lshrdi3.o CC target/libgcc/__divdi3.o CC target/libgcc/__udivdi3.o CC target/libgcc/__udivmoddi4.o CC target/libgcc/__umoddi3.o AR libgcc.a LINK openbios.multiboot libdrivers.a(pci.o): In function `ob_pci_unmap': /tmp/openbios/drivers/pci.c:405: undefined reference to `ofmem_unmap' rules.mak:235: recipe for target 'openbios.multiboot' failed make[1]: *** [openbios.multiboot] Error 1 make[1]: Leaving directory '/tmp/openbios/obj-x86' Makefile:19: recipe for target 'build' failed make: *** [build] Error 1 if i select amd64 on a 64bit machine it works without a problem. What is the problem here? Thanks Jens

3 4

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

02 Jan '18

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

5 22

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

30 Dec '17

The PowerPC timebase register is made available to forth using the tbu@ and tbl@ words. The tbu@ word pushes the upper 32 bits of this register. The tbl@ word pushes the lower 32 bits of this register. Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> --- arch/ppc/qemu/init.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 5ce080c..d12084c 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -751,6 +751,22 @@ static void adler32(void) RET(s2 << 16 | s1); } +/* reads the upper timebase register ( -- tbu ) */ +static void get_tbu(void) +{ + int time; + asm volatile("mftbu %0" : "=r"(time)); // load from TBU register + PUSH(time); +} + +/* reads the lower timebase register ( -- tbl ) */ +static void get_tbl(void) +{ + int time; + asm volatile("mftb %0" : "=r"(time)); // load from TBL register + PUSH(time); +} + void arch_of_init(void) { @@ -1022,4 +1038,8 @@ arch_of_init(void) bind_func("platform-boot", boot); bind_func("(arch-go)", arch_go); + + /* Makes the timebase register accessible from forth */ + bind_func("tbu@", get_tbu); + bind_func("tbl@", get_tbl); } -- 2.14.3 (Apple Git-98)

5 13

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

30 Dec '17

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

3 4

b?branch
by Jd Lyons 28 Dec '17

28 Dec '17

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

4 24

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

25 Dec '17

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

4 9

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

22 Dec '17

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

3 10

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

19 Dec '17

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

1 0

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

18 Dec '17

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

2 5

Jump to page: