(Rather Late) Surprise: Intel has "PCI Expansion ROM OS" Implementation for Computer Cluster

For some reason I stumbled upon one of Intel's patent application: Cluster computing - nic based os provision WO 2012040606 A2. The patent application cited my BUILDING A ''KERNEL'' IN PCI EXPANSION ROM article as non-patent citation.

I had that thought back then, that some companies must've built (or will build) something usable out of the principle explained there. I'm actually rather surprised why it didn't happen earlier. Of course, we have etherboot and PXE-boot eons ago. However, there's no such complete OS, even though a very small one in PCI Expansion ROM. Well, perhaps one of the limitation is the cost of the ROM.

Anyway, the use case explained in the patent application is interesting nonetheless. Head over to the patent application to see more details. It's a good read ;)

Migrating AMIBIOS 1B Module Utilities Source Code to GitHub

A long time ago (read: 10+ years) I created some small, mostly BIOS-related, utilities and dumped the source code on the web. I even forgot that they're there in my website (https://sites.google.com/site/pinczakko/source-code). Fortunately, over time, some people come across those source code and found the source code useful for them. Some of them asked question or give suggestions. Therefore, I decided to gradually move the code over to GitHub and update the code as well, so that the code would still be compile-able with present day toolchain.

Some of the utilities are small utilities to parse, extract and modifies AMIBIOS8 1B (main) module--akin to original.tmp in (legacy) Award BIOS. You need to use AMI Module Management Tool (MMTool) to obtain the 1B module from AMI BIOS binary file.

The utilities source code are now in Github: https://github.com/pinczakko/AMIBIOS8_1B_Utils. The code is POSIX compliant. I haven't test it against Mingw-w64 cross compiler to produce Windows binary--I recall that I used mingw (32-bit) on Windows to write the code back then. The code compiled just fine in Arch Linux gcc toolchain as of July 2017. Therefore, the code can produce Linux/Unix executable just fine.

I don't really remember the exact time when I wrote the utilities. But, it was wrtitten in 2010 and used in one of my project(s) in that year for one of my client(s). Those projects requires AMIBIOS8 binary modification. That's the reason I wrote the utility.

For the time being, feel free to play with it and modify it. I plan to add support for cross compilation with Mingw-w64 later on. If you tested the code on real AMIBIOS8 binary, I'd like to know the result ;-).

Anyway, the code is GPL v2-licensed (kudos to Gabor Stefanik for reminding me to put proper licensing note).

Experimental PCI Expansion ROM "OS" Code Migrated to GitHub

The code for the experimental PCI Expansion ROM "OS" explained in the Building a "Kernel" in PCI Expansion ROM article is now in GitHub: https://github.com/pinczakko/PCI-Expansion-ROM-OS. I made some changes to make it compile-able in current version of Nasm and GCC. I've only tested the compilation in Arch Linux (x86-64). I'm not sure it will work in other Linux distros. Give it a try ;-). Quick skim over the resulting binary seems to indicate the result is OK. I'm going to check it with a disassembler later on. If anyone wants to help me with that, please do so and post your result in the comment section below. 

Many of you might be aware that the code has been modified into pure GCC-only code in the Low Cost Embedded x86 Teaching Tool article. I need to migrate that code as well. But, I'm quite sure it will require special GCC version to be able to emit the correct binary, akin to the one used by Coreboot. I'll post an update once I've updated that one as well. 

Anyway, it's rather surprising to me that using Nasm + GCC is more future-proof compared to using GCC alone. It shows that you can't be really sure about the future-proof-ness of the toolset you used for software development.

IBM OpenPower Firmware Source Code Brief Analysis

First post this year ;-)

I'm taking a detour to other hardware architecture here, despite this blog is focused on x86/x86-64. As for why, it's because I was working with IBM Power 5 machine for more than a year and I found it interesting. I'm not going to talk about Power 5 here though because it's a closed system, in terms of firmware. I'm here to talk about Power 8 and its successor.

The Power 8 architecture is the first incarnation of OpenPower hardware architecture. Luckily, the firmware source code for this platform is freely available in Github: https://github.com/open-power.

Now, let's look at how we might read the code:

• The most interesting part is the Initial Program Loader (IPL) firmware: https://github.com/open-power/hostboot. This is basically the equivalent of UEFI Platform Init (PI) code, or the bulk of the BIOS code in the old days--excluding the runtime code, such as power management and SMI handlers.
• The next interesting part is skiboot: https://github.com/open-power/skiboot. This looks like the equivalent of the non-PI part of UEFI because it provides the interface that the OS can call at runtime to communicate with the platform firmware. I might be wrong tough, but all code I skimmed over indicates that.
• Last but not least is petitboot: https://github.com/open-power/petitboot. This is basically an analog of GRUB or Systemd bootloader in x86/x86-64 Linux.

The important thing that's missing from the OpenPower Github is the Baseboard Management Controller (BMC) source code. I'm not sure why IBM doesn't standardize that part as well or at least provide a reference implementation. Perhaps, it's because IBM wants to provide a point for differentiation among its partners. Also, if we think about it, the BMC code is probably the most vulnerable point should some one wants to attack an OpenPower environment because it usually provides a remote access to manage the server even before it finished booting.

I'll update this post once I've read the IPL code in more detailed manner. Hint: if you want to read it as well, try starting with the linker script (*.ld) file.