OpenBIOS August 2010

openbios@openbios.org

13 participants
46 discussions

starting
by G 3 18 Oct '10

18 Oct '10

I have begun doing work with OpenBIOS. I was wondering if it is possible to compile OpenBIOS for PowerPC on Mac OS X? If not, what Linux distro should I use? Any advice would really help.

6 17

SPARC64: Forth re-entrancy during MMU I/D TLB miss
by Mark Cave-Ayland 04 Sep '10

04 Sep '10

Hi everyone, So having a poke around various bits of documentation relating to implementing pgmap@, I've come to the realisation that since the Solaris kernel needs to install it's own va>tte-data implementation into OpenBIOS then it's going to be necessary to call back into Forth from the D/I-MMU miss traps. I've been looking around the code in arch/sparc64/switch.S but it looks as if this code only swaps between 2 individual contexts - am I right in thinking there needs to be a way of specifying the memory address of the context for this code to be reusable during a trap? Or would a better way be to duplicate this file but with another static context used only for MMU miss traps? Another question for PPC users: will pgmap@/pgmap! be required there too? I'm trying to figure out if this is something that needs to live within libopenbios/ofmem_common.c or whether it's just a SPARC-specific hack. It looks as if these words are also required for SPARC32 so I'm leaning towards the former... ATB, 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 3

vocabulary.fs issues
by Programmingkid 31 Aug '10

31 Aug '10

The words get-order and order do pretty much the same thing. The problem is their output is very different. The order word outputs list in unsigned format, and the get-order word output words in signed format. I think these and other words in vocabulary.fs should output their list in unsigned format because it is a lot friendlier to read than signed format. No matter which format wins, I suggest order and get-order should have the same output format. This change would eliminate any confusion someone might experience when using these words.

2 1

Sparc64 memory allocation problem
by Blue Swirl 26 Aug '10

26 Aug '10

Here's last lines from OpenBSD 4.3 boot, with DEBUG_CIF enabled: Booting cdrom:f/bsd 2590536@0x1000000of_client_interface: call-method 80aec8 ffe880f8 0 278748 1000000 call-method claim ([5] -- [2]) handle_calls return: 0 1000000 of_client_interface: call-method 80aec8 ffe88838 400000 278748 call-method claim ([4] -- [3]) handle_calls return: 0 0 400000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 278748 1000000 0 400000 call-method map ([7] -- [1]) handle_calls return: 0 of_client_interface: call-method 80aec8 ffe880f8 2000 4000 call-method claim ([4] -- [2]) handle_calls return: 0 2001e000 of_client_interface: call-method 80aec8 ffe88838 2000 4000 call-method claim ([4] -- [3]) handle_calls return: 0 0 1e000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 4000 2001e000 0 1e000 call-method map ([7] -- [1]) handle_calls return: 0 +3236576@0x1800000of_client_interface: call-method 80aec8 ffe880f8 0 400000 1800000 call-method claim ([5] -- [2]) handle_calls return: 0 1800000 of_client_interface: call-method 80aec8 ffe88838 400000 400000 call-method claim ([4] -- [3]) handle_calls return: 0 0 800000 ^ badness, mem_claim returns 0x800000 of_client_interface: call-method 80aed0 ffe880f8 ffffffffffffffff 400000 1800000 0 800000 call-method map ([7] -- [1]) handle_calls return: 0 Unhandled Exception 0x0000000000000010 PC = 0x0000000000803e20 NPC = 0x0000000000803e24 Stopping execution The client executes near 0x800000. However, the ofmem_claim_phys() (called from mem_claim() in lib.c) will happily allocate and return that range. BSD loader then crashes because it tries to zero the BSS which will be at 0x800000 and zeroing reaches PC value. Here's the loader code: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/sparc64/stand/ofwboot/el… Maybe some memory allocation method (FCode?) still does not use ofmem.

4 10

Re: [OpenBIOS] Fwd: [Bug 623852] Re: PPC emulation loops on booting a FreeBSD kernel
by Nigel Horne 25 Aug '10

25 Aug '10

