The x86 bios firmware is raw binary of 16-bit real mode machine code. Upon CPU reset, it starts executing at 0xffff0 address, which is 16 bytes below 1MiB. This address space is typically mapped to the ROM containing the BIOS.

This video showcases a few interesting things: qemu isa-debugcon device, qemu monitor, rizin editor (radare2 fork), and coreboot.

Related reading: https://wiki.gentoo.org/wiki/System_Initialization_of_Intel_x86_with_BIOS_Firmware

An intuitive analogy to memory barriers:

• two threads running on two cpu with their own L1 cache are like two person collaboratively editing files on their computer, connected to central file repo.
• on each person's own computer is a working copy (L1 cache) of the files (memory locations) that correspond to the the central repo (memory, or shared cache like L2)
• each person's computer randomly issue pull and push operations on the files (note that each file is push/pulled independently unlike git). the intuition captures the unpredictable nature of cache flushes and misses, where each cache line operates individually.
• when collaborating on a file, a person should manually pull on a file before editing. but that's of no use if the other person don't push after their write. but if both party collaborates, there will be no inconsistency.
• the pull operation is equivalent to a loadload fence, captured by acquire semantics. the push operation is equivalent to a storestore fence, captured by release semantics.
• the loadstore fence ensures the out-of-order execution doesn't happen around the barrier such that read always happens before the barrier and write always after the barrier. there is no simple version control analog, but both loadload and storestore implies the loadstore fence.
• the storeload fence ensures the write before the barrier always before reads after the barrier.

In addition to that, some of my own notes:

• relaxed semantics uses special cpu instructions (e.g. LOCK) to skip using non-shared caches (i.e. L1), this ensures all cores access to the same data.
• acqrel semantics uses three operations together: pull, change, push.
• seqcst semantics, on top of acqrel guarantee, ensures a total order of load and store. it can be implemented by cpu waiting for the pipeline to finish and flushing the caches before issuing future instructions. (my speculation)

A detailed description on the hardware architecture of Game Boy console.

A nice article on the exploration of a performance issue, which ultimately leads to the discovery of a bug in AMD CPU.

it's intended to dispel a few common myths and help regular people understand UEFI a bit better.

The article is a bit long, but it indeed contains a lot of information I actually wanted to know.

Kernel schedules to pid 0 on idle, which issues the "halt" instruction (x86) to cause the cpu to stop working. There is a "dynamic tick" technique that don't wake up cpu on a fixed period but rather can be programmed to wake up at some time. The technique is used on mobile processors.

A post by Julia Evan on ftrace - a feature in kernel to trace any kernel functions! trace-cmd is a command line tool that makes it easy to do so.

A searchable list of Linux x64 and x86 syscall numbers. Also shows the kernel source code where the syscall is defined, as well as the registers for each of the arguments.

A fasterthanlime video on injecting code to a foreign Windows processes.

Interesting article comparing x86 with other IA by Raymond C.

Also see: https://devblogs.microsoft.com/oldnewthing/20220418-00/?p=106489 (The x86 architecture is the weirdo, part 2)

Zero-dependency blink led as a demo on how to write embedded rust.

The author tuck a valid blank program with exit code 42 into a ELF file as small as possible. The exploration (and the exploitation) is quite fun and informative to read.

A lot of material into osdev, including booting, initialization, interrupt handling, syscall, etc.

This article taught me a lot on troubleshotting windows bluescreen problem, BIOS, ACPI, and how to reverse engineer firmwares.

An informative series about executable file formats.

<blockquote>The Adventures of OS: Making a RISC-V Operating System using Rust</blockquote>