Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sannum/rpi3 fixups #93

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Sannum/rpi3 fixups #93

wants to merge 4 commits into from

Conversation

sannum
Copy link

@sannum sannum commented Jun 28, 2021

A series of fixups for directly booting seL4 and seL4_test binary images on the Raspberry pi3 in both aarch32 and aarch64 modes as well as succesfully passing the dtb from the bootloader to the elfloader as this is currently not working.

The resulting sel4test-driver-image-arm-bcm2837 binary images should be directly bootable using the common bootloader.bin/start.elf and the following config.txt files:

enable_uart=1 
kernel=sel4test-driver-image-arm-bcm2837
kernel_address=0x[IMAGE_START_ADDR]

and

enable_uart=1 
kernel=sel4test-driver-image-arm-bcm2837
kernel_address=0x[IMAGE_START_ADDR]
arm_64bit=1

for aarch32 and aarch64 builds respectively.
Currently it seems the kernel_address must be manually configured to match the shoehorn generated IMAGE_START_ADDR which can be found with

aarch64-linux-gnu-objdump -t elfloader/elfloader | grep _text

as described in elfloader-tool/README.md

This also means that u-boot is not required as per https://docs.sel4.systems/Hardware/Rpi3.html.

@@ -133,7 +133,7 @@ void main(UNUSED void *arg)
#endif

if (bootloader_dtb) {
printf(" dtb=%p\n", dtb);
printf(" dtb=%p\n", bootloader_dtb);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch

It seems that the 'ldp x0, x1, [sp, #-16]!' syntax used to load the
registers stored to the stack before calling the fixup_image_base
function does not in fact load the registers as expected (at least
on my Raspberry Pi 3B).
This causes the dtb address supplied by the bootloader to be lost when
elfloader loads the dtb image which is an issue if a dtb is not built
into the kernel binary image.

In the example usage from arm
(https://developer.arm.com/documentation/
102374/0101/Loads-and-stores---load-pair-and-store-pair)
the 'ldp x0, x1, [sp], seL4#16' is used for poping the stack.
This also seems to also work as expected on my Raspberry Pi 3B
resulting in the dtb address to be loaded as expected in sys_boot.c.

Signed-off-by: Viktor Sannum <[email protected]>
For arm builds, check if the bootloader has passed the dtb image
address also for binary image builds, similarly to uimages.

The Raspberry Pi bootloader for example, is able to both load
binary images directly and passes the dtb address to the loaded
image as expected.

Signed-off-by: Viktor Sannum <[email protected]>
Minor fixup, the dtb variable is always 0 when printed in
sys_boot.c as it refers to the the address the dtb is loaded
to after load_images has finished loading it from either the
bootloader_dtb or cpio archive.

Print bootloader_dtb instead, since it contains the address
to a valid dtb given by the bootloader or efi.

Signed-off-by: Viktor Sannum <[email protected]>
The Raspberry Pi3 has its own definition for configuring the
setting for binary images builds for aarch64 only, meaning
it cannot be part of the more generic binary_list definition.

The 32-bit aarch32 rpi3 builds can also boot from a binary
image so there is no actual need for this sepcial handling.

Remove it and move the bcm2837/rpi3 match to the binary_list
definition instead.

Signed-off-by: Viktor Sannum <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants