OpenBIOS May 2013

openbios@openbios.org

7 participants
9 discussions

[PATCHv2 00/20] Switch to standards-compliant Forth console from C console
by Mark Cave-Ayland 22 Jun '13

22 Jun '13

As mentioned previously on-list, OpenBIOS currently contains two consoles - a C based console and a Forth based console. The Forth based console is currently broken, but is more feature complete than the C console, whilst also being more portable across different architectures. This patchset performs the following functions: - Fix various bugs in the Forth console - Optimise performance using low-level C graphics routines - Add simple IEEE1275-like initialisers for TCX and VGA graphics - Switch TCX and VGA drivers over to use the new console using the standard is-install word Once this patchset is committed, a further patchset will follow to remove all of the duplicate C console code, remove packages/video.c and unify the console input/routines into libopenbios. Changes since v1: - Rebase onto SVN trunk - Various minor bugfixes/tidy-ups - Fix CSI n;mH and CSI n;mf as reported by Blue Swirl - Implementation of remaining missing fb8-* defer words: fb8-insert-lines fb8-insert-characters fb8-delete-characters Mark Cave-Ayland (20): display.fs: Fix up default-font word. display.fs: Fix fb8-delete-lines within the inbuilt Forth terminal emulator. terminal.fs: Fix linefeeds on the bottom line of the Forth console. terminal.fs: Fix backspace sequence in Forth terminal. video: Create new video_common.c file for shared video primitive routines. video_common.c: Move primitive graphic operations into libopenbios/video_common.c. pci: Modify PCI display devices so that open and close words are not created automatically during initialisation. video: Create tcx.fs and vga.fs to simulate Fcode video initialisation code. display.fs: pass the colour depth and line bytes to the Forth terminal routines. video_common.c: create low-level video_mask_blit() function. video_common.c: create low-level video_invert_rect() function. display.fs: Fix fb8 routines to work with bit depths > 8. video_common.c: create low-level video_fill_rect() function. display.fs: optimise scrolling by copying/deleting multiple scanlines at once. display.fs: Add vertical font-spacing as per the existing C console implementation. terminal.fs: handle all cursor positioning within the terminal package. terminal.fs: Fix CSI n;mH and CSI n;mf control sequences. display.fs: add implementation of fb8-insert-lines. display.fs: add implementation of fb8-insert-characters and fb8-delete-characters. video: switch VGA and TCX drivers over to Forth console using is-install. openbios-devel/arch/sparc32/console.c | 12 - openbios-devel/arch/sparc32/openbios.c | 2 +- openbios-devel/drivers/build.xml | 2 + openbios-devel/drivers/pci.c | 14 +- openbios-devel/drivers/pci.h | 1 + openbios-devel/drivers/sbus.c | 2 + openbios-devel/drivers/tcx.fs | 13 + openbios-devel/drivers/vga.fs | 13 + openbios-devel/drivers/vga_vbe.c | 2 +- openbios-devel/forth/device/display.fs | 228 +++++++------- openbios-devel/forth/device/font.fs | 4 + openbios-devel/forth/device/terminal.fs | 67 +++- openbios-devel/include/libopenbios/video.h | 24 ++ openbios-devel/include/packages/video.h | 6 +- openbios-devel/libopenbios/build.xml | 1 + openbios-devel/libopenbios/console_common.c | 1 + openbios-devel/libopenbios/video_common.c | 446 +++++++++++++++++++++++++++ openbios-devel/packages/video.c | 279 +---------------- 18 files changed, 700 insertions(+), 417 deletions(-) create mode 100644 openbios-devel/drivers/tcx.fs create mode 100644 openbios-devel/drivers/vga.fs create mode 100644 openbios-devel/include/libopenbios/video.h create mode 100644 openbios-devel/libopenbios/video_common.c -- 1.7.10.4

3 25

[PATCH] Building OpenBIOS on Mac OS X
by Programmingkid 10 May '13

10 May '13

