Platform for the OPENBIOS question

[Lloyd Thomson]

Hi all

Maybe I missed it, but for the Open BIOS that is being discussed, is there a specific single board computer (SBC), motherboard, chipset (or ?) that the BIOS will be targeted on.

My understanding is that this will be an x86 board, and it sounds like it will be at least partly targeted toward the game industry. However, since my favorite language is actually solder, I am mostly curious. There are a lot of chipset options out there, and each one of these may have a different effect on the workings and architecture of the BIOS.

If this has not been discussed, you all may want to do so.

Incidentally, I would also recommend that you start with a monitor level input / output / short command structure. It really makes it easier to test code and eliminate problems  when you have a basic (NOT BASIC) set of commands that you can use to look at or change control registers and memory locations.

On new hardware projects, I also like to either get a serial port working first thing, or will hook up a small ASCII LCD panel to the system. That way I can see what is going on inside by using simple print statements, and can check to see that variables are what I expect, and that certain stages of the software are being executed.

Later

Lloyd Thomson
Sr. Design Engineer
One Stop Satellite Solutions
1805 University Cir
Ogden, UT 84408-1805
801 626 7272
[e-mail]
www.osss.com

"If we knew what we were doing, it wouldn't be called research, would it" Albert Einstein

[Mads Martin Jørgensen]

* Lloyd Thomson  [Aug 21. 2001 09:49]:
> Hi all
>
> Maybe I missed it, but for the Open BIOS that is being discussed, is
> there a specific single board computer (SBC), motherboard, chipset (or
> ?) that the BIOS will be targeted on.

I think we would eventually want drivers for a lot of different
constellations.
> My understanding is that this will be an x86 board, and it sounds like
> it will be at least partly targeted toward the game industry. However,
> since my favorite language is actually solder, I am mostly curious.
> There are a lot of chipset options out there, and each one of these
> may have a different effect on the workings and architecture of the
> BIOS.

No, AFAIK it will be targeted to be Open Firmware compliant, and
therefore working on different archs.

But I could be wrong,
Mads Martin

P.S Why is the reply-to: address different from the address mailed to?

[Stefan Reinauer]

* Mads Martin Jørgensen  [010821 19:04]:
> No, AFAIK it will be targeted to be Open Firmware compliant, and
> therefore working on different archs.

exactly. Goal is to have one flexible, small firmware that allows extensions
very easy and platform independant. Advantages are obvious: The whole boot
loader desaster could be solved as well as the fact that most pci cards don't
work on any system except intel compliant stuff, thus breaking PCI standard 2.x
for the existing cards it is pretty easy to write a small emulation layer
that gives them an open firmware compliant interface (for code examples look
at the regarding code in XFree86 or the milo bootloader for alpha axp)

Also, this firmware could be used in embedded systems as well as servers,
workstation, home pcs running the same base system but different interfaces
optimized to the needs of the concerned platforms while still not getting
into any compatibility problems.
> P.S Why is the reply-to: address different from the address mailed to?

elvis.informatik.uni-freiburg.de is the actual name of the machine running the
list, whereas freiburg.linux.de/www.freiburg.linux.de are aliases. Due to some
weird configuration of the machine (I am not allowed to chance it
unfortunately) the address is changed when sending the mail.
But maybe we can write to John Foster once again and try to cooperate on the
use of the domain openbios.org, which would resolve the whole problem.

Best regards 
      Stefan Reinauer

[Ronald G Minnich]

On Tue, 21 Aug 2001, Mads Martin Jørgensen wrote:
> > Maybe I missed it, but for the Open BIOS that is being discussed, is
> > there a specific single board computer (SBC), motherboard, chipset (or
> > ?) that the BIOS will be targeted on.
>
> I think we would eventually want drivers for a lot of different
> constellations.

yep, that's what we all want. But you're going to have to pick one to
start.

