Wouldn't it make sense to add some C-bindings to the forth
kernel? I have examined all the built-in tokens and as far
as far as I can tell there is currently no way to call an
external function (well, save abusing the inb/outb mechanism).
Some background:
The forth kernel and the MOL OF loader are statically
linked as a single binary (the ROM image).
The MOL part of the code contains low-level support for
exceptions and similar things. It also contains filesystem
support, SCSI support, boot disk search algorithms, device
tree handling and the OF client interface (and some other stuff).
To make the C-code and the forth code interoperate, I would
like to be able to
1. Call C-functions from forth code by pushing the address
of the function on the stack. Something like
call ( function_addr -- <whatever> )
2. Be able to invoke the forth interpreter from C-code
(I think this can be implementable without modifying
the kernel code, but I haven't looked into it yet).
I can of course solve the first point be adding a primitive
to the words[] table, but wouldn't it make sense also for
other projects? I imagine that a real-world implementation
will implement some things in C (more people are familiar
with C and there are already plenty of code written in C
that can be reused; filesystems for instance...).
/Samuel
On Sat, Oct 25, 2003 at 02:45:19PM +0200, Stefan Reinauer wrote:
> >Yes, I think so. I'm not sure exactly how much work is involved but
> >I will give it a go (it is not necessary to do a full OF implementation
> >right away...).
> >
> I can have a look on integrating the MOL OF functionality into
> BeginAgain, but for putting BeginAgain into MOL I'd prefer if you could
> try this first.
Certainly. I don't think putting the MOL OF code directly into
BeginAgain is such a good idea, at least not the current incarnation
of the of-mol code. My thought was to add the BeginAgain kernel
to of-mol and then gradually start to use it for OF client services
and for user interaction.
> >For MOL, the device tree is loaded from a config file (for MacOS, it is
> >essentially a copy of a "real" device tree). Bus probing and
> >similar things are not needed (although one could implement this
> >if one really wants to). Cloning the device tree at OF startup is
> >sufficient
> >(just like most parts of the device tree is hardcoded in ROM in most
> >machines).
> >
> Ah.. these device tree files I have seen. It's a really quick way of
> setting resources up for different kinds of systems. Are the different
> device trees needed for different purposes/machines?
Yes, different device trees are used for different purposes.
The Mac OS 9 device-tree originates from a B&W G3. Since only
certain PCI-bridges and interrupt controllers are suppoerted by
the OS, I have to use those in the device-tree. MacOS 9 also
expects certain legacy hardware to be present (the via-cuda for
instance).
In general, I prefer to use virtual MOL hardware rather then emulated
real-world hardware since this is much more efficient (the MOL OS side
driver just makes "system calls" to MOL rather than accessing hardware
through PCI register).
The Mac OS X device tree has essentially been built from scratch. It
contains more virtual MOL hardware than the Mac OS 9 tree. Since OSX
is a much more open architecture, it is possible to write custom MOL
drivers for things like interrupt controllers so there is no need
to emulate any hardware at all.
> Or is it just a matter of emulating the
> kind of machine that you have Mol running on?
No, MOL is completely hardware independent (except that 601 based
CPUs are unsupported).
> Do you have scripts for cloning the device tree in OpenFirmware?
No, not in OpenFirmware. Under linux, a copy of the
device tree is available under /proc/device-tree so it is just a matter
of reformatting things into a format more suitable for MOL.
> The device tree should actually be hardcoded for all onboard devices
> and only expansion cards like PCI should be dynamically added.
Yes, this is essentially what MOL does. Only a few minor tweaks are
done to the device tree at startup (MOL supports three parallell
virtual network cards, but typically only a single one is used).
> In BeginAgain I've implemented a plugin
> system that allows to emulate PCI cards in a simple manner. I planned to
> do the Framebuffer output this way, but since OpenBIOS lacks a PCI
> driver and a framebuffer driver you get nothing but a black window that
> you can write to with lowlevel functions..
>
> If you don't disagree I'd like to move this discussion to
> openbios(a)lists.openbios.org in future.
Sure.
/Samuel
Hello,
I am a newbie in this subjet, and thus I do not know
if my question is really redundant, but is this
project also about PC's BIOS (e.g. American
Megatrends)?
How can I make something to change my BIOS? (after I
understand how PC works (deeply), and know how to
code)
Thank you.
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Hi Frank,
* Frank Alcantara <frank(a)thyamad.com> [031014 14:00]:
> I am a complete newbie in BIOS Area, I am starting this just now. So I
> guess the freebios is the best option to my embedded projects. Few day
> ago, I saw some posts about a Award bios source, this source should be
> very usefully for who is starting, there are this source available?
> Where can I find this? There are others bios sources available? I will
> starting in freebios studying all possible sources and posting all of my
> observations, please help me in this startup.
Award BIOS Source code was illegally published quite a long while ago,
but it is not advisable to use this for any purpose, since it is
Award/Phoenix's intellectual property.
See http://www.openbios.org/project/rules.html
Since most closed source software is never reviewed by a huge amount of
community people, I am deeply convinced that you can learn a lot more
about techniques, concepts and implementation from the free firmware
variants that are out there, namely LinuxBIOS, OpenBIOS, uboot, gbios,
Proll, Tiara. Find the URLs at http://www.openbios.org/docs/links.html
Stefan
Just to again cause some traffic on this list ;-)
If you, like myself, don't read slahdot, here's
what I just came across as a search result.
It is from end february, but I haven't seen an echo on this list, besides
a comment from eric ["boy is EFI a kludge!"] in august which I'm not sure
of whether it's related.
http://slashdot.org/articles/03/02/20/189208.shtml
"BIOS' Days Are Numbered"
Set your comment threshold to 5 and/or search for openfirmware !-]
It may be a good start to follow up on once we have something usable.
Torsten
Hi
I am a complete newbie in BIOS Area, I am starting this just now. So I
guess the freebios is the best option to my embedded projects. Few day
ago, I saw some posts about a Award bios source, this source should be
very usefully for who is starting, there are this source available?
Where can I find this? There are others bios sources available? I will
starting in freebios studying all possible sources and posting all of my
observations, please help me in this startup.
Please forgive my awful English and thanks in advance.
Frank Alcantara.
Thyamad Consultoria.
frank(a)thyamad.com
http://www.thyamad.com
Dear OpenBIOS community,
it's time for another update of BeginAgain, the OpenBIOS forth kernel,
and it does deserve version number 1.1
It is available from the OpenBIOS CVS in the directory "kernel/"
or at http://www.openbios.org/bin/kernel-1.1.tar.bz2
Changes since 1.0
-----------------
- some code optimizations speed BeginAgain up by an average of 20%,
loops are up to 300% faster.
- fixes, cleanups.. IO operations work now, compiling on BSD almost
works ;-)
- new plugin interface allows external plugins to emulate certain
hardware.
- A PCI plugin allows emulating PCI devices in the Linux/Unix version
of BeginAgain
- A QT plugin emulates a graphics card providing an 8bit framebuffer.
There's currently no fcode driver yet to drive this framebuffer, but
it can be accessed from forth.
Installation and usage
----------------------
The beginning of documentation is available at
http://www.openbios.org/development/kernel.html
Bug reports
-----------
Any trouble, bugs etc. should be reported to the openbios mailinglist
<openbios(a)lists.openbios.org>
Best regards,
Stefan