I have been asked to forward this to you - could you help, please? Thanks! -Nigel > > > -------- Original Message -------- > > It looks like a firmware issue. Please report this to > openbios(a)openbios.org. You get the output below by using the -nographic > option. > > >>> ============================================================= >>> OpenBIOS 1.0 [Aug 17 2010 14:41] >>> Configuration device id QEMU version 1 machine id 2 >>> CPUs: 1 >>> Memory: 512M >>> UUID: 00000000-0000-0000-0000-000000000000 >>> CPU type PowerPC,750 > Welcome to OpenBIOS v1.0 built on Aug 17 2010 14:41 > Trying cd:,\\:tbxi... > Consoles: Open Firmware console > > FreeBSD/powerpc Open Firmware loader, Revision 0.1 > (root(a)xserve.lan.xcllnt.net, Sun Jul 18 04:50:11 UTC 2010) > Memory: 524288KB > Booted from: cd > > Loading /boot/defaults/loader.conf > /boot/kernel/kernel data=0x72c6b8+0x3e280 syms=[0x4+0x5ac10+0x4+0x7d8ad] > / > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Kernel entry at 0x100100 ... > panic: OFW translations above 32-bit boundary! > Uptime: 1s > -- Nigel Horne. Arranger, Adjudicator, Band Trainer, Composer, Tutor, Typesetter. NJH Music, ICQ#20252325, twitter: @nigelhorne njh(a)bandsman.co.uk http://www.bandsman.co.uk

2 2

Solaris 9: failed boot with strange device names
by Mark Cave-Ayland 25 Aug '10

25 Aug '10

Hi all, So given that the Fcode evaluator is sorted for Solaris 10, I thought I'd try my original Solaris 9 disk image again and was surprised to find that it didn't boot. Further investigation seems to show that strangely encoded device names are being passed into cif-open which is failing: : get-file ( 6000 ffe35870 27 ) 00000000ffe36378: fname>devname$ 3 > 2dup type /platform/OpenBiosTeam,OpenBIOS/ufsboot ok 3 > resume ok ( 6000 ffe35870 27 ) 00000000ffe36378: fname>devname$ ( 6000 ffe35ee8 2f ) 00000000ffe36380: ufs-fopen 3 > 2dup type cdrom:a,|platform|OpenBiosTeam,OpenBIOS|ufsboot ok 3 > resume ok ( 6000 ffe35ee8 2f ) 00000000ffe36380: ufs-fopen : ufs-fopen ( 6000 ffe35ee8 2f ) 00000000ffe360e8: drop ( 6000 ffe35ee8 ) 00000000ffe360f0: cif-open ( 6000 0 ) 00000000ffe360f8: (semis) : get-file ( 6000 ffe35870 17 ) 00000000ffe36378: fname>devname$ 3 > 2dup type /platform/sun4u/ufsboot ok 3 > resume ok ( 6000 ffe35870 17 ) 00000000ffe36378: fname>devname$ ( 6000 ffe35ee8 1f ) 00000000ffe36380: ufs-fopen 3 > 2dup type cdrom:a,|platform|sun4u|ufsboot ok 3 > resume ok ( 6000 ffe35ee8 1f ) 00000000ffe36380: ufs-fopen : ufs-fopen ( 6000 ffe35ee8 1f ) 00000000ffe360e8: drop ( 6000 ffe35ee8 ) 00000000ffe360f0: cif-open OFMEM: ofmem_claim_virt virt=ffffffffffffffff size=0000000000000200 align=0000000000000001 ( 6000 0 ) 00000000ffe360f8: (semis) It looks as if a special type of device-specifier is being passed into cif-open consisting of a device and argument, a comma, then the actual filename required with /s replaced by |s. Is this some kind of special syntax that needs to be taught to the dev word and/or cif-open words? ATB, 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

3 10

[commit] r859 - trunk/openbios-devel/arch/sparc64
by repository service 25 Aug '10

25 Aug '10

