OpenBIOS January 2013

openbios@openbios.org

14 participants
55 discussions

Re: [OpenBIOS] [RFC 3/3] SPARC32/64: Mimic Sun's OBP behaviour if a divide by zero occurs.
by Artyom Tarasenko 11 Jan '13

11 Jan '13

[Appologies if the mail appears twice. Got the "graylisted" error from the mailing list again, and since the message didn't appear within the last two days, resending it] On Mon, Jan 7, 2013 at 7:46 PM, Tarl Neustaedter <tarl-b2(a)tarl.net> wrote: > > On 2013-Jan-7 13:44 , Programmingkid wrote: >> >> What PowerPC systems trap on divide by zero? > > > PPC 8360 > http://stackoverflow.com/questions/6460558/powerpc-how-to-make-div-0-return… Actually from this article I don't see that exception is happening in the Firmware. I'm very surprised, but our tests on RS/6000 (PReP) and Beige Rev 1 (thanks dreadbit for testing that!) show that PPC firmware allows division by zero: 0 > 1 0 / ok 1 > 0 0 / ok 2 > . 0 ok 1 > . 0 ok 0 > It would be interesting to know what happens on a CHRP platform, can anyone check?

1 0

Re: [OpenBIOS] [commit] r1078 - trunk/openbios-devel/arch/ppc/qemu
by Olivier DANET 10 Jan '13

10 Jan '13

> De : Mark Cave-Ayland > Envoyés : 10.01.13 20:54 > Objet : Re: [OpenBIOS] [commit] r1078 - trunk/openbios-devel/arch/ppc/qemu > > >On 10/01/13 18:25, Programmingkid wrote: > >> On Jan 9, 2013, at 7:27 PM, Mark Cave-Ayland wrote: >> >>> (this is what I get with the patch I just posted applied): >>> >>> 0> here 10 0 fill ok >>> 0> here 4 44332211 filll ok >>> 0> here 8 dump >>> fff503c0 44 33 22 11 00 00 00 00 00 00 00 00 00 00 00 00 D3"............. >> >> Same as Open Firmware. >> >> >>> 0> here 5 44332211 filll ok >>> 0> here 8 dump >>> fff503c0 44 33 22 11 44 00 00 00 00 00 00 00 00 00 00 00 D3".D........... >> >> This output in incorrect. This is what Open Firmware outputs: >> ff94d75c: 44 33 22 11 44 33 22 11 >> >> >>> 0> here 6 44332211 filll ok >>> 0> here 8 dump >>> fff503c0 44 33 22 11 44 33 00 00 00 00 00 00 00 00 00 00 D3".D3.......... >> >> This output is also incorrect. This is what Open Firmware outputs: >> ff94d75c: 44 33 22 11 44 33 22 11 >> >> >>> 0> here 7 44332211 filll ok >>> 0> here 8 dump >>> fff503c0 44 33 22 11 44 33 22 00 00 00 00 00 00 00 00 00 D3".D3"......... >> >> This output is incorrect. This is what Open Firmware outputs: >> ff94d75c: 44 33 22 11 44 33 22 11 >> >> >>> 0> here 8 44332211 filll ok >>> 0> here 8 dump >>> fff503c0 44 33 22 11 44 33 22 11 00 00 00 00 00 00 00 00 D3".D3"........ > >Hmmm well that looks as if it just rounds up to the next 4-byte word, >which is like the last patch but without the extra byte handling on the >end. Segher - can you confirm this on your hardware? > > >ATB, > >Mark. Out of curiosity, I have tried these sequences on a SparcStation5 and a PowerPC G3 iBook Both get the same result. here 4 44332211 fill > 11 11 11 11 here 5 44332211 fill > 11 11 11 11 11 here 8 44332211 fill > 11 11 11 11 11 11 11 11 The lowest significant byte is repeated and the lenght is the byte count. Hope this help ... Olivier

2 1

[PATCH] PPC: Fix filll word used by BootX
by Mark Cave-Ayland 10 Jan '13

10 Jan '13

As pointed out by Segher, the length parameter is specified in bytes rather than cells. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- openbios-devel/arch/ppc/qemu/init.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/openbios-devel/arch/ppc/qemu/init.c b/openbios-devel/arch/ppc/qemu/init.c index 61374c3..3107708 100644 --- a/openbios-devel/arch/ppc/qemu/init.c +++ b/openbios-devel/arch/ppc/qemu/init.c @@ -614,18 +614,25 @@ static void kvm_of_init(void) } /* - * filll ( addr len quad -- ) + * filll ( addr bytes quad -- ) */ static void ffilll(void) { const u32 longval = POP(); - u32 len = POP(); - u32 *aaddr = (u32 *)cell2pointer(POP()); - - while (len--) { - *aaddr++ = longval; + u32 bytes = POP(); + u32 *laddr = (u32 *)cell2pointer(POP()); + char *baddr; + u32 len; + + for (len = 0; len < bytes / 4; len++) { + *laddr++ = longval; } + + baddr = (char *)laddr; + for (len = 0; len < bytes % 4; len++) { + *baddr++ = ((char *)&longval)[len]; + } } void -- 1.7.10.4

1 0

[commit] r1078 - trunk/openbios-devel/arch/ppc/qemu
by repository service 10 Jan '13

10 Jan '13

Author: mcayland Date: Sun Dec 9 21:37:53 2012 New Revision: 1078 URL: http://tracker.coreboot.org/trac/openbios/changeset/1078 Log: PPC: Implement filll (fill long) word for QEMU/PPC as required by BootX. Based upon an original patch by John Arbuckle <programmingkidx(a)gmail.com>. Signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/ppc/qemu/init.c Modified: trunk/openbios-devel/arch/ppc/qemu/init.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/init.c Fri Dec 7 15:28:07 2012 (r1077) +++ trunk/openbios-devel/arch/ppc/qemu/init.c Sun Dec 9 21:37:53 2012 (r1078) @@ -613,6 +613,21 @@ fword("finish-device"); } +/* + * filll ( addr len quad -- ) + */ + +static void ffilll(void) +{ + const u32 longval = POP(); + u32 len = POP(); + u32 *aaddr = (u32 *)cell2pointer(POP()); + + while (len--) { + *aaddr++ = longval; + } +} + void arch_of_init(void) { @@ -877,6 +892,9 @@ device_end(); + /* Implementation of filll word (required by BootX) */ + bind_func("filll", ffilll); + bind_func("platform-boot", boot); bind_func("(go)", go); }

3 2

[RFC 1/3] Allow customisable behaviour when a divide-by-zero situation is encountered.
by Mark Cave-Ayland 07 Jan '13

07 Jan '13

Sun's OBP and Apple's OpenFirmware have different behaviours from each other when a divide-by-zero error is encountered. Since we can't reenter Forth from a trap on all platforms, detect this case before performing the division and allow an optional defer word to be executed instead. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> --- openbios-devel/forth/bootstrap/bootstrap.fs | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/openbios-devel/forth/bootstrap/bootstrap.fs b/openbios-devel/forth/bootstrap/bootstrap.fs index 6878449..dc20caf 100644 --- a/openbios-devel/forth/bootstrap/bootstrap.fs +++ b/openbios-devel/forth/bootstrap/bootstrap.fs @@ -445,10 +445,23 @@ variable leaves 0 leaves ! \ 7.3.2.3 double number arithmetic \ +defer (div-by-zero-handler) + : s>d dup 0 < ; : dnegate 0 0 2swap d- ; : dabs dup 0 < if dnegate then ; -: um/mod mu/mod drop ; +: um/mod + dup 0 = if + \ Allow optional override of divide by zero handling + ['] (div-by-zero-handler) /n + @ 0 <> if + (div-by-zero-handler) drop + else + mu/mod drop + then + else + mu/mod drop + then + ; \ symmetric division : sm/rem ( d n -- rem quot ) -- 1.7.10.4

