More docs

merge-requests/3/head
bzt 2 years ago
parent ca2d3be488
commit 6989513caf

@ -17,7 +17,7 @@ Kétféleképp tudod integrálni a projektedbe:
Statikus Függvénykönyvtárként
-----------------------------
Az `uefi` könyvtárban futtasd a következő parancsot
Azonos metódus, mint a gnu-efi-nél, nem igazán javasolt. Az `uefi` könyvtárban futtasd a következő parancsot
```sh
$ USE_GCC=1 make
```
@ -32,11 +32,11 @@ Ezzel összeszerkesztheted a programodat, de nem fogod tudni újrafordítani, é
maradsz.
Szigorúan véve csak a **crt0.o** és a **link.ld** fájlokra van szükség, ez elég ahhoz, hogy elindítsa és meghívja az alkalmazásod
"main()" eljárását. Viszont ahhoz, hogy a libc funkciókat (mint pl. memcmp, strcpy, malloc vagy fopen) is használhasd, linkelned
kell a **libuefi.a** fájllal.
"main()" eljárását. Viszont ahhoz, hogy a libc funkciókat (mint pl. memcmp, strcpy, malloc vagy fopen) használhasd, linkelned
kell a **libuefi.a** fájllal is.
Egyenlőre ez csak gcc-vel működik, mivel a Clang úgy van beállítva, hogy direktben PE fájlokat hoz létre, ezért nem tud statikus
ELF .a fájlokat generálni, sem linkelni velük.
Egyenlőre ez a metódus csak gcc-vel működik, mivel a Clang úgy van beállítva, hogy direktben PE fájlokat hoz létre, ezért nem tud
statikus ELF .a fájlokat generálni, sem linkelni velük.
Forrásként terjesztve
---------------------
@ -63,7 +63,7 @@ int main(int argc, char **argv)
```
Alapértelmezetten Clang + lld környezetet keres és állít be, ami direktben PE fájlt hoz létre konvertálás nélkül. Ha a `USE_GCC`
környezeti változó be van állítva, akkor a hoszt natív GNU gcc + ld használatával egy megosztott függvénykönyvtárat fordít, amit
aztán átkonvertál .efi fájllá.
aztán átkonvertál .efi fájllá, pont, mint ahogy a gnu-efi is csinálja.
### Elérhető Makefile opciók
@ -93,7 +93,8 @@ include uefi/Makefile
```
A fordítási környezet konfiguráló úgy lett kialakítva, hogy akárhány architektúrával elboldogul, azonban eddig csak
az `x86_64` crt0 lett alaposan letesztelve. Van egy `aarch64` crt0 is, de mivel nekem nincs ARM UEFI-s gépem, teszteletlen.
Elvileg kéne működnie.
Elvileg kéne működnie. Ha új architectúrára akarod portolni, akkor a setjmp struct-ot kell megadni az uefi.h-ban, valamint
csinálni neki egy crt0_X.c fájlt. Ennyi. Minden más platformfüggetlenül lett megírva.
### Elérhető konfigurációs opciók

@ -3,21 +3,21 @@ POSIX-UEFI
<blockquote>We hate that horrible and ugly UEFI API, we want the usual POSIX!</blockquote>
This is a very small build environment that helps you to develop for UEFI under Linux (and other POSIX systems). It was
greatly inspired by [gnu-efi](https://sourceforge.net/projects/gnu-efi) (big big kudos to those guys), but it is a lot
smaller, easier to integrate (works with LLVM Clang and GNU gcc both) and easier to use because it provides a POSIX like
API for your UEFI application.
------------------------------------------------------------------------------------------------------------------------
NOTE: a smartypants on reddit is worried that I'm supposedly "hiding something" because of the use of `-Wno-builtin-declaration-mismatch`
(gcc) and `-Wno-incompatible-library-redeclaration` (Clang) flags. **Here's my answer to you: I hide nothing**, that flag is only
needed because you can disable transparent UTF-8 convertion. You see, under the hood UEFI uses 16 bit characters, and for example
`strlen(wchar_t *str)` or `main(int argc, wchar_t *argv)` isn't eaxctly POSIX-standard, that's why there's a need for that flag.
needed because you can disable transparent UTF-8 conversion. You see, under the hood UEFI uses 16 bit characters, and for example
`strlen(wchar_t *str)` or `main(int argc, wchar_t *argv)` isn't exactly POSIX-standard, that's why there's a need for that flag.
You should know that had you have spent more time learning or just *reading this README* instead of falsely accusing others on reddit.
------------------------------------------------------------------------------------------------------------------------
This is a very small build environment that helps you to develop for UEFI under Linux (and other POSIX systems). It was
greatly inspired by [gnu-efi](https://sourceforge.net/projects/gnu-efi) (big big kudos to those guys), but it is a lot
smaller, easier to integrate (works with LLVM Clang and GNU gcc both) and easier to use because it provides a POSIX like
API for your UEFI application.
An UEFI environment consist of two parts: a firmware with GUID protocol interfaces and a user library. We cannot change
the former, but we can make the second friendlier. That's what POSIX-UEFI does for your application. It is a small API
wrapper library around the GUID protocols, not a fully blown POSIX compatible libc implementation.
@ -27,7 +27,7 @@ You have two options on how to integrate it into your project:
Distributing as Static Library
------------------------------
In the `uefi` directory, run
Same method as with gnu-efi, not really recommended. In the `uefi` directory, run
```sh
$ USE_GCC=1 make
```
@ -42,7 +42,7 @@ You can use this and link your application with it, but you won't be able to rec
the linking and converting.
Strictly speaking you'll only need **crt0.o** and **link.ld**, that will get you started and will call your application's
"main()", but to get libc functions like memcmp, strcpy, malloc or fopen, you'll have to link with **libuefi.a**.
"main()", but to get libc functions like memcmp, strcpy, malloc or fopen, you'll have to link with **libuefi.a** too.
For now this only works with gcc, because Clang is configured in a way to directly create PE files, so it cannot create
nor link with static ELF .a files.
@ -70,8 +70,8 @@ int main(int argc, char **argv)
return 0;
}
```
By default it uses Clang + lld, and PE is generated without conversion. If `USE_GCC` is set, then the host native's GNU gcc + ld
used to create a shared object and get converted into an .efi file.
By default it uses Clang + lld, and PE is generated directly without conversion. If `USE_GCC` is set, then the host native's
GNU gcc + ld is used to create a shared object and get converted into an .efi file, just like how gnu-efi does.
### Available Makefile Options
@ -101,7 +101,9 @@ include uefi/Makefile
```
The build environment configurator was created in a way that it can handle any number of architectures, however
only `x86_64` crt0 has been throughfully tested for now. There's an `aarch64` crt0 too, but since I don't have
an ARM UEFI board, it hasn't been tested on real machine. Should work though.
an ARM UEFI board, it hasn't been tested on real machine. Should work though. If you want to port it to another
architecture, all you need is a setjmp struct in uefi.h, and an appropriate crt_X.c file. That's it. Everything
else was coded in an architecture independent way.
### Available Configuration Options

Loading…
Cancel
Save