> > I've got a pascal-program called UniFLASH, really good. With a
> I'm interested, i just work on a Eprom programmen and that thing we'll
> be wellcome ;)
i sent the url to everybody. (www.bios.be)
Ciao,
Stephan [SpaceNet-Systems]
> > Booting with orig. Bios, switching to second chip, flashing
> > openBIOS, reboot. Testing, switching back to orig. Bios, reset.
> Excellent summary. Switching should be from the front panel of the
> computer.
Thanx. :)))
> > Why switching RW? RW is only interpreted by the Chip which has it's
> > CE-Pin enabled.
> Yes! thanks, I get it. The motherboard takes care of the other chip
> control pins. (but we should check datasheets just to make sure)
www.amd.com (there are sheets for the AMD flash-devices)
> Can someone give me a EEPROM part number please? (I don't have any
> motherboards (yet), and my computer belongs to the University and
> cannot be dismantled)
we aren't using EEPROMs, we are using Flash-memories (a small difference).
But anyway:
AM28F020, AM28F010 (2 popular AMD-flashs)
look at the page of uniFLASH i sent everybody. There is uniflash with a list
of supported
flashs and chipsets.
> > I've got a pascal-program called UniFLASH, really good. With a huge
> > database of chips and algorithms (including the
> > Chipset-programming!). If somebody is interested i can
> > give you the URL.
> Is it designed to use with a particular programmer? or for motherboard
> BIOS flashing? Would be a useful resource either way.
> Can I have a look at it?
I sent the URL to everybody.
(www.bios.be)
It's used to flash a bios onto the board, if u like INCLUDING the bootblock,
it's free, it's with sourcecode, it's not GPLed, you can do whatever you
like
the only thing the author wants is to credit him.
I can build a nice interface for uniflash and make it the
"openBIOS-flash-tool" :)))
Ciao,
Stephan [SpaceNet-Systems]
> You can add 440LX to that list of yours.
did it. :)
> You will manually switch the line to CE and RW of the existing bios
> chip and have another similar chip with switched control lines on a
> PCI card.
PCI? No, ISA-Bus.
The BIOS is connected to the ISA-Bus via a 74 245 (addressdecoder).
The ISA-Bus is connected to the PCI-Bus via the PCI/ISA-Bridge.
> The computer will initially be booted from the original BIOS and a
> program will be written to the new BIOS in the same way as a
> conventional BIOS upgrade is performed, by manipulating the CE and RW
> lines of both chips.
Booting with orig. Bios, switching to second chip, flashing openBIOS,
reboot.
Testing, switching back to orig. Bios, reset.
> Is my understanding correct?
> I realise that RW can be 2 pins, just different implementation.
Why switching RW? RW is only interpreted my the Chip which has it's CE-Pin
enabled.
(i think so)
> Also, I am good at figuring out IC datasheets. Which chips are most
> commonly used for flash BIOS?
I've got a pascal-program called UniFLASH, really good. With a huge database
of chips
and algorithms (including the Chipset-programming!). If somebody is
interested i can
give you the URL.
Ciao,
Stephan [SpaceNet-Systems]
I just came across an interesting feature on some new Gigabyte
motherboards (www.gigabyte.com.tw). They have dual flash ROMs on them.
One is a backup BIOS. Seems interesting.
Does anybody have one of these boards? It might be interesting to find
out how they're hooked up and how you switch to the second ROM.
James Oakley
jfunk(a)roadrunner.nf.net
Hi!
I wish everybody to quote back, so we can make a list of the most popular
chipsets used in our development-environment.
We can try to build interfaces for the most popular boards first.
Here are my Boards:
FIC VA503+ Via Apollo MVP3
FIC PT2200 Intel 430HX
FIC PT2006 Intel 430VX
FIC VB601 Intel 440BX
Noname Intel 430FX
I hope we can build a list that way.
Ciao,
Stephan [SpaceNet-Systems]
Proposed OpenBIOS Boot Specification
Pre-boot:
OpenBIOS performs the following steps:
* Switch the CPU to 32-bit protected mode.
* Detect the DRAM and set chipset registers accordingly.
* Enable devices on the Super I/O (floppy, COM ports, etc.)
* Scan the PCI bus and allocate requested resources.
* Look for known boot devices: floppy, IDE, ATAPI, various
SCSI cards, and anything else that might be bootable.
* Select one of these devices. Read the first sector into
memory and jump to it.
Some sort of setup utility will be added later, probably
similar to Sun's command-line boot PROMs. For now, all op-
tions will be set at compile time.
Boot Sector:
The boot sector begins execution with the CPU in 32-bit
protected mode, privilege level zero, interrupts disabled,
A20 gate on. The CS, DS, ES, and SS selectors all have base
address 0, limit 0xFFFFFFFF. All except CS are read/write.
EBX and EIP contain the base address of the boot sector.
Addresses below this belong to OpenBIOS. Do not modify them
as long as you need to use the OpenBIOS services.
ESP points to the top of DRAM, and your initial stack.
Services:
The service routines are accessed by loading AX with
the desired service and calling the Service Entry Point, at
0x000FFFE0.
* Read Sectors from Boot Device *
AX = 0x0000
EDX = Starting sector number
ECX = Sector count
ESI = Address to store the first sector read
Sectors are counted in a linear fashion, starting from
zero. Since each sector is 512 bytes, the OS kernel must
reside within the first two terabytes of the boot device.
OpenBIOS does not write to block devices. That must be
done from the OS kernel.
* Read Data from Console Device *
AX = 0x0100
ECX = Max number of bytes to read
ESI = Address to store incoming bytes
* Write Data to Console Device *
AX = 0x0101
ECX = Number of bytes to write
ESI = Address of data to write
The "console device" may be either a monitor and keyboard,
or a serial port. For now, consider it a dumb ASCII terminal,
although more capabilities might be added later.
What other services do we need?
Special addresses:
The OpenBIOS ROM image starts at 0xE0000 or 0xF0000 depen-
ding on the hardware. It might be copied into shadow RAM. The
following addresses are defined; all others are reserved:
0x000FFF80 The BIOS ID string, up to 96 bytes long. The first
eight bytes must be "OpenBIOS", so that LILO will
know which boot loader to install. The string also
contains the version number, motherboard name, and
a list of features supported by this BIOS.
0x000FFFE0 Service Entry Point
0x000FFFF0 CPU Reset Vector
Basic Techniques:
For the last 2.5 years, I've worked at Unicore Software,
building custom versions of Award BIOS and (the nearly defunct)
MR BIOS. Here are the basics:
You need one computer for building BIOSes and another for
testing them. It's nice if they have separate monitors and
keyboards.
I use a $500 ROM emulator, connected to my workstation
by a serial cable. A cheaper alternative would be to insert
a ZIF socket between the ROM chip and the motherboard. Boot
up with the "good chip", swap in the "test chip" (after the
good chip has copied itself to shadow RAM), flash your code
onto the test chip, and reboot.
If your test motherboard has one of those wafer-thin PSOP
flash chips with microscopic pins, forget it. Intel loves to
make flash-proof motherboards, and then code the BIOS to reject
any non-Intel CPU.
You will need some sort of debugging output long before
you figure out how to turn on the the video card.
I use three ISA postcards displaying I/O writes to ports
80h, 84h, and 300h. Unicore has stopped selling these cards,
so these few leftovers are very precious to me. They bear the
inscription "ORCHID UNIO993 REV B". If they can't be bought,
I'll write up a design spec and post it.
One possibility I haven't explored is sending debug data
out the serial port.
Overall Strategy:
Buy one of the new "Super 7" motherboards with the VIA
Apollo chipset and a socketed flash chip. For starters, hard-
code the Super I/O and PCI settings to match the original BIOS.
Write code to read (not write) a floppy disk, and write a sim-
ple boot sector to test it. Then do the same for IDE. In a
few weeks, depending on your programming skill, you'll have a
bootable (albeit highly un-portable) BIOS.
Linux should still work fine, with a few changes to the
boot loader. Don't tell me about booting DOS & Windows--I work
with 16-bit BIOS code every day and it is a *nightmare*. Linux
didn't get where it is today by cloning Windows, and we won't
get anywhere by imitating Award or Phoenix.
Dave Coffin 3/9/99
--
David Coffin Evening: 781-397-9932
967 Salem Street Daytime: 978-686-6468x341
Malden, MA 02148-4515 E-mail: dcoffin(a)shore.net
Has anyone on the list had experiance with Needhams PB-10 Prom programmer?
I am thinking about purchasing one for BIOS development so I am looking for
comments, good, bad, ugly....
Dave
PS.
For info:
http://www.needhams.com/home.htm
Greetings Folks -
I've been lurking on the list for a while, but there's been some call as to
how to get started doing PROM start-up code on an x86 so I figured I'd
pitch in what I've been doing, with the hope of getting some feedback from
others.
My situation: I'm designing an AMD ELAN SC-410 based embedded system, and
I want to write the firmware that will initialize the hardware and then
launch my application. The app code is a 32 bit protected mode widget that
makes no use of any operating system or BIOS calls. Thus my startup code
is just that: code to start the processor off, initialize the hardware,
switch to protected mode, and then run my app.
Here's my current coding flow. It is, I realize, somewhat crude, but it
works so far. It might get you started, and I'd love to hear feedback and
suggestions.
All my code is, as yet, being written in assembly. I'm using MASM to
assemble it, and specifying a .TINY memory model, so I end up with a .COM
file (which, although intended to be run by DOS at 1000:0100, is really a
relocatable binary.)
My memory device of choice is a 29F040B, which is a 512KB device (addressed
from 0x00000 to 0x7FFFF. I load the .COM file as a binary into my PROM
programmer buffer at location 0x70000. This maps, in the system memory
space, to 0xF0000. Then I hand edit the buffer, starting at address
0x7FFF0, where I put EA 00 00 00 F0. This is JMP F000:0000 at system
address FFFF0. At power-on, the CS:IP initializes to F000:FFF0 and
executes the JMP to the start of my .COM file. And off I go...
Right now I'm just fiddling with the hardware initialization, writing
diagnostic codes out to port 0x300 and watching for them on the ISA bus.
Anyway, I hope this might get some people started. If you have any
suggestions, I'd love to hear them.
Cheers!
Phil King
pking(a)netschools.net
At 05:00 PM 2/26/99 -500, you wrote:
>..... How do I use this stuff (all
>the way back at step one: plug in power supply) so we can "get
>some product out the door"? Is there anyone on the mailing list
>that can tell us what to do?
Welcome to the list. Sounds like you are pretty much in the same position
that I am. I have a pretty good background in Motherboard design, some
software design experience and no BIOS design experience. So I am working
on getting past square one, which is - how do I compile code and burn it
into a prom. I do have the prom programmer. I just need to figure out how
to get my Microsoft compiler to generate x86 code that can be put into an
EPROM. I have been told by a number of people that it can be done. As soon
as I learn how I will post it to the list.
Dave
