[announce] OpenBIOS Forth Kernel V1.0 released

[Stefan Reinauer]

Dear LinuxBIOS community,

After some months of development I am happy to announce the new
OpenBIOS forth kernel "BeginAgain".

It is available from the OpenBIOS CVS in the directory "kernel/" 
or at http://www.openbios.org/bin/kernel-1.0.tar.bz2

Features
--------
- indirect-threaded forth engine
- openfirmware user interface
- small and portable
- easily enhancable

Platform Notes
--------------

Currently targets for X86 PCs and AMD64 exist. The OpenBIOS forth
kernel was developed using gcc on Linux systems. Minor changes might
be necessary in non-linux/gcc build environments.

Design Goals
------------

The design goals of "BeginAgain" were:

1) Portability
  2) Maintainability
  3) Small Size

----------------------------------------------------------------------

1) Portability

BeginAgain, with minimal changes, will work on new systems.  There
   is support for X86 and AMD64 at the moment. Implementing support
   for new systems only requires adaptions to the start code and
   system abstraction.  The current code has been developed using gcc
   3.x, but no explicit GCCisms are used.  Since gcc is the most
   widely spread compiler, it should be a good base for easily porting
   OpenBIOS to new platforms.

2) Maintainability

The code is split into several parts:

_________________________________________
   |                                         |
   |            Forth dictionary             |
   |_________________________________________|

^                         |    forth code
   ________|_________________________|_________
           |                         |   
           |                         v    native code
    _____________         ___________________
   |             |       |                   |
   |  Scheduler  | ----> |  primitive words  |
   |_____________|       |___________________|
           ^                         ^
           |                         |
       |                         |
    _____________         ____________________
   |             |       |                    |
-->|  Startup    |       | system abstraction |
   |_____________|       |____________________|

Platform dependent part
   -----------------------

a) After taking control the "scheduler", in forth context called
      "inner interpreter, reads the forth dictionary, a list of nested
      word definitions that are built using primitive words.

b) These primitive words are written in C, so they take advantage
      of the compiler's ability to optimize code. They represent the
      minimum set of forth words that are needed to define all language
      constructs, including the Open Firmware system.

c) The startup code is probably the most platform sensitive code.
      It's task is simple - get the scheduler up and running and
      provide a dictionary to execute. OpenBIOS provides multiple boot
      targets per platform. For example, on x86 it is possible to run
      the kernel either from Grub or LinuxBIOS.  An additional target
      (available on all platforms) allows running the code from a Unix
      shell.

d) The system abstraction part ought to be kept as small as
      possible. The primary words provide an interface for
      non-memory-mapped IO, and there's a small builtin console due to
      the fact that OpenBIOS has no device tree and/or drivers at the
      moment.

Once these platform dependent parts are in place, they can be used
   to create an indirect-threaded dictionary file. This dictionary
   file contains a platform abstracted version of forth code that
   currently depends on the endianness and pointer (cell) size of the
   target platform. 
   To keep the forth dictionary and the native code strictly seperate
   the unix hosted version of the kernel has a small builtin
   interpreter able to bootstrap all of the base system including a
   forth written interpreter, which represents part of the
   openfirmware user interface. 
   In a second stage the advanced forth written interpreter is used to
   extend the bootstrap dictionary with additional features. As an
   example, ANS forth wordlist support is added, which will be used in
   the device tree code.
   Currently the OpenBIOS dictionary contains a nearly complete
   implementation of the Open Firmware user interface. It passes the
   Hayes ANS Forth test suite that is run when OpenBIOS is built,
   writing it's output to the file forth.html.

Since the machine is abstracted as early and completly as possible,
   porting OpenBIOS to a new platform requires only minor efforts.

3) Small size

The less code that needs to be adopted when porting OpenBIOS to a
   new platform, the quicker new ports can happen. Therefore the
   OpenBIOS kernel is really small. Here is a sample:

