larry.panzer(a)excel.net said:
> Could you post some more info on your i960 board, is it a custom
> design? It may make a good testbed platform on which to try the
> OpenBIOS, when the time arrives. It might make some sence to do a pro/
> con list of the different design techniques for this BIOS.
Well, OK. The card I refer to is the Picture Elements Imaging Subsystem
Engine (ISE). There is information about it on our web page. It may not
be of any real use to this list because they cost more then some cheaper
PCI motherboard. However, it does have lots of PCI stuff to fuss with
and has taught me the issues of BIOS management of PCI busses. Still
interested? Read on.
ISE is a full-size PCI card that has an i960RD on board. Internally, the
board has a PCI bus connected to the secondary bus side of the i960RD.
There is a DEC PCI-to-PCI bridge that adds another PCI bus.
The board has daughter card positions that are electrically PCI. The
daughter cards use typical interface chips (i.e. PLX PCI9080) to do
the bus manipulation. Therefore, the cards appear to software like
standard PCI devices.
I have written code for the i960 that does the job that the BIOS32 does
on a PC, namely it locates the PCI devices, probes their registers and
assigns interrupt numbers and address space. It is this little bit that
may be most interesting to this list.
I have also ported TCL 7.6 to this environment. I have given TCL access
to the PCI space by a "bios32" extension (load {} bios32) that adds
commands to read/write configuration space registers.
The software for the ISE board is fairly generic, and available for free
from our FTP site. <ftp://ftp.picturel.com/pub/source/ucr/> UCR Version 1.0
is sitting there now, I'll be making a 1.1 release (and updating the TCL
port) in a month or so. People are free to look at the PCI stuff to see
what I had to go through, and the code may be used under GPL terms.
(The TCL source has its own license that allows free use.)
Some portions of uCR are known to work under i386 with gcc, as I have
built and linked programs to run under Linux, using uCR in place of the
C library. This is for simulation purposes, but may provide a decent
test bed for embedded software.
Anyhow, there you go. In a month or so, things will settle down enough
that I can port uCR to i386/PC board if there is interest.
--
Steve Williams "The woods are lovely, dark and deep.
steve(a)icarus.com But I have promises to keep,
steve(a)picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com
OpenFirmware hurts! Don't go down this path. As a former Apple employee
where OF was law, it causes more problems than it solves. The Forth
derivation is baroque and tends to only bring back unmaintainable code
(you though asm could be bad?!? You ain't seen nothing yet!) Also
talking with Sun people (where OF originally began, though in a slightly
derivitive and sometime incompatible language known as OpenBoot) who code
it on regular basis, they hate the horribly restrictive environment and
the debugging facilities suck wind, but they are stuck with it.
Being able to initialize an OF card is okay, but doing a full OF
implementation on the host ROM side is a nightmare.
greg
>On Sat, 11 Apr 1998, David Freeman wrote:
>
>> Wouldn't that be an OpenFirmware clone? I know that most modern PPC
>> systems now use OpenFirmware, as well as newer SPARC systems. An
>> OpenFirmware clone would be cool...
>
>This isn't exactly what I thought of at first, but it sounds like the best
>thing to do now that I think about it. This would probably help out some
>people trying to run LinuxPPC on Winbloze-NT only Motorola PowerStack
>machines (You can flash a new bios onto them from a floppy, I believe)
>
>Maybe we can even add some cool features like control from an ethernet
>interface.. Have it look for a bootp server at boot, and then allow telnet
>configuration.. This would be *great* for setting up a cluster.. Take the
>machine out of the box, hook it up, and configure it without ever hooking
>up a monitor, keyboard, or inserting a floppy. There are some security
>issues with this though, but I think those can be dealt with.
>
>Something like my previous idea is possible with a fully open-source
>firware code.. What company would want to bother with something like that
>anyway? I personally think it would be very useful.
>
>> And it isn't exactly proprietary either, independent companies make
>> their own implementations of OpenFirmware, so I guess it would be
>> possible to get the specs, and write clone, eh?
>>
>> Troy Benjegerdes wrote:
>> >
>> > Does this list exist at all? I haven't seen any activity for about 2 weeks
>> > or something.
>> >
>> > Anyway, would anyone like to develop a GNU bios for PPC systems? I *might*
>> > be in a position to get all the needed specifications and actually get the
>> > developed *used* when it is stable.
>>
>
>----------------------------------------------------------------------------
>| Troy Benjegerdes | troybenj(a)iastate.edu | hozer(a)dodds.net |
>| Unix is user friendly... You just have to be friendly to it first. |
>| This message composed with 100% free software. http://www.linux.org |
>----------------------------------------------------------------------------
>
>
>---
>OpenBIOS -- http://www.linkscape.net/openbios/
>openbios-request(a)linkscape.net Body: un/subscribe
>Problems? dcinege(a)psychosis.com
>
>
---
OpenBIOS -- http://www.linkscape.net/openbios/
openbios-request(a)linkscape.net Body: un/subscribe
Problems? dcinege(a)psychosis.com