How do you run a program all by itself without an operating system running? Can you create assembly programs that the computer can load and run at startup, e.g. boot the computer from a flash drive and it runs the program that is on the cpu?
相关问题
- Why should we check WIFEXITED after wait in order
- Null-terminated string, opening file for reading
- What's the difference between 0 and dword 0?
- Linux kernel behaviour on heap overrun or stack ov
- Translate the following machine language code (0x2
相关文章
- What happens to dynamic allocated memory when call
- Is it possible to run 16 bit code in an operating
- How to generate assembly code with gcc that can be
- Select unique/deduplication in SSE/AVX
- Optimising this C (AVR) code
- Why does the latency of the sqrtsd instruction cha
- Difference in ABI between x86_64 Linux functions a
- x86 instruction encoding tables
You place your binary code to a place where processor looks for after rebooting (e.g. address 0 on ARM).
General answer to the question: it can be done. It's often reffered to as "bare metal programming". To read from flash drive, you want to know what's USB, and you want to have some driver to work with this USB. The program on this drive would also have to be in some particular format. On some particular filesystem... This is something that usually boot loaders do. Many ARM boards let you do some of those things. Some have boot loader to help you with basic setup.
Here you may find great tutorial of how to do basic operating system on Raspberry PI.
Edit: This article, and the whole wiki.osdev.org will anwer most of your questions http://wiki.osdev.org/Introduction
Also, if you don't want to experiment directly on hardware, you can run it as a virtual machine using hypervisors like qemu. See how to run "hello world" directly on virtualized ARM hardware here.
Runnable examples
Let's create and run some minuscule bare metal hello world programs that run without an OS on:
We will also try them out on the QEMU emulator as much as possible, as that is safer and more convenient for development. The QEMU tests have been on on an Ubuntu 18.04 host with the pre-packaged QEMU 2.11.1.
The code of all x86 examples below and more is present on this GitHub repo.
How to run the examples on x86 real hardware
Remember that running examples on real hardware can be dangerous, e.g. you could wipe your disk or brick the hardware by mistake: only do this on old machines that don't contain critical data! Or even better, use cheap semi-disposable devboards such as the Raspberry Pi, see the ARM example below.
For a typical x86 laptop, you have to do something like:
Burn the image to an USB stick (will destroy your data!):
plug the USB on a computer
turn it on
tell it to boot from the USB.
This means making the firmware pick USB before hard disk.
If that is not the default behavior of your machine, keep hitting Enter, F12, ESC or other such weird keys after power-on until you get a boot menu where you can select to boot from the USB.
It is often possible to configure the search order in those menus.
For example, on my T430 I see the following.
After turning on, this is when I have to press Enter to enter the boot menu:
Then, here I have to press F12 to select the USB as the boot device:
From there, I can select the USB as the boot device like this:
Alternatively, to change the boot order and choose the USB to have higher precedence, I would hit F1 on the "Startup Interrupt Menu" screen, and then navigate to:
Boot sector
On x86, the simplest and lowest level thing you can do is to create a Master Boot Sector (MBR), which is a type of boot sector, and then install it to a disk.
Here we create one with a single
printf
call:Outcome:
Note that even without doing anything, a few characters are already printed on the screen. Those are printed by the firmware, and serve to identify the system.
And on the T430 we just get a blank screen with a blinking cursor:
main.img
contains the following:\364
in octal ==0xf4
in hex: the encoding for ahlt
instruction, which tells the CPU to stop working.Therefore our program will not do anything: only start and stop.
We use octal because
\x
hex numbers are not specified by POSIX.We could obtain this encoding easily with:
which outputs:
but it is also documented on the Intel manual of course.
%509s
produce 509 spaces. Needed to fill in the file until byte 510.\125\252
in octal ==0x55
followed by0xaa
.These are 2 required magic bytes which must be bytes 511 and 512.
The BIOS goes through all our disks looking for bootable ones, and it only considers bootable those that have those two magic bytes.
If not present, the hardware will not treat this as a bootable disk.
If you are not a
printf
master, you can confirm the contents ofmain.img
with:which shows the expected:
where
20
is a space in ASCII.The BIOS firmware reads those 512 bytes from the disk, puts them into memory, and sets the PC to the first byte to start executing them.
Hello world boot sector
Now that we have made a minimal program, let's move to a hello world.
The obvious question is: how to do IO? A few options:
serial port. This is a very simple standardized protocol that sends and retrieves characters from a host terminal.
On desktops, it looks like this:
Source.
It is unfortunately not exposed on most modern laptops, but is the common way to go for development boards, see the ARM examples below.
This is really a shame, since such interfaces are really useful to debug the Linux kernel for example.
use debug features of chips. ARM calls theirs semihosting for example. On real hardware, it requires some extra hardware and software support, but on emulators it can be a free convenient option. Example.
Here we will do a BIOS example as it is simpler on x86. But note that it is not the most robust method.
main.S
GitHub upstream.
link.ld
Assemble and link with:
Outcome:
And on the T430:
Tested on: Lenovo Thinkpad T430, UEFI BIOS 1.16. Disk generated on an Ubuntu 18.04 host.
Besides the standard userland assembly instructions, we have:
.code16
: tells GAS to output 16-bit codecli
: disable software interrupts. Those could make the processor start running again after thehlt
int $0x10
: does a BIOS call. This is what prints the characters one by one.The important link flags are:
--oformat binary
: output raw binary assembly code, don't warp it inside an ELF file as is the case for regular userland executables.To better understand the linker script part, familiarize yourself with the relocation step of linking: What do linkers do?
Cooler x86 bare metal programs
Here are a few more complex bare metal setups that I've achieved:
Use C instead of assembly
Summary: use GRUB multiboot, which will solve a lot of annoying problems you never thought about. See the section below.
The main difficulty on x86 is that the BIOS only loads 512 bytes from the disk to memory, and you are likely to blow up those 512 bytes when using C!
To solve that, we can use a two-stage bootloader. This makes further BIOS calls, which load more bytes from the disk into memory, here is a minimal stage 2 assembly example from scratch using the int 0x13 BIOS call
Alternatively:
-kernel
option, which loads an entire ELF file into memory. Here is an ARM example I've created with that method.kernel7.img
, much like QEMU-kernel
does.For educational purposes only, here is a one stage minimal C example:
main.c
entry.S
linker.ld
run
C standard library
Things get more fun if you also want to use the C standard library however, since we don't have the Linux kernel, which implements much of the C standard library functionality through POSIX.
A few possibilities, without going to a full-blown OS like Linux, include:
Write your own. It's just a bunch of headers and C files in the end, right? Right??
Newlib
Detailed example at: https://electronics.stackexchange.com/questions/223929/c-standard-libraries-on-bare-metal/223931
Newlib implements all the boring non-OS specific things for you, e.g.
memcmp
,memcpy
, etc.Then, it provides some stubs for you to implement the syscalls that you need yourself.
For example, we can implement
exit()
on ARM through semihosting with:as shown at in this example.
For example, you could redirect
printf
to the UART or ARM systems, or implementexit()
with semihosting.embedded operating systems like FreeRTOS and Zephyr.
Such operating systems typically allows you to turn off pre-emptive scheduling, therefore giving you full control over the runtime of the program.
They can be seen as a sort of pre-implemented Newlib.
GNU GRUB Multiboot
Boot sectors are simple, but they are not very convenient:
It is for those reasons that GNU GRUB created a more convenient file format called multiboot.
Minimal working example: https://github.com/cirosantilli/x86-bare-metal-examples/tree/d217b180be4220a0b4a453f31275d38e697a99e0/multiboot/hello-world
I also use it on my GitHub examples repo to be able to easily run all examples on real hardware without burning the USB a million times.
QEMU outcome:
T430:
If you prepare your OS as a multiboot file, GRUB is then able to find it inside a regular filesystem.
This is what most distros do, putting OS images under
/boot
.Multiboot files are basically an ELF file with a special header. They are specified by GRUB at: https://www.gnu.org/software/grub/manual/multiboot/multiboot.html
You can turn a multiboot file into a bootable disk with
grub-mkrescue
.Firmware
In truth, your boot sector is not the first software that runs on the system's CPU.
What actually runs first is the so-called firmware, which is a software:
Well known firmwares include:
The firmware does things like:
loop over each hard disk, USB, network, etc. until you find something bootable.
When we run QEMU,
-hda
says thatmain.img
is a hard disk connected to the hardware, andhda
is the first one to be tried, and it is used.load the first 512 bytes to RAM memory address
0x7c00
, put the CPU's RIP there, and let it runshow things like the boot menu or BIOS print calls on the display
Firmware offers OS-like functionality on which most OS-es depend. E.g. a Python subset has been ported to run on BIOS / UEFI: https://www.youtube.com/watch?v=bYQ_lq5dcvM
It can be argued that firmwares are indistinguishable from OSes, and that firmware is the only "true" bare metal programming one can do.
As this CoreOS dev puts it:
Post BIOS initial state
Like many things in hardware, standardization is weak, and one of the things you should not rely on is the initial state of registers when your code starts running after BIOS.
So do yourself a favor and use some initialization code like the following: https://stackoverflow.com/a/32509555/895245
Registers like
%ds
and%es
have important side effects, so you should zero them out even if you are not using them explicitly.Note that some emulators are nicer than real hardware and give you a nice initial state. Then when you go run on real hardware, everything breaks.
El Torito
Format that can be burnt to CDs: https://en.wikipedia.org/wiki/El_Torito_%28CD-ROM_standard%29
It is also possible to produce a hybrid image that works on either ISO or USB. This is can be done with
grub-mkrescue
(example), and is also done by the Linux kernel onmake isoimage
usingisohybrid
.ARM
In ARM, the general ideas are the same.
There is no widely available semi-standardized pre-installed firmware like BIOS for use to use for the IO, so the two simplest types of IO that we can do are:
I have uploaded:
a few simple QEMU C + Newlib and raw assembly examples here on GitHub.
The prompt.c example for example takes input from your host terminal and gives back output all through the simulated UART:
See also: How to make bare metal ARM programs and run them on QEMU?
a fully automated Raspberry Pi blinker setup at: https://github.com/cirosantilli/raspberry-pi-bare-metal-blinker
See also: How to run a C program with no OS on the Raspberry Pi?
To "see" the LEDs on QEMU you have to compile QEMU from source with a debug flag: https://raspberrypi.stackexchange.com/questions/56373/is-it-possible-to-get-the-state-of-the-leds-and-gpios-in-a-qemu-emulation-like-t
Next, you should try a UART hello world. You can start from the blinker example, and replace the kernel with this one: https://github.com/dwelch67/raspberrypi/tree/bce377230c2cdd8ff1e40919fdedbc2533ef5a00/uart01
First get the UART working with Raspbian as I've explained at: https://raspberrypi.stackexchange.com/questions/38/prepare-for-ssh-without-a-screen/54394#54394 It will look something like this:
Make sure to use the right pins, or else you can burn your UART to USB converter, I've done it twice already by short circuiting ground and 5V...
Finally connect to the serial from the host with:
For the Raspberry Pi, we use a Micro SD card instead of an USB stick to contain our executable, for which you normally need an adapter to connect to your computer:
Don't forget to unlock the SD adapter as shown at: https://askubuntu.com/questions/213889/microsd-card-is-set-to-read-only-state-how-can-i-write-data-on-it/814585#814585
https://github.com/dwelch67/raspberrypi looks like the most popular bare metal Raspberry Pi tutorial available today.
Some differences from x86 include:
IO is done by writing to magic addresses directly, there is no
in
andout
instructions.This is called memory mapped IO.
for some real hardware, like the Raspberry Pi, you can add the firmware (BIOS) yourself to the disk image.
That is a good thing, as it makes updating that firmware more transparent.
Resources