size in   |   x86   |   amd64
             bytes    | gcc 3.3 | gcc 3.3.1
     -----------------+---------+----------------		     
     multiboot kernel |  6724   |     15464
     -----------------+---------+---------------- 
     LinuxBIOS kernel |  7016   |     15896
     -----------------+---------+----------------
     LinuxBIOS kernel |         |
     inc. dictionary  | 27048   |     52920
     --------------------------------------------

Installation and usage
----------------------

Run "make" to compile all binaries and dictionaries required to run
the OpenBIOS kernel
  $ make
Per default all binaries will be placed in the directory obj-{platform}.

Then you can execute the kernel from a shell, by giving the command
  $ make run

To boot LinuxBIOS from GRUB, copy openbios.multiboot and
openfirmware.dict to /boot, then add a new entry to your 
menu.lst config file which looks like this:

-------------------- 8< --------------------
  title openbios
    kernel (hd0,2)/boot/openbios.multiboot
    module (hd0,2)/boot/openfirmware.dict
-------------------- 8< --------------------

(hd0,2) is the equivalent to the Linux partition /dev/hda3

OpenBIOS can be used as a payload to LinuxBIOS (www.linuxbios.org) or
booted in EtherBoot (www.etherboot.org). The simplest way is to use
the kernel that includes the full dictionary: openbios.full

Bug reports
-----------

Any trouble, bugs etc. should be reported to the openbios mailinglist

Further Development
-------------------

BeginAgain is pretty much complete now. Expect only bugfixes and
optimizations in the future. Interpretation mode versions of most loop
constructs should be included although they are not really needed to
get more development going. The next steps in writing an Open Firmware
implementation is to complete the Device and Client Interfaces. These
two parts are needed to set up a device tree, initialize hardware, and
boot the operating system.  Once there is a device tree and some basic
device interface functions it will be possible to run fcode drivers
for device initialization in OpenBIOS, using the FCode evaluator that
resides in the OpenBIOS CVS directory forth/evaluator/.

Regards,
     Stefan

[Gregg C Levine]

Hello (again) from Gregg C Levine
Nice! And I am reporting an error of sorts. Here's a paste of the log
from a script for the build process. For some reason its breaking
towards the end, with regards to the dictionary that was created for
booting from GRUB. Here, I'll post it:
Script started on Tue Sep 16 23:52:05 2003
root@who3:/usr/src/openbios/kernel# make

Welcome to OpenBIOS..

Creating build directory /usr/src/openbios/kernel/obj-x86
Checking types...found 32bit platform, creating "types.h"

Building common core files for architecture x86
  compiling primitives.c...    		ok
  compiling stack.c...    		ok
  compiling dict.c...    		ok
  compiling lib.c...    		ok
  compiling openbios.c...    		ok

Building files for unix hosted bootstrap
  compiling unix.c...    		ok
  linking unix bootstrap... 		ok

Bootstrapping dictionary...		ok
Building final dictionary...		ok
Building binary converter...		ok

Compiling x86 architecture specific binaries
  assembling mboot.S...     		ok
  compiling multiboot.c...    		ok
  assembling boot.S...     		ok
  compiling plainboot.c...    		ok
  generating linkable dictionary...	ok
  compiling builtin.c...    		ok
  compiling console.c...    		ok

Linking:
  native multiboot kernel for grub...