Author: mcayland Date: Wed Aug 25 18:58:55 2010 New Revision: 859 URL: http://tracker.coreboot.org/trac/openbios/changeset/859 Log: Alter the MMU properties as suggested by the UltraSPARC-II device tree prtconf output in the Debian sparc-utils package and Solaris 9 boot; i.e. remove the /CPU/mmu device, relocate its methods to /virtual-memory, and alter the /chosen mmu property so that it now points to /virtual-memory. This helps both Solaris 9 and OpenSolaris boot further along the way. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Modified: trunk/openbios-devel/arch/sparc64/lib.c trunk/openbios-devel/arch/sparc64/tree.fs Modified: trunk/openbios-devel/arch/sparc64/lib.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/lib.c Tue Aug 24 21:45:57 2010 (r858) +++ trunk/openbios-devel/arch/sparc64/lib.c Wed Aug 25 18:58:55 2010 (r859) @@ -446,7 +446,7 @@ { "SUNW,retain", mem_retain }, }; -DECLARE_UNNAMED_NODE(mmu, INSTALL_OPEN, 0); +DECLARE_NODE(mmu, INSTALL_OPEN, 0, "/virtual-memory"); NODE_METHODS(mmu) = { { "open", mmu_open }, @@ -462,33 +462,18 @@ void ob_mmu_init(const char *cpuname, uint64_t ram_size) { - char nodebuff[256]; - /* memory node */ REGISTER_NODE_METHODS(memory, "/memory"); /* MMU node */ - snprintf(nodebuff, sizeof(nodebuff), "/%s", cpuname); - push_str(nodebuff); - fword("find-device"); - - fword("new-device"); - - push_str("mmu"); - fword("device-name"); - - fword("finish-device"); - - snprintf(nodebuff, sizeof(nodebuff), "/%s/mmu", cpuname); - - REGISTER_NODE_METHODS(mmu, nodebuff); + REGISTER_NODE_METHODS(mmu, "/virtual-memory"); ofmem_register(find_dev("/memory"), find_dev("/virtual-memory")); push_str("/chosen"); fword("find-device"); - push_str(nodebuff); + push_str("/virtual-memory"); fword("open-dev"); fword("encode-int"); push_str("mmu"); Modified: trunk/openbios-devel/arch/sparc64/tree.fs ============================================================================== --- trunk/openbios-devel/arch/sparc64/tree.fs Tue Aug 24 21:45:57 2010 (r858) +++ trunk/openbios-devel/arch/sparc64/tree.fs Wed Aug 25 18:58:55 2010 (r859) @@ -31,19 +31,13 @@ external : open true ; : close ; - \ claim ( phys size align -- base ) -\ : claim 2drop ; - \ release ( phys size -- ) + \ see arch/sparc64/lib.c for methods finish-device new-device " virtual-memory" device-name external - : open true ; - : close ; - \ claim ( phys size align -- base ) -\ : claim 2drop ; - \ release ( phys size -- ) + \ see arch/sparc64/lib.c for methods finish-device " /options" find-device

1 0

[commit] r858 - trunk/openbios-devel/libopenbios
by repository service 24 Aug '10

24 Aug '10

Author: blueswirl Date: Tue Aug 24 21:45:57 2010 New Revision: 858 URL: http://tracker.coreboot.org/trac/openbios/changeset/858 Log: Claim memory areas used by ELF loader Can't enable Sparc32 yet, there is no ofmem_claim(). Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/libopenbios/elf_load.c Modified: trunk/openbios-devel/libopenbios/elf_load.c ============================================================================== --- trunk/openbios-devel/libopenbios/elf_load.c Sun Aug 22 23:29:25 2010 (r857) +++ trunk/openbios-devel/libopenbios/elf_load.c Tue Aug 24 21:45:57 2010 (r858) @@ -11,6 +11,7 @@ #include "libopenbios/sys_info.h" #include "libopenbios/ipchecksum.h" #include "libopenbios/bindings.h" +#include "libopenbios/ofmem.h" #define printf printk #define debug printk @@ -505,10 +506,11 @@ size = MIN(phdr[i].p_filesz, phdr[i].p_memsz); if (!size) continue; -#if 0 +#ifndef CONFIG_SPARC32 if( ofmem_claim( phdr[i].p_vaddr, phdr[i].p_memsz, 0 ) == -1 ) { - printk("Claim failed!\n"); - return; + printk("Ignoring failed claim for va %lx memsz %lx!\n", + (unsigned long)phdr[i].p_vaddr, + (unsigned long)phdr[i].p_memsz); } #endif /* Workaround for archs where sizeof(int) != pointer size */

1 0

Re: [OpenBIOS] fword and feval
by Programmingkid 24 Aug '10

24 Aug '10

