Added links to readmes

0F_executionlevel/OLVASSEL.md

@@ -4,7 +4,7 @@ Oktatóanyag 0F - Futási szintek
 Mielőtt rátérhetnénk a virtuális memóriára, beszélnünk kell a futási szintekről. Minden szintnek saját
 lapfordító tára van, emiatt életbevágó, hogy tudjuk, melyik szinten futunk éppen. Ezért ebben az oktatóanyagban
 megbizonyosodunk róla, hogy rendszerfelügyeleti szinten (supervisor) azaz EL1-en vagyunk-e. Qemu alatt a gép
-indulhat egyből EL1-en, az igazi Raspberry Pi vason azonban mindig virtualizációs szinten (hypervisor) azaz EL2-n
+indulhat egyből EL1-en, az igazi Raspberry Pi vason azonban általában virtualizációs szinten (hypervisor) azaz EL2-n
 ébredünk. Qemu alatt a szintváltást a "-d int" kapcsolóval debuggolhatjuk.
 
 ```sh
@@ -23,7 +23,7 @@ visszatérést hazudunk, hogy ténylegesen szintet váltsunk.
 
 FIGYELEM: a teljesség kedvéért hozzáadtam az EL3-at is az [Issue #6](https://github.com/bztsrc/raspi3-tutorial/issues/6)
 miatt, bár normális körülmények között a Raspberry EL2-n futtatja a kernel8.img-t. Bizonyos config.txt parancsokkal elérhető,
-hogy EL3-on induljon (köszönet btauro-nak az infóért).
+hogy EL3-on induljon (köszönet [@btauro](https://github.com/btauro)-nak az infóért).
 
 Main
 ----

0F_executionlevel/README.md

@@ -4,7 +4,7 @@ Tutorial 0F - Execution levels
 Before we can go on to virtual memory, we have to talk about execution levels. Each level has it's own
 memory translation tables, therefore it's cruital to know which one we are using. So in this tutorial we're
 make sure of it, we are at supervisor level, EL1. Qemu may start machine at EL1, but real Raspberry Pi hardware
-always boots at hypervisor level, EL2. Under qemu use "-d int" to debug the level change.
+normally boots at hypervisor level, EL2. Under qemu use "-d int" to debug the level change.
 
 ```sh
 $ qemu-system-aarch64 -M raspi3 -kernel kernel8.img -serial stdio -d int
@@ -21,7 +21,7 @@ the CPU we want AArch64 mode in EL1. Finally, we fake an exception return to cha
 
 NOTE: For completeness, I've added code for EL3 too because of [Issue #6](https://github.com/bztsrc/raspi3-tutorial/issues/6),
 although normally Raspberry runs kernel8.img in EL2. With some config.txt options, you can make it run in EL3 (thanks
-btauro for the info).
+[@btauro](https://github.com/btauro) for the info).
 
 Main
 ----

14_raspbootin64/OLVASSEL.md

@@ -9,7 +9,7 @@ A betöltőprogram egyik felét adja csak, a kernel fogadót, ami az RPi-n fut.
 megtalálható az eredeti forrásban [raspbootcom](https://github.com/mrvn/raspbootin/blob/master/raspbootcom/raspbootcom.cc) néven.
 Ha Windowsos gépekről is szeretnél kernelt küldeni, akkor javaslom inkább a John Cronin féle átiratot, a
 [raspbootin-server](https://github.com/jncronin/rpi-boot/blob/master/raspbootin-server.c)-t, ami natív Win32 API-t használ.
-Ezen kvül, @milanvidakovic volt olyan jó fej, hogy megosztotta az általa írt [Java-s verziót](https://github.com/bztsrc/raspi3-tutorial/files/1850345/Raspbootin64Client.zip).
+Ezen kvül, [@milanvidakovic](https://github.com/milanvidakovic) volt olyan jó fej, hogy megosztotta az általa írt [Java-s kernel küldő](https://github.com/milanvidakovic/Raspbootin64Client)t.
 
 Hogy az új kernelt ugyanoda tölthessük be, el kell mozdítanunk a kódunkat az útból. Ezt chain loading-nak hívják, amikor
 az első kód ugyanarra a címre tölti be a második kódot, ezért az utóbbi azt hiszi, a firmware töltötte be.

14_raspbootin64/README.md

@@ -9,7 +9,7 @@ I only provide one part of the loader, the kernel receiver, which runs on the RP
 part, the sender, which runs on your PC see the original [raspbootcom](https://github.com/mrvn/raspbootin/blob/master/raspbootcom/raspbootcom.cc) utility.
 If you want to send kernels from a Windows machine, I suggest to take a look at John Cronin's rewrite,
 [raspbootin-server](https://github.com/jncronin/rpi-boot/blob/master/raspbootin-server.c) which can be compiled for the Win32 API.
-Even more, @milanvidakovic was kind to share a [Java version](https://github.com/bztsrc/raspi3-tutorial/files/1850345/Raspbootin64Client.zip) with you.
+Even more, [@milanvidakovic](https://github.com/milanvidakovic) was kind to share a [Java version](https://github.com/milanvidakovic/Raspbootin64Client) of the kernel sender with you.
 
 In order to load the new kernel to the same address, we have to move ourself out of the way. It's called chain
 loading: one code loads the next code to the same position in memory, therefore the latter thinks it was loaded

OLVASSEL.md

@@ -78,7 +78,7 @@ fájl (vagy a második esetben az SD kártya képfájl) nevét. Végezetül az u
 emulált gép UART0-ját átirányítsuk a qemu-t futtató terminál be- és kimenetére, azaz hogy minden, a virtuális gépen
 soros vonalra küldött karater megjelenjen a terminálon, az ott leütött karaktereket pedig kiolvashassuk a vm-en. Ez
 csak az 5-ös oktatóanyagtól működik, mivel az UART1 alapból *nem* irányítódik át. Ehhez plusz paraméterekre van szükség,
-mint például `-chardev socket,host=localhost,port=1111,id=aux -serial chardev:aux` (köszönet godmar-nak az infóért).
+mint például `-chardev socket,host=localhost,port=1111,id=aux -serial chardev:aux` (köszönet [@godmar](https://github.com/godmar)-nak az infóért).
 
 **!!!FIGYELEM!!!** Qemu emulálása felületes, csak a legáltalánosabb perifériákat támogatja! **!!!FIGYELEM!!!**
 

README.md

@@ -78,7 +78,7 @@ case the SD card image) to be used. Finally the last argument redirects the emul
 of the terminal running qemu, so that everything sent to the serial line will be displayed, and every key typed in the
 terminal will be received by the vm. Only works with the tutorials 05 and above, as UART1 is *not* redirected by default.
 For that, you would have to add something like `-chardev socket,host=localhost,port=1111,id=aux -serial chardev:aux` (thanks
-godmar for the info).
+[@godmar](https://github.com/godmar) for the info).
 
 **!!!WARNING!!!** Qemu emulation is rudimentary, only the most common peripherals are emulated! **!!!WARNING!!!**