2 3

Re: [OpenBIOS] patches
by Programmingkid 07 Jan '13

07 Jan '13

On Jan 7, 2013, at 10:22 AM, Mark Cave-Ayland wrote: > On 07/01/13 15:14, Programmingkid wrote: > >>> Was there any patch in particular you are concerned with? To the best of my knowledge, all of the patches except the OFMEM virtual-physical mapping fix have been out for review in a similar form for a while now. >>> >>> I've also spent a couple of days heavily testing them against my set of PPC ISO images, so I'm not expecting any serious regressions... >> >> I was hoping to review the get-key-map patch before it was submitted. Now that I have looked at it, it seems good enough. > > Oh I see - sorry I didn't mean to offend. > > My thinking was that because both yourself and Amadeusz are keen to work on OS X boot, I'd rather commit a skeleton function until such time as we can figure out the real mapping and/or why you version causes random hangs :/ > > BTW with the RFC patchset I just posted to the list applied, all the outstanding issues from William's original patches should now be resolved! So please test away and report back... I can get Darwin kernel to boot now but it panics early :O There is still one unresolved issue that William's patches fixed. When booting Mac OS X using this command: "boot cd:,\\:tbxi", it causes Bootx to go back and try to find the partition that it can open. This search fails. A way around this is to just specify the partition to open: "boot cd:9,\\:tbxi". William made two patches that handles this situation: http://lists.openbios.org/pipermail/openbios/2011-August/006630.html http://lists.openbios.org/pipermail/openbios/2011-August/006640.html I don't think these patches can be applied now, but I do suggest we come up with a way to only open the APPLE_HFS and APPLE_HFSX partitions. P.S. The recent patches to OpenBIOS have made my Mac OS 10.0 cd boot further than before. :)

