OpenBIOS August 2011

openbios@openbios.org

19 participants
88 discussions

[PATCH] make select-dev and unselect-dev compatible with OBP
by Bob Breuer 05 Aug '11

05 Aug '11

select-dev and unselect-dev are pre Open Firmware, and not the same as open-dev/device-end. Make them Sun OBP compatible by pulling the functionality for select-dev/unselect-dev out of (and simplifying) begin-package/end-package. Signed-off-by: Bob Breuer <breuerr(a)mc.net> --- forth/admin/devices.fs | 4 ---- forth/debugging/fcode.fs | 22 +++++++++++++++++----- forth/device/pathres.fs | 4 ---- 3 files changed, 17 insertions(+), 13 deletions(-) Index: forth/device/pathres.fs =================================================================== --- forth/device/pathres.fs (revision 1045) +++ forth/device/pathres.fs (working copy) @@ -471,10 +471,6 @@ ( ihandle ) ; -: select-dev ( dev-str dev-len -- ihandle | 0 ) - open-dev -; - : execute-device-method ( ... dev-str dev-len met-str met-len -- ... false | ?? true ) 2swap Index: forth/admin/devices.fs =================================================================== --- forth/admin/devices.fs (revision 1045) +++ forth/admin/devices.fs (working copy) @@ -46,10 +46,6 @@ 0 active-package! ; -: unselect-dev ( -- ) - device-end -; - : ?active-package ( -- phandle ) active-package dup 0= abort" no active device" ; Index: forth/debugging/fcode.fs =================================================================== --- forth/debugging/fcode.fs (revision 1045) +++ forth/debugging/fcode.fs (working copy) @@ -10,21 +10,33 @@ : headers ( -- ) ; -: begin-package ( arg-str arg-len reg-str reg-len dev-str dev-len -- ) +\ Open specified device node and make it the current instance. +\ pre Open Firmware, but Sun OBP compatible +: select-dev ( dev-str dev-len -- ) open-dev dup 0= abort" failed opening parent." dup to my-self ihandle>phandle active-package! +; + +: begin-package ( arg-str arg-len reg-str reg-len dev-str dev-len -- ) + select-dev new-device set-args ; -: end-package ( -- ) - my-parent >r - finish-device +\ Close current node, deselect active package and current instance, +\ leaving no instance selected +\ pre Open Firmware, but Sun OBP compatible +: unselect-dev ( -- ) + my-self close-dev 0 active-package! 0 to my-self - r> close-dev ; +: end-package ( -- ) + finish-device + unselect-dev +; + : apply ( ... "method-name< >device-specifier< >" -- ??? ) ;

2 3

Re: [OpenBIOS] OpenBios Sparc64
by Mark Cave-Ayland 05 Aug '11

05 Aug '11

On 04/08/11 15:39, Ghitulete Razvan wrote: > I've written several lines of code in C in which I am trying to access > the OpenBoot CIF to execute an instruction. But immediately after I do > the call to the CIF interface address the PROM freezes. Does anyone > have any ideas why is this so. I'm getting the CIF address from the > %o4 register passed by SILO Do you really mean OpenBoot or do you mean OpenBIOS? There was a bug in earlier versions of OpenBIOS where the CIF arguments were being read in the wrong order which is now fixed. Basically as you read the IEEE 1275 specification, left -> right maps to bottom -> top of stack so it may just be that you need to reverse the order of your arguments. Also if you are using OpenBIOS, you can enable DEBUG_CIF in libopenbios/client.c which will output all the CIF calls and their arguments on the console to help you. HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

2 1

Re: [OpenBIOS] OpenBios Sparc64
by Blue Swirl 04 Aug '11

04 Aug '11

On Thu, Aug 4, 2011 at 2:39 PM, Ghitulete Razvan <razvan.ghitulete(a)gmail.com> wrote: > I've written several lines of code in C in which I am trying to access > the OpenBoot CIF to execute an instruction. But immediately after I do > the call to the CIF interface address the PROM freezes. Does anyone > have any ideas why is this so. I'm getting the CIF address from the > %o4 register passed by SILO Impossible to say without sources. Perhaps you should compare your CIF code to what SILO, Linux or *BSD are doing.

1 0

Re: [OpenBIOS] OpenBios Sparc64
by Tarl Neustaedter 04 Aug '11

04 Aug '11

On 2011-Jul-19 09:45 , Ghitulete Razvan wrote: > So I kinda got rid of that MMU Miss error, but now, when i try and > open-dev the display adapter i get a 0 return code on the stack. The > output being something like this. > > ok showstack > ok " /pci/SUNW,m64B " open-dev > 0 ok > That usually means the "open" method of your driver didn't succeed. For whatever reason, the SUNW,m64B driver returned a failure at open - either some allocation failed or it decided it didn't like the hardware it found.

2 1

Re: [OpenBIOS] [Qemu-devel] OpenBSD/macppc and sparc64 failing to boot with similar error.
by Brad 03 Aug '11

03 Aug '11

