Comparison of x86 and ArmV6-M Boot/Reset Process

Question

Looking at the ARMv6-M Technical Reference Manual the reset/startup process is defined. Simplistically, it loads the SP from 0x00000000 and PC from 0x00000004.

For x86, I'm trying to find similar information. From a general Google search, I can see that simplistically the CPU first loads the BIOS which then loads a boot device and passes execution to it if the last two bytes are 0x55 and 0xAA. I have a number of questions related to this process:

1. I assume the reset vector of an x86 CPU will be directed towards BIOS code?
2. Where is the reset vector address of a x86 CPU documented? I can't seem to find it in Combined Volume Set of Intel® 64 and IA-32 Architectures Software Developer’s Manuals.
3. When I Google search x86 boot procedure, why is BIOS included and not simply the reset vector address like in ArmV6M given? I know it would be silly, but couldn't I theoretically create a microcontroller using an x86 CPU and not have a BIOS and just start executing from my code in ROM like in a typical ArmV6M microcontroller? Therefore, isn't the BIOS separate from x86 and just the name given to some code whose purpose is to collect connected hardware information? i.e. couldn't an Armv6M system have a BIOS as well? Therefore, aren't technologies like BIOS/UEFI and MBR/GPT not intrinsically related to x86, but are often present with x86 to facilitate the general purpose nature of many x86 computers? (so 0xAA55 is particular to x86 BIOSes?)

Answer 1

Processors are processors, architectures are designed by different folks, so no reason to assume any two work the same way.

Note that you are looking at the, let's say, non-normal ARM boot. The cortex-m uses a (traditional let's say) vector table. The full sized ARMs, ARMv1 through ARMv6 or 7-A use a table of INSTRUCTIONS, not addresses. Then the ARMv8 (cortex-a not m) has its own scheme (this is the 64 bit ARM a wholly new design from the prior). And then the cortex-ms as you have discovered, armv6m-8m.

If you go way back to the beginning it is clearly documented by Intel (search for iapx 88 book) that the CS is set to FFFFh and the instruction pointer 0000h. And that it starts executing code there (kinda like the full sized ARMs). And then from way back there is an interrupt vector table (I find it disturbing that someone marked up the digital version from bitsavers from Intel, vector is the correct term and/or not confusing nor in need of replacement) that I think starts at address zero. Now obviously both with arm and x86 having a single (or two, maybe three) hardware interrupts into the core/chip does not scale to today, so other solutions have evolved (well, more interrupts).

If you think about both architectures or any architecture (msp430 is similar to x86, there is a vector table near the top of memory space) you ideally need some non-volatile memory (rom/flash) and some ram (sram/dram usually need some sram to run code to initialize the dram controller). Depending on the rules of the architecture the board/chip designer needs to configure the address decoder to point some address space to non-volatile and some to ram. And the non-volatile has to at least cover where the chip/core boots.

In the case of arm the chip designer can strap different addresses within limits, I think on some older ones with a single strap you could choose a high or low start address (0x00000000 and 0xFFFF0000 or something like that, you can easily look it up). The cortex-ms rules are more rigid. Some architectures put the interrupt/exception solution in the rom address space with the reset and some have it far enough away to imply that it should be in ram. An MCU would usually want it in rom space but a general purpose in ram somewhere as the operating system will want to choose where interrupts go runtime as drivers get loaded, vs a bare-metal mcu solution that you want it all solved at compile time.

Note you might need to look at all the Intel docs, around the days of the 486 they separated the hardware and the software developers manual, the document above was back when it was one combined manual.

Now why do we not have pre-bios details? Or at least not talk about them. Good, bad, or otherwise, IBM and Intel and Microsoft set us on this path, Intel primarily. The PC clone thing still exists to this day, decades later, we still see many remnants of that from the BIOS and ways for plug in cards to work with the bios/boot to add stuff, etc. You can certainly buy an x86 processor and try to make your own board without using a stock bios, and just write your own boot from reset code.

