The main task for any BIOS is to initialize the memory controller, which for modern DDR4 or DDR5 memory is a very complex and undocumented task, so it must be done usually by a binary firmware blob provided by Intel or AMD.
The usual operating systems might be able to initialize the peripherals, but they expect an already working memory and a memory map provided by the BIOS.
After a quick browsing through the sources, it seems that this project has not progressed so far yet, even if it probes for working memory and it may be able to use the cache memory as RAM on some CPU models (as all BIOSes must do, before the memory controller is initialized).
Under an emulator like QEMU, a BIOS can work even if it is not able to initialize a real memory controller, but on real bare-metal hardware that has to work.
The fact that DDR works at all is kinda black magic, every boot the memory controller does a training routine to understand the analog aspects of the specific ram and board in order to actually make it function at all.
https://www.systemverilog.io/ddr4-initialization-and-calibra...
Edit: Reading the article is really cool, I just searched it as a reference but it is very in depth!
A lot of wifi/other wireless analog devices go through analogous training procedures. Things like timing and delays are pretty important to these types of systems and you don't have a clock edge to synchronize against like you do in wired protocols like SPI (though I imagine DDR initialization does have pins used for this or similar).
Yeah, DDR does have a synchronous clock. One of the points of calibration is making sure the signals are actually sampled correctly wrt to the clock signal since the bit times are so short even small differences of trace length matter. The length matching is just to get it in the ballpark that can be corrected with per pin delays.
Ironically perhaps, at bit times like these it's easier to not have a clock signal and simply perform clock recovery like PCIe does, but that comes with higher latency for the interface.
These days in x86 SoCs, DRAM is normally initialized by other cores smaller like the ME and PSP before the main core which would run the bios come up. For instance, apparently oxide's code doesn't have to bring up DRAM despite being the first code to run on the main cores.
>The main task for any BIOS is to initialize the memory controller, which for modern DDR4 or DDR5 memory is a very complex and undocumented task, so it must be done usually by a binary firmware blob provided by Intel or AMD.
I don't question that binary blobs are distributed by Intel or AMD...
I also don't question that DDR5 memory is probably more complex (since it is newer, and newer technology is usually more complex) than DDR4, which is probably more complex than DDR3, etc., etc.
But, on a purely conceptual level, RAM is not all that complex... It's ridiculously simple. On a conceptual level, RAM is just a bunch of wires where most of those wires determine the address, some of those wires are for power, clock signal and ground, and some other of those wires move data back and forth to the CPU. Not complex at all!
The memory needs to be initialized? Well, maybe on startup it needs to be quickly calibrated/tested to make sure that a given RAM will work at a given frequency, but again, not rocket science!
If a memory controller requires a lot of complex initialization -- then maybe it isn't designed right?
A well-designed memory controller (if it were well designed) -- should abstract away details of what it does with the underlying memory such that it presents a single, simple, easy-to-understand, easy-to-initialize, unified, homogenous interface to memory.
In other words, no need for a lot of BIOS initialization code or black box binary blobs -- IF it is created correctly...
Somone doesn't like Intel or AMD black box binary blobs?
Well, people have (and I'm guessing more will, over time!) implemented their own memory controllers running on FPGA's...
But I'll let the statement "DDR5 memory is a very complex and undocumented task, so it must be done usually by a binary firmware blob provided by Intel or AMD." stand for now.
Does anyone have any recs to learn about what goes into a basic BIOS? The TinyBIOS source is super easy to read but I'm looking more for something like xv6 which is both fun to read and also pedagogic (a tall order I'm asking for free, I know ;)
There are at least three "real" 8086 BIOSes-- "real" as in they can work on actual hardware rather than just emulators-- available in source form, which might be worth examining.
https://www.phatcode.net/downloads.php?id=101 -- this is a respin of code that apparently originated in the 1980s in sketchy Taiwanese clones, so I think some of the docs are reverse engineered
http://glabios.org/ is an all-new-still-under-development project, but it works well enough for my hobby usage.
Obviously, being for a simple 8086 mrans they don't have some of the complex chipset config used in a modern PC, and even stuff like "hard disc support" is outsourced (for that, you might consider stuff like the XT-IDE Universal BIOS)
Sergey's XT BIOS does have a license. It is GPL3. There is no license file in the repo but each source file contains the copyright and license information.
A86 is a great minimalist assembler for 16-bit code. In the humble words of its author:
"A86 (with its 32-bit version A386) is the finest assembler available, at any cost under any terms, for the Intel 86-family of microprocessors (IBM-PC, compatibles, and not-so-compatibles)."
Actually, come to think of it, I'm not sure if a86.exe is a 16-bit binary or 32, so it might not run on modern Windows.
Most of the ALIX boards use something called TinyBIOS[1][2]. Browsing through the source tree from the pcengines site, it doesn't seem to share any relation with this project here.
Whatever they're comfortable with. There isn't really much IDE support for ASM, so it doesn't really matter what you pick as long as you can do dirty things with the build system. I tend to just use vscode.
