Loading a simple "kernel" at the address other than default on Raspberry Pi 4
Hi, I have written a simple kernel which prints Hello World to UART. The simple kernel works successfully and prints Hello World to UART, if I load it at 0x80000, which is the default load address for the 64-bit kernel. There's a configuration(config.txt)[1] kernel_address on Raspberry Pi 4 but whenever I change the load address by even 1 byte, the simple kernel would not run. It is only able to run at 0x80000. I tried to find the entry address of the standard kernel for raspberry pi[2]. I have trusted firmware-A[3] on my Raspberry Pi, which prints the load address before loading the standard kernel. Entry address for the standard kernel is always 0x200000! Even if I manually change the load address in the raspberry pi configuration, the standard kernel is always loaded at 0x200000!. How is the standard kernel being loaded at 0x200000, but my simple kernel cannot be loaded at any address except for the default address(0x80000)? [1] https://github.com/raspberrypi/documentation/blob/develop/documentation/asci... [2] https://github.com/raspberrypi/linux [3] https://www.trustedfirmware.org/projects/tf-a/
Disclaimer: I'm not an expert in ARM, I'm just trying to help because I've been (still am really) in the journey of writing a hobbist OS and know how small suggestions can help sometimes. On Tue, Nov 02, 2021 at 05:13:16PM +0500, Mushahid Hussain wrote:
There's a configuration(config.txt)[1] kernel_address on Raspberry Pi 4 but whenever I change the load address by even 1 byte, the simple kernel would not run. It is only able to run at 0x80000.
Most likely the stages (and code) that run in previous stages expect your code to be present precisely at this address. Hence, when you change the target address even by 1 byte it doesn't work. Remember that if the CPU reads something that causes it to throw an error/exception, it doesn't go to the next instruction. QEMU + GDB can be great allies when answering these types of questions. Something like this (I haven't tested it but this is a starting point): QEMU cmd: qemu-system-aarch64 -gdb tcp::8864 -drive format=raw,file=$(OUTPUT_RAW_DISK) \ -S -d guest_errors -d int -no-reboot -no-shutdown GDB cmd: gdb -ex 'target remote localhost:8864' \ -ex 'layout asm' \ -ex 'layout regs' \ -ex 'b *0x80000' \
How is the standard kernel being loaded at 0x200000, but my simple kernel cannot be loaded at any address except for the default address(0x80000)?
I'm not familiar with that firmware but again if I were you I would be debugging the standard kernel as well.
From my personal experience (I'm developing for x86-64), there were a couple of things that GRUB bootloader did out-of-the-box for the linux kernel to make its life easier that I had to write myself because I wanted to write the bootloader too.
My point is, for quite sometime I was looking for the answers in the linux kernel when in reality those were in a different component (grub in this case). Make sure that this isn't the case for you as well. Happy coding :)
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, 02 Nov 2021 17:13:16 +0500, Mushahid Hussain said:
I have written a simple kernel which prints Hello World to UART. The simple kernel works successfully and prints Hello World to UART, if I load it at 0x80000, which is the default load address for the 64-bit kernel.
There's a configuration(config.txt)[1] kernel_address on Raspberry Pi 4 but whenever I change the load address by even 1 byte, the simple kernel would not run. It is only able to run at 0x80000.
The config.txt value is for the boot loader, to tell it where the kernel should be loaded. There's another number, set during the kernel build, that tells the kernel what address it should expect to be loaded at. So if your micro-kernel is build to load at 0x80000 and then you tell the boot loader to load at 0x80001, or vice versa, things will go badly. You need to find some way to ensure that the boot loader and the initial part of the kernel (the one that proceeds to unpack the rest of the kernel, set up KASLR, and relocation if neded) agree on what address things start off at.
There's another number, set during the kernel build, that tells the kernel what address it should expect to be loaded at.
Thank you for the reply. I have added a linker script specifying the same load address as one one config.txt. The simple kernel(hello world) is only able to run, when both addresses(in linker script and config.txt) are 0x80000. I don't know how that number can be set during the build other than in the linker script. I would love to know about it. Can you point me towards the resources to learn about it?
You need to find some way to ensure that the boot loader and the initial part of the kernel (the one that proceeds to unpack the rest of the kernel, set up KASLR, and relocation if neded) agree on what address things start off at.
How can I set the load address for the initial part of the kernel other than in the linker script? On Wed, 3 Nov 2021 at 02:59, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Tue, 02 Nov 2021 17:13:16 +0500, Mushahid Hussain said:
I have written a simple kernel which prints Hello World to UART. The simple kernel works successfully and prints Hello World to UART, if I load it at 0x80000, which is the default load address for the 64-bit kernel.
There's a configuration(config.txt)[1] kernel_address on Raspberry Pi 4 but whenever I change the load address by even 1 byte, the simple kernel would not run. It is only able to run at 0x80000.
The config.txt value is for the boot loader, to tell it where the kernel should be loaded. There's another number, set during the kernel build, that tells the kernel what address it should expect to be loaded at.
So if your micro-kernel is build to load at 0x80000 and then you tell the boot loader to load at 0x80001, or vice versa, things will go badly.
You need to find some way to ensure that the boot loader and the initial part of the kernel (the one that proceeds to unpack the rest of the kernel, set up KASLR, and relocation if neded) agree on what address things start off at.
-- Mushahid Hussain
participants (3)
-
Mushahid Hussain -
Paulo Miguel Almeida -
Valdis Klētnieks