Reset on execution of bare-metal app after bootloader - DE10-Nano (Cyclone V)

---

Did you by any chance make changes to the scatter file to point to the on chip ram?

https://www.intel.com/content/www/us/en/docs/programmable/683211/current/modify-project-to-run-from-sdram-instead.html

I assume you mean a scatter file to point to the SDRAM. Yes, I used an SDRAM scatter file and the document you linked to was the guide that I was following. I have copied the SDRAM scatter file contents below (it's identical to the one in the guide). Note that, as I mentioned in my original post, I am able to debug from SDRAM without issue if I load the bootloader from the factory DE10-Nano image first. The problems begin when I try using my build of U-Boot (to initialize the SDRAM prior to debugging).

scatter_SDRAM.scat:

SDRAM 0x02000000 0x02000000 ; 32M SDRAM
{
APP_CODE +0
{
* (+RO, +RW, +ZI)
}
ARM_LIB_STACKHEAP 0x03000000 EMPTY 0x01000000 ; Application heap and stack
{}
}

Thanks!
Brett

Thank you for the idea to try. Unfortunately, I am getting the same result using the 2022.01 branch.

U-Boot 2022.01-19547-g2544e805ea-dirty (Nov 10 2022 - 11:58:27 -0600)

CPU: Altera SoCFPGA Platform
FPGA: Altera Cyclone V, SE/A6 or SX/C6 or ST/D6, version 0x0
BOOT: SD/MMC Internal Transceiver (3.0V)
Watchdog enabled
DRAM: 1 GiB
MMC: dwmmc0@ff704000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Model: Altera SOCFPGA Cyclone V SoC Development Kit
Net:
Warning: ethernet@ff702000 (eth0) using random MAC address - 72:71:f8:f1:63:8e
eth0: ethernet@ff702000
Hit any key to stop autoboot: 0
=> undefined instruction
pc : [<02000bae>] lr : [<0200005f>]
reloc pc : [<c309cbee>] lr : [<c309c09f>]
sp : 03ffffe8 ip : 3ffe4248 fp : 02000bf8
r10: 02000bf8 r9 : 3bf61ed0 r8 : 00000000
r7 : 02000be7 r6 : 00000000 r5 : 00000000 r4 : 00000000
r3 : 00000000 r2 : 80000000 r1 : 02000d60 r0 : 02000c08
Flags: nZCv IRQs off FIQs off Mode SVC_32 (T)
Code: b2c0 1c53 604b 7010 (4770) eef1
Resetting CPU ...

resetting ...

Thanks,
Brett

Hi,

>Have you tried compiling and running the uboot version 2017.03-rc2 ?
>Is it able to work?

I would have done this before even posting here if it made sense (and was possible). Unfortunately, this is not practical and would likely not reveal much. As described here, the U-Boot build flow changed considerably starting with SoC EDS Standard version 19.1. Furthermore, the U-Boot source code was integral to SoC EDS prior to this and later removed. To compile U-Boot 2017.03-rc2, I would have to locate an old version of SoC EDS Standard that contained U-Boot 2017.03-rc2. Then I would need to backdate my installation of SoC EDS to this version (rendering the current version unusable). Even if I could get to this step, the output would not be comparable to U-Boot 2022.01 since, according to everything I have read, there has been a number of under-the-hood changes to U-Boot between these releases.

>Could you share me the file "socfpga_cyclone5_de10_nano"?

The only files with this name that I could find have a dts and dtb extension. My understanding is that these are device tree files for Linux and thus not relevant to the current discussion.

In terms of building U-Boot, "socfpga_cyclone5_de10_nano" denotes a configuration, not a particular file. From what I can tell this configuration information is buried within some number of files scattered throughout the U-Boot project.

>Could you point me the link where to get the uboot version of 2017.03-rc2?

Your guess is probably better than mine as to where to find this. All I have is the SD Card image containing the prebuilt U-Boot files (https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=1046&PartNo=4).

>Lets try to compare the u boot changes between the latest and 2017, starting from the config file.

As stated above, this is not possible/practical or I would have done it already.

One new thing that I have discovered is that the example projects in HWLibs will run on the newer U-Boot releases (2022.04 and 2022.01). I should note that it is the GNU compiler versions that are working (I am unable to compile the ARMCC versions). So evidently there is something different in the startup code that makes these projects work and my Arm Compiler 6 project to not work.

So to recap as to what works and what doesn't:

Can anyone at Intel confirm that a bare-metal project compiled in Arm DS 2022.0 using Arm Compiler 6 can be succesfully executed on a recent release of U-Boot?

Thanks,
Brett

Hi,

---

@JingyangTeh_Altera wrote:

For CycloneV you should be using the Arm Compiler 5 which targets the Cortex-A9 on Cyclone V SoC,

Arria V SoC and Intel Arria 10 SoC.

The Arm Compiler 6 targets Cortex-A53 on Intel Stratix 10 SoC and Agilex SoC.

---

Could you please point me to Intel literature that states this? It contradicts what I have found. On Intel's Arm Development Studio for Intel SoC FPGA webpage it states:

I cannot find anything stating that the current version of Arm DS (2022.0), which does not include Arm Compiler 5, should not to be used with Cyclone V, or that users need to downgrade to an Arm DS version from 3 years ago in order to have support for Cyclone V.

Granted, I realize that the HWLibs examples use GNU and Arm Compiler 5 and that they have not yet been updated to support Arm Compiler 6. But much/most of the Intel literature/examples/etc. is years out of date and not aligned with the current toolsets.

Again, I have no problem compiling and executing Arm Compiler 6 bare-metal applications from OCRAM, or SDRAM with U-Boot 2017-rc2. The problems are only with newer versions of U-Boot. I don't see how this is an Arm Compiler 6 problem. Something changed in U-Boot which is causing issues.

Thanks,
Brett