From 22fc0181a349eaee5109619ed4d61380b3d34ef9 Mon Sep 17 00:00:00 2001
From: bzt <zoltan.baldaszti@gmail.com>
Date: Fri, 12 Jan 2018 19:50:41 +0100
Subject: [PATCH] Fixed typos

---
 02_multicorec/README.md      |   2 +-
 09_framebuffer/OLVASSEL.md   |   2 +-
 10_virtualmemory/kernel8.img | Bin 4152 -> 4152 bytes
 10_virtualmemory/start.S     |   2 +-
 README.md                    |   2 +-
 5 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/02_multicorec/README.md b/02_multicorec/README.md
index fe66b93a..67315da0 100644
--- a/02_multicorec/README.md
+++ b/02_multicorec/README.md
@@ -1,7 +1,7 @@
 Tutorial 02 - Multicore C
 =========================
 
-Now let's try something more complex, shall we? By complex I mean stop the CPU cures just like in the first tutorial,
+Now let's try something more complex, shall we? By complex I mean stop the CPU cores just like in the first tutorial,
 but this time stop one of them from C!
 
 Start
diff --git a/09_framebuffer/OLVASSEL.md b/09_framebuffer/OLVASSEL.md
index 139ca69a..55e3273f 100644
--- a/09_framebuffer/OLVASSEL.md
+++ b/09_framebuffer/OLVASSEL.md
@@ -1,7 +1,7 @@
 Oktatóanyag 09 - Framebuffer
 ============================
 
-Rendben, végre valami csicsa-picsa :-) Eddig a képernyő sötét volt. Most be fogjuk állítani a felbontását
+Rendben, végre valami parasztvakítás :-) Eddig a képernyő sötét volt. Most be fogjuk állítani a felbontását
 egy csomó parancsot tartalmazó üzenettel és egyetlen egy mbox_call hívással, majd kirakunk egy képet. Teleraktam
 kommenttel az lfb.c forrást (igaz, angol nyelvűek), hogy segítsenek eligazodni a parancsokban. De végeredményben
 nem tesz mást, mint feltölt egy int tömböt és meghívja az mbox_call-t, igazán egyszerű. Ha gondolod, megpróbálhatsz
diff --git a/10_virtualmemory/kernel8.img b/10_virtualmemory/kernel8.img
index f49d53a4c9877396283f112a8dc279769d3a6893..0202f5303ac7670ca6a6586e2e513f8f647cd436 100755
GIT binary patch
delta 12
Tcmdm?utQ-&03*}Jz~}q`9<T(A

delta 12
Tcmdm?utQ-&03+kZz~}q`9;*b4

diff --git a/10_virtualmemory/start.S b/10_virtualmemory/start.S
index c6495a8b..142f2285 100644
--- a/10_virtualmemory/start.S
+++ b/10_virtualmemory/start.S
@@ -57,7 +57,7 @@ _start:
     mrs     x0, hcr_el2
     mov     x2, #0x0800
     movk    x2, #0x30d0, lsl #16
-    msr     sctlr_el1, x1
+    msr     sctlr_el1, x2
     // change execution level to EL1
     mov     x2, #0x3c4
     msr     spsr_el2, x2
diff --git a/README.md b/README.md
index b2235c5a..84d8a38f 100644
--- a/README.md
+++ b/README.md
@@ -101,7 +101,7 @@ Similarily, all peripherals communicates in memory with the CPU. Each has it's d
 0x3F000000, but it's not in real RAM (called Memory Mapped IO). Now there's no mailbox for peripherals, instead each
 device has it's own protocol. What's common for these devices that their memory must be read and written in 32 bit
 units at 4 bytes aligned addresses (so called words), and each has control/status and data words. Unfortunately
-Broadcom (the manucafturer of the SoC chip) is legendary bad at documenting their products. The best we've got is the
+Broadcom (the manufacturer of the SoC chip) is legendary bad at documenting their products. The best we've got is the
 BCM2835 documentation, which is close enough.
 
 There's also a Memory Management Unit in the CPU which allows creating virtual address spaces. This can be programmed