From 63b45f687868af38d21930790f0d0e517b50b2e2 Mon Sep 17 00:00:00 2001
From: Wojtek Kosior <kwojtus@protonmail.com>
Date: Mon, 13 Jan 2020 13:08:38 +0100
Subject: shorten linking in Makefile

---
 src/arm/PL1/kernel/kernel.ld        | 27 +++++++++++++++++++++++++++
 src/arm/PL1/kernel/kernel_stage1.ld | 27 ---------------------------
 2 files changed, 27 insertions(+), 27 deletions(-)
 create mode 100644 src/arm/PL1/kernel/kernel.ld
 delete mode 100644 src/arm/PL1/kernel/kernel_stage1.ld

(limited to 'src/arm/PL1/kernel')

diff --git a/src/arm/PL1/kernel/kernel.ld b/src/arm/PL1/kernel/kernel.ld
new file mode 100644
index 0000000..3130634
--- /dev/null
+++ b/src/arm/PL1/kernel/kernel.ld
@@ -0,0 +1,27 @@
+ENTRY(_boot) /* defined in boot.S; qemu needs it to run elf file */
+
+/* Code starts at  0x8000 - that's where RPis in 32-bit mode load
+ * kernel at. My experiments do, however, show, that qemu emulating
+ * RPi2 loads the kernel at 0x10000! (took some pain to find out).
+ * rpi-open-firmware, on the other hand, loads kernel at 0x2000000!
+ * This is not really a problem, since:
+ *   1. We can use our bootloader to load the kernel at 0x8000
+ *   2. We've rewritten stage 1 of both bootloader and kernel in
+ *      careful assembly, so that they should work regardless of
+ *      where they are loaded.
+ *   3. In qemu, we can load kernel.elf instead of raw binary
+ *      (qemu will do the right thing then)
+ */
+
+SECTIONS
+{
+
+	. = 0x8000;
+
+	__start = .;
+	.kernel_stage1 :
+	{
+		KEEP(kernel_stage1.o)
+	}
+	__end = .;
+}
diff --git a/src/arm/PL1/kernel/kernel_stage1.ld b/src/arm/PL1/kernel/kernel_stage1.ld
deleted file mode 100644
index 3130634..0000000
--- a/src/arm/PL1/kernel/kernel_stage1.ld
+++ /dev/null
@@ -1,27 +0,0 @@
-ENTRY(_boot) /* defined in boot.S; qemu needs it to run elf file */
-
-/* Code starts at  0x8000 - that's where RPis in 32-bit mode load
- * kernel at. My experiments do, however, show, that qemu emulating
- * RPi2 loads the kernel at 0x10000! (took some pain to find out).
- * rpi-open-firmware, on the other hand, loads kernel at 0x2000000!
- * This is not really a problem, since:
- *   1. We can use our bootloader to load the kernel at 0x8000
- *   2. We've rewritten stage 1 of both bootloader and kernel in
- *      careful assembly, so that they should work regardless of
- *      where they are loaded.
- *   3. In qemu, we can load kernel.elf instead of raw binary
- *      (qemu will do the right thing then)
- */
-
-SECTIONS
-{
-
-	. = 0x8000;
-
-	__start = .;
-	.kernel_stage1 :
-	{
-		KEEP(kernel_stage1.o)
-	}
-	__end = .;
-}
-- 
cgit v1.2.3