Sannum/rpi3 fixups #93
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
axel-h
reviewed
Jun 28, 2021
| @@ -133,7 +133,7 @@ void main(UNUSED void *arg) | |||
| #endif | |||
|
|
|||
| if (bootloader_dtb) { | |||
| printf(" dtb=%p\n", dtb); | |||
| printf(" dtb=%p\n", bootloader_dtb); | |||
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 <sannum.viktor@gmail.com>
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 <sannum.viktor@gmail.com>
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 <sannum.viktor@gmail.com>
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 <sannum.viktor@gmail.com>
sannum
force-pushed
the
sannum/rpi3_fixups
branch
from
08bd8d2
to
cdaefa8
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
and
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
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.