• Content Count

  • Joined

  • Last visited

About eperie

  • Rank

Profile Information

  • Gender

Recent Profile Visitors

486 profile views
  1. Thank you Igor - I should be able to make my way through Armbian's build system at one point.
  2. I have been looking for the source code of the Arm Trusted Firmware 1.4 and the modified u-boot used in the Armbian image for the OrangePi One Plus, to no avail. Could someone point me to the right git repositories ? Thanks!
  3. 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
  4. 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 .
  5. 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.
  6. 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.
  7. @Zabor Documentation at fel-mass-storage indicates that Zadig 2.2 and sunxi-fel.exe were successfully tested on Windows 8.1 32 bits: Just to let you know they are working great on Windows 10 64 bits (build 14393.321) as well - thanks a for this Windows port of sunxi-fel.
  8. Yes, this is the case of mine - thanks.
  9. No problem, I happily volunteered, and Armbian saved me a ***lot*** if time while setting-up my nanopi-m1. I had read about those power supply issues on the forum, but thought I would be fine with a 2A micro-USB power supply - it seems I was wrong: my cable is not short, and I am not sure about its gauge. I powered the board with a MB102 breadboard power supply rated for 5V/1.2A directly on the 4 pins header using Dupond cables as suggested, and cpuburn-a7 hanged the board again. Looking now for a 5V switching power supply: I am not sure the breadboard power supply is doing the job. Thanks for the help.
  10. I installed Armbian_5.14_Nanopim1_Debian_jessie_3.4.112, and followed the steps described at #73 and #80, but did not start cpuburn-a7 - I am discussing cpuburn-a7 further. That is, I had only armbianmonitor web server (three processes) and armbianmonitor command-line running. Time CPU load %cpu %sys %usr %nice %io %irq CPU 06:36:51: 1008MHz 0.03 0% 0% 0% 0% 0% 0% 40 C ... 06:51:03: 480MHz 0.03 0% 0% 0% 0% 0% 0% 58 C 06:51:08: 480MHz 0.03 1% 0% 0% 0% 0% 0% 58 C 06:51:13: 480MHz 0.03 1% 0% 0% 0% 0% 0% 59 C 06:51:18: 480MHz 0.02 1% 1% 0% 0% 0% 0% 58 C 06:51:23: 480MHz 0.02 0% 0% 0% 0% 0% 0% 59 C 06:51:28: 480MHz 0.02 0% 0% 0% 0% 0% 0% 58 C 06:51:33: 480MHz 0.02 0% 0% 0% 0% 0% 0% 59 C 06:51:39: 480MHz 0.02 1% 1% 0% 0% 0% 0% 58 C 06:51:44: 480MHz 0.02 1% 1% 0% 0% 0% 0% 58 C 06:51:49: 480MHz 0.01 1% 1% 0% 0% 0% 0% 58 C 06:51:54: 480MHz 0.01 0% 0% 0% 0% 0% 0% 58 C 06:51:59: 480MHz 0.01 0% 0% 0% 0% 0% 0% 58 C Starting cpuburn-a7 hangs my nanopi-neo immediatly, leaving both power (green) and heart-beat (blue) LEDs solid. I got the same behaviour a couple of times - rebooted, kept armbianmonitor -m running until temperature reached 58 C, then started cpuburn-a7 again. Did you experiment this with any other H3-based SBC ? I can perform other tests and provide feedback upon request - my time zone is Eastern Time/UTC-05:00. Thanks.
  11. 1) For Ubuntu 14.04 x86: retrieve a 32 bits Linux toolchain from Linaro - note that latest releases are providing Linux x86_64-hosted toolchains only - I tested on a Live CD Lubuntu x86 14.04 image. wget https://releases.linaro.org/14.01/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.8-2014.01_linux.tar.xz tar Jxf gcc-linaro-arm-linux-gnueabihf-4.8-2014.01_linux.tar.xz export PATH=$(pwd)/gcc-linaro-arm-linux-gnueabihf-4.8-2014.01_linux/bin:$PATH 1.1) create hello.c #include <stdio.h> #include <stdlib.h> int main(int argc, char** argv) { printf("Hello, World!\n"); return EXIT_SUCCESS; } 1.2) compilation arm-linux-gnueabihf-gcc -o hello hello.c 1.3) execution (on a nanopi-m1 running Armbian 5.16, but it should work as is on an orangepi-one...) ./hello Hello, World! 2) For Ubuntu 14.04 x86_64: retrieve latest 64 bits Linux toolchain from Linaro - I tested on a Live CD Lubuntu 14.04 x86_64 image. wget https://releases.linaro.org/components/toolchain/binaries/5.3-2016.02/arm-linux-gnueabihf/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz tar Jxf gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf.tar.xz export PATH=$(pwd)/gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabihf/bin:$PATH go through steps 1.1, 1.2, 1.3. Working fine with Armbian_5.14_Nanopim1_Debian_jessie_3.4.112.raw as well, still on a nanopi-m1.