From 7fee5f7114d9450bb7dc15b5bb9d9fa4880f9a25 Mon Sep 17 00:00:00 2001 From: Andre Richter Date: Tue, 30 Mar 2021 22:55:06 +0200 Subject: [PATCH] fix typo --- 15_virtual_mem_part3_precomputed_tables/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/15_virtual_mem_part3_precomputed_tables/README.md b/15_virtual_mem_part3_precomputed_tables/README.md index 8de51b1b..f83ff5b4 100644 --- a/15_virtual_mem_part3_precomputed_tables/README.md +++ b/15_virtual_mem_part3_precomputed_tables/README.md @@ -433,7 +433,7 @@ attractive either, because writing larger pieces of assembly is an error-prone a Fortunately, there is a third way. We are writing an embedded kernel, and therefore the execution environment is way more static and deterministic as compared to a general-purpose kernel that can be deployed on a wide variety of targets. Specifically, for the Raspberrypi, we exactly know the **load -address** of the kernel in advance, and we know about the capabilites of the `MMU`. So there is +address** of the kernel in advance, and we know about the capabilities of the `MMU`. So there is nothing stopping us from precomputing the kernel's translation tables ahead of time. A disadvantage of this approach is an increased binary size, but this is not a deal breaker in our