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.
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.
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.
You can use a Core 2 era processor, no need to fall back that long in the past.
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
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...
I am in awe of people who have the time for such projects!