This patch allows for building OpenBIOS on Mac OS X, but without the "Trying" output. It has been tested on Mac OS 10.6 and Debian Linux. signed-off-by: John Arbuckle <programmingkidx(a)gmail.com> Index: trunk/openbios-devel/config/scripts/switch-arch =================================================================== --- trunk/openbios-devel/config/scripts/switch-arch (revision 1133) +++ trunk/openbios-devel/config/scripts/switch-arch (working copy) @@ -89,15 +89,25 @@ archname() { - HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s/i86pc/x86/ \ - -e s/sun4u/sparc64/ -e s/sparc$/sparc32/ \ - -e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ - -e "s/Power Macintosh/ppc/"` + OS_NAME=`uname` + if test "$OS_NAME" = "Darwin"; then # Can't depend on uname -m on Mac OS X + IS_64BIT=`sysctl hw.cpu64bit_capable` + if test "$IS_64BIT" = "hw.cpu64bit_capable: 1"; then + HOSTARCH="amd64" + else + HOSTARCH="x86" + fi + else + HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s/i86pc/x86/ \ + -e s/sun4u/sparc64/ -e s/sparc$/sparc32/ \ + -e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ + -e "s/Power Macintosh/ppc/"` + fi } select_prefix() { - for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- + for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}-linux- ${1}-elf- ${1}-eabi- ppc-elf- do if type ${TARGET}gcc > /dev/null 2>&1 then

3 2

Re: [OpenBIOS] [Qemu-ppc] [PATCH 1/7] pci: add MPC105 PCI host bridge emulation
by Blue Swirl 09 May '13

09 May '13

On Tue, May 7, 2013 at 5:48 AM, Hervé Poussineau <hpoussin(a)reactos.org> wrote: > Andreas Färber a écrit : > >> Am 06.05.2013 22:57, schrieb Hervé Poussineau: >>> >>> Alexander Graf a écrit : >>>> >>>> On 05/03/2013 07:57 AM, Hervé Poussineau wrote: >>>>> >>>>> Alexander Graf a écrit : >>>>>> >>>>>> Am 02.05.2013 um 22:08 schrieb Hervé Poussineau >>>>>> <hpoussin(a)reactos.org>: >>>>>> >>>>>>> Non-contiguous I/O is not implemented. >>>>>>> >>>>>>> There is also somewhere a bug in the memory controller, which means >>>>>>> that some real firmwares may not detect the correct amount of memory. >>>>>>> This can be bypassed by adding '-m 1G' on the command line. >>>>>>> >>>>>>> Add x-auto-conf property, to automatically configure the memory >>>>>>> controller at startup. This will be required by OpenBIOS, which >>>>>>> doesn't know how to do it. >>>>>> >>>>>> Why not teach it? I'd prefer to see that logic in firmware. >>>>> >>>>> Me too, but I'm not confident enough in my capabilities to do it. >>>> >>>> Huh? Why not? Most of the device initialization code in OpenBIOS >>>> happens in C, so you don't even have to touch Forth code :). >>>> >>>>> Autoconfiguration is only in one place of the code, so I think it can >>>>> be removed easily once OpenBIOS has this logic. >>>> >>>> I'd prefer if we could come up with a clean model from the start. It >>>> really shouldn't be hard at all. >>>> >>> I thought that for all other usages of OpenBIOS in QEMU, RAM was >>> supposed to be available as soon as machine was powered on. >>> >>> However, I checked OpenBIOS code: >>> One of the first things done in arch/ppc/qemu/start.S is to copy the >>> exception vectors. So, I should add code before it to detect memory >>> controller, detect ram size and configure memory controller? >> >> >> No. Why? QEMU does not depend on the memory controller being >> initialized, only the OS might expect some registers to be filled in. So >> you should look at or add the MPC105 PHB initialization hook in >> OpenBIOS' PCI code, long after the memory is set up. > > > OpenBIOS depends of memory being available (at least the first KB/MB) even > at its very startup, in arch/ppc/qemu/start.S. PCI initialization code comes > much later. OpenBIOS for Sparc32 and Sparc64 does not use RAM before RAM size has been read from fw_cfg. A check for QEMU signature is done and machine ID is also read before that. arch/sparc32/entry.S arch/sparc64/entry.S It should be easy to change PPC to check the machine ID before accessing RAM. > At boot, MPC105 datasheet says that memory controller is not configured, ie > you have to not use RAM in OpenBIOS before PCI initialization. The memory controller should be initialized much earlier than PCI. > > For other PPC targets (mac99, g3beige) using OpenBIOS, RAM is accessible at > startup, so that's not a problem for OpenBIOS. > > So, no, QEMU does not depend of the memory controller being initialized, but > OpenBIOS depends of the RAM being accessible ways before PCI initialization. > I don't speak of the OS which might (or might not) expect some registers to > be filled in. > x-auto-conf property correctly sets some registers, so that memory is > available at startup (like on mac99, g3beige emulations). > > Hervé >