You might want to try the SiS 630E based mainboards, since both Tiara and
linuxbios run on those. So we understand the issues.
> No, AFAIK it will be targeted to be Open Firmware compliant, and
> therefore working on different archs.

that doesn't make any sense to me. the arch has nothing to do with open
firmware compliance.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Lloyd Thomson]

The responses to this question are the reasons I asked this question. (and
no, I still will have no time to help. My crystal ball says that my schedule
is going to get a lot worse before it even remotely starts to improve.
Sorry - guess I will have to lurk and suggest only). It seems that there is
a overall consensus on what the OPENBIOS will do, but I have yet to see
agreement on the type of platform the BIOS will be developed around.

I did go and look at the link to the IEEE information on OPENBIOS and to the
web page that this mail list is working with (just in case you have deleted
that email, try http://www.freiburg.linux.de/OpenBIOS/). To be honest I
didn't know these web pages were there before I asked the platform question.
However, on the mail list web page, in the portion that talks about
developing a BIOS, (http://www.freiburg.linux.de/OpenBIOS/dev/) there are
several steps mentioned at the beginning of the process involving choosing a
platform. These are very logical steps, and will be necessary for each of
you to follow.

I would like to make a suggestion. Find a good, qualified, motherboard,
maybe one that most of you already have, and the rest of you beg, borrow, or
buy that same motherboard.

If everyone has the same platform as a starting point, you eliminate a
massive amount of variables in the development cycle. Once the code is rock
solid on that platform, start porting it to other systems. Also, if everyone
has the same hardware, everyone can help each other with the problems that
will appear.

As most prople know, it is hard enough to get a single set of code to run on
one platform with one programmer writting the code. Adding multiple
programmers, different writing styles, and calling conventions will really
add confusion to the mix. Throw in a dozen motherboards or chipsets, and you
really get a Pandora Box.

I do realize that there are standards out there, and the IEEE web page
address's these. I also realize that as a bona fide lurker, and a preferred
hardware puke, I don't know everything there is to know about software
system design or high performance systems. However, after over ten years of
hardware / firmware development on small computer systems, I have learned
that the KISS (Keep It Simple Stupid) approach saves an infinite amount of
time.

I guess that what I am trying to do is stand back from the desired end
product, and define the beginning point for the project. Since I do not have
an emotional tie to the project (I think), I am just trying to lend a hand
in holding back on the enthusiasm (just a little) and at least making you
think out the entire process a little more.

All for now. Feel free to throw all the feathers you want my way, but go
easy with the rocks!!!

Lloyd

----- Original Message -----
From: "Ronald G Minnich" 
To: 
Sent: Tuesday, August 21, 2001 1:00 PM
Subject: Re: [OpenBIOS] Platform for the OPENBIOS question

On Tue, 21 Aug 2001, Mads Martin Jørgensen wrote:
> > Maybe I missed it, but for the Open BIOS that is being discussed, is
> > there a specific single board computer (SBC), motherboard, chipset (or
> > ?) that the BIOS will be targeted on.
>
> I think we would eventually want drivers for a lot of different
> constellations.

yep, that's what we all want. But you're going to have to pick one to
start.

You might want to try the SiS 630E based mainboards, since both Tiara and
linuxbios run on those. So we understand the issues.
> No, AFAIK it will be targeted to be Open Firmware compliant, and
> therefore working on different archs.

that doesn't make any sense to me. the arch has nothing to do with open
firmware compliance.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Arp Kruithof]

Lloyd wrote:
> I do realize that there are standards out there, and the IEEE web page
> address's these. I also realize that as a bona fide lurker, and a preferred
> hardware puke, I don't know everything there is to know about software
> system design or high performance systems. However, after over ten years of
> hardware / firmware development on small computer systems, I have learned
> that the KISS (Keep It Simple Stupid) approach saves an infinite amount of
> time.

And I totally agree

Well, I'm also basically a lurker ... all I ever really wanted to get 
involved in would be an Open Source Modular BIOS for PC-
compatibles so everyone could assemble the modules needed for 
the chips used on the mobo and 'update' the BIOS for all the old 
boxes mobo's out there that don't get any support from the factory 
any more (update as in BIOS Y2K bugs, support booting from CD 
etc etc also for oldish 486 and P5 style boxes serving as, well 
server of some sort).

Looking around the web I ran into this OpenBIOS thingy, was 
delighted at first and then started reading about all the 
OpemFirmware requirements FCode etc etc and got a glorious 
headache -- Certainly _NOT_ KISS ... I just want to do some 
chipset/mobo hacking to get something everyone can use for free 
running on as many systems as possible - we have free OSes for 
each and every machine but for the BIOS everything we can and 
can't do with our machines is still decided by a handfull of small 
companies charging money and not offering what we want.

The 'desire' to boot into a GUI at BIOS level seems cool but _does_ 
make things a whole lot more complicated (also not KISS) - I'd see 
it as an add-on on top of working beep-IO/serial-IO/text-IO init 
routines. When you start all that fancy talk about not wanting 
_any_ textual 'spam' from graphics card, SCSI adapter, 
MFM/RLL/IDE/EIDE HDD-adapter or whatever (aparently for some 
out there without a basic grasp of the well documented expansion 
ROM init sequences) you are really loosing me. What's so bad 
about the machine telling me one or two things about itself while 
booting (great help for troubleshooting a friend's PC that you don't 
know nothing about). The effort to try and get rid of these 
messages just isn't worth it .... and you very, very probably really 
don't want to mess with doing your own init of all Graphics / SCSI 
whatever other adapter card as 80% of the time you just won't get it 
done with simple chipset-used-on-the-adapter-datasheets.

Having said that ... if all you want (for starters) is that the spam 
don't apear ... that's easy for _anything_ that comes after the VGA-
init ... just take over / monitor all INT 10 funtionallity and don't 
output anything requested from subsequent expansion ROM init's 
(so don't mess with the actual init just 'handle' the display IO for 
them either by sending it to NULL or by doing it through you BIOS-
level GUI) - it's very unlikely the expansion ROM init routines of 
anything other than a display adapter itself would bypass INT10.

Even for the VGA-init there must be some dirty no-spam-hack 
possible without doing the graphics adapter init yourself -
maybe hooking the timer interrupt and checking for changes in the 
INT10 vectors or other display related BIOS-data to monitor 
progress of the VGA-Init and then blank the screen ASAP (you 
may get a short spam-flash) or maybe even set the debug flag,  
single step through the VGA-init and then monitor any direct 
memory IO in the display adapter memory range as well as INT10 
(as some adapters first neatly set up INT 10 and then use it 
themselfes to display their spam.... just some thougths ... but as I 
said _I_ don't think it's worth the effort - just let the spam roll by 
and then do your GUI thing (or not rather??)

Okay, now flame me for not playing along ;-)
Arp
[e-mail]
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Stefan Reinauer]

* Ronald G Minnich  [010821 21:00]:
> yep, that's what we all want. But you're going to have to pick one to
> start.
>
> You might want to try the SiS 630E based mainboards, since both Tiara and
> linuxbios run on those. So we understand the issues.

I thought about getting a new development machine at home pretty soon and
I saw that the Gigabyte GA-7DXR has dual bios functionality, but until
now I was not able to detect the second flash chip with /dev/bios :-(
(Has anyone specs for this?) This would probably make it a perfect test
machine since you can switch back and forth between the firmwares.
Otoh, it might be wiser not to use an almost bleeding edge chipset to do 
this on :)
> > No, AFAIK it will be targeted to be Open Firmware compliant, and
> > therefore working on different archs.
>
> that doesn't make any sense to me. the arch has nothing to do with open
> firmware compliance.

No, but as Open Firmware has a (for my taste) very clean concept and clear
defined handling of endianesses and register sizes including 64bit/32bit
compatibility, this should make it easier, once we have a working low level 
startup code.

BTW, does the DS10 you used for your tests have a socketed flash? We have two
here, but both have soldered SMD flash roms. Unfortunately, I did a mistake
when I was flashing LinuxBIOS the last time. As they only do in rom FSB,
there's no way out except calling compaq service.

Are there any sis 630 boards you can recommend? As LinuxBIOS supports loading
ELF images over network now, I'd like to stay away from using DOC parts.

I read your statement that sdram is not supported by linuxbios at the moment.
Is this (still) true? I have an old NMC (Enmic) board running an AMD K6-2
on an older Via Apollo (I think it's MVP3) chipset at home. But when I tried
to adopt the support for Via chipsets in linuxbios to that chipset (as far 
as I saw, most registers are the same on that one) the efforts only resulted
in a triple fault reboot from the CPU. Unfortunately this board only has
SDRAM slots. What is the exact problem with SDRAM (please forgive the stupid
manner of this question ;) )

Best regards
      Stefan

[Ronald G Minnich]

On Wed, 22 Aug 2001, Stefan Reinauer wrote:
> BTW, does the DS10 you used for your tests have a socketed flash? We have two
> here, but both have soldered SMD flash roms. Unfortunately, I did a mistake
> when I was flashing LinuxBIOS the last time. As they only do in rom FSB,
> there's no way out except calling compaq service.

it is soldered. You have to be really careful.

You did try flipping sw3 jp8? you should be able to recover. Where in
flash did you put linuxbios?
> Are there any sis 630 boards you can recommend? As LinuxBIOS supports loading
> ELF images over network now, I'd like to stay away from using DOC parts.

if you're going to use elfboot over the net, almost anything but ASUS
should work.
> I read your statement that sdram is not supported by linuxbios at the moment.

sdram was always supported. I must have said something wrong. It's just a
real mess to get right for different chipsets.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Stefan Reinauer]

* Ronald G Minnich  [010822 18:05]:
> it is soldered. You have to be really careful.
>
> You did try flipping sw3 jp8? you should be able to recover. Where in
> flash did you put linuxbios?

yes, unfortunately the board did not react in any way on the setting of sw3
jp8. it still came up with the linuxbios serial output. Stupid me assumed
that the flash is scanned for an elf image, without reading the code diligently
enough. Instead the code expected 2 linuxbioses in blocks 0 and 1, and the
kernels starting from block 2, so linuxbios stopped whith an illegal elf
header message. Seems I unlearned being careful a bit when i did all the flash
hot swapping for /dev/bios.
> > Are there any sis 630 boards you can recommend? As LinuxBIOS supports loading
> > ELF images over network now, I'd like to stay away from using DOC parts.
>
> if you're going to use elfboot over the net, almost anything but ASUS
> should work.

I found on the Linuxbios homepage that ASUS uses the wrong flash parts. Iirc
I flashed some bioses on asus boards using /dev/bios. Is the 440GX problem
still alife, too? If it helps, I could try to get that hardware supported by
/dev/bios since I want to develop the driver towards being a universal flasher
tool for Linux.
> sdram was always supported. I must have said something wrong. It's just a
> real mess to get right for different chipsets.

Maybe I got it wrong.. Then I'll try to work myself into the MVP3 specs again
and see how far I come.

Regards,
   Stefan

[Maciej W. Rozycki]

On Wed, 22 Aug 2001, Stefan Reinauer wrote:
> yes, unfortunately the board did not react in any way on the setting of sw3
> jp8. it still came up with the linuxbios serial output. Stupid me assumed
> that the flash is scanned for an elf image, without reading the code diligently
> enough. Instead the code expected 2 linuxbioses in blocks 0 and 1, and the
> kernels starting from block 2, so linuxbios stopped whith an illegal elf
> header message. Seems I unlearned being careful a bit when i did all the flash
> hot swapping for /dev/bios.

Does the DS10 have a SROM mini console as most (all?) Alpha systems from
Digital have?  If so you should be able to reinstall firmware from it. 
All you need is a serial terminal at 9600bps (IIRC).

[Stefan Reinauer]

* Maciej W. Rozycki  [010822 22:45]:
> Does the DS10 have a SROM mini console as most (all?) Alpha systems from
> Digital have?  If so you should be able to reinstall firmware from it. 
> All you need is a serial terminal at 9600bps (IIRC).

Yes.. it does. And I even think I read something about recovering flash
from srom, but the cable you need is some weird internal connector and 
I couldn't get hold of a cable for that one yet. Fortunately the machine
is partly alife again since compaq gave us an exchange board and took the
old one to there engineers

Best regards,
Stefan

[Maciej W. Rozycki]

On Wed, 22 Aug 2001, Stefan Reinauer wrote:
> > Does the DS10 have a SROM mini console as most (all?) Alpha systems from
> > Digital have?  If so you should be able to reinstall firmware from it. 
> > All you need is a serial terminal at 9600bps (IIRC).
>
> Yes.. it does. And I even think I read something about recovering flash
> from srom, but the cable you need is some weird internal connector and 
> I couldn't get hold of a cable for that one yet. Fortunately the machine
> is partly alife again since compaq gave us an exchange board and took the
> old one to there engineers

Hmm, it was possible to recover from a floppy (but not from network, for
example), IIRC.  I'll dig through my SROM user's manual...

[Ronald G Minnich]

On Thu, 23 Aug 2001, Maciej W. Rozycki wrote:
> Hmm, it was possible to recover from a floppy (but not from network, for
> example), IIRC.  I'll dig through my SROM user's manual...

it definitely is possible, since I fried flash here and the compaq guys
recovered it for me on-site.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Stefan Reinauer]

* Ronald G Minnich  [010823 17:20]:
> On Thu, 23 Aug 2001, Maciej W. Rozycki wrote:
> > Hmm, it was possible to recover from a floppy (but not from network, for
> > example), IIRC.  I'll dig through my SROM user's manual...
>
> it definitely is possible, since I fried flash here and the compaq guys
> recovered it for me on-site.

Uh.. depends on whom from compaq you get then probably... The engineer here
brought a new motherboard and took the old one to factory repair

Stefan

[Ronald G Minnich]

On Wed, 22 Aug 2001, Stefan Reinauer wrote:
> yes, unfortunately the board did not react in any way on the setting of sw3
> jp8. it still came up with the linuxbios serial output. Stupid me assumed
> that the flash is scanned for an elf image, without reading the code diligently
> enough. Instead the code expected 2 linuxbioses in blocks 0 and 1, and the
> kernels starting from block 2, so linuxbios stopped whith an illegal elf
> header message. Seems I unlearned being careful a bit when i did all the flash
> hot swapping for /dev/bios.

what I did is to leave the SRM image in place, and only have one linuxbios
to start.

There is still a way to recover even when you toast flash. I just don't
know what it is :-(

There is a keyboard sequence that lets you talk to the maintenance
processor. As it comes up try hitting ESC-ESC-rmc
> I found on the Linuxbios homepage that ASUS uses the wrong flash parts. Iirc
> I flashed some bioses on asus boards using /dev/bios. Is the 440GX problem
> still alife, too? If it helps, I could try to get that hardware supported by
> /dev/bios since I want to develop the driver towards being a universal flasher
> tool for Linux.

l440gx is fixed, I can now write L440gx flash! I just wrote random junk
into it yesterday.

The VIA chipsets are just plain hard. My code kind of works with one SDRAM
in on the 8601 and 69x chipset. I didn't have the time to figure them out
so I moved on. I am hoping VIA will get me some working code at some
point.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Stefan Reinauer]