But with today's x86 chips, good luck with that there is some tribal knowledge, that makes that quite difficult both from a hardware and software perspective. There are less than a handful of BIOS vendors, who have been doing this for decades as well. You decide you want to get into the motherboard business (very bad idea), you basically have to pay whatever price they ask, assuming you can find some one who can design the pcb and have it actually work too.

The BIOS as we call it (improper use of the name, but whatever, it is what we say) is on flash/rom and is the code the processor boots up running, its authors know these details (or they did and they just reuse that code long after the person who knew retired/died). Per that PC design a combination of motherboard and plug in card solutions for making a generic BIOS/EFI set of calls where the hardware vendor has hidden the details (read the first sector of your storage media, please do not make me have to have code for dozens/thousands of different solutions. Print some text characters on a screen buffer, please do not make me have to know how to write pixels on every possible video card) that at least gets you through a somewhat well known and evolved boot process to get you most of the way if not all the way into your operating system where today kernel drivers then detect and do actually have code for every (supported) different/incompatible hardware peripheral.

Looking around SO you will see countless folks trying to boot an x86 the way an operating system or bootloader would using bios/efi calls, known address/offset on some media, etc. But how that flash/rom code works is another story. It is most certainly documented. This is Intel after all (even with AMD), now if this is an NDA document or just one so rarely downloaded that it is hard to find. But it is documented. You might find info in a virtual machine/simulator, although I wonder if those have a bios or just barely enough of one to get the popular operating systems booted and/or they cheat.

Based on how history has gone, I would assume there is a high address if not something with a lot of ones in the msbits of the address, that the current x86 processors do their first fetches, and then it is up to board designers and software folks to take it from there.

End of the day all processors have to have a first fetch address solution and ideally interrupt/exception solution. Hardware folks have to setup their decoders to deal with that first fetch address and provide a way for the software developers to put that first instruction in that path. And you will not sell very many chips unless you document that for your target audience. Now for an MCU, the target audience is ideally tens/hundreds of thousands/millions of individual customers. For a modern x86, that list is relative small, software a handful of folks, hardware in the hundreds to thousands of customers. x86 and the pc standard if you will are really the way to go, apple deviated for a bit but likely in the near future they will stop using the x86 and stick with their new solution, leaving the x86 to the pc model.

1. Yes, what we call the BIOS (fancy bootloader with OS like features) does have the code that boots the processor, the flash that contains the first fetched instruction.

2. Keep looking. SO is not a google this for me site.

3. Absolutely. Any (general purpose) processor can have a bootloader that provides abstracted low level services to hide the details and provide a common interface. But for example an armv6m is likely going to be found in an MCU which does not have a need for supporting an infinite number of incompatible plug in products (outside usb, which is it's own nightmare), the target market for that core, and/or where you usually find it, it is in an MCU where the peripherals are known and resources are scarce and you ideally do not way layers of bloat, although folks are doing it today for some reason you do not even want an (RT)OS, just good old baremetal hardcoded software specifically for that chip.

   We know that Apple (and they were not the first) has a "PC" with a non-x86 in it that supports at least a short list of peripherals (video chips/cards, etc), but this is Apple the list is short, not singular, but short (per peripheral type). So it has been done, but things like PCIe were created by/for x86 based pcs, and there are still some pc-isms there that you may have to deal with (none of the cards I work on but I do not know how the bios things work today with video cards for example, I assume it simply evolved slowly from the first pc solution).

You are better off buying some old 8086 or 80186 parts and messing with those if you really feel the need. If you want to buy a current x86 chip, good luck with that. From watching the hardware folks do it, I would recommend an AMD rather than Intel, you will have a better chance. But will AMD talk to you as an individual with no big names behind you as customers and without a large enough annual consumption of chips? I do not know.

Is it technically possible to buy any generation of x86 processor put it on a board and write your own code and not use someone's BIOS, not using a BIOS of your own, absolutely. Every x86 board is technically that, processor, flash/rom, and first fetched instruction on that flash/rom. At that level, it is by definition bare metal code just like you see/write on an mcu.