Arria10 Secure Boot : unable to boot SPL FUSE
On the Arria10, a signed SPL using the FUSE method does not boot at all, but it does boot when using the USER method. The behavior is the same as if we had not programmed the fuses. Details : Using the alt_authtool.py utility found in the repository, the SPL is signed. The tool accepts the following options: - fuse: embed root pubkey in image. BootROM verifies its hash against device fuses. - fpga: fetch trusted root pubkey from location in FPGA memory. - user: embed root pubkey in image. BootROM does not verify. read EC key Private-Key: (256 bit) priv: 9e:e1:55:ec:b6:be:bd:15:22:80:73:3a:66:ee:07: fa:58:26:1f:d0:13:c8:e5:6a:b0:05:bc:23:f7:dc: 58:46 pub: 04:0d:b3:cf:29:e9:54:60:7a:1c:d2:99:ca:5e:dd: d0:72:98:0c:5f:89:33:2c:16:35:24:4f:65:ad:ba: 23:45:9d:ec:5e:22:06:9f:b6:b2:bd:d0:19:8c:53: aa:af:20:1c:df:72:0f:02:e9:44:b0:86:1a:d5:b5: 7a:2c:81:65:dd ASN1 OID: prime256v1 NIST CURVE: P-256 First, we generate the SPL using the user option, then follow the Application Note, and the Arria10 board boots correctly. python3 -B -E $(which alt_authtool.py) sign -t user -k ${ROOT_KEY_PEM} -i ${DEPLOYDIR}/u-boot-spl-public-key.sfp -o ${DEPLOYDIR}/u-boot-spl-public-key-signed.sfp --fuseout ${DEPLOYDIR}/u-boot-spl-public-key-signed.fuse The following text is displayed: SHA256 digest of root public key: 3dfe63cab8b3657db2ebdeaca234f0d6ec3744a3905d7e04dfa63a5a6721dfe7 ==> The SPL with USER option boots correctly. Next, we generate the SPL using the fuse option. With this, the FPGA should only be able to boot if the fuses are programmed (volatile or non-volatile). When alt_authtool.py is executed, it displays the SHA256 hash of the public key. We use this public key to construct a file containing: key1 3DFE63CAB8B3657DB2EBDEACA234F0D6EC3744A3905D7E04DFA63A5A6721DFE7 Using this key file, we generate an EKP file with Quartus (compressed into a zip and attached to the present message). In the end, using the Quartus Prime Programmer, we program the Arria10 board with EKP file (this takes less than one second). Immediately after programming the volatile fuses, the board resets (the power supply current drops from 1A to 0.8A, and then returns to 1A), and the fan stops and restarts. ==> However, on the serial console, the SPL signed with the FUSE method does not display any messages, and neither U-Boot nor the kernel is loaded. On the other hand, the SPL signed with the USER method is still able to boot, even with the volatile fuses programmed (boot messages appear, and both U-Boot and the kernel are loaded). Question: Can you help us to solve this boot issue with the FUSE method ? The behavior is like volatile fuses are not programmed ! If you need more information and details, please tell us. Thanks in advance. Christian & Baptiste
NCONT ERROR in ACK for access 0 : ACK = 0x01 when trying to connect with Arm DS debugger through JTA
Hi, I am an embedded developer trying to help bring up a custom Arria 10 board. I can successfully load the SOF file to configure the FPGA using the Intel Quartus Prime Programming utility through a USB Blaster 1 connected to the JTAG interface, but when I try to manually load and run the preloader using the Arm DS debugger I get the "NCONT ERROR in ACK for access 0: ACK = 0x01" message in the Target Console window. From what I have read on the forums, this indicates that there is a JTAG COM issue with the board. I have consulted with our FPGA designer and board layout person, and they tell me the JTAG interface is configured and connected correctly. I tend to believe them since I can successfully load the SOF file through the JTAG interface. After getting the error, the debugger pops up a window stating "The target hardware identity could not be verified. Please check that the target being connected to is of type Arria 10 SoC". I have found a similar post on the Arm DS support website regarding this issue and followed the bare-metal user guide procedure for loading the preloader which worked for that person, but it did not work for me. The preloader instructions can be found at https://www.intel.com/content/www/us/en/docs/programmable/683211/current/import-preloader.html. Any help or suggestions with this issue would be greatly appreciated. Thanks, Richard
Arria 10 Preloader SPL Uboot Error
Hi, I am getting an error loading/debugging uboot through the Arm Development Studio debugger on my custom Arria 10 Han Pilot board that boots from QSPI Flash. I am following the instructions here for building the preloader and uboot from the custom Quartus project handoff xml file: https://www.rocketboards.org/foswiki/Documentation/BuildingBootloaderCycloneVAndArria10#Arria_10_SoC_45_Boot_from_QSPI I created a debugger script per the instructions in that same document located here: https://www.rocketboards.org/foswiki/Documentation/BuildingBootloaderCycloneVAndArria10#Arria_10_SoC_45_Debugging_U_45Boot When I run the script in the debugger, everything seems to work up to the point where u-boot gets loaded. When that happens, I get the following error: +loadfile u-boot-socfpga/u-boot Target Message: Memory access caused precise abort. Debug Precise Abort Registers : DFSR = 0x00000805, DFAR = 0x01001020 ERROR(CMD16-TAD59-NAL18): # in C:\Users\engineering\HD-MRPS\Linux_Boot\11-18-2023\debug-u-boot-A10.ds:27 while executing: loadfile u-boot-socfpga/u-boot ! Failed to load "u-boot" ! Download of 356,184 bytes to address S:0x01000040 failed while writing block of 4,096 bytes to address S:0x01000040 ! Bus error on memory operation.ERROR(CMD656): The script C:\Users\engineering\HD-MRPS\Linux_Boot\11-18-2023\debug-u-boot-A10.ds failed to complete due to an error during execution of the script I checked that memory address in the debugger and verified that it is not writable (all red). This error seems to indicate that the preloader did not correcly initialize the memory for some reason. I also do not get any output form the serial terminal while the preloader executes which indicates that the IO is not configured correctly either. I have attached the debugger script I am running and the corresponding error log. I can replicate this error on my Han Pilot Arria 10 dev kit that is configured to load from an SD card. With this setup, I follow these instructions for building the preloader and uboot: https://www.rocketboards.org/foswiki/Documentation/BuildingBootloaderCycloneVAndArria10#Arria_10_SoC_45_Boot_from_SD_Card It seems like the qts-filter_Arria10.sh script does not import all of the necessary configuration differences of the custom board to the bootloader build environment. It also seems that the Han Pilot dev kit is different that the Intel Arria 10 dev kit and those differences don't get imported by the qts-filter_Arria10.sh either. I researched the Forums for similar issues and I found this thread where the preloader was not configuring the memory and IO correctly for a custom board, but the solution was never posted to the board even though the problem was apparently solved. Here is that thread: https://community.intel.com/t5/Intel-SoC-FPGA-Embedded/Preloader-uboot-SPL/td-p/1478716/page/2 Do any Intel employees involved with that thread happen to know what the solution to that problem was? I would appreciate any help you can provide with this issue. Thanks, Richard
Intel Arria 10 SOC QSPI boot Stuck
Hi team, We are using Intel Arria 10 SOC 10AS032E2F29I2SG and QSPI flash for the boot source MT25QU01GBBB8E12-0SIT . During the booting time , the line gets stucked at SF: Detected N25Q1024A with page size 256 Bytes, erase size 4 KiB, total 128 MiB . This happens intermittently and at some cases the booting gets completed.I have attached the log image below for your reference. Please suggest to resolve this issue asap. Thanks in advance.Can't execute an ARM Compiler 5/6 built image from Arria V SoC devkit SDRAM without debugger
Hi, I try to build a bare metal app for the Arria V SoC devkit using Arm Compiler 6/5 (DS-5 built in) and load it from the QSPI into the SDRAM (on the devkit without debugger). The app is never executed. I followed several guides, All resulted with working preloader that doesn't load the app: 1. Link: https://community.intel.com/t5/Intel-SoC-FPGA-Embedded/scatter-file-linker-script-and-preloader-integrations-for/m-p/1472491/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufExHME5POUsyNERNRFVVfDE0NzI0OTF8U1VCU0NSSVBUSU9OU3xoSw#M1882 2. asdf soc hands baremetal (attached) 3. guide found in this forum (attached) 1 | My Environment - Windows 10 - SoC EDS 18.1.0.625 - DS-5 Ultimate Edition, Version: 5.29.1 (installed with SoC EDS) - Quartus Prime 18.1 (including Quartus Prime Programmer) 2 | Example Projects For comparison I used two example projects: 1. Altera-SoCFPGA-HardwareLib-Unhosted-AV-GNU - Link: (attached to this post) - Result: The built app is loaded successfully with debugger and without it (SoC only) 2. Altera-SoCFPGA-HardwareLib-Timer-AV-ARMCC - Link: (attached to this post) - Result: The app is loaded only when using debugger. I wish to load it without debugger. 3 | 1. I used the Arria V SoC GHRD handoff folder to build the preloader: - Checked SDRAM scrub - Unchecked watchdog interrupt and any boot device other than the QSPI - Next image address is 0x60000) I see the preloader UART prints. I use the same preloader with both images (only the GCC built image is executed without debugger) 2. In both cases I flash the bare metal app into the QSPI starting from address 0x60000: quartus_hps -c 1 -o PV -a 0x60000 [image_name].bin 3. I don’t know if its matters, but in project (2.1) the resulted ELF is converted to .bin using objcopy. In project (2.2) its converted using fromelf. In both cases I use the same mkimage command: mkimage -A arm -T standalone -C none -a [SDRAM_START_ADDR] -e 0 -n "baremetal_image" -d [name].bin [image_name].bin 4. The [SDRAM_START_ADDR] is different in both projects. In (2.2) its provided in the scatter file, in (2.1) its provided in the linker script. I did noticed a comment in the GCC project (2.1) linker script: MEMORY { boot_rom (rx) : ORIGIN = 0xfffd0000, LENGTH = 64K oc_ram (rwx) : ORIGIN = 0xffff0000, LENGTH = 64K /* Need to have 64bytes available before start of program, to store the mkimage header */ ram (rwx) : ORIGIN = 0x100000 + 0x40, LENGTH = 1023M - 0x40 } "Need to have 64bytes available before start of program, to store the mkimage header" I'm not sure this space exists in project (2.2) as well. Could this be the reason for my problem? 5. I looked at each project built ELF "Image entry point". In both cases it points to a valid place (proj 2.1 – cs3_reset , proj 2.2 – alt_interrupt_vector). Both lead to main So I don't know what is the specific difference causing the GCC project (2.1) built image to be loaded and work properly as opposed to the ARM project (2.2) built image.Creating an SD Card for the Intel Agilex® 7 SoC
This time, I'm writing about creating an SD card for the Intel Agilex® 7 SoC. The catalyst for this was the announcement of Intel® Agilex™ FPGAs (code named Sundance Mesa) Delivering Industry-Leading Power-Efficient Performance. I believe this device could serve as a compelling reason to transition from the Cyclone® V SoC in the future. However, as the device is not yet available, I aim to tackle the creation of an SD card for the Intel Agilex® 7 SoC using the already mass-produced Intel Agilex® 7 F-Series Transceiver SoC Development Kit. The goal is to migrate the SD card image used in the DE10-Nano/FPGA Cloud Connectivity Kit (Cyclone® V SoC) to enable container operation. This article is intended for those who have experience with Cyclone® V SoC but are new to development with Intel® Stratix® 10 SoC/Intel Agilex® 7 SoC. Author's Environment Build SD Card Image FPGA Image: CentOS 7.4 with Intel® Quartus® Prime Software 22.3 Other Image: CentOS 7.4 using Docker (Base Image: Debian 11.5/bullseye) Write and Customize SD Image: Ubuntu 20.04 Device: Intel Agilex® 7 FPGA F-Series Transceiver-SoC Development Kit (Engineering Sample/ES, Device OPN: AGFB014R24A2E3VR0) Intel® Quartus® Prime Software Version: v22.3 Pro Edition GCC Arm Cross Compiler: arm-11.2-2022.02-x86_64 Note: Regarding the host OS, the version is a bit old since it is the environment I usually use. Articles on RocketBoards.org recommend Ubuntu 20.04. I had to use Docker for building because the versions I used did not work directly. For this project, I used the ES version of the device. This will only affect the part of creating the FPGA image. Introduction It's important to note that most of the commands used in this article are a combination of the following two documents: GSRD for Agilex 7 F-Series Transceiver-SoC DevKit (P-Tile and E-Tile) Building Bootloader for Stratix 10 and Agilex The first document allows for building everything at once using Yocto, an open-source-based build project. The second document describes building each component separately. While building with Yocto provides the advantage of automatically building and using internal tools, it can be challenging to understand what exactly is being executed within the project. Building each component separately requires executing more commands, but it makes it easier to understand what is being built, which might be more familiar to those with Cyclone® V SoC development experience. Furthermore, it might be easier when it comes to customizing options later in the article. Given this background, this article will be based on Building Bootloader for Stratix 10 and Agilex. (I also aim to cover Yocto customization, as I believe I have a decent understanding of it, time permitting.) The document mostly outlines the steps, paying little attention to the technical background. This article will cover those steps in practice, including the underlying knowledge that supports them. Note: As the article became quite extensive, for readability reasons, some parts overlapping with commands found on RocketBoards.org have not been included here. Please make sure to refer to the links on RocketBoards.org for comprehensive guidance. About the SD Image Configuration As a recap, let's look at the SD card image used in the FPGA Cloud Connectivity Kit tutorial. Note that this is a direct URL to the SD card image, so please be cautious. For Cyclone® V SoC, it looked like this: root@de10nano:~# ls -l /dev/mmcblk0* brw-rw---- 1 root disk 179, 0 Oct 20 22:19 /dev/mmcblk0 brw-rw---- 1 root disk 179, 1 Oct 20 22:19 /dev/mmcblk0p1 #U-Boot, zImage, DTB brw-rw---- 1 root disk 179, 2 Oct 20 22:19 /dev/mmcblk0p2 #Linux Filesystem brw-rw---- 1 root disk 179, 3 Oct 20 22:19 /dev/mmcblk0p3 #Preloader Three partitions were created: Partition 1 contained U-Boot, zImage, DTB (Device Tree Blob), and essential components for Linux boot; Partition 2 housed the Linux Filesystem (Ubuntu18.04); and Partition 3, which cannot be directly mounted, contained the Preloader. Now, looking at the Intel Agilex® 7 SoC image: root@agilex:~# ls -l /dev/mmcblk0* brw-rw---- 1 root disk 179, 0 Apr 21 21:54 /dev/mmcblk0 brw-rw---- 1 root disk 179, 1 Apr 21 21:54 /dev/mmcblk0p1 #U-Boot, Image, DTB brw-rw---- 1 root disk 179, 2 Apr 21 21:54 /dev/mmcblk0p2 #Linux Filesystem The number of partitions has been reduced to two. This is because the Boot Up procedure has changed. Differences in Boot Up Procedures The Boot Up procedure for the Intel Agilex® 7 SoC (precisely from Intel® Stratix® 10 SoC onwards) may seem to be refined compared to the Cyclone® V. This is influenced by the SDM (Secure Device Manager). Cyclone V SoC GSRD GSRD for Agilex 7 F-Series Transceiver-SoC DevKit (P-Tile and E-Tile) For a rough understanding, the end of the Preloader stage for Cyclone® V and the end of the ATF (Arm Trusted Firmware) stage for Intel Agilex® 7 SoC present a similar scenario. The SDM stage offers more functionality than the Boot ROM of Cyclone® V, so thinking of SDM as a part of the Boot ROM + Preloader stage might be helpful. The Presence of SDM From Intel® Stratix® 10 onwards, the writing of FPGA images has been managed by something known as the Secure Device Manager (SDM). The existence of SDM allows the FPGA to always verify a secure image before configuration, among other benefits. SDM, in addition to the Boot ROM, possesses a processor and requires initialization at boot time. For the Intel Agilex® 7 SoC Development Kit, the boot image cannot be read from an SD card connected to the HPS (since the SD card is optional), hence it is read from the onboard QSPI Flash. Note: With the introduction of SDM, there are two types of configuration methods: HPS First and FPGA First. It can be a bit confusing, but the Intel Agilex® 7 SoC FPGA Boot User Guide: Boot Flow Overview details different stages of boot. The method described on RocketBoards.org primarily follows the HPS First boot. The document's FSBL (First Stage Bootloader) includes what was previously described as U-Boot SPL and ATF. ARM Trusted Firmware-A (TF-A/ATF) Starting with the Intel® Stratix® 10 SoC, using Arm within the HPS requires the use of Trusted Firmware. This can be understood as the protocol for using Arm A-series processors. Customization situations for this firmware are not commonly needed. For reference, here are some URLs: Trusted Firmware-A Documentation arm-trusted-firmware This firmware is later stored inside a file named uboot.itb. U-Boot SPL (Secondary Program Loader) The Secondary Program Loader (SPL) of U-Boot is not the second loader of U-Boot, but rather the second in the overall boot sequence. The SPL stage involves setting up the minimum necessary I/O and SDRAM configurations. There are various resources on U-Boot SPL that can be referred to for more detailed information. Develop U-Boot: Generic SPL framework: U-Boot Phases Summary of SD Card Configuration Let's recap the necessary files for booting the Intel Agilex® 7 SoC Development Kit. The specific file names mentioned are visible when the SD card is mounted. Outside the SD Card (Stored in QSPI Flash) Phase 1 FPGA Image (.jic) Phase 1 FPGA Image U-Boot SPL Hex/Binary (New) SD Card: Partition 1 Linux Kernel Image (Image) Phase 2 FPGA Image (ghrd.core.rbf) Device Tree Blob (socfpga_agilex_socdk.dtb) u-boot.itb U-Boot Image Trusted Firmware-A (New! Described as ATF in articles on RocketBoards.org) Device Tree File SD Card: Partition 2 Rootfs Image The commands to execute this document are essentially the same as those in the Building Bootloader for Stratix 10 and Agilex document, so section names are directly quoted from there. Note: In the case of a Yocto build, the Linux Kernel Image, Phase 2 FPGA Image, and Device Tree Blob are all combined into a single file named kernel.itb. B. Build Hardware Design (Differences Exist Between ES and Production) In this section, we create configuration files (.sof) containing both Phase 1 and Phase 2 from the GHRD (Golden Hardware Reference Design). Note that some functionalities are limited on the ES board, and the device's OPN differs. Reference: Intel Agilex® 7 FPGA F-Series Transceiver-SoC Development Kit User Guide. cd $TOP_FOLDER rm -rf ghrd-socfpga-QPDS-22.3pro-21.1std QPDS-22.3pro-21.1std.zip agilex_soc_devkit_ghrd wget https://github.com/altera-opensource/ghrd-socfpga/archive/refs/tags/QPDS-22.3pro-21.1std.zip unzip QPDS-22.3pro-21.1std.zip mv ghrd-socfpga-QPDS-22.3pro-21.1std/agilex_soc_devkit_ghrd . rm -rf ghrd-socfpga-QPDS-22.3pro-21.1std QPDS-22.3pro-21.1std.zip cd agilex_soc_devkit_ghrd # disable sgmii and partial reconfiguration - to decrease build time export HPS_ENABLE_SGMII=0 export ENABLE_PARTIAL_RECONFIGURATION=0 export QUARTUS_DEVICE=AGFB014R24A3E3VR0 #ES Board Only export ENABLE_HPS_EMIF_ECC=0 #ES Board Only ~/intelFPGA_pro/22.3/nios2eds/nios2_command_shell.sh make scrub_clean_all ~/intelFPGA_pro/22.3/nios2eds/nios2_command_shell.sh make generate_from_tcl # change the board id to be 4 - the one used when booting from SD card #Production Board #sed -i 's/set_global_assignment -name STRATIX_JTAG_USER_CODE .*/\ #set_global_assignment -name STRATIX_JTAG_USER_CODE 4/g' ghrd_agfb014r24b2e2v.qsf # ES Board sed -i 's/set_global_assignment -name STRATIX_JTAG_USER_CODE .*/\ set_global_assignment -name STRATIX_JTAG_USER_CODE 4/g' ghrd_agfb014r24a3e3vr0.qsf ~/intelFPGA_pro/22.3/nios2eds/nios2_command_shell.sh make all cd .. This results in the creation of either `ghrd_agfb014r24b2e2v.sof` (for Production) or `ghrd_agfb014r24a3e3vr0.sof` (for ES). The division into Phase 1 and Phase 2 is done after creating the bootloader (U-boot SPL) binary. C. Build Arm Trusted Firmware / D. Build U-Boot This section does not have any changes, so please refer to the documentation. For building the Arm Trusted Firmware, create bl31.bin, and for U-Boot, alongside U-Boot SPL u-boot-spl-dtb.hex, create U-boot's image u-boot.itb. Building Bootloader for Stratix 10 and Agilex: Agilex - Boot from SD Card E. Prepare QSPI Image (! ES/Production difference exists !) For Production boards, follow the documentation on RocketBoards.org exactly. For ES boards, you need to change the QSPI Flash and FPGA's OPN. ~/intelFPGA_pro/22.3/nios2eds/nios2_command_shell.sh \ quartus_pfg -c agilex_soc_devkit_ghrd/output_files/ghrd_agfb014r24a3e3vr0.sof \ ghrd.jic \ -o hps_path=u-boot-socfpga/spl/u-boot-spl-dtb.hex \ -o device=MT25QU02G \ -o flash_loader=AGFB014R24A3E3VR0 \ -o mode=ASX4 \ -o hps=1 Executing this will generate the image ghrd.hps.jic (Phase 1 FPGA Image with U-boot SPL) and ghrd.core.rbf (Phase 2 FPGA Image) to be stored in QSPI Flash. Linux Kernel Build The RocketBoards.org documentation moves on to creating the SD Card image next, but since we're still missing some components, we'll adjust the order slightly. Jump to the section Appendix - Building Linux Binaries in the documentation and follow the instructions up to "Building Linux Kernel". Rootfs The documentation then uses Yocto's Poky, an open-source build project for creating an embedded Linux distribution. While Poky is lightweight and good for initial trials, using a more general distribution like Ubuntu offers more packages and conveniences. This time, we aim to switch to Ubuntu 20.04. First, access Ubuntu Base 20.04.5 LTS (Focal Fossa). Here, you can download just the base rootfs. Download the tar.gz file with -arm64 in its name. As of writing (December 2022), version 20.04.5 was the latest, so download that. cd $LINUX_BIN/a53 wget https://cdimage.ubuntu.com/ubuntu-base/releases/20.04/release/ubuntu-base-20.04.5-base-arm64.tar.gz The downloaded file is equivalent to the core-image-minimal-agilex.tar.gz built with Yocto. Note: The downloaded file is minimal, so simply creating and writing the SD card with it will not boot. After writing, you need to edit the SD card image (more on this later). G. Prepare SD Card Image Now that all materials are gathered: (Reiterated) Outside SD Card (stored in QSPI Flash) Phase 1 FPGA Image (ghrd.hps.jic) ([Section E](#e-prepare-qspi-image--esproduction-difference-exists)) Phase 1 FPGA Image U-Boot SPL Hex/Binary (u-boot-spl-dtb.hex) ([Section C](#c-build-arm-trusted-firmware--d-build-u-boot)) SD Card: Partition 1 Linux Kernel Image (Image) ([Linux Kernel Build](#linux-kernel-build)) Phase 2 FPGA Image (ghrd.core.rbf) ([Section E](#e-prepare-qspi-image--esproduction-difference-exists)) Device Tree Blob (socfpga_agilex_socdk.dtb) ([Section D](#c-build-arm-trusted-firmware--d-build-u-boot)) u-boot.itb ([Section D](#c-build-arm-trusted-firmware--d-build-u-boot)) U-Boot Image Trusted Firmware-A ([Section C](#c-build-arm-trusted-firmware--d-build-u-boot)) Device Tree File SD Card: Partition 2 Rootfs Image (ubuntu-base-20.04.5-base-arm64.tar.gz) ([Rootfs](#rootfs)) Combine all these to create one image. For Rootfs, the document differs, so I suggest creating a symlink to easily switch between Yocto and Ubuntu. If using Ubuntu, it's recommended to allocate a larger partition due to the need for downloading packages later. Also, the document does not mention it, but remember to copy over the kernel modules. Navigate to the main directory, remove any existing SD card directory, then create a new SD card directory: cd $TOP_FOLDER sudo rm -rf sd_card && mkdir sd_card && cd sd_card wget https://releases.rocketboards.org/release/2020.11/gsrd/tools/make_sdimage_p3.py chmod +x make_sdimage_p3.py mkdir sdfs && cd sdfs cp $TOP_FOLDER/u-boot-socfpga/u-boot.itb . cp $LINUX_BIN/a53/Image . cp $LINUX_BIN/a53/socfpga_agilex_socdk.dtb . cp $TOP_FOLDER/ghrd.core.rbf . cd .. A clever trick: mkdir rootfs-yocto && cd rootfs-yocto # Not needed if not building with Yocto sudo tar xf $LINUX_BIN/a53/core-image-minimal-agilex.tar.gz sudo rm -rf lib/modules/* sudo cp -r $LINUX_BIN/a53/modules/* lib/modules/ cd .. mkdir rootfs-ubuntu && cd rootfs-ubuntu sudo tar xf $LINUX_BIN/a53/ubuntu-base-20.04.5-base-arm64.tar.gz sudo rm -rf lib/modules/* sudo cp -r $LINUX_BIN/a53/modules/* lib/modules/ cd .. ln -s rootfs-ubuntu rootfs To adjust the partition size, modify the size parameter in lines 2, 3, and 4 (in the following example, partition 1 is 56MB and partition 2 is 800MB, totaling 856MB): sudo python3 make_sdimage_p3.py -f \ -P sdfs/*,num=1,format=fat32,size=56M \ -P rootfs/*,num=2,format=ext3,size=800M \ -s 856M \ -n sdcard.img cd .. Note: Increasing the size will enlarge the image size, thereby increasing the writing time to the SD card. Writing the JIC File to QSPI Flash Execute the command as directed in the G. Boot section. The text mentions setting MSEL to JTAG, which is the state "SW1: ON-ON-ON-ON". Conversely, to read from QSPI, return to the state "SW1: ON-OFF-OFF-ON". cd $TOP_FOLDER/flash_image/ ~/intelFPGA_pro/22.3/nios2eds/nios2_command_shell.sh \ quartus_pgm -m jtag -o "pvi;./ghrd.hps.jic" Writing to the SD Card Write the completed SD card image using your preferred application or tool. I used dd or balenaEtcher. $ sudo dd if=sdcard.img of=/dev/<your device path> status=progress As mentioned in the previous note, inserting the SD card as is into the Intel Agilex® 7 SoC DK will not boot. U-Boot cannot find the Linux init process and stops. Therefore, after writing, you need to customize various settings. Customizing the SD Card Re-inserting the SD card should show a new disk added, with two partitions visible. $ ls /dev/sd* # Before inserting the SD card sda sda1 sda2 sda3 $ ls /dev/sd* # After inserting the SD card sda sda1 sda2 sda3 sdb sdb1 sdb2 $ mkdir mnt # Create directory for mounting $ sudo mount /dev/sdb2 mnt In the above example, sdb is the SD card disk. Since sdb2 corresponds to the filesystem, we'll configure this part. There are various ways to configure, and using `mmdebstrap` as mentioned in the Cyclone® V SoC Linux Construction Procedure: 7. Building the Root File System (rootfs) is safe, but let's try a more straightforward push. First, install QEMU since the architecture is different. sudo apt install qemu-user-static binfmt-support After installation, copy the necessary files and mount the subdirectories that are handy when chrooting. sudo cp -b /etc/resolv.conf mnt/etc/resolv.conf sudo cp /usr/bin/qemu-aarch64-static mnt/usr/bin sudo mount -t proc /proc mnt/proc sudo mount -t sysfs /sys mnt/sys sudo mount -o bind /dev mnt/dev sudo mount -o bind /dev/pts mnt/dev/pts This alone makes it possible to chroot. sudo chroot mnt Once you've chrooted, start by installing packages with apt. The author notes that attempting to use apt directly led to errors, so chmod was adjusted on /tmp first. (Reference: sudo apt-get update couldn't create temporary file) It's recommended to install packages for partition size adjustment (`parted`), network-related applications, the `systemd` init process, and your favorite editor. chmod 1777 /tmp apt clean && apt update apt install -y vim git parted iproute2 netplan.io iputils-ping network-manager isc-dhcp-client kmod sudo openssh-server systemd Also, configure users and other settings. passwd adduser agilex usermod -aG sudo agilex It's handy to write network settings as well if necessary. vim /etc/ssh/sshd_config # uncomment PasswordAuthentication yes cat << EOF > /etc/netplan/00-default.yaml network: version: 2 renderer: networkd ethernets: eth0: dhcp4: yes EOF Once finished, exit the session and unmount each directory. Be aware, if subdirectories are not unmounted first, you may encounter a "Target is busy" refusal. exit # Exit chroot sudo umount mnt/proc sudo umount mnt/sys sudo umount mnt/dev/pts sudo umount mnt/dev sudo umount mnt Now, it's time to boot! Boot Up and Disappointment Up to the kernel boot, you should see logs similar to those in the Building Bootloader for Agilex 7 documentation. However, once the Root Filesystem is loaded, it transitions to Ubuntu. Ultimately, if you reach the screen showing: Ubuntu 20.04.5 LTS localhost.localdomain ttyS0 localhost login: % This indicates completion. Try logging in with the user ‘agilex’ created earlier. If you've set up the network settings correctly, connecting an Ethernet cable to the same board as the SD card should automatically fetch an IP address, allowing internet access. This marks the successful creation and booting of the SD card image using the latest Intel® Quartus® Prime Software v22.3. However, unlike the image from FPGA Cloud Connectivity Kit, containers do not operate. Attempting to start services within the container will result in errors during installation: sudo apt install -y lxc # Installation error occurs Refer to: Linux Containers. In the next part, we will address this issue by introducing how to customize Linux kernel options to enable container operation. Stay tuned. Tips: Using Docker Containers to Build SD Card Components Despite having a high-speed machine for building, it's hosted on CentOS 7.4, which is slightly outdated. Due to various circumstances, it's not feasible to simply switch to Ubuntu 20.04. Attempts to work directly with CentOS 7.4 were abandoned due to unresolved package dependencies. However, utilizing Docker containers proved to be a convenient solution for building. As a base, the following page within RocketBoards.org is available: Docker Yocto Build. Yet, the Dockerfile provided there is designed for Yocto and lacks the packages necessary for direct kernel building. A bit of customization allows for direct building. The task is straightforward: add the Ubuntu 20.04 packages listed in Building Bootloader for Agilex 7 to the appropriate sections of the Dockerfile. Specifically, execute apt-get as root around line 17, where useradd is located. For execution methods, refer to the original Dockerfile: OE Build Container: Dockerfile. Note that ‘swig’ and ‘kmod’ were additionally required during the build process. For reference, here's a comparison before and after customization: $ diff Dockerfile Dockerfile.custom 17a18,26 > > ARG DEBIAN_FRONTEND=noninteractive > RUN apt-get update && apt-get install -yq gawk wget git-core diffstat unzip texinfo \ > gcc-multilib build-essential chrpath socat cpio python python3 \ > python3-pip python3-pexpect xz-utils debianutils iputils-ping \ > python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm \ > libncurses-dev gawk flex bison openssl libssl-dev swig kmod && \ > rm -rf /var/lib/apt-lists/* After completing the Docker build, run it. Ensure to mount directories containing the Intel® Quartus® Prime Software and sources along with GCC toolchains for convenience. Once logged into the container, proceed with the build as usual: $ docker build -t buildSA --build-arg username=$(whoami) --build-arg build_dir=$PWD . $ docker run -v ~/intelFPGA_pro/22.3:~/intelFPGA_pro/22.3 -v $PWD:$PWD -it --rm --user=$UID --name builder buildSA References Intel Agilex® 7 FPGAs (code named Sundance Mesa) Deliver Industry Leading Power-Efficient Performance Building Bootloader for Stratix 10 and Agilex Agilex™ SoC GSRD OE Build Container Docker Yocto Build DE10-Nano/FPGA Cloud Connectivity Kit using Microsoft* Azure Cyclone® V SoC GSRD Intel Agilex® 7 SoC FPGA Boot User Guide: Boot Flow Overview Intel Agilex® 7 Configuration User Guide: Secure Device Manager Trusted Firmware-A Documentation Intel SoC FPGA Documentation for Trusted Firmware-A Develop U-Boot:Generic SPL framework:U-Boot Phases Ubuntu Base 20.04.5 LTS (Focal Fossa) balenaEtcher - Flash OS images to SD cards & USB drives Cyclone V SoC に載せるLinuxの構築手順 sudo apt-get update couldn't create temporary file Intel Agilex® 7 FPGA F-Series Transceiver-SoC Development Kit User Guide Linux Containers コンテナ Ready SDカードイメージ作成 for Intel Agilex® 7 SoC Code names are used by Intel to identify products, technologies, or services that are in development and not publicly available. These are not "commercial" names and not intended to function as trademarks. Statements in this document that refer to future plans or expectations are forward-looking statements. These statements are based on current expectations and involve many risks and uncertainties that could cause actual results to differ materially from those expressed or implied in such statements. For more information on the factors that could cause actual results to differ materially, see our most recent earnings release and SEC filings at www.intc.com. Copies of documents which have an order number and are referenced in this document may be obtained by calling 1-800-548-4725 or visiting www.intel.com/design/literature.htm. © Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others. You may not use or facilitate the use of this document in connection with any infringement or other legal analysis concerning Intel products described herein. You agree to grant Intel a non-exclusive, royalty-free license to any patent claim thereafter drafted which includes subject matter disclosed herein. © Intel Corporation. Intel, the Intel logo, and other Intel marks are trademarks of Intel Corporation or its subsidiaries. Other names and brands may be claimed as the property of others.
Agilex 7 non-RSU boot: how to configure SDM to use 4x redundant HPS SPL images starting QSPI addr 0?
To boot an Agilex 7 (HPS boot first), the SDM QSPI is flashed with 4 redundant images that are 512KB (max) each. As I understand, the SDM copies the SPL into the HPS on-chip RAM, then releases the HPS reset. This works fine. On the HPS console, I can see the U-Boot SPL prints. However, if I corrupt the first image by erasing the first 512KB of QSPI, the device does not boot. How can I get the SDM to try the second image if the first image is bad, and so on?