Hi,
> what I did is to leave the SRM image in place, and only have one linuxbios
> to start.
>
> There is still a way to recover even when you toast flash. I just don't
> know what it is :-(
>
> There is a keyboard sequence that lets you talk to the maintenance
> processor. As it comes up try hitting ESC-ESC-rmc

Unfortunately in the remote management console there is no way to flash
the machine's firmware. (No documented one at least). The RMC was the 
only thing being alife after the flash attempt.
> The VIA chipsets are just plain hard. My code kind of works with one SDRAM
> in on the 8601 and 69x chipset. I didn't have the time to figure them out
> so I moved on. I am hoping VIA will get me some working code at some
> point.

So is it a good starting point to remove 2 of the 3 SDRAM Dimms until the whole
thing boots somehow?

Best regards,
  Stefan

[Ronald G Minnich]

On Wed, 22 Aug 2001, Stefan Reinauer wrote:
> So is it a good starting point to remove 2 of the 3 SDRAM Dimms until the whole
> thing boots somehow?

yes.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Lloyd Thomson]

----- Original Message -----
> From: "Mads Martin Jørgensen" 
> To: 
> Sent: Tuesday, August 21, 2001 11:04 AM
> Subject: Re: [OpenBIOS] Platform for the OPENBIOS question

<snip>
> P.S Why is the reply-to: address different from the address mailed to?

Perhaps I should answer this one as well.

I have several email accounts, and track them all from several places.

I am subscribed to this mail list under my personal email address, which is

[e-mail]

MMJ may have noticed that my signature on the email mentioned my work email
address

[e-mail]

and as mentioned before, the mail list address is

[e-mail]

I have a couple more throw-aways I could give you, but these wouldn't do
much good to get ahold of me!!!

I also admit that I tend to forget to select the correct mail account name
when I send out a new email.

If you want to get in touch with me using email, any of these accounts will
work. I just tend to use them for different purposes. Not that there is
really any need to do so that I can see right now. Just trying to remove a
small wrinkle in the record :<)

Lloyd Thomson
Sr. Design Engineer
One Stop Satellite Solutions
1805 University Cir
Ogden, UT 84408-1805
801 626 7272
[e-mail]
www.osss.com

"If we knew what we were doing, it wouldn't be called research, would it"
Albert Einstein

Lloyd Thomson
President
Bulldog Industries Inc.
1378 East 300 North
Layton, UT 84040
801 547-9719
[e-mail]

<snip>
Mads Martin Jørgensen, http://mmj.dk
"Why make things difficult, when it is possible to make them cryptic and
totally illogic, with just a little bit more effort."
                                -- A. P. J.

P.S. I LIKE THIS ONE!!!
LT

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Stefan Reinauer]

Hi,
> Maybe I missed it, but for the Open BIOS that is being discussed, 
> is there a specific single board computer (SBC), motherboard, chipset
> (or ?) that the BIOS will be targeted on.

OpenBIOS is meant to be a clean Open Source implementation of the IEEE 1275-94
specification for boot firmware. The most well known example for an
implementation of this standard is Sun's OpenBOOT or Apple's PowerPC firmware.
Now, this specification mostly deals with interfaces and APIs between 
device driver roms (PCI cards i.e.) and the firmware as well as an API for
a user interface and for operating system hooks.
The IEEE 1275-94 specs describes FCODE, a forth based byte code language that
allows option roms to be completely instruction set independant (CPU
independant) Biggest win is the fact that an expansion card with such a 
firmware will work with all machines with an IEEE-1275 compliant firmware
without any additional x86 emulation like on Alpha platforms.
In fact, not having an Open Firmware compliant ROM on a PCI adapter breaks
compliance to the PCI standard, which makes total sense.
Even though firmware on x86 machines is flawed by design and simply not
flexible enough for anything except booting DOS, you need a lot of dirty
hacks in boot loaders to get decent systems working (ever seen lilo or
milo sources?)
> My understanding is that this will be an x86 board, and it sounds like
> it will be at least partly targeted toward the game industry. However,
> since my favorite language is actually solder, I am mostly curious. 
> There are a lot of chipset options out there, and each one of these may
> have a different effect on the workings and architecture of the BIOS.

Chipset support can mostly be developed seperate from the base firmware system.
Adding support for a new "platform" requires setting up ram controller, caching
etc and initializing the machine so that the fcode evaluator can be started.
The real chipset components support (onb. VGA/USB/Keyb/serial/tuning...) is
implemented in platform independant fcode, which makes them run on any
machine having such a chipset, according to the IEEE-1275-94 spec, even
without the need to recompile it.
> Incidentally, I would also recommend that you start with a monitor level 
> input / output / short command structure. It really makes it easier to
> test code and eliminate problems  when you have a basic (NOT BASIC) set
> of commands that you can use to look at or change control registers and
> memory locations.

At the moment we're developing a C compiler with an FCode backend and an
FCode tokenizer, which will allow to easily work with the actual code.
The final fcode evaluator will be able to run the tokenizer itself, so 
it will be possible to debug drivers directly on the firmware console if
neccessary.
I thought about writing a backend to gcc which outputs the needed FCode, but
after following some politically/religious based discussion between the
people who wrote the Java Bytecode backend for gcc (which is pretty similar
to fcode) and RMS concerning the possibility to work around the GPL using
a bytecode backend for gcc, this seems not to be an option.
Second, I'd rather prefer not to use the suboptimal output that the gcc mid
level language RTL produces (at least it's pretty unusable for
stack machines as java bytecode or fcode is)
Since written in C, these tools can be included in the bios for direct
development (if they fit in the chip, which should be easily possible for
any 256K+ flash device).
> On new hardware projects, I also like to either get a serial port working
> first thing, or will hook up a small ASCII LCD panel to the system. That
> way I can see what is going on inside by using simple print statements,
> and can check to see that variables are what I expect, and that certain 
> stages of the software are being executed.

Low level serial output as well as port 80 diagnostics work at the moment,
allowing the most neccessary debug output.

For further information on these standards, don't hesitate to ask and please
check out the links in the link section of the openbios homepage at 
http://www.freiburg.linux.de/OpenBIOS/

Best regards,
     Stefan Reinauer

[Mads Martin Jørgensen]

* Stefan Reinauer  [Aug 21. 2001 10:44]:
> At the moment we're developing a C compiler with an FCode backend and an
> FCode tokenizer, which will allow to easily work with the actual code.
> The final fcode evaluator will be able to run the tokenizer itself, so 
> it will be possible to debug drivers directly on the firmware console if
> neccessary.
> I thought about writing a backend to gcc which outputs the needed FCode, but
> after following some politically/religious based discussion between the
> people who wrote the Java Bytecode backend for gcc (which is pretty similar
> to fcode) and RMS concerning the possibility to work around the GPL using
> a bytecode backend for gcc, this seems not to be an option.
> Second, I'd rather prefer not to use the suboptimal output that the gcc mid
> level language RTL produces (at least it's pretty unusable for
> stack machines as java bytecode or fcode is)

And--not to forget; gcc is a big hairy smelly beast with a tremendous
complexity.

[Ronald G Minnich]

On Tue, 21 Aug 2001, Stefan Reinauer wrote:
> In fact, not having an Open Firmware compliant ROM on a PCI adapter breaks
> compliance to the PCI standard, which makes total sense.

stefan, doesn't that make every vga card out there a violator? does any
good graphics hardware have fcode in the rom for init?
> At the moment we're developing a C compiler with an FCode backend and an
> FCode tokenizer, which will allow to easily work with the actual code.

If at any point you get something going we would like to see about linking
it in to linuxbios. If this works you will have more platforms to work
with.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Stefan Reinauer]

* Ronald G Minnich  [010821 21:03]:
> On Tue, 21 Aug 2001, Stefan Reinauer wrote:
> > In fact, not having an Open Firmware compliant ROM on a PCI adapter breaks
> > compliance to the PCI standard, which makes total sense.
>
> stefan, doesn't that make every vga card out there a violator? does any
> good graphics hardware have fcode in the rom for init?