2 1

patches
by Programmingkid 07 Jan '13

07 Jan '13

Hi Mark, could you please post your patches onto the mailing list before committing them please.

2 1

[commit] r1084 - trunk/openbios-devel/forth/admin
by repository service 07 Jan '13

07 Jan '13

Author: mcayland Date: Mon Jan 7 13:57:56 2013 New Revision: 1084 URL: http://tracker.coreboot.org/trac/openbios/changeset/1084 Log: Ignore any attempts to emit a character to stdout when stdout is set to 0. When booting in standard (non-verbose) mode, BootX sets the stdout package handle to zero to suppress output, yet still continues to invoke the underlying emit word. This would cause OpenBIOS to become confused, often getting stuck in a tight loop. This patch checks the value of stdout before calling the underlying emit word, and simply returns if stdout is not set. Based upon an original patch by William Hahne <will07c5(a)gmail.com>. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/forth/admin/iocontrol.fs Modified: trunk/openbios-devel/forth/admin/iocontrol.fs ============================================================================== --- trunk/openbios-devel/forth/admin/iocontrol.fs Mon Jan 7 13:57:54 2013 (r1083) +++ trunk/openbios-devel/forth/admin/iocontrol.fs Mon Jan 7 13:57:56 2013 (r1084) @@ -80,8 +80,11 @@ ; : io-emit ( char -- ) - io-out-char c! - io-out-char 1 " write" stdout @ $call-method drop + stdout @ if + io-out-char c! + io-out-char 1 " write" stdout @ $call-method + then + drop ; variable CONSOLE-IN-list

1 0

[commit] r1083 - trunk/openbios-devel/drivers
by repository service 07 Jan '13

07 Jan '13

