Intro / Overview | UEFI Dev (in C)
Вставка
- Опубліковано 4 лип 2024
- Intro, setup, and hello world program to start programming for x86_64 EFI applications.
We'll be writing a program to make GPT disk images with an EFI system partition and basic data partition, and an OS loader EFI application for an operating system bootloader.
Everything will follow official specifications and documentation for UEFI, ACPI, FAT32, etc. as much as possible.
Hopefully this will show that UEFI isn't mysterious or complex, and is actually nice to program for, assuming your machines support it.
I'll try to explain all code as I'm typing it up and reading the docs. Expect some long, boring videos unless I suddenly become really funny or great at editing.
UEFI dev playlist:
• UEFI Programming in C
Git Repo:
github.com/queso-fuego/uefi-dev
Repo state as of this video (with slight makefile changes):
git clone --recurse-submodules github.com/queso-fuego/uefi-dev
cd uefi-dev
git checkout 9f65a7b05543bc42c43a12baec3b5cb878cf4a37
Videos for the EFI application (BOOTX64.EFI) will update this repo, after the gpt disk image videos are done.
Notes:
- wchar_t and L"" string literals are not needed, and I don't like them much due to wide characters being 16 bit on windows and 32 bit on linux by default. UTF-16 can be used directly with C11 or later, with u"" string literals and char16_t from uchar.h. If you have errors with uchar.h or don't want to use it, you can use 'typedef uint_least16_t char16_t;' and cast string literals to (char16_t *)"" to get the C11+ standard UTF-16 type.
- You can of course write EFI applications in other languages, even assembly. The system table pointer is passed to an efi entry point in RDX (see UEFI 2.10 spec section 2.3.4.1). Calling conventions seem to follow Microsoft's x86_64 calling convention/abi.
I recommend flat assembler (fasm) for writing assembly: flatassembler.net/. It's small, fast, and has built-in PE file & EFI subsystem support!
- I may make an .iso creator program in the future as an alternative to the GPT hard disk image creator. The ISO9660 and El Torito specs are public and freely available, but look a lot more involved than GPT images which are only a couple structs & arrays for the MBR and GPT headers & tables.
Misc links:
en.wikipedia.org/wiki/UEFI
uefi.org/specifications
uefi.org/uefi
en.cppreference.com/w/c/strin...
www.unicode.org/faq/utf_bom.h...
gcc.gnu.org/onlinedocs/gcc/St... (look at included freestanding headers e.g. stdint.h)
en.wikipedia.org/wiki/Red_zon...
www.qemu.org/download/
github.com/tianocore/tianocor...
www.kraxel.org/repos/jenkins/...
www.7-zip.org/
nuwen.net/mingw.html
github.com/skeeto/w64devkit
github.com/queso-fuego/UEFI-G... (this will be rewritten in upcoming videos)
rufus.ie/en/
Alternatively, for C development on Windows:
www.mingw-w64.org/downloads/ (gcc/mingw)
releases.llvm.org/download.html (clang/LLVM)
www.msys2.org/
www.cygwin.com/
or WSL/WSL2
github.com/sainnhe/everforest (neovim colorscheme)
www.sumatrapdfreader.org/free... (fast/minimal pdf reader for windows)
Join the Community Discord: / discord
Next video(s):
- Starting a C program to create valid GPT hard disk images, including an EFI system partition with FAT32 filesystem, which will boot an EFI application in emulation and on real hardware.
Contact:
queso_fuego.srht.site/contact.html
- Let me know if there's anything specific you'd like to see!
Questions about setup/software/etc.?
Check the FAQ: queso_fuego.srht.site/about.html
Outline:
0:00 intro/overview
6:30 dev tools for linux & windows
27:47 example EFI application, BOOTX64.EFI
38:58 test on qemu
41:00 test on hardware (laptop)
42:51 wrapping up/coming up
Music credits:
Winter Night by Sakura Girl | / sakuragirl_official
Music promoted by www.chosic.com/free-music/all/
Creative Commons CC BY 3.0
creativecommons.org/licenses/...
#uefi #x86_64 #intro - Наука та технологія
The moment I want to program something that isn't a .js application, the number of clear and concise materials to people unfamiliar with that area drops off of a cliff. It's straight foreward no BS tutorials like this that keep programming moving forward.
Just as I've been searching high and low for modern UEFI dev tutorials, yours come along! Thanks for this, looking foward to this series :)
absolute work of art, love this series man
Thanks!
Jesus christ, thanks for writing all of those typedefs in the header file. I just wanted a quick overview of what all these things were and the renaming the built in types just made that quick and painless. Thanks again!
Glad to hear it!
I'm going to use what the UEFI spec has itself, which is all C-style typedefs and pseudocode, so hopefully that's simple and easy enough to look up later and compare if needed
I Get Back again, Actually I am seeing the video number 9, but I have to return to see again the videos, each time I understand more, thank you very much for this set of videos.
If you want more EFI check out the @ThatOSDev channel or his playlist here:
ua-cam.com/play/PLwH94sFU_ljPi2ClIcWIvuc1GdLT81uuH.html
It's been a great help and inspiration for my own developments
Thank you my friend. 👍
64 bit and uefi 🥳 yay!
Faaaantastic presentation!
Wow, thanks! Appreciate it
Followed your bios stuff with the bootgames. Looking forward to this
Some day I am going to learn all this stuff. At 51, I am sure I have tons of time to do that. Sigh. You are awesome.
Well, I've had some interest since later teenage years, but for programming, that started part time in college for a few classes for a few years, and I've had a full time programming/analyst job for the last 6 years. Right now it's been 6-8 years at most of off and on learning & programming, and half of that probably 20-30 hours/week, or less.
But I read and research a lot more nowadays, and try things out badly and stubbornly until they work, and then improve the design from there. If there's lower levels to try out, then dive into those too, until you can't go any where deeper or there isn't info to find. It's not efficient but teaches you a lot of how things are put together under the hood and different tradeoffs to make. Can also try to make things simpler than they are often are.
I usually don't understand anything unless I write it up myself and test it out, it doesn't stick in the brain and make sense until that point.
What I'm trying to say is that it is possible but it does depend on time commitment and interest. Knowledge compounds over time, and it gets easier and faster to pick up more things the more you do. If you're truly interested in something it will work out in the end.
uefi osdev? yay!
hey man
good to see someone doing actual os dev
almost all the os dev tutorials out there are just "use bios interrupts and do stuff" and i was so frustated
i tried going through uefi documentation but couldn't (time issue)
Thanks, I'm trying to give at least some context for things when used, and not "type this in" just because without any explanation.
The docs are a lot to go through, but thankfully you can mostly pick and choose what parts you need, they made it nice and modular in that way.
YT says 2 unavailable videos are hidden.
There's a couple videos in there set to private that will come out this week, I'm getting some final commits done today/tomorrow and wanted all those in before linking to them from the videos.
It's one of my goals for 3 months is to finish this series.
Yeah mine too... 😅
Keep finding stuff to add.
Haha, I recognize my TESTOS bat file for QEMU. 👍
The words of a dead man
@@joee-kp7qt I'm not dead, so I am not sure what you are talking about.
Just a heads up. The UEFI is a PE32+. Meaning you do NOT need a cross-compiler to make the actual EFI file itself. The Cross-Compiler can be used for the kernel however. Although I never did in my series. I never needed it. Although the Nuwem GCC version is the one I use, it's NOT a cross-compiler. So just giving you a heads on that. Cheers on the video my friend.
That's true, I should have explained that better. Mingw gcc makes PE files and isn't a cross compiler for windows. Linux gcc needs to be a cross compiler for PE executables since it makes ELF files by default. UEFI does support 32 bit PE32 and 64 bit PE32+, but I haven't messed with 32 bit.
If I'm wrong please correct, I'm going off of chapter 2 in the spec for 32 bit calling conventions
well chapter one does state PE32+ only, even for 32 bit. Okay, that makes sense then.
I've seen references to UEFI32 and microsoft has 32 bit header docs which have the EFI subsystem type 10, but I agree with you and will say it requires PE32+ to be safe. learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_optional_header32?redirectedfrom=MSDN
Going to assume it may have supported PE32 explicitly in the past and more recent versions assume full 64 bit executables for compatibility with both
You're awesome man I've been searching for this my whole life!. Could you also make a 64 bit os series compatible with this uefi tutorial please? (Because I've had no success with GRUB2 and no video mode and all so would really appreciate another os tutorial!) Thanks a lot!!
Yes, the end of the uefi videos will roll into 64 bit kernel/os programming. I wanted uefi to work as an OS bootloader, and it will have a graphics mode set from the graphics output protocol (GOP) and pass the framebuffer for that as input to an OS
@@QuesoFuego I can't thank you enough bro but thanks a lot dude!
so the uefi programming is not limited by just making bootloaders?
because im really interested in trying to make my own os from scratch, and with my architecture that would require a uefi bootloader.
but in your amazing playlist, i see you implemented simple graphics and cursor access
these shouldnt be related to OS functions? or it is just a more refined bootloader?
It's whatever interfaces or apis are available from the spec, and supported by your hardware, normally you'd use exitbootservices() to fully get control of memory and load a kernel or other program to end the bootloader portion, but that could lead into an OS or any other programming.
The graphics are writing pixel data to the GOP framebuffer, the cursor is drawing pixels for a cursor to that framebuffer depending on the data returned by the pointer protocol apis.
Uefi is meant more as a bootloader or BIOS replacement, but could technically be used for general programming or OS.
They aren't OS functions, they're implemented in firmware and uefi is a standard interface for that firmware
@@QuesoFuego The picture is clear now.
Watching your videos and reading the comment's section is always great! I've learned so much so far! This series is gold!
Fun fact: the slow frequency of video uploads/updates make me always anxious for the next episode. Please don't rush, take your time. Thanks man.
Are you going to add the old kernel to this?
I can't speak for him, but I have hinted to him that since his legacy OS is 32-Bit, and it's all based off of legacy code, that he might actually be better off writing the new OS from scratch. Not only could he take advantage of EFI directly without the legacy code, but he could even improve on his design. IMHO, he would be better off writing the 64-Bit kernel directly from the 64-Bit EFI. Older computers from the last 10 years can still use EFI, even if it's CMS ( compatibility mode ), which is still 64-Bit. Writing it from scratch would actually save him time and without the frustration of converting.
For 64 bit there has to be changes to the GDT, IDT, and paging setups, probably minor things other than that. UEFI would be replacing the pre-kernel setup, but I might try to get similar info from the ACPI tables and elsewhere for the 32 bit OS bootloader setup, and have it call the kernel with similar info. While there should be 32 bit UEFI support, I don't have any machines that use that, my older stuff only uses BIOS.
It would be easier to have 2 separate kernels, one for 32 bit and one for 64 bit, so I may do that. That's closer to what linux/BSDs do for supporting multiple architectures, they have i686 and x86_64 for example. Otherwise there'd be #ifdefs and other things getting in the way in a lot of places to have the same kernel support both at once.
@@QuesoFuego Yea, two different kernels could work.
EDIT : Now that I think about it, modular code could work. You have both 32 and 64 Kernels, and then everything is modular in design. It would just boil down to compiling it either 32 or 64 bit respectively. With that said though, I am looking forward to your 64-Bit version since that meets todays modern computers. This was definately a good question to ask by @lowos107.
Thanks for answering
why does this have only few views
Thumbnail isn't great, very niche topic, lack of SEO, UA-cam algorithm changes all the time, etc. etc.
what neovim theme are you using?
I think it's everforest? How did you move the line and column numbers to the left side of the status line though?
It is everforest, with the Todo color changed. The status line is at the bottom of my vimrc (or init.vim),
set statusline+=\ %l/%L:%c git.sr.ht/~queso_fuego/dot_files/tree/master/item/.vimrc
Thank you so much!@@QuesoFuego
whats your nvim color scheme?
github.com/sainnhe/everforest
but I changed the TODO and #includes colors after this git.sr.ht/~queso_fuego/dot_files/commit/e1602bf8be78af4d5a30aa0bd83f587a2d90233c
HAJIKWAI MWENDAWAZIMU WA UEFI. MWENDA UNIFIED POLE HAJIKWAI.