I want to update the boot firmware used by an "ancient" ISA bus PC that I'm trying to reactivate. Kevin O'C. told me to use SeaBIOS, I need to use Coreboot. So, here I am.
FWIW, I'm a retired IBM mainframe system programmer, with more than 45 years of experience. Please be very gentle with me. What is "old hat" to me doesn't necessarily map onto x86 hardware.
The machine in question uses the 3 IC (386DX) version of VTI's "Topcat" chipset. From the day I acquired it, a 486-33DX has been in situ. Part of the reactivation scheme includes the installation of an already on hand IBM/Cyrix 3X clock multiplying 586 CPU. If I read the chipset reference (URL follows immediately) correctly, as much as 64 MB of RAM can be employed.
https://ia800603.us.archive.org/0/items/bitsavers_vtiVTITOPCTChipsetOct90_14...
I have several reasons for wanting to upgrade the firmware: a Y2K date handling flaw, PIO IDE (PATA) limited to 5nn MB (no LBA) plus no optical drive support, no support of the 586's performance features, and a possible inability to deal with 64 MB of RAM. If the chipset can do it, I want to do it. BTW, an Adaptec AHA1542 SCSI controller will handle the HDD, but full PATA capability, if needed, can't be bad.
No EEPROM here. (E)PROM burning will have to be done.
While Win 98 as the OS would not be disastrous, I BADLY want to use Linux. Candidate distros seem to be TinyCore and Gentoo. Gentoo has been done on similar hardware and that project's URL follows.
http://yeokhengmeng.com/2018/01/make-the-486-great-again/
TIA for your responses.
Eli D.
Hi Eli,
Dne 07. 11. 19 v 2:02 Eli Duttman napsal(a):
TIA for your responses.
I would suggest to check the original linuxbios project [1] archives as it started around 586 era CPUs. Closest match is perhaps "bifferboard" port [2] I did several years ago. The thing to watch was a problem that gcc wanted to emit to new instructions like "cpuid" or "cmov" you need to compile the coreboot with correct gcc options.
First of all the tricky or maybe not so tricky part is RAM bringup. You need either to use cache as RAM, or somehow quickly init the RAM in assembly startup so you can use C stuff from coreboot. The coreboot (used to) have a romcc compiler which uses general registers only + SSE, but you don't have the SSE in your CPU... Perhaps you will have to have your own bootblock with complete RAM bringup. The RAM init seems to be in the datasheet page 37, but this was always a pain to get right. Maybe on such old system it will be just easy as it was on biffer board. You can check initial biffer board check-in in [3].
Unfortunately I'm very busy so I can't help much, although I like the blast from the past idea.
Thanks, Rudolf
[1] https://review.coreboot.org/cgit/coreboot.git/tree/?h=coreboot-v1 [2] https://blogs.coreboot.org/blog/2012/01/17/bifferboard-porting/ [3] https://review.coreboot.org/cgit/coreboot.git/commit/?id=c9da0157c7b35bb7964...
Rudolf,
That you took time to respond to a NOOB, at all, is highly appreciated.
It's definitely C 101 time for me. I'm an assembly language programmer and COBOL is number 2. I've previously looked into C but (now unfortunately) developed a distaste for it, given its claims of "universality" and incompatability with COBOL's data structures. However, you definitely don't want to hear my gripes. XYZ for Dummies will be the starting point.
Would disassembling the contents of the installed BIOS ROM make sense? That code, obviously, gets RAM squared away. While unpleasant, I've dealt with machine language patches.
Eli D.
________________________________ From: Rudolf Marek r.marek@assembler.cz Sent: Thursday, November 7, 2019 5:19 PM To: Eli Duttman eduttman@hotmail.com; coreboot@coreboot.org coreboot@coreboot.org Subject: Re: [coreboot] Howdy!
Hi Eli,
Unfortunately I'm very busy so I can't help much, although I like the blast from the past idea.
Thanks, Rudolf
Hi!
You need either to use cache as RAM
On those very old processors and chipsets it's rather unlikely that you'll get cache as RAM working, since those are typically missing some rather essential functionality for that; mostly that they don't have MTRRs. Using romcc would probably be an option, but romcc romstage was dropped a few years ago, so that's not useful for porting the device to a current coreboot version. Using an old (pre romcc-romstage removal) coreboot version or even linuxbios (not to be confused with linuxboot) is probably your best bet here.
Regards Felix
Felix, Danke vielmals! The machine I'm currently using has Git installed. Can you or another member point me at what source I need to download?
A Google search, with linuxbios as the target, was not productive. I came across a nice slide presentation, but that said use cache as RAM.
Eli D.
________________________________ From: Felix Held felix-coreboot@felixheld.de Sent: Thursday, November 7, 2019 7:55 PM To: coreboot@coreboot.org coreboot@coreboot.org Subject: [coreboot] Re: Howdy!
Using an old (pre romcc-romstage removal) coreboot version or even linuxbios (not to be confused with linuxboot) is probably your best bet here.
Regards Felix
So, LinuxBIOS/coreboot v2 is just an older version of the current coreboot, so it's in the same repository as the current code, so git clone https://review.coreboot.org/coreboot.git gives you _all_ code, and git checkout 38cd29ebd7282333650cf11ed50c7f2fd4031e80 (a rather arbitrary version I picked) pushes the source tree back to 2009. "git log" allows you to browse the history to pick a commit to start from if this one isn't old enough.
While v2 already supported Cache as RAM, it also still supported lots of non-CAR platforms that we eventually retired from our tree.
Since you mentioned that the system is using an EPROM, what type is it? Maybe there's a way to emulate it: you'll have to go through quite some burn cycles before you get a bootable result, and that will cost a lot of time. Unless you're doing the project as an exercise in practical archeology, you only want to use tools contemporary to the device, you might want to look into newer tech that might be able to help you.
In any case, good luck on your project!
Am Fr., 8. Nov. 2019 um 05:08 Uhr schrieb Eli Duttman <eduttman@hotmail.com
:
Felix, Danke vielmals! The machine I'm currently using has Git installed. Can you or another member point me at what source I need to download?
A Google search, with linuxbios as the target, was not productive. I came across a nice slide presentation, but that said use cache as RAM.
Eli D.
*From:* Felix Held felix-coreboot@felixheld.de *Sent:* Thursday, November 7, 2019 7:55 PM *To:* coreboot@coreboot.org coreboot@coreboot.org *Subject:* [coreboot] Re: Howdy!
Using an old (pre romcc-romstage removal) coreboot version or even linuxbios (not to be confused with linuxboot) is probably your best bet here.
Regards Felix
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Thanksfor the pushes in the right direction. I'm probably in WAY over my head. Definitely not the LAs, ZAPs, CLCs ... that I'm familiar/comfortable with and that stuff has gone stale over the 2+ years, since retirement. In any event, I downloaded the Git archive.
It turns out that page 90 of the chipset PDF contains the requisite memory map info. The reference Felix previously supplied is for the 286/386SX (16 bit) version of the chipset. I'm dealing with the 3 IC, 386DX (32 bit), version. The machine has 8 sockets for 9 chip, 30 pin, SIMMs, which works out to a pair of 32 bit banks plus parity. Right now, 20 MB (4X 4 MB & 4X 1 MB "slugs) are present and getting to 32 MB is easy. Getting to 64 MB means using 4 16MB "slugs", in a single 32 bit bank, and that could be a "pipe dream".
Further "digging" into the PDF triggered a memory. IIRC, the OEM BIOS is QUADTEL.
I don't have a digital electronics bench. My bench, such as it is, is for analog stuff. If you Google my name, you will find I have a presence in the audio hobby.
Eli D.
Hi!
Since you mentioned that the system is using an EPROM, what type is it? Maybe there's a way to emulate it
If it's a parallel eeprom/nor flash, the memsim2 might be worth a look. Beware though that if the mainboard has +12V connected to the programming voltage pin or another unused pin of the socket, that'll fry the memsim2, so build a small adapter that doesn't connect those two pins, but connects the rest. There's also an open source tool to push the firmware image to the emulator; haven't tried the vendor tool.
Regards Felix
I may have caused some confusion, sorry. Until I check the machine, which is in storage, I'm not certain about what's on the board, other than it's definitely not an EEPROM. A write once/read many PROM would be my guess.
FWIW, I've previously used a burning service for EPROMs and plan on doing so again. My electronics bench is configured for things like the 12AX7/ECC83, not digital stuff.
I will move ahead, very slowly. The 32 MB RAM limitation I appear to be squarely up against rules any sort of useful Linux out. The OS will be Windows 98 (phooey!) and I already have DOS utilities, which can deal with the Y2K and 586 configuration matters. Autoexec.bat or (possibly) config.sys will run that code, before windoze thunks out of 16 bit real mode into 32 bit protected mode.
16 MB 30 pin SIMM "slugs" are available, but I can't even begin to guess if the chipset can be tweaked into working with them. It would seem the number of address lines hasn't changed, as 30 pins is 30 pins. The SIMMs are arranged in 2X 4 "slug" banks, with each SIMM making up 1 byte of any given 32 bit word.
Eli D.
________________________________ From: Felix Held felix-coreboot@felixheld.de Sent: Monday, November 11, 2019 2:29 AM To: Eli Duttman eduttman@hotmail.com Cc: coreboot@coreboot.org coreboot@coreboot.org Subject: Re: [coreboot] Re: Howdy!
Hi!
Since you mentioned that the system is using an EPROM, what type is it? Maybe there's a way to emulate it
If it's a parallel eeprom/nor flash, the memsim2 might be worth a look. Beware though that if the mainboard has +12V connected to the programming voltage pin or another unused pin of the socket, that'll fry the memsim2, so build a small adapter that doesn't connect those two pins, but connects the rest. There's also an open source tool to push the firmware image to the emulator; haven't tried the vendor tool.
Regards Felix
-- Felix Held c/o cyberkombinat23 Steinstraße 23 76133 Karlsruhe Germany
mail@felixheld.de
Ust-ID: DE301814366
I'm, perhaps, 1 micron closer to the objective. The 30 pin SIMM diagram (link follows immediately) tells the tale. https://allpinouts.org/pinouts/connectors/memory/dram-simm-30-pin/ It comes down to whether or not the chipset can drive the A11 line, at the appropriate times. A11 is connected only on 16 MB "slugs".
Ah, hardware "joys". As irritating as this stuff is to me, I think back to the IBM 360F30 I started on in Feb. 1972. That machine's microcode ROM required compressed air, in order to function correctly. I'm NOT joking. Look card read only storage (CROS) up.
Eli D.
-
Eli Duttman -
Felix Held -
Patrick Georgi -
Rudolf Marek