Coreboot port for 486 motherboard (UM8881/6) | Hacker News Reader

Coreboot port for 486 motherboard (UM8881/6)

github.com

98 pointsrasz24 comments

It's neat to see how people have been able to collect and save all sorts of information about older chipsets which makes projects like this possible.

I've often wondered about how to re-solve certain problems now that we have decades of hindsight. For instance, your BIOS doesn't boot from CDs or from large disks. So what do we do? We make a disk image (vnd on BSD and whatever the equivalent on Linux make this so easy) and install an old fashioned BIOS boot block. We have a small 40 megabyte or so FAT-16 filesystem (FAT-32 wasn't a thing until 1996), on which we have a kernel, such as NetBSD because NetBSD can still run on 486 systems without fuss.

The kernel, once loaded, knows how to access large disks, CDs, or even mount a filesystem over NFS. We then use that system to disklabel / fdisk the rest of the disk, format an FFS filesystem and swap, and install our OS. Simple, right?

But how do we get this image on to an 80486 system? We really shouldn't lose to history the kinds of tools that let us boot from floppy. NetBSD still can, even though it takes something like six of them.

Since the i80486 has no management engine, running an open source BIOS would make it fully, 100% open. Interesting... Will my next email server be an i80486 system? It's worth considering.

>Since the i80486 has no management engine, running an open source BIOS would make it fully, 100% open.

Note there are fully open source RISC-V designs you can program into a FPGA that will yield higher performance than any 486 by orders of magnitude.

What's an example FPGA for this purpose?

This is one that you can use a fully open toolchain to build with: https://groupgets.com/products/orange-crab-85f-lattice-ecp5-...

Which you can build a RISCV core + linux for using: https://github.com/litex-hub/linux-on-litex-vexriscv

Goodness, this is cool! Do you have experience with this FPGA/toolchain? How long does it typically take to render something from Verilog to bitstream? E.g. a hello world adder v/s a risc v cpu?

I do! I’ve played around with it with this exact setup. It really depends on your processor, these toolchains really love a good mix of both high frequency and multi core. A hello world adder is less than a minute, a riscv core much much longer. A 16 core zen4/zen5 can compile the riscv core and linux in roughly 20 minutes? Compared to about an hour on a M1 Max macbook pro - It’s been awhile so I could be misremembering.

thanks, that's good to know!

I can vouch for ECP5, it is a good choice in terms of size and open source toolchain support (excellent, although non-aided by lattice).

can't you just have grub on PCI Option ROM or PXE from 66.104.*

> Will my next email server be an i80486 system? It's worth considering.

Nope. Anything crypto related (notably TLS transport) would not work or would be horrendously slow.

Have you tried it? ;)

TLS on a 33 MHz m68030 is passable. Since the i80486 should be closer in performance to the m68040, negotiation could take place inside of the timeout that many servers would have. In some ways it would be a good rate limiter since you'd likely only want to allow a single connection at a time.

Looking at the sizes and structure of the source alone, it is obvious that Coreboot is a product of the post-HLL average developoor, while in the 486 era BIOSes were exclusively written in very carefully optimised Asm. One naturally wonders what the latter could fit in the space of today's multiple-megabyte flash ROMs.

Not sure what hell let loose has to do with anything...

Maybe HLL stands for “High Level Language”?

Ah, of course. I have never seen that abbreviation before.

Funny. I searched the term and found Hell Let Loose. Glad it was clarified because I never would have figured it out on my own. Also, incredible game worth checking out.

> while in the 486 era BIOSes were exclusively written in very carefully optimised Asm

Nope; the change happened in the 386 era; by the 486 era most BIOSes would be (partially/mostly) written in a pretty uncarefully written "HLL". Even before I would argue against the "carefully optimized" ASM.

They were written in Asm up into the 2000s; at least AMI and Award were. Despite a lot of macro use, there was certainly an emphasis on keeping things as small as possible.

Contrast that with just shoving compiler output into the ROM image.

They had _some_ asm (you just can't avoid it), plus whatever historical crap they already had, but most definitely the immense majority of an Award BIOS of the 2000s is compiled C code (e.g. "new setup"). And done by "developoors" as much as it gets.

Do note that, even with compilers of the era, using HLL with care can result in having an _easier_ time managing codesize than some of the garbage written in assembly by random developers... specially as feature creep starts to set in, which by the 2000s was in full force.

Have you ever seen a USB stack (even for HID boot protocol) in assembly on a commercial BIOS?

Have you ever seen a USB stack (even for HID boot protocol) in assembly on a commercial BIOS?

Yes. On AMIBIOS 627.10 and Award v6.00 (both used into the early 21st century) the USB stack is 100% Asm, as is the rest of the BIOS.

I left that scene in the late 2000s but my understanding is that C didn't start showing up in BIOS until the UEFI era (Tianocore etc.).

There have been some leaks over the years of both "old-school" and "new-school" BIOSes, so these facts can be verified.

I will take a look, but right now I would be skeptical of any such "100% asm" "leak", considering how easy it is to get a lightly commented listing. My position is indefensible, so no point arguing though.

> C didn't start showing up in BIOS until the UEFI era (Tianocore etc.).

"Showing up" is an understatement, since Tianocore is almost all C. And we didn't switch from 100% asm to 99% c overnight.

I had a 486 with AMI WinBIOS [1]. It looks like a UEFI setup, just 20 years earlier. If they wrote all that in ASM, then I'm really impressed!

https://www.youtube.com/watch?v=2aHWtVJSctM

Yes, WinBIOS was 100% Asm.

It wouldn't fit in a 64K ROM otherwise, and even then it was compressed.

I am in awe of people who have the time for such projects!

Reply on news.ycombinator.com