- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
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:
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.
링크가 복사됨
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
It's very important for us so I'll be waiting.
Just wanted to suggest:
Since the ARM compiler built image loads successfully with debugger, and since the debugger uses the ELF image and not the final .bin with the mkimage header, maybe a good starting point will be to check if the supplied SDRAM scatter file is suitable for use with the preloader and mkimage header. If not, what are the required changes.
Thank you for your help.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Hi,
Are you running both cases i.e. application from the SDRAM?
If it is SDRAM, preloader scatter file needs to be updated with the SDRAM starting address, size and application stack and heap size.
Regards
Tiwari
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Hi,
Yes, I ran both cases from SDRAM. In my first post I provided several guides (received them from this forum) and sample projects, all provide a modified scatter file for SDRAM.
The problem is that in the ARM case, while using the SDRAM scatter file, I can load the bare metal to the SDRAM only with debugger. If I use the preloader its not working.
With GCC I'm able to load the program with and without debugger.
Since the debugger uses the output elf and not the final image containing the mkimage header addition, maybe there is something wrong with this part (ARM linker/ scatter file case)
I looked for a guide/example showing how to load the program from SDRAM without debugger (while using ARM tools) but didn't find one.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Hi,
Thank you for your help and private message.
I apologize but I think you misunderstood me:
I have no problem with the GNU toolchain. If I use the GNU compiler & linker I'm able to load my bare metal app to the SDRAM with and without debugger.
My problem is when I'm using the ARM toolchain. When I use the ARM compiler & linker I'm able to load my bare metal app to the SDRAM only with the debugger.
My goal is to load it to the SDRAM with the preloader and devkit only without debugger.
Thanks
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Hi,
1. I want to use the ARMCC since its better suited for the ARM architecture. Its a compiler released by ARM specifically for their architecture and I want to utilize its power.
2. I don't understand the relation to Hwlib?
I don't have any problems with Hwlibs.
3. My problem is probably with the scatter file. I need help/example with loading a bare metal app to the SDRAM without debugger.
Once the elf image (.axf) is ready, its converted into binary file and we add the mkimage header in order for the preloader to load it. Something in that process (and the scatter file) is wrong.
I need your help with that.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Hi,
Just to update you here.
I have filed internal request to build the steps on ARMCC but there is no deadline for this to fix as team is engaged on newer product support.
As I have suggested previously, please use the GNU CC examples and procedure as this working fine.
With that, now I will transfer this thread to community support.
Thanks for understanding.
Regards
Tiwari
