[PATCHv2 00/20] Switch to standards-compliant Forth console from C console
by Mark Cave-Ayland
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
6 years, 1 month
- 3
- 25
[PATCH] Building OpenBIOS on Mac OS X
by Programmingkid
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
6 years, 2 months
- 3
- 2
Re: [OpenBIOS] [Qemu-ppc] [PATCH 1/7] pci: add MPC105 PCI host bridge emulation
by Blue Swirl
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é
>
6 years, 2 months
- 1
- 0
Re: [OpenBIOS] Patch that allows for building OpenBIOS on Mac OS X!
by Segher Boessenkool
>>> 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
6 years, 2 months
- 1
- 0
OpenBIOS 1.1 release
by Mark Cave-Ayland
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.
6 years, 2 months
- 1
- 0
[commit] r1136 - tags/openbios-1.1
by repository service
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/
6 years, 2 months
- 1
- 0
[commit] r1135 - trunk/openbios-devel
by repository service
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
6 years, 2 months
- 1
- 0
About udelay
by Programmingkid
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?
6 years, 2 months
- 3
- 3
[commit] r1134 - trunk/openbios-devel/arch/sparc64
by repository service
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)
6 years, 2 months
- 1
- 0
- ← Newer
- 1
- Older →