Jump to content

Re-building/updating arm-trusted-firmware and u-boot only


eperie

Recommended Posts

I am currently learning on the H5 on a OrangePiPC2.

I would like to be able to add debug messages to arm-trusted-firmware (bl31) and u-boot code, then  re-build them and update my SD card.

I did successfully build an image, but having spent some time going through the build scripts and the documentation, and performed a number of recursive

grep commands looking where bl31.bin was being referenced from, I have not been able to answer the following questions yet:


1) where is located the script code responsible for packaging bl31.bin and u-boot into an image acceptable by the H5 boot ROM ?

2) where is located the script code responsible for writing bl31.bin and u-boot into the image ?

3) is creating a user patch for arm-trusted-firmware currently supported by the build scripts ?

4) if yes, should the patch be located in userpatches/u-boot/u-boot-sun50i-dev/board_orangepipc2, or in something like userpatches/arm-trusted-firmware/u-boot-sun50i-dev/board_orangepipc2 ?

5) is there anyway to pass options to compile.sh so that only arm-trusted-firmware and u-boot, similar to KERNEL_ONLY=yes ?

 

Thanks.

 

 

Link to comment
Share on other sites

First, please note that this u-boot compilation setup for 64-bit sunxi boards is temporary and will change in the future.

 

13 hours ago, eperie said:

1) where is located the script code responsible for packaging bl31.bin and u-boot into an image acceptable by the H5 boot ROM ?

https://github.com/armbian/u-boot-sun50i/blob/master/Makefile

 

13 hours ago, eperie said:

2) where is located the script code responsible for writing bl31.bin and u-boot into the image ?

SPL, ATF (bl31.bin) and u-boot proper are packaged into a single binary and are flashed to SD card as a single file.

https://github.com/armbian/build/blob/master/config/sources/sun50iw2.conf#L14

 

13 hours ago, eperie said:

3) is creating a user patch for arm-trusted-firmware currently supported by the build scripts ?

 

Yes, please look at this patch for an example (even though this shutdown code does not work properly): https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sun50i-dev/add-pc2-shutdown.patch

Please note that ATF is currently located in the "arm-trusted-firmware" subdirectory of the u-boot "proxy" repository

Edit: applying patches for the ATF is possible. Creating a patch using CREATE_PATCHES=yes build script option most likely will not work because ATF is a submodule in the repository.

 

13 hours ago, eperie said:

4) if yes, should the patch be located in userpatches/u-boot/u-boot-sun50i-dev/board_orangepipc2, or in something like userpatches/arm-trusted-firmware/u-boot-sun50i-dev/board_orangepipc2 ?

userpatches/u-boot/u-boot-sun50i-dev/board_orangepipc2 should be fine

 

13 hours ago, eperie said:

5) is there anyway to pass options to compile.sh so that only arm-trusted-firmware and u-boot, similar to KERNEL_ONLY=yes ?

No, but you can always abort the kernel compilation by pressing <Ctrl-C> at the right time

Link to comment
Share on other sites

I see, for some reason, I had been looking for something similar to Apritzel's boot0img tool, and did not notice the ATF/u-boot bundling was being performed in the Makefile.

Thank you very much for your time and your clear and thorough explanations.

Link to comment
Share on other sites

Thank you Martin for this information.  Apritzel's master branch should be perfectly fine for now, my goal being to become familiar with Arm Trusted Firmware/AArch64.
In the case Apritzel's newest branch would be required, I may simply attempt to send more "Craftbeer der Welt" to the Armbian team , and hope for the best :)

Link to comment
Share on other sites

Providing some feedback after having exploited the information I got from Zabor and Martin.

I am exposing here my current uderstanding on AARCH64/u-boot/Linux, mistakes are mine, and corrections are very welcome.

 

My original goal was to be able to regain full control on my H5/A64 processors at the u-boot level: ARM Trusted Firmware is a great initiative, but users not having multi-thousand dollars DS-Stream probes and DS-5 licences are currently be left in the dark: recent versions of ARM Trusted Firmware allow defining symbols that will make the firmware loop in pre-BL31 loads - see Arm Trusted Firmware porting guide  and this article. I had not been able to find a simple/cheap solution for fully experimenting with AARCH64 from u-boot at the more privileged EL3 level, and Allwinner ROM is acting as pre-BL31 payloads in our case anyway. I ultimately paid for a hardware I want to have a full (and cheap/easy) access to.

 