Author: mcayland Date: Mon Jan 7 13:57:54 2013 New Revision: 1083 URL: http://tracker.coreboot.org/trac/openbios/changeset/1083 Log: adb_kbd.c: Implement dummy get-key-map word for the ADB keyboard package. This word is used by some bootloaders to detect keypresses at startup e.g. to enable verbose boot. The current implementation simply returns an empty array (indicating no keys are pressed) as the key/bitmap mapping is unknown; however this allows bootloaders which make use of the word to execute. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/drivers/adb_kbd.c Modified: trunk/openbios-devel/drivers/adb_kbd.c ============================================================================== --- trunk/openbios-devel/drivers/adb_kbd.c Mon Jan 7 13:57:51 2013 (r1082) +++ trunk/openbios-devel/drivers/adb_kbd.c Mon Jan 7 13:57:54 2013 (r1083) @@ -42,11 +42,13 @@ } static void keyboard_read(void); +static void keyboard_getkeymap(void); NODE_METHODS( keyboard ) = { { "open", keyboard_open }, { "close", keyboard_close }, { "read", keyboard_read }, + { "get-key-map", keyboard_getkeymap }, }; /* VT100 escape sequences */ @@ -471,6 +473,7 @@ int next_key; char sequence[ADB_MAX_SEQUENCE_LEN]; int len; + char keytable[32]; }; static adb_dev_t *my_adb_dev = NULL; @@ -531,6 +534,21 @@ ADB_kbd_us, ADB_sequences); kbd->next_key = -1; kbd->len = 0; + + /* Debugging BootX: the lines below force get-key-map to report that + * cmd-V is being held down, which forces BootX to run in verbose mode + * for debugging. + * + * TODO: if we can find a mapping between the get-key-map bitmap and + * ADB scancodes, the keyboard driver should be altered to update this + * accordingly. + */ + + /* + kbd->keytable[3] = 0x40; + kbd->keytable[28] = 0x10; + */ + dev->state = kbd; my_adb_dev = dev; } @@ -566,3 +584,12 @@ } PUSH(i); } + +/* ( -- keymap ) (?) */ +/* should return a pointer to an array with 32 bytes (256 bits) */ +static void keyboard_getkeymap(void) +{ + adb_kbd_t *kbd = my_adb_dev->state; + + PUSH( pointer2cell(kbd->keytable) ); +}

1 0

[commit] r1082 - trunk/openbios-devel/arch/ppc/qemu
by repository service 07 Jan '13

07 Jan '13

Author: mcayland Date: Mon Jan 7 13:57:51 2013 New Revision: 1082 URL: http://tracker.coreboot.org/trac/openbios/changeset/1082 Log: PPC: Fix mapping of OpenBIOS ROM in RAM copy within OFMEM The OpenBIOS ROM in RAM copy was being incorrectly mapped in OFMEM as part of the 1:1 physical to virtual mapping used for OpenBIOS housekeeping at the top of RAM. Change the existing 1:1 mapping to handle everything up to the ROM in RAM copy, and then add a separate virtual mapping for the OpenBIOS ROM in RAM address space. This ensures that the OpenBIOS address space mapping is now recorded in the MMU translations property, and hence presented to client kernels to be incorporated in their existing mapping list before taking control of the MMU. With this patch applied, my NetBSD 5 test ISO is now able to complete a substantial part of its kernel boot. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c Modified: trunk/openbios-devel/arch/ppc/qemu/ofmem.c ============================================================================== --- trunk/openbios-devel/arch/ppc/qemu/ofmem.c Sun Jan 6 14:29:59 2013 (r1081) +++ trunk/openbios-devel/arch/ppc/qemu/ofmem.c Mon Jan 7 13:57:51 2013 (r1082) @@ -553,7 +553,13 @@ ofmem_claim_virt(0, get_ram_bottom(), 0); ofmem_map(0, 0, get_ram_bottom(), 0); - ofmem_claim_phys(get_ram_top(), ofmem->ramsize - get_ram_top(), 0); - ofmem_claim_virt(get_ram_top(), ofmem->ramsize - get_ram_top(), 0); - ofmem_map(get_ram_top(), get_ram_top(), ofmem->ramsize - get_ram_top(), 0); + /* Map everything at the top of physical RAM 1:1, minus the OpenBIOS ROM in RAM copy */ + ofmem_claim_phys(get_ram_top(), get_hash_base() + HASH_SIZE - get_ram_top(), 0); + ofmem_claim_virt(get_ram_top(), get_hash_base() + HASH_SIZE - get_ram_top(), 0); + ofmem_map(get_ram_top(), get_ram_top(), get_hash_base() + HASH_SIZE - get_ram_top(), 0); + + /* Map the OpenBIOS ROM in RAM copy */ + ofmem_claim_phys(ofmem->ramsize - OF_CODE_SIZE, OF_CODE_SIZE, 0); + ofmem_claim_virt(OF_CODE_START, OF_CODE_SIZE, 0); + ofmem_map(ofmem->ramsize - OF_CODE_SIZE, OF_CODE_START, OF_CODE_SIZE, 0); }

1 0