1 0

Re: [OpenBIOS] Patch that allows for building OpenBIOS on Mac OS X!
by Segher Boessenkool 09 May '13

09 May '13

>>> archname() >>> { >>> - HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s/i86pc/x86/ \ >>> - -e s/sun4u/sparc64/ -e s/sparc$/sparc32/ \ >>> - -e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ >>> - -e "s/Power Macintosh/ppc/"` >>> + OS_NAME=`uname` >>> + if test "$OS_NAME" = "Darwin"; then # Can't depend on uname >>> -m on Mac OS X >>> + IS_64BIT=`sysctl hw.cpu64bit_capable` >>> + if test "$IS_64BIT" = "hw.cpu64bit_capable: 1"; then >>> + HOSTARCH="amd64" >>> + else >>> + HOSTARCH="x86" >>> + fi >>> + else >>> + HOSTARCH=`uname -m | sed -e s/i.86/x86/ -e s/i86pc/x86/ \ >>> + -e s/sun4u/sparc64/ -e s/sparc$/sparc32/ \ >>> + -e s/arm.*/arm/ -e s/sa110/arm/ -e s/x86_64/amd64/ \ >>> + -e "s/Power Macintosh/ppc/"` >>> + fi >>> } >> >> This is wrong. "uname" does not tell you the machine architecture; >> "uname -m" does, at least on my PowerPC Macs. Also: > > Who said I was trying to obtain the machine architecture? That is what this function does. > As I said in the comment you can't depend on uname -m on Mac OS X. > It will not tell you if the architecture is 64 bit or 32 bit. And ignoring it does not tell you if the machine is x86 at all, which you just blindly assume. It might work for you, but it is just wrong and breaks things for other people. > Do you even use Mac OS X? Yes I do. > The hw.cpu64bit_capable will tell you that information. > >> $ sysctl hw.cpu64bit_capable >> second level name cpu64bit_capable in hw.cpu64bit_capable is invalid > > I don't know what you are using, but on Mac OS 10.6 and up it is > valid. Are you even using Mac OS X? If so, what version? It might > be possible to build OpenBIOS on Mac OS 10.5, but I really doubt > anything before that would work. It is not valid on any OSX version; it is only valid on x86. Everything builds fine on 10.3 and 10.4, fwiw. >>> select_prefix() >>> { >>> - for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}- >>> linux- ${1}-elf- ${1}-eabi- >>> + for TARGET in ${1}-unknown-linux-gnu- ${1}-linux-gnu- ${1}- >>> linux- ${1}-elf- ${1}-eabi- ppc-elf- >> >> This is also wrong. ppc-elf is neither a canonical nor a common >> prefix. >> Whoever built your toolchain was hellbent on making life difficult >> for >> the users of said toolchain. > > WHAT? Just because you don't like the name doesn't make it wrong. Let's add a "butterfly-cherry-blossom-sortofelf-" prefix as well! I have many toolchains with custom program prefixes; I don't expect the openbios scripts to automatically pick those up, either. It is not going to scale... > In the end you are wrong about most of the issues you brought up. I > would appreciate it if you kept your comments to yourself. Thank you. Segher

1 0

OpenBIOS 1.1 release
by Mark Cave-Ayland 04 May '13

04 May '13

After 4 years of hard work, the OpenBIOS team are proud to announce the release of OpenBIOS 1.1. Since the last release, over 600 commits have been made to the SVN repository with a wealth of improvements and new features. As a result of these changes, the ability of OpenBIOS 1.1 to boot various kernels under QEMU has significantly improved. Multi-architecture features =========================== - Internal memory API (OFMEM) implementation All main architectures in OpenBIOS have been migrated to a new shared OFMEM API rather than maintaining their own individual implementations. This API handles both internal and external memory allocations, and automatically handles generation of the relevant memory and virtual-memory node properties required for clients. - Forth Source Debugger A basic Forth source debugger is included that can be used to step through Forth words which are marked using the debug word. Once the source debugger has been entered, it is possible to step up, step down, drop to a Forth interpreter shell or continue execution whilst viewing the current stack contents. - 64-bit 1275 6d5 implementation OpenBIOS now contains the additional 64-bit word set required by some bootloaders. - Forth Local Variables In order to support bootloaders such as Apple's BootX, OpenBIOS now contains an implementation of Forth local variables. - Internal libopenbios code reorganisation Over time, a lot of the code related to loading executable files had been forked for each individual architecture, e.g. ELF loader. The codebase has been substantially refactored so that the individual forks have been combined in a centralised libopenbios meaning that a substantial portion of duplicate code has been removed from each architecture. SPARC32 compatibility ===================== OpenBIOS SPARC32 is currently able to boot the following OS/kernels: * Linux * NetBSD * OpenBSD * Some later versions of Solaris (Solaris 8 and early Solaris 9 are known to work) SPARC64 compatibility ===================== OpenBIOS SPARC64 is currently able to boot the following OS/kernels: * Linux (with virtio drivers) Many thanks to Artyom Tarasenko for making this possible. PPC compatibility ================= OpenBIOS PPC is currently able to boot the following OS/kernels: * Linux * HelenOS The following kernels will partially boot, but still suffer from some emulation bugs under QEMU: * FreeBSD * NetBSD * Darwin/OS X Many thanks to William Hahne and his mentor, Natalia Portillo, for contributing the patches required to support Darwin/OS X kernel boot in OpenBIOS as part of the Google Summer Of Code. PPC64 compatibility =================== OpenBIOS PPC64 is currently experimental but should be capable of executing some bootloaders. Please report details of any testing to the OpenBIOS/QEMU mailing lists. Credits ======= Many thanks to everyone who has contributed to OpenBIOS by providing bug reports, patches or testing. In particular the team would like to thank (in alphabetical order): John Arbuckle Segher Boessenkool Mark Cave-Ayland Olivier Danet Andreas Färber Alexander Graf William Hahne Igor Kovalenko Tarl Neustaedter Natalia Portillo Stefan Reinauer Amadeusz Sławiński Blue Swirl Artyom Tarasenko Andreas Tober Laurent Vivier Please visit http://www.openfirmware.info/ for more information on OpenBIOS.

1 0

[commit] r1136 - tags/openbios-1.1
by repository service 04 May '13

04 May '13

Author: blueswirl Date: Sat May 4 13:01:04 2013 New Revision: 1136 URL: http://tracker.coreboot.org/trac/openbios/changeset/1136 Log: Tag version 1.1 Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Added: tags/openbios-1.1/ - copied from r1135, trunk/openbios-devel/

1 0

[commit] r1135 - trunk/openbios-devel
by repository service 04 May '13

04 May '13

Author: blueswirl Date: Sat May 4 12:56:49 2013 New Revision: 1135 URL: http://tracker.coreboot.org/trac/openbios/changeset/1135 Log: Bump version to 1.1 Signed-off-by: Blue Swirl <blauwirbel(a)gmail.com> Modified: trunk/openbios-devel/VERSION Modified: trunk/openbios-devel/VERSION ============================================================================== --- trunk/openbios-devel/VERSION Fri May 3 23:45:00 2013 (r1134) +++ trunk/openbios-devel/VERSION Sat May 4 12:56:49 2013 (r1135) @@ -1 +1 @@ -1.0 +1.1

1 0

About udelay
by Programmingkid 03 May '13

03 May '13

I see that you used a loop to simulate a wait time. I think there must be a better way of doing it. Doesn't the Sparc emulator have access to a hardware clock that we can use instead of a loop?

3 3

[commit] r1134 - trunk/openbios-devel/arch/sparc64
by repository service 03 May '13

03 May '13

Author: mcayland Date: Fri May 3 23:45:00 2013 New Revision: 1134 URL: http://tracker.coreboot.org/trac/openbios/changeset/1134 Log: SPARC64: Add trivial implementation of udelay() The OpenBIOS IDE driver calls udelay() in order to wait for IDE transfers to complete. Without an implementation of udelay(), the IDE timeout is too low causing sporadic errors during periods of high I/O activity. As reported by Artyom Tarasenko. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk> Modified: trunk/openbios-devel/arch/sparc64/openbios.c Modified: trunk/openbios-devel/arch/sparc64/openbios.c ============================================================================== --- trunk/openbios-devel/arch/sparc64/openbios.c Sat Apr 27 13:42:18 2013 (r1133) +++ trunk/openbios-devel/arch/sparc64/openbios.c Fri May 3 23:45:00 2013 (r1134) @@ -547,6 +547,9 @@ void udelay(unsigned int usecs) { + volatile int i; + + for (i = 0; i < usecs * 100; i++); } static void init_memory(void)

1 0