Giter Club home page Giter Club logo

fcode-utils's Introduction

Welcome to OpenBIOS
-------------------

OpenBIOS is a free, portable implementation of IEEE 1275-1994 
(Open Firmware). Find detailed information about OpenBIOS at 
http://www.openbios.org/

What is OpenBIOS?
-----------------

OpenBIOS can replace your system firmware (BIOS) partly or completely. It
can also be used as a bootloader to create an Open Firmware compatible
interface between legacy firmware and an operating system.

This is achieved by a modular concept that consists of a portable Forth
kernel and three interfaces for user interaction, device initialization
and client (operating system) control.

While far not all possible applications of OpenBIOS are implemented yet,
a lot of functionality is already there. OpenBIOS can be used to enhance
LinuxBIOS (http://www.linuxbios.org), or be booted from any multiboot
capable bootloader to bring Open Firmware to your machine. OpenBIOS can
also be used when an operating system is already running. It provides
the needed OpenFirmware functionality to MOL (MacOnLinux) to boot MacOS
9 and X on PPC machines, as well as Linux (all supported platforms)

OpenBIOS build options
---------------------

   config/scripts/switch-arch <platform>  - build for specified platform
   					    Look in config/example for
					    platforms.

   make            - build all configured binaries

   make run        - run unix example.

   
How OpenBIOS works
------------------

 The OpenBIOS forth core is split into a forth kernel written in portable 
 C and a forth dictionary which operated on by the kernel.

 When building the forth core, you get different versions of
 the forth kernel: 

 * a unix executable program

   - to execute a forth dictionary from a file. This can be used for
     easily testing and developing OpenBIOS on a unix host.

   - to create a dictionary file. Such a dictionary file sets up
     all of the forth language. Primitives are indexed to save relocations.

     The default is to create a forth dictionary forth.dict from
     forth/start.fs. This file includes all of the basic forth language
     constructs from forth/bootstrap.fs and starts the interpreter.

     To achieve this, the hosted unix version contains a basic set of
     forth words coded in C that allow creating a full dictionary.

 * a varying number of target specific binaries. On x86 you can start 
   openbios for example from GRUB or LinuxBIOS. They are all based on
   the same forth engine consisting of a dictionary scheduler, primitive 
   words needed to build the forth environment, 2 stacks and a simple 
   set of console functions. These binaries can not be started directly
   in the unix host environment.

Requirements
------------
 * gcc
 * gnu make
 * OpenBIOS FCode Utils
   Download with svn co svn://openbios.org/openbios/fcode-utils
 * grub or any other multiboot loader to run the multiboot
   binary "openbios.multiboot" with it's module "openbios-<platform>.dict"
 * xsltproc
 
Building & Usage
----------------

 * make

   this builds "openbios.multiboot", the standalone image and "openbios-unix", 
   the hosted image. Additionally it creates a forth dictionary
   file from forth/start.fs. All generated files are written to 
   the absolute directory held by the variable BUILDDIR, which defaults
   to obj-[platform]. Some compile time parameters can be tweaked in
   include/config.h
   
 * use "openbios-unix" to create a forth dictionary on your own:
   $ obj-x86/openbios-unix -Iforth start.fs
   creates the file forth.dict from forth source forth/start.fs.

 * use "openbios-unix" to run a created dictionary: 
   $ obj-x86/openbios-unix obj-x86/openbios-unix.dict
   This is useful for testing
 
 * booting openbios
   You can boot openbios i.e. in grub. Add the following lines to
   your menu.lst:

    title openbios
      kernel (hd0,2)/boot/openbios.multiboot
      module (hd0,2)/boot/openbios-x86.dict

   Note: change (hd0,2) to the partition you copied the openbios image and
   openbios-x86.dict to.

   To boot OpenBIOS from LinuxBIOS/etherboot, you can either use
   "openbios-plain.elf" or "openbios-builtin.elf":

   - openbios-plain.elf is the pure kernel that loads the dictionary from a 
     hardcoded address in flash memory (0xfffe0000)

   - openbios-builtin.elf also includes the dictionary directly so that it
     can be easily used from etherboot or the LinuxBIOS builtin ELF
     loader without taking care of the dictionary

CREDITS
-------
OpenBIOS was developed by Stefan Reinauer, Samuel Rydh and Patrick Mauritz.
The OpenBIOS IDE driver was written by Jens Axboe.
For license details on this piece of software, see the file COPYING.


If you have patches, questions, comments, feel free to contact the OpenBIOS
mailinglist.

Regards,
     the OpenBIOS team

fcode-utils's People

Contributors

afaerber avatar blueswirl avatar fweimer-rh avatar lemenkov avatar mcayland avatar paulepanter avatar programmingkidx avatar reinauer avatar vivier avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fcode-utils's Issues

Produce man pages for documentation

It’d be great to have the UNIX manual pages for detok, romheaders, and toke in addition to the HTML documentation. Ideally both could be produced from the same source.

Support building to a separate directory

It’d be useful for porting and continuous integration for the project to support building to a separate directory than the source tree and for this directory to be specifiable on the make command line. (For example, make OBJDIR=/builds/fcode-utils/fcode-utils-1.0.3~5 to use the specified directory for build intermediates and products.)

Ideally:

  • The build won’t fail if the source directory is read-only and a separate build directory is specified.
  • The result of git status after building to a separate build directory will be clean, without needing a .gitignore file.
  • Simultaneous builds from the same source directory to separate build directories will all succeed without interfering with each other in any way.

Make test suite builder-agnostic

On my Mac using a very recent macOS and Xcode, I can easily build fcode-utils with just a quick make, but make tests unfortunately fails with a huge set of diffs.

It looks like the test suite works by comparing the test result logs with a static set of logs created in specific build environments, and doesn’t take differences in the file headers or whitespace into account.

For example, here’s the first page of results in my terminal:

CygTestLogs=/Users/cmh/Documents/Projects/OpenFirmware/fcode-utils/testlogs/testlogs-ppc-linux csh AutoCompare

177
177 TokCondl/TokExstCondTstY.Log files differ.
3,4c3,4
< Welcome to toke - OpenBIOS tokenizer v1.0.2
< (C) Copyright 2001-2006 Stefan Reinauer.
---
> Welcome to toke - FCode tokenizer v1.0.3
> (C) Copyright 2001-2010 Stefan Reinauer.
10,11d9
< 	Tokenizer Compiled on PPC under GNU_Linux
< 		Mon, 23 Oct 2006 at 13:20:18 CDT
TokCondl/TokExstCondTstY.DeTok files differ.
1,2c1,2
< \  Welcome to detok - OpenBIOS detokenizer v1.0.2
< \  (C) Copyright 2001-2006 Stefan Reinauer.
---
> \  Welcome to detok - FCode detokenizer v1.0.3
> \  (C) Copyright 2001-2010 Stefan Reinauer
16c16
<                 " Begin Nest Test Test"
---
>         " Begin Nest Test Test"
19c19
<                 " Exists, level 1"
---
>         " Exists, level 1"
22c22
<                 " Exists and exists, level 2"
---
>         " Exists and exists, level 2"
25c25

and so on.

It seems like the test suite could be improved in a couple of ways:

  • Have one standard set of known-good results to compare against, rather than per-build-environment sets.
  • Output the results into a separate directory (specifiable via a make variable) rather than the same directory as the test sources.
  • Ignore whitespace in result comparisons when that doesn’t matter. (Does it ever? I don’t know the code or tests…)

That would make it much easier to find meaningful test failures, and to do repeatable CI builds.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.