/usr/src/openbios/kernel/obj-x86/dict.o: In function
`load_dictionary':
/usr/src/openbios/kernel/obj-x86/dict.o(.text+0x150): undefined
reference to `strncmp'
/usr/src/openbios/kernel/obj-x86/dict.o(.text+0x177): undefined
reference to `memcpy'
collect2: ld returned 1 exit status
make[1]: *** [openbios.multiboot] Error 1
make: *** [x86] Error 2
root@who3:/usr/src/openbios/kernel# exit
Script done on Tue Sep 16 23:52:47 2003

Any suggestions Stefan? Besides I like your ideas regarding the Open
BIOS concepts. Incidentally for that project, can you put up the older
versions of the /dev/bios files? Say, anything up to 3.*?
-------------------
Gregg C Levine [e-mail]
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )
> -----Original Message-----
> From: [e-mail] [mailto:linuxbios-
> [e-mail]] On Behalf Of Stefan Reinauer
> Sent: Tuesday, September 16, 2003 12:03 PM
> To: LinuxBIOS
> Subject: [announce] OpenBIOS Forth Kernel V1.0 released
>
> Dear LinuxBIOS community,
>
> After some months of development I am happy to announce the new
> OpenBIOS forth kernel "BeginAgain".
>
> It is available from the OpenBIOS CVS in the directory "kernel/"
> or at http://www.openbios.org/bin/kernel-1.0.tar.bz2
> Features
> indirect-threaded forth engine
> openfirmware user interface
> small and portable
> easily enhancable
> Platform Notes
>
> Currently targets for X86 PCs and AMD64 exist. The OpenBIOS forth
> kernel was developed using gcc on Linux systems. Minor changes might
> be necessary in non-linux/gcc build environments.
> Design Goals
>
> The design goals of "BeginAgain" were:
> Portability
> Maintainability
> Small Size

----------------------------------------------------------------------
> Portability
>
> BeginAgain, with minimal changes, will work on new systems.

There
> is support for X86 and AMD64 at the moment. Implementing support
>    for new systems only requires adaptions to the start code and
>    system abstraction.  The current code has been developed using

gcc
> 3.x, but no explicit GCCisms are used.  Since gcc is the most
>    widely spread compiler, it should be a good base for easily

porting
> OpenBIOS to new platforms.
>
> Maintainability
>
> The code is split into several parts:
>
> |                                         |
> |            Forth dictionary             |
> |_________________________________________|
>     ^                         |    forth code
>
> ________|_________________________|_________
>         |                         |
>         |                         v    native code
>  _____________         ___________________
> |             |       |                   |
> |  Scheduler  | ----> |  primitive words  |
> |_____________|       |___________________|
>         ^                         ^
>         |                         |
>    |                         |
>  _____________         ____________________
> |             |       |                    |
>
> -->|  Startup    |       | system abstraction |
>    |_____________|       |____________________|
> Platform dependent part
>
> a) After taking control the "scheduler", in forth context called
>       "inner interpreter, reads the forth dictionary, a list of

nested
>   word definitions that are built using primitive words.
>
> b) These primitive words are written in C, so they take advantage
>       of the compiler's ability to optimize code. They represent the
>       minimum set of forth words that are needed to define all

language
>   constructs, including the Open Firmware system.
>
> c) The startup code is probably the most platform sensitive code.
>       It's task is simple - get the scheduler up and running and
>       provide a dictionary to execute. OpenBIOS provides multiple

boot
>   targets per platform. For example, on x86 it is possible to

run
>   the kernel either from Grub or LinuxBIOS.  An additional

target
>   (available on all platforms) allows running the code from a

Unix
>   shell.
>
> d) The system abstraction part ought to be kept as small as
>       possible. The primary words provide an interface for
>       non-memory-mapped IO, and there's a small builtin console due

to
>   the fact that OpenBIOS has no device tree and/or drivers at

the
>   moment.
>
>
> Once these platform dependent parts are in place, they can be

used
> to create an indirect-threaded dictionary file. This dictionary
>    file contains a platform abstracted version of forth code that
>    currently depends on the endianness and pointer (cell) size of

the
> target platform.
>    To keep the forth dictionary and the native code strictly

seperate
> the unix hosted version of the kernel has a small builtin
>    interpreter able to bootstrap all of the base system including a
>    forth written interpreter, which represents part of the
>    openfirmware user interface.
>    In a second stage the advanced forth written interpreter is used

to
> extend the bootstrap dictionary with additional features. As an
>    example, ANS forth wordlist support is added, which will be used

in
> the device tree code.
>    Currently the OpenBIOS dictionary contains a nearly complete
>    implementation of the Open Firmware user interface. It passes the
>    Hayes ANS Forth test suite that is run when OpenBIOS is built,
>    writing it's output to the file forth.html.
>
> Since the machine is abstracted as early and completly as

possible,
> porting OpenBIOS to a new platform requires only minor efforts.
>
> Small size
>
> The less code that needs to be adopted when porting OpenBIOS to a
> new platform, the quicker new ports can happen. Therefore the
> OpenBIOS kernel is really small. Here is a sample:
>      size in   |   x86   |   amd64
>       bytes    | gcc 3.3 | gcc 3.3.1
>
> -----------------+---------+----------------
>   multiboot kernel |  6724   |     15464
>   -----------------+---------+----------------
>   LinuxBIOS kernel |  7016   |     15896
>   -----------------+---------+----------------
>   LinuxBIOS kernel |         |
>   inc. dictionary  | 27048   |     52920
> Installation and usage
>
> Run "make" to compile all binaries and dictionaries required to run
> the OpenBIOS kernel
>   $ make
> Per default all binaries will be placed in the directory

obj-{platform}.
> Then you can execute the kernel from a shell, by giving the command
>   $ make run
>
> To boot LinuxBIOS from GRUB, copy openbios.multiboot and
> openfirmware.dict to /boot, then add a new entry to your
> menu.lst config file which looks like this:
>
> -------------------- 8< --------------------
>   title openbios
>     kernel (hd0,2)/boot/openbios.multiboot
>     module (hd0,2)/boot/openfirmware.dict
> -------------------- 8< --------------------
>
> (hd0,2) is the equivalent to the Linux partition /dev/hda3
>
> OpenBIOS can be used as a payload to LinuxBIOS (www.linuxbios.org)

or
> booted in EtherBoot (www.etherboot.org). The simplest way is to use
> the kernel that includes the full dictionary: openbios.full
> Bug reports
>
> Any trouble, bugs etc. should be reported to the openbios

mailinglist
> Further Development
>
> BeginAgain is pretty much complete now. Expect only bugfixes and
> optimizations in the future. Interpretation mode versions of most

loop
> constructs should be included although they are not really needed to
> get more development going. The next steps in writing an Open

Firmware
> implementation is to complete the Device and Client Interfaces.

These
> two parts are needed to set up a device tree, initialize hardware,

and
> boot the operating system.  Once there is a device tree and some

basic
> device interface functions it will be possible to run fcode drivers
> for device initialization in OpenBIOS, using the FCode evaluator

that
> resides in the OpenBIOS CVS directory forth/evaluator/.
>
> Regards,
>      Stefan
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

[Stefan Reinauer]

* Gregg C Levine  [030917 06:03]:
> /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x150): undefined
> reference to `strncmp'
> /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x177): undefined
> reference to `memcpy'

Ups. What gcc version are you using? Can you try compiling with
-DDEBUG_GDB in CFLAGS, this adds some normally builtin functions.
> Any suggestions Stefan? Besides I like your ideas regarding the Open
> BIOS concepts. Incidentally for that project, can you put up the older
> versions of the /dev/bios files? Say, anything up to 3.*?

All old versions I have lying around are in 
http://www.openbios.info/bin/

Do you need some particular code? The CVS version should be better in
most cases.

Stefan

[Gregg C Levine]

Hello (again) from Gregg C Levine
Okay, I knew you'd ask that question, when I sent that bug report off.
But forgot to include this in the first message. Version of
GCC=2.9.5.3, short version of binary utilities 2.10, and they were
built for I386, for Slackware Linux. I'll try adding that to the
section for the C Flags in the make file.
-------------------
Gregg C Levine [e-mail]
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )
> -----Original Message-----
> From: Stefan Reinauer [mailto:[e-mail]]
> Sent: Wednesday, September 17, 2003 7:18 AM
> To: Gregg C Levine
> Cc: 'LinuxBIOS'
> Subject: Re: [announce] OpenBIOS Forth Kernel V1.0 released
> Gregg C Levine  [030917 06:03]:
> > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x150): undefined
> > reference to `strncmp'
> > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x177): undefined
> > reference to `memcpy'
>
> Ups. What gcc version are you using? Can you try compiling with
> -DDEBUG_GDB in CFLAGS, this adds some normally builtin functions.
> > Any suggestions Stefan? Besides I like your ideas regarding the

Open
> > BIOS concepts. Incidentally for that project, can you put up the

older
> > versions of the /dev/bios files? Say, anything up to 3.*?
>
> All old versions I have lying around are in
> http://www.openbios.info/bin/
>
> Do you need some particular code? The CVS version should be better

in
> most cases.
>
> Stefan

[Gregg C Levine]

Hello (again) from Gregg C Levine
Okay, by adding that flag to the flags region of the make file, made
it work, sort of. Now the explosion happens when the process reaches
the steps for creating an image for working with our project here,
Linux BIOS, that's where it happens, something to do with the strip
command. GCC is still 2.9.5.3, and binary utilities are still
2.11.90.0.19, (my mistake), below this will be my script file, (cut
and paste):
Script started on Wed Sep 17 13:21:21 2003
root@who3:/usr/src/openbios/kernel# make

Welcome to OpenBIOS..

Creating build directory /usr/src/openbios/kernel/obj-x86
Checking types...found 32bit platform, creating "types.h"

Building common core files for architecture x86
  compiling primitives.c...    		ok
  compiling stack.c...    		ok
  compiling dict.c...    		ok
  compiling lib.c...    		ok
  compiling openbios.c...    		ok

Building files for unix hosted bootstrap
  compiling unix.c...    		ok
  linking unix bootstrap... 		ok

Bootstrapping dictionary...		ok
Building final dictionary...		ok
Building binary converter...		ok

Compiling x86 architecture specific binaries
  assembling mboot.S...     		ok
  compiling multiboot.c...    		ok
  assembling boot.S...     		ok
  compiling plainboot.c...    		ok
  generating linkable dictionary...	ok
  compiling builtin.c...    		ok
  compiling console.c...    		ok

Linking:
  native multiboot kernel for grub... 	ok
  native kernel (for LinuxBIOS)... 	ok
Usage: strip <switches> in-file(s)
 The switches are:
  -I --input-target <bfdname>      Assume input file is in format
<bfdname>
  -O --output-target <bfdname>     Create an output file in format
<bfdname>
  -F --target <bfdname>            Set both input and output format to
<bfdname>
  -p --preserve-dates              Copy modified/access timestamps to
the output
  -R --remove-section <name>       Remove section <name> from the
output
  -s --strip-all                   Remove all symbol and relocation
information
  -g -S --strip-debug              Remove all debugging symbols
     --strip-unneeded              Remove all symbols not needed by
relocations
  -N --strip-symbol <name>         Do not copy symbol <name>
  -K --keep-symbol <name>          Only copy symbol <name>
  -x --discard-all                 Remove all non-global symbols
  -X --discard-locals              Remove any compiler-generated
symbols
  -v --verbose                     List all object files modified
  -V --version                     Display this program's version
number
  -h --help                        Display this output
  -o <file>                        Place stripped output into <file>
strip: supported targets: elf32-i386 a.out-i386-linux efi-app-ia32
elf32-little elf32-big srec symbolsrec tekhex binary ihex trad-core
make[1]: *** [openbios] Error 1
make: *** [x86] Error 2
root@who3:/usr/src/openbios/kernel# exit
Script done on Wed Sep 17 13:23:00 2003

Stefan your guess is as good as mine, as to what happened here. For
/dev/bios, I found that the version you have there, tended to cause an
oops, with my system tools, I'll grab it again, and try it. Basically
the earlier ones, 2.9 for example, worked. This is before your site
migrated to its present home.

Oh and Ron, thank you for quoting me. It makes me feel better to see
that happen.
-------------------
Gregg C Levine [e-mail]
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )
> -----Original Message-----
> From: Stefan Reinauer [mailto:[e-mail]]
> Sent: Wednesday, September 17, 2003 7:18 AM
> To: Gregg C Levine
> Cc: 'LinuxBIOS'
> Subject: Re: [announce] OpenBIOS Forth Kernel V1.0 released
> Gregg C Levine  [030917 06:03]:
> > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x150): undefined
> > reference to `strncmp'
> > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x177): undefined
> > reference to `memcpy'
>
> Ups. What gcc version are you using? Can you try compiling with
> -DDEBUG_GDB in CFLAGS, this adds some normally builtin functions.
> > Any suggestions Stefan? Besides I like your ideas regarding the

Open
> > BIOS concepts. Incidentally for that project, can you put up the

older
> > versions of the /dev/bios files? Say, anything up to 3.*?
>
> All old versions I have lying around are in
> http://www.openbios.info/bin/
>
> Do you need some particular code? The CVS version should be better

in
> most cases.
>
> Stefan

[Gregg C Levine]

Hello (again) from Gregg C Levine
Stefan, it looks as if I was right. The version that's on your site,
does cause an oops, here it is:
invalid operand: 0000
CPU:    0
EIP:    0010:[<c2860072>]    Not tainted
EFLAGS: 00010246
eax: c2861e4a   ebx: c2860000   ecx: c2860000   edx: c2861e40
esi: 00000000   edi: c2860000   ebp: c1781fbc   esp: c1781f1c
ds: 0018   es: 0018   ss: 0018
Process insmod (pid: 1317, stackpage=c1781000)
Stack: c2860000 c28600f5 c0117625 c1780000 40020a40 bfffcabc c011dbaa
c2860000
       00004c30 00004664 c09cf000 00000060 c0367000 ffffffea 00000004
c1da093c
       00000060 c285d000 c2860060 00004c30 00000000 00000000 00000000
00000000
Call Trace:    [<c28600f5>] [<c0117625>] [<c011dbaa>] [<c2860060>]
[<c0108973>]

Code: 0f 45 c2 50 68 60 1e 86 c2 e8 e0 67 8b fd e8 ab 75 95 fd 83

I suspect that the module, is causing insmod to have a bad time.
Here's the decoded one:
ksymoops 2.4.9 on i586 2.4.21.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.21/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol
resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to
find
map, modules, ksyms etc.  ksymoops -h explains the options.

Warning (compare_maps): ksyms_base symbol
__ide_do_rw_disk_R__ver___ide_do_rw_disk not found in System.map.
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
ide_build_dmatable_R__ver_ide_build_dmatable not found in System.map.
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
ide_destroy_dmatable_R__ver_ide_destroy_dmatable not found in
System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
ide_dma_intr_R__ver_ide_dma_intr not found in System.map.  Ignoring
ksyms_base entry
Warning (compare_maps): ksyms_base symbol
ide_get_best_pio_mode_R__ver_ide_get_best_pio_mode not found in
System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
ide_pci_register_driver_R__ver_ide_pci_register_driver not found in
System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
ide_pci_unregister_driver_R__ver_ide_pci_unregister_driver not found
in System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
ide_pio_timings_R__ver_ide_pio_timings not found in System.map.
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
ide_set_xfer_rate_R__ver_ide_set_xfer_rate not found in System.map.
Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
ide_setup_dma_R__ver_ide_setup_dma not found in System.map.  Ignoring
ksyms_base entry
Warning (compare_maps): ksyms_base symbol
ide_setup_pci_device_R__ver_ide_setup_pci_device not found in
System.map.  Ignoring ksyms_base entry
Warning (compare_maps): ksyms_base symbol
ide_setup_pci_devices_R__ver_ide_setup_pci_devices not found in
System.map.  Ignoring ksyms_base entry
invalid operand: 0000
CPU:    0
EIP:    0010:[<c2860072>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: c2861e4a   ebx: c2860000   ecx: c2860000   edx: c2861e40
esi: 00000000   edi: c2860000   ebp: c1781fbc   esp: c1781f1c
ds: 0018   es: 0018   ss: 0018
Process insmod (pid: 1317, stackpage=c1781000)
Stack: c2860000 c28600f5 c0117625 c1780000 40020a40 bfffcabc c011dbaa
c2860000
       00004c30 00004664 c09cf000 00000060 c0367000 ffffffea 00000004
c1da093c
       00000060 c285d000 c2860060 00004c30 00000000 00000000 00000000
00000000
Call Trace:    [<c28600f5>] [<c0117625>] [<c011dbaa>] [<c2860060>]
[<c0108973>]
Code: 0f 45 c2 50 68 60 1e 86 c2 e8 e0 67 8b fd e8 ab 75 95 fd 83
> > EIP; c2860072 <[bios]__module_license+a/88>   <=====
> > eax; c2861e4a <[bios].rodata.start+2a/120>
> > ebx; c2860000 <[bios]__module_kernel_version+0/16>
> > ecx; c2860000 <[bios]__module_kernel_version+0/16>
> > edx; c2861e40 <[bios].rodata.start+20/120>
> > edi; c2860000 <[bios]__module_kernel_version+0/16>
> > ebp; c1781fbc <_end+1490fa0/2514fe4>
> > esp; c1781f1c <_end+1490f00/2514fe4>

Trace; c28600f5 <[bios]init_module+5/8>
Trace; c0117625 <sys_init_module+59d/654>
Trace; c011dbaa <timer_bh+26/380>
Trace; c2860060 <[bios]bios_init+0/0>
Trace; c0108973 <system_call+33/38>

Code;  c2860072 <[bios]__module_license+a/88>
0000000000000000 <_EIP>:
Code;  c2860072 <[bios]__module_license+a/88>   <=====
   0:   0f 45 c2                  cmovne %edx,%eax   <=====
Code;  c2860075 <[bios]__module_license+d/88>
   3:   50                        push   %eax
Code;  c2860076 <[bios]__module_license+e/88>
   4:   68 60 1e 86 c2            push   $0xc2861e60
Code;  c286007b <[bios]__module_license+13/88>
   9:   e8 e0 67 8b fd            call   fd8b67ee <_EIP+0xfd8b67ee>
c0116860 <printk+0/11c>
Code;  c2860080 <[bios]__module_license+18/88>
   e:   e8 ab 75 95 fd            call   fd9575be <_EIP+0xfd9575be>
c01b7630 <pcibios_present+0/18>
Code;  c2860085 <[bios]__module_license+1d/88>
  13:   83 00 00                  addl   $0x0,(%eax)

13 warnings issued.  Results may not be reliable.

I don't know what ksymoops means about the last line, but its all
there. Everything is as I last posted regarding the kernel project
program. Other then the peculiar complaint from strip it works. Ron,
if your curious, that's from the latest version of Stefan's /dev/bios
module. Why it compiles, but promptly throws that, is why I'm here. If
you want, I'll switch to any other methods of communicating with
Stefan.
-------------------
Gregg C Levine [e-mail]
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )
> -----Original Message-----
> From: [e-mail] [mailto:linuxbios-
> [e-mail]] On Behalf Of Gregg C Levine
> Sent: Wednesday, September 17, 2003 5:59 PM
> To: 'Stefan Reinauer'
> Cc: 'LinuxBIOS'
> Subject: RE: [announce] OpenBIOS Forth Kernel V1.0 released
>
> Hello (again) from Gregg C Levine
> Okay, by adding that flag to the flags region of the make file, made
> it work, sort of. Now the explosion happens when the process reaches
> the steps for creating an image for working with our project here,
> Linux BIOS, that's where it happens, something to do with the strip
> command. GCC is still 2.9.5.3, and binary utilities are still
> 2.11.90.0.19, (my mistake), below this will be my script file, (cut
> and paste):
> Script started on Wed Sep 17 13:21:21 2003
> root@who3:/usr/src/openbios/kernel# make
>
> Welcome to OpenBIOS..
>
> Creating build directory /usr/src/openbios/kernel/obj-x86
> Checking types...found 32bit platform, creating "types.h"
>
> Building common core files for architecture x86
>   compiling primitives.c...    		ok
>   compiling stack.c...    		ok
>   compiling dict.c...    		ok
>   compiling lib.c...    		ok
>   compiling openbios.c...    		ok
>
> Building files for unix hosted bootstrap
>   compiling unix.c...    		ok
>   linking unix bootstrap... 		ok
>
> Bootstrapping dictionary...		ok
> Building final dictionary...		ok
> Building binary converter...		ok
>
> Compiling x86 architecture specific binaries
>   assembling mboot.S...     		ok
>   compiling multiboot.c...    		ok
>   assembling boot.S...     		ok
>   compiling plainboot.c...    		ok
>   generating linkable dictionary...	ok
>   compiling builtin.c...    		ok
>   compiling console.c...    		ok
>
> Linking:
>   native multiboot kernel for grub... 	ok
>   native kernel (for LinuxBIOS)... 	ok
> Usage: strip <switches> in-file(s)
>  The switches are:
>   -I --input-target <bfdname>      Assume input file is in format
>
> <bfdname>
>   -O --output-target <bfdname>     Create an output file in format
> <bfdname>
>   -F --target <bfdname>            Set both input and output format

to
> <bfdname>
>   -p --preserve-dates              Copy modified/access timestamps

to
> the output
>   -R --remove-section <name>       Remove section <name> from the
> output
>   -s --strip-all                   Remove all symbol and relocation
> information
>   -g -S --strip-debug              Remove all debugging symbols
>      --strip-unneeded              Remove all symbols not needed by
> relocations
>   -N --strip-symbol <name>         Do not copy symbol <name>
>   -K --keep-symbol <name>          Only copy symbol <name>
>   -x --discard-all                 Remove all non-global symbols
>   -X --discard-locals              Remove any compiler-generated
> symbols
>   -v --verbose                     List all object files modified
>   -V --version                     Display this program's version
> number
>   -h --help                        Display this output
>   -o <file>                        Place stripped output into <file>
> strip: supported targets: elf32-i386 a.out-i386-linux efi-app-ia32
> elf32-little elf32-big srec symbolsrec tekhex binary ihex trad-core
> make[1]: *** [openbios] Error 1
> make: *** [x86] Error 2
> root@who3:/usr/src/openbios/kernel# exit
> Script done on Wed Sep 17 13:23:00 2003
>
> Stefan your guess is as good as mine, as to what happened here. For
> /dev/bios, I found that the version you have there, tended to cause

an
> oops, with my system tools, I'll grab it again, and try it.

Basically
> the earlier ones, 2.9 for example, worked. This is before your site
> migrated to its present home.
>
> Oh and Ron, thank you for quoting me. It makes me feel better to see
> that happen.
> Gregg C Levine [e-mail]
>
> "The Force will be with you...Always." Obi-Wan Kenobi
> "Use the Force, Luke."  Obi-Wan Kenobi
> (This company dedicates this E-Mail to General Obi-Wan Kenobi )
> (This company dedicates this E-Mail to Master Yoda )
> > -----Original Message-----
> > From: Stefan Reinauer [mailto:[e-mail]]
> > Sent: Wednesday, September 17, 2003 7:18 AM
> > To: Gregg C Levine
> > Cc: 'LinuxBIOS'
> > Subject: Re: [announce] OpenBIOS Forth Kernel V1.0 released
> > Gregg C Levine  [030917 06:03]:
> > > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x150): undefined
> > > reference to `strncmp'
> > > /usr/src/openbios/kernel/obj-x86/dict.o(.text+0x177): undefined
> > > reference to `memcpy'
> >
> > Ups. What gcc version are you using? Can you try compiling with
> > -DDEBUG_GDB in CFLAGS, this adds some normally builtin functions.
> > > Any suggestions Stefan? Besides I like your ideas regarding the
>
> Open
> > > BIOS concepts. Incidentally for that project, can you put up the
>
> older
> > > versions of the /dev/bios files? Say, anything up to 3.*?
> >
> > All old versions I have lying around are in
> > http://www.openbios.info/bin/
> >
> > Do you need some particular code? The CVS version should be better
>
> in
> > most cases.
> >
> > Stefan
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

Re OpenBIOS Forth Kernel V1.0 released

[Balint Cristian]

Hi Stefan, Hi all !
> Stefan

Hust an Q from a very courios person:

Some forthfirmare  init code ?
Are you/team started working on it ?

Forth Base Dictionary  : : : : : : : : Status: 95%
Open Firmware specific Forth Dictionary  : : : : : : : : Status: 0%
Device Interface  : : : : : : : : Status: 0%
Client Interface  : : : : : : : : Status: 0%
User Interface  : : : : : : : : Status: 0%

Best Regards,
Cristian