In my case,  learning AARCH64 hardware by running simple, then more complex programs from u-boot , downloaded with loadbin or loads, while having full control on the processor, is more convenient than starting tampering with u-boot built-in commands or Linux kernel modules right the way - my two cents. Of course,  being able to develop commands on u-boot or Linux drivers would ideally be the ultimate goal. Not mentionning here Linux is running at EL1, and cannot therefore do things that can be achieved from a u-boot running at EL3.

 

You just have to apply the u-boot-sun50i-el3.patch path to Armbian sources, and rebuild u-boot and ARM Trusted Firmware. I don't have  a patch suitable to be put in the userpatches directory available yet - working on it...

 

u-boot usually boots in EL2 or EL1, depending on whether or not CONFIG_ARMV8_SWITCH_TO_EL1 was defined in u-boot configuration - Armbian's u-boot is running at El2.

But it may be transfered control to in EL3, as pointed-out by a comment at line #64 of arm/cpu/armv8/start.S:

 

        /*
         * Could be EL3/EL2/EL1, Initial State:
         * Little Endian, MMU Disabled, i/dCache Disabled
         */

When EL3_UBOOT is defined when compiling ARM Trusted Firmware, BL31 will simply:

- not configure the MMU,

- directly jump to the address of the next payload image bundled on the SD card, which is u-boot in the case of Armbian or mainline u-boot bundled with ARM Trusted Firmware.

#ifdef  EL3_UBOOT
        void (*uboot)(void) = (void (*)(void))  (uintptr_t) next_image_info->pc;
        INFO("BL3-1: Transferring control to address 0x%lx in EL3.\n", (uintptr_t) uboot);
        (*uboot)();
#endif

I am using a trivial program to be executed from u-boot in order to verify the u-boot current Exception Level - it can be built using the attached el.sh script.

 

#include <stdint.h>
int main(int argc, char** argv) {
    register uint64_t __regCurrentEL;
    __asm volatile ("mrs %0, CurrentEL" : "=r" (__regCurrentEL));
    return __regCurrentEL >> 2;
}

u-boot go command is more a call than a go, and it will display the 32 bits return code returned the program it called. An other option is to have the program store information into memory at a specific address, and dump it with u-boot md command upon  program completion.

 

  • u-boot with standard bl31:
     
=> loads
## Ready for S-Record download ...

## First Load Addr = 0x00400000
## Last  Load Addr = 0x4200001F
## Total Size      = 0x41C00020 = 1103101984 Bytes
## Start Addr      = 0x42000000
=> go 0x42000000
## Starting application at 0x42000000 ...
## Application terminated, rc = 0x2
=>

u-boot is running at EL2.

 

  • u-boot with patched bl31:
=> loads
## Ready for S-Record download ...

## First Load Addr = 0x00400000
## Last  Load Addr = 0x4200001F
## Total Size      = 0x41C00020 = 1103101984 Bytes
## Start Addr      = 0x42000000
=> go 0x42000000
## Starting application at 0x42000000 ...
## Application terminated, rc = 0x3
=>

u-boot is running at EL3.

 

You should obviously NOT use the patched BL31 for something else than learning on AARCH64 from u-boot with full control on the processors: u-boot is lowering its EL to EL1 in the bootm command, but there may be some side effects of the patch, more specifically SMC services provided by BL31 not being available anymore, if any were available.

Remember, the original was to be able to learn on AARCH64 using my nanopi neo2 at not cost, still ramping up: I am working on sample programs to switch between ELs, and AARCH64/AARCH32 modes.

 

If this post was of some interest for any of you, please advise, I will post more working examples to be executed from u-boot when they will be available.

If not, just do not waste your time answering :-)

 

By the way, attached bl31.bin should work as is on both H5 and A64 from what I understand. I tested on a nanopi neo2 and a pine64, but built a patched bl31.bin for both.

 

bl31.bin

el.c

el.sh

el.srec

u-boot-sun50i-el3.patch

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines