I've placed the schematics on my website at http://wiley246h122.roadrunner.nf.net:2080/openbios/ (yes, it's a static address) for the OpenBIOS development hardware. There is currently no documentation, but the circuit is, in a way, straightforward.
If anybody can check it over and verify if it's correct I will be forever in your debt.
For those who don't know, this is a single ISA card that allows dual-flash functionality, standard port 0x80 POST, enhanced OpenBIOS POST (to character LCD, actually human-readable!), and 5 general-purpose 8bit IO ports (for experimentation, education, and embedded designs).
Feel free to contact me on any issues here.
James Oakley jfunk@roadrunner.nf.net - To Unsubscribe: send mail to majordomo@freiburg.linux.de with "unsubscribe openbios" in the body of the message
James,
For a number of reasons, this circuit is not going to work. Among them:
1. You've hooked up IO Read and IO Write - this puts the Flash in the IO space, not the memory space. You need MEMRead and MEMWrite
2. On the actual hardware that I have seen out there, segment F000h is not sent to the ISA bus at all. In fact, most modern chipsets have a totally separate data bus for the flash and other peripherals - so you will never see any access to your boot board. We have used both techniques on boards that we have designed in the past.
3. Even if you find a board that decodes F000 to the ISA bus, you will now have bus contention between your board and the old standard flash on the motherboard. Not a problem if the flash is socketed, but many boards (some of ours, for example) have soldered flash, making this non-trivial as well.
Given these major issues, here are a couple of alternatives:
- You could build a small carrier board to plug into the flash socket on your motherboard which would hold 2 flash chips and some sort of decoder that will switch between them under software control.
- build support for boot-block flash into OpenBIOS.
Sorry for the bad news, but there are still options for some little hardware-hacking projects..
Regards, Chris
-----Original Message----- From: owner-openbios@elvis.informatik.uni-freiburg.de [mailto:owner-openbios@elvis.informatik.uni-freiburg.de]On Behalf Of James Oakley Sent: Monday, July 05, 1999 7:25 PM To: openbios@elvis.informatik.uni-freiburg.de Subject: [OpenBIOS] OpenBIOS POST, flash, and IO card site.
I've placed the schematics on my website at http://wiley246h122.roadrunner.nf.net:2080/openbios/ (yes, it's a static address) for the OpenBIOS development hardware. There is currently no documentation, but the circuit is, in a way, straightforward.
If anybody can check it over and verify if it's correct I will be forever in your debt.
For those who don't know, this is a single ISA card that allows dual-flash functionality, standard port 0x80 POST, enhanced OpenBIOS POST (to character LCD, actually human-readable!), and 5 general-purpose 8bit IO ports (for experimentation, education, and embedded designs).
Feel free to contact me on any issues here.
James Oakley jfunk@roadrunner.nf.net - To Unsubscribe: send mail to majordomo@freiburg.linux.de with "unsubscribe openbios" in the body of the message
- To Unsubscribe: send mail to majordomo@freiburg.linux.de with "unsubscribe openbios" in the body of the message
Chris Davis wrote:
- You've hooked up IO Read and IO Write - this puts the Flash in the
IO space, not the memory space. You need MEMRead and MEMWrite
Whoops, oversight on my part. I'll have to hook up MEMR/MEMW to the flash. I was kinda tired when I was drawing it up, IOR/IOW is used only for the POST and GPIO. Thanks for pointing that out.
- On the actual hardware that I have seen out there, segment F000h is
not sent to the ISA bus at all. In fact, most modern chipsets have a totally separate data bus for the flash and other peripherals - so you will never see any access to your boot board. We have used both techniques on boards that we have designed in the past.
This is a lack of documentation problem (I'll write some, I swear). You'll notice that the CE lines are connected to the flash switch. The flash switch is, in turn connected to the appropriate line from the flash socket to address the appropriate chip. That's why there is no address decoding circuitry.
- Even if you find a board that decodes F000 to the ISA bus, you will
now have bus contention between your board and the old standard flash on the motherboard. Not a problem if the flash is socketed, but many boards (some of ours, for example) have soldered flash, making this non-trivial as well.
This, I have thought of. If your flash is socketed, you only have to remove it, (and you can put it on the new board directly, so you only have to buy one and you don't need an EPROM programmer to put a backup BIOS on, yay). For the SMT flashes, I originally thought it would be best to avoid them as you could probably get a MB with socketed flash that has the chipset you're working on. However, this may not be the case all the time (personally, I think flash should always be socketed). If a board has SMT flash, it would be a matter of clipping the CE pin and wiring the signal to the flash switch, if the developer were confident enough.
- You could build a small carrier board to plug into the flash socket
on your motherboard which would hold 2 flash chips and some sort of decoder that will switch between them under software control.
That too, I have recently thought of. You could probably place two SMT chips on a board the size of a 28-pin DIP that would plug directly into the original socket (like those BASIC Stamps). Software control, however, requires I/O, which has to gotten from ISA, parallel, OpenBIOS card, etc..
- build support for boot-block flash into OpenBIOS.
IIRC, you can only overwrite a boot-block if you haul the chip out and use an EPROM programmer. Hmmm.. I wonder if boot-block operates the same from all of the BIOS companies.. We could simply be compatible with that.
Thanks for the input, it's appreciated.
James Oakley jfunk@roadrunner.nf.net - To Unsubscribe: send mail to majordomo@freiburg.linux.de with "unsubscribe openbios" in the body of the message