sikkiladho / leo Goto Github PK

We are facing the Kernel panic. Following the UART log output:

UART Log:
https://pastebin.mozilla.org/er67cUTn

We have to look at the first errors:

[ 1.750626] rootfs image is not initramfs (invalid magic at start of compress ed archive); looks like an initrd
[ 1.810959] Unable to handle kernel write to read-only memory at virtual addr ess ffffff8000400000

It seems kernel is looking for an initramfs file, but kernel in raspian OS doesn't not use initrd or initramfs file. It is because, we have abused the "initramfs" config to load the load the linux kernel. Initramfs config is used to provide initramfs and initrd files to the kernel.

Firmware believes that we are loading the initramfs file, therefore it adds an entry about initramfs to the dtb file at the runtime but there's no initramfs image at ffffff8000400000, it is the kernel itself.

What we have to is to clear the "initrd" field added by the firmware to dtb.

We can edit the dtb blobs at runtime in the hypervisor, by utilizing libfdt library.

We have been noticing a backtrace in UART log, indicated that CPUs are started in inconsistent modes. Here's what might be causing it.

After all cores are up, linux checks the mode they are in, if they are in different modes, it writes to UART about the inconsistency of the nodes.

Looking here we can read a comment,

A correctly-implemented bootloader must start all CPUs in the same mode:
In this case, both 32bit halves of __boot_cpu_mode will contain the
same value (either 0 if booted in EL1, BOOT_CPU_MODE_EL2 if booted in EL2).
Should the bootloader fail to do this, the two values will be different.
This allows the kernel to flag an error when the secondaries have come up.

Trusted Firmware only allows primary cpu(cpu0) to pass through kernel8.img,(which in this case is Leo's code). We never brought up the secondary cores at Leo and TF-A gave all those cores to Linux kernel in HYP/EL2 mode. Here is the CPU node BCM2711 device tree.

When linux brings up the secondary cores, CPU0 is in EL1(becasue we eret it to EL1 here. However, secondary cores(cpu1/2/3) are still in HYP/EL2 mode. Thus the inconsistency of modes between primary and secondary cores.

What do we need to do?

1. Modify the device tree blob with libfdt to use PSCI instead of spin_table to bring up the secondary cores. Here's the CPU node in DTB to be modified.
2. Trapping all asynchronous exceptions at Leo(EL2) and looking for smc with smc_fid: PSCI_CPU_ON_AARCH64

As we research more into this, I will update this issue very soon.

Hypervisor successfully prints Hello World to UART. It needs to jump into standard kernel with exception level el2.

We are using this function to jump from any exception level to el1 and to address 0x200000

There is a way to load two binaries in raspberry pi.
in config.tx, initramfs configuration loads kernel at 0x200000.

In theory, hypervisor should pass the control to standard kernel, but it is stuck after printing hello world.

Update:

• all the requirements should be met for the kernel explained in /Documentation/arm64/booting.rst

Hi, I am Paran Lee.

Fix cp command doubled typo.

I made a pull request. #3

I hope my update will be helpful to those new to Leo project.

We also have a warning.

[ 0.000000] WARNING: x1-x3 nonzero in violation of boot protocol:
[ 0.000000] x1: 00000000003ffee0
[ 0.000000] x2: 0000000000000018
[ 0.000000] x3: ffffffffffffffff
[ 0.000000] This indicates a broken bootloader or old kernel

It seems we have not zeroed out x1-x3 as defined in the arm64/booting.rst.

This should be solved by zeroing out x1-x3 in the jump function in src/utils.S