On 01/08/11 5:35 PM, Blue Swirl wrote: > On Mon, Aug 1, 2011 at 12:33 AM, Brad<brad(a)comstyle.com> wrote: >> I know sparc64 had little chance of actually working but >> I thought I'd take it for a spin with 0.15.0-rc1 and >> see how it fared in addition to macppc which has a good >> chance of working nowdays with modern QEMU. Lets see >> what QEMU and related bugs are left.. >> >> I noticed the bootblocks for each respective arch are >> failing in a very similar manner. I would guess that >> this is most likely a bug with the OpenBIOS Open Firmware >> implementation? >> >> Any assistance with this? Blue? After a little playing around I have found this is definitely a bug in QEMU. Turning on the OpenBSD malloc S flag which is what I run on all of my systems triggered this behavior in QEMU and trying to narrow it down further since S is a combination of other flags I found it was the J flag specifically that is triggering this behavior. From malloc(3).. J ``Junk''. Fill some junk into the area allocated. Currently junk is bytes of 0xd0 when allocating; this is pronounced ``Duh''. :-) Freed chunks are filled with 0xdf. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

Re: [OpenBIOS] Reducing CPU usage
by Programmingkid 02 Aug '11

02 Aug '11

> > On Mon, Aug 1, 2011 at 2:11 AM, Programmingkid > <programmingkidx(a)gmail.com> wrote: >> Is there a way to make OpenBIOS not use so much CPU time when running in QEMU? My laptop becomes very hot when I do anything in OpenBIOS. > > I've noticed that too. The input device (keyboard/serial) is scanned > in a tight busy loop. With some effort, this could be changed to > interrupt driven. I was thinking the exact same thing. > But the same thing happens also when lots of Forth is executed, maybe > the Forth interpreter and QEMU code fits in the CPU cache nicely and > this then maximizes CPU throughput and power consumption. Maybe we should give the user the option to reduce cpu usage. A compile-time or runtime option might do. My idea is set the interrupt controller to run code that makes the currently running code sleep for 10 milliseconds. That would take care of both problems. We would finally have computers that don't feel like space heaters after doing some Forth programming on them.

1 0

Reducing CPU usage
by Programmingkid 01 Aug '11

01 Aug '11

Is there a way to make OpenBIOS not use so much CPU time when running in QEMU? My laptop becomes very hot when I do anything in OpenBIOS.

2 1

Re: [OpenBIOS] [Qemu-devel] OpenBSD/macppc and sparc64 failing to boot with similar error.
by Blue Swirl 01 Aug '11

01 Aug '11

On Mon, Aug 1, 2011 at 12:33 AM, Brad <brad(a)comstyle.com> wrote: > I know sparc64 had little chance of actually working but > I thought I'd take it for a spin with 0.15.0-rc1 and > see how it fared in addition to macppc which has a good > chance of working nowdays with modern QEMU. Lets see > what QEMU and related bugs are left.. > > I noticed the bootblocks for each respective arch are > failing in a very similar manner. I would guess that > this is most likely a bug with the OpenBIOS Open Firmware > implementation? > > Any assistance with this? Blue? > > > $ qemu-system-ppc -nographic -cdrom cd50.iso -boot d > >>> ============================================================= >>> OpenBIOS 1.0 [Jun 16 2011 08:02] >>> Configuration device id QEMU version 1 machine id 2 >>> CPUs: 1 >>> Memory: 128M >>> UUID: 00000000-0000-0000-0000-000000000000 >>> CPU type PowerPC,750 > Welcome to OpenBIOS v1.0 built on Jun 16 2011 08:02 > Trying cd:,\\:tbxi... >>> OpenBSD/macppc BOOT 1.1 > open(cd:/etc/boot.conf): Unknown error: code 24 > boot> ? > > > $ qemu-system-sparc64 -nographic -cdrom cd50.iso -boot d > OpenBIOS for Sparc64 > Configuration device id QEMU version 1 machine id 0 > kernel cmdline > CPUs: 1 x SUNW,UltraSPARC-IIi > UUID: 00000000-0000-0000-0000-000000000000 > Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 > Type 'help' for detailed information > Trying cdrom:f... > Not a bootable ELF image > Not a bootable a.out image > > Loading FCode image... > Loaded 4829 bytes > entry point is 0x4000 > OpenBSD IEEE 1275 Bootblock 1.3 > .. > Jumping to entry point 0000000000100000 for type 0000000000000001... > switching to new context: entry point 0x100000 stack 0x00000000ffe86b49 >>> OpenBSD BOOT 1.4 > Trying bsd... > open ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????: Unknown error: code 24 > > Boot: I get this with OpenBSD 4.3: OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 kernel cmdline CPUs: 1 x SUNW,UltraSPARC-IIi UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on Jul 20 2011 21:17 Type 'help' for detailed information Trying cdrom:f... Not a bootable ELF image Not a bootable a.out image Loading FCode image... Loaded 4893 bytes entry point is 0x4000 OpenBSD IEEE 1275 Bootblock 1.1 .. Jumping to entry point 0000000000800000 for type 0000000000000001... switching to new context: entry point 0x800000 stack 0x00000000ffe86b49 >> OpenBSD BOOT 1.2 Trying bsd... Booting cdrom:f/bsd 2590536@0x1000000+3236576@0x1800000+957728@0x1b162e0 symbols @ 0xffcda1c0 36 start=0x1000000 CHAINprom_get_msgbuf: test failed prom_get_msgbuf: allocated new buf at 00000000 prom_get_msgbuf: claiming new buf at 00000000

1 0