TinyBIOS – A minimalist open-source BIOS project for fun(github.com)
github.com
TinyBIOS – A minimalist open-source BIOS project for fun
https://github.com/pwk4m1/TinyBIOS
30 comments
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 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!
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.
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.
Probing (especially analog) is common throughout all discrete components. Baud rates are negotiated, clock speeds probed, handshakes made, etc.
The idea that DDR4/5 analog probing is “black magic” makes me think of a software engineer who’s had their first go at a hardware TRM.
The idea that DDR4/5 analog probing is “black magic” makes me think of a software engineer who’s had their first go at a hardware TRM.
Wow, what a fantastic resource. Extremely detailed while being concise, with links to other great explanations in the same site. Bookmarked
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.
On AMD Zen and later that is true, but on Intel the BIOS is still responsible for DRAM init (done via Intel's FSP)
> which for modern DDR4 or DDR5 memory is a very complex and undocumented task
It’s most definitely documented; you simply don’t have access to said documents.
It’s most definitely documented; you simply don’t have access to said documents.
>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...
Some of them are up to DDR4 capabilities...
https://github.com/oprecomp/DDR4_controller
https://www.google.com/search?q=open+source+ddr4+ip+core
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.
Yes, that's true as of 2022...
But will that continue to remain true?
?
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...
Some of them are up to DDR4 capabilities...
https://github.com/oprecomp/DDR4_controller
https://www.google.com/search?q=open+source+ddr4+ip+core
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.
Yes, that's true as of 2022...
But will that continue to remain true?
?
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.
https://github.com/skiselev/8088_bios These are more targeted towards some specific hardware projects (Xi8088/Micro8088)
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)
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.
https://github.com/skiselev/8088_bios These are more targeted towards some specific hardware projects (Xi8088/Micro8088)
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)
Glabios is GPL3, although unfortunately based upon MASM (non-free and quite old-fashioned assembler).
The other two are sketchy and no license (i.e. unusable), respectively.
The other two are sketchy and no license (i.e. unusable), respectively.
IBM's documentation for the original PC includes its BIOS source code. Not sure if in its entirely, or a good portion thereof.
Checked sources just to see what assembler was used.
It uses NASM, my go-to assembler. A great choice.
It uses NASM, my go-to assembler. A great choice.
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.
"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.
A86 might as well be perfect, and I'd still not use it.
It is not Open Source.
It is not Open Source.
I’m quite sure the PC Engines alix2 uses TinyBIOS
maybe you thinking about https://en.wikipedia.org/wiki/Coreboot?
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.
The current APU boards use Coreboot[3]
[1] https://www.pcengines.ch/alix.htm
[2] https://www.pcengines.ch/tinybios.htm
[3] https://www.pcengines.ch/apu2.htm
The current APU boards use Coreboot[3]
[1] https://www.pcengines.ch/alix.htm
[2] https://www.pcengines.ch/tinybios.htm
[3] https://www.pcengines.ch/apu2.htm
Author here, there's indeed no relation at all between the projects apart from my unfortunate choice of name for my project.
Side question: what IDE/editor ASM developers use today?
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.
I favor KDE's kate as editor, nasm as assembler, gnu make as build system.
Not an ASM developer, but I know SASM (https://dman95.github.io/SASM/english.html) exists.