On Aug 20, 2010, at 6:00 AM, openbios-request(a)openbios.org wrote: > On Thu, Aug 19, 2010 at 4:52 PM, Programmingkid > <programmingkidx(a)gmail.com> wrote: >> I am trying to use the fword and feval functions in the file "kernel/forth.c". I know the header file for these functions are located in "include/libopenbios/bindings.h". I used this code to include the bindings.h file: >> >> #include "libopenbios/bindings.h" >> >> For some reason, I still see these errors: >> >> Building OpenBIOS for x86 >> Building...error: >> ?HOSTCC host/kernel/bootstrap.o >> ?HOSTCC host/kernel/dict.o >> ?HOSTCC host/kernel/primitives.o >> ?HOSTCC host/kernel/stack.o >> ?HOSTCC forthstrap >> host/kernel/primitives.o: In function `setupLocalDictionary': >> /home/user/Development/openbios-devel/obj-x86/../kernel/forth.c:1035: undefined reference to `_fword' >> /home/user/Development/openbios-devel/obj-x86/../kernel/forth.c:1037: undefined reference to `_fword' >> /home/user/Development/openbios-devel/obj-x86/../kernel/forth.c:1044: undefined reference to `feval' >> /home/user/Development/openbios-devel/obj-x86/../kernel/forth.c:1045: undefined reference to `feval' >> host/kernel/primitives.o: In function `loadLocalVariable': >> /home/user/Development/openbios-devel/obj-x86/../kernel/forth.c:1072: undefined reference to `feval' >> collect2: ld returned 1 exit status >> make[1]: *** [forthstrap] Error 1 >> make[1]: Leaving directory `/home/user/Development/openbios-devel/obj-x86' >> make: *** [build] Error 1 >> >> >> This is a simple function someone could use as an example to be used in the file forth.c >> >> static void test(void) >> { >> ? ? ? ?feval("banner"); >> } >> >> Anyone know what I am doing wrong or how to solve this problem? > > You are using the bootstrap compiler, which has only very limited set > of basic Forth words defined and actually even some of those will not > work during bootstrap time. > > Full set of words like 'feval' is available when the library compiled > by bootstrap compiler is loaded into non-bootstrap kernel. Your > example should compile in arch/x86/openbios.c or arch/unix/unix.c. Thanks for the help, but I still run into problems. I want to be able to use the functions from the forth interpreter. I tried adding my functions to primitives.c and bootstrap.c, but openbios won't compile. Here are the functions I am trying to make available to the interpreter: static void setupLocalDictionary(void) { int localWordListID, standardDictionaryID; #define NUMBER_OF_DICTIONARIES 2 char commandString[100]; fword("wordlist"); localWordListID = POP(); fword("get-order"); POP(); // removes the number of dictionaries standardDictionaryID = POP(); sprintf(commandString, "%d %d %d", standardDictionaryID, localWordListID, NUMBER_OF_DICTIONARIES); feval(commandString); feval("set-order"); } // (addr len -- ) // variable static void loadLocalVariable(void) { int lengthOfVariableString, addressOfVariableString; char variableString[WIDTH], defineVariableCommandString[WIDTH]; int stackSize; #define NUMBER_OF_NEEDED_STACK_ITEMS 2 depth(); stackSize = POP(); if(stackSize < NUMBER_OF_NEEDED_STACK_ITEMS) { printk("\nSorry but loadLocalVarable needs stack in this format: (addr len -- )\n"); return; } lengthOfVariableString = POP(); addressOfVariableString = POP(); strncpy(variableString, (char *) addressOfVariableString, lengthOfVariableString); variableString[lengthOfVariableString] = '\0'; sprintf(defineVariableCommandString, "variable %s", variableString); feval(defineVariableCommandString); //printk("variable = %s\t", variableString); } Any ideas as to where I can place them?

2 1

[commit] r857 - trunk/openbios-devel/packages
by repository service 22 Aug '10

22 Aug '10

Author: mcayland Date: Sun Aug 22 23:29:25 2010 New Revision: 857 URL: http://tracker.coreboot.org/trac/openbios/changeset/857 Log: The Solaris 9 Fcode boot block relies on the assumption that Sun's OpenBOOT would always interpose /packages/ufs-file-system if it existed when opening a disk device. Emulate this behaviour in order to fix Solaris 9 boot. With thanks to Tarl for pointing me in the right direction. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)siriusit.co.uk> Modified: trunk/openbios-devel/packages/sun-parts.c Modified: trunk/openbios-devel/packages/sun-parts.c ============================================================================== --- trunk/openbios-devel/packages/sun-parts.c Sun Aug 22 23:23:19 2010 (r856) +++ trunk/openbios-devel/packages/sun-parts.c Sun Aug 22 23:29:25 2010 (r857) @@ -220,6 +220,20 @@ } } else { DPRINTF("sun-parts: no filesystem found; bypassing misc-files interpose\n"); + + /* Solaris Fcode boot blocks assume that the disk-label package will always + automatically interpose the "ufs-file-system" package if it exists! We + need to mimic this behaviour in order for the boot to work. */ + push_str("ufs-file-system"); + feval("find-package"); + ph = POP_ph(); + + if (ph) { + ph = POP_ph(); + push_str(argstr); + PUSH_ph(ph); + fword("interpose"); + } } free( str );

1 0