Occasional ContributorHow is the reset implemented when I issue a reset reset.system command from the DS-5 debugger (connected to the target via the Altera Arria 10 SoC bare metal debug agent) ?
I see different behaviour when I issue this on the A10 dev kit and our A10 custom hardware and need to understand what is happening beneath the DS-5 covers to investigate further.
Regular ContributorHi,
Can you explain what is the different behavior that you are observing?
Regarding the reset command in DS-5 please read the reset description from ARM infocenter:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0452o/CIHGEEBG.html
Occasional ContributorHi -
I do not see our UEFI bootloader run following the reset. I see the same thing when the HPS WDOG reset occurs.
If I connect the debugger and halt the core, we are stuck in a v tight loop at:
S:0x000003EC : LDR r1,[r0,#0]
S:0x000003F0 : ANDS r2,r1,#1
S:0x000003F4 : BEQ {pc}-8 ; 0x3ec
This is reading the the i_fpga_mgr_fpgamgrregs/misci register at 0xffd03018 looking for bit 0 to be set.
It's always 0 following the HPS WDOG reset.
Does the fact that it is checking this suggest that the boot from the primary boot device(QSPI) has failed ?
Thanks !
Paul
Occasional ContributorWe've identified the problem here. The QSPI flash requires a reset to allow the boot to work. See:
https://rocketboards.org/foswiki/Documentation/SocBoardQspiBoot
Regular ContributorHi,
Great! Are you applying the Solution #2 that solve your issue?
I would like to know if your initial problem was also solve.