As far as I understand the specs, yes, this is true. Depending on what you
consider good, maybe there are some cards - the Sun Ultra5/10 have PCI graphics
adaptors that contain such a code, so it should be possible to use these when
the basic API to OpenFirmware is working. I know that Adaptec has FCode 
Firmware on some of their scsi adaptors. I don't know how much these cards'
hardware differs from their PC equivalents. Eventually it is even possible
to reflash some of the PC cards with the Fcode firmware, but I don't know
about legal issues when doing this. Though, at least Adaptec had FCode updates
on their web page some time ago.
> If at any point you get something going we would like to see about linking
> it in to linuxbios. If this works you will have more platforms to work
> with.

Since you have far more experience with the early setup code, I think this
would be a very good symbiosis.

Best regards
      Stefan

[Martin Roth]

It doesn't look to me like the pci spec says that Open firmware is required.
> From the pci 2.2 spec:

6.3. PCI Expansion ROMs
The PCI specification provides a mechanism where devices can provide expansion RPM 
code that can be executed for device-specific initialization and, possibly, a system boot 
function...

6.3.1. PCI Expansion ROM Contents
PCI device expansion ROMs may contain code (executable or interpretive) for multiple 
processor architectures.....

This all says to me that you can provide one, multiple, or no roms in your pci adapter.

martin

On Wed, 22 Aug 2001 16:33:11 +0200, Stefan Reinauer wrote:
> Ronald G Minnich  [010821 21:03]:
> > On Tue, 21 Aug 2001, Stefan Reinauer wrote:
> > > In fact, not having an Open Firmware compliant ROM on a PCI adapter breaks
> > > compliance to the PCI standard, which makes total sense.
> >
> > stefan, doesn't that make every vga card out there a violator? does any
> > good graphics hardware have fcode in the rom for init?
>
> As far as I understand the specs, yes, this is true. Depending on what you
> consider good, maybe there are some cards - the Sun Ultra5/10 have PCI graphics
> adaptors that contain such a code, so it should be possible to use these when
> the basic API to OpenFirmware is working. I know that Adaptec has FCode 
> Firmware on some of their scsi adaptors. I don't know how much these cards'
> hardware differs from their PC equivalents. Eventually it is even possible
> to reflash some of the PC cards with the Fcode firmware, but I don't know
> about legal issues when doing this. Though, at least Adaptec had FCode updates
> on their web page some time ago.
> > If at any point you get something going we would like to see about linking
> > it in to linuxbios. If this works you will have more platforms to work
> > with.
>
> Since you have far more experience with the early setup code, I think this
> would be a very good symbiosis.
>
> Best regards
>      Stefan
>
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message

[Stefan Reinauer]

* Ronald G Minnich  [010821 21:03]:
> On Tue, 21 Aug 2001, Stefan Reinauer wrote:
> > In fact, not having an Open Firmware compliant ROM on a PCI adapter breaks
> > compliance to the PCI standard, which makes total sense.
>
> stefan, doesn't that make every vga card out there a violator? does any
> good graphics hardware have fcode in the rom for init?

My (up to now quite theoretical) idea to solve this was to have a small
int10 emulation. Scitech's free x86emu does this with very little code
(the base functionality is not even 10k of C code). Defining FCode words
for this and calling it from within a framebuffer driver wrapper should
not be too hard.

Best regards,
      Stefan

[Ronald G Minnich]

On Wed, 22 Aug 2001, Stefan Reinauer wrote:
> My (up to now quite theoretical) idea to solve this was to have a small
> int10 emulation. Scitech's free x86emu does this with very little code
> (the base functionality is not even 10k of C code). Defining FCode words
> for this and calling it from within a framebuffer driver wrapper should
> not be too hard.

won't help. The graphics hardware is totally non-working until you run the
expansion rom code. If there's no fcode then you have a problem.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message