Arria 10 HPS Bridge Lockup after Reset

Hi Jingyang,

Apologies, I was away last week.

By JTAG debugger, I'm referring to using a USB-Blaster and the debugger in ARM Development Studio (2022).

I'm not using U-Boot proper as it is too big to use without DDR RAM. Only the U-Boot SPL. For reference, this is the U-Boot repository I'm using: https://github.com/UARPGitHub/u-boot-socfpga - it's a slightly modified version of the v2023.10 branch, which has had a few minor tweaks to cope with there being no DDR RAM (basically changing the defconfig along with removing some of the code which initialised the DDR RAM).

The FPGA is configured from an EPCQL device using Active Serial.

---

After much playing around, there appear to be two seperate problems going on simultaneously which is why everything was completely confiusing.

The first was that for some reason occasionally Qsys/PlatformDesigner inexplicably added in random second reset controller with synchronous assert/deassert. This meant that the FPGA side of the HPS bridge was not being reset because the clock was no longer present so the synchronous assert didn't do anything. After regenerting from Qsys without changing anything the random reset controller disappeared leaving the intended async assert/sync deassert controller that was already there allowing the bridge to be reset properly on a cold processor reset.

This seems to be a wierd Qsys bug. I regenerated the code again after changing something completely unrelated (an Av-MM address) and again the random second reset controller appeared in the HDL. But then again disappeared after another regenerate and no changes. So who knows what that is about. I'll just have to keep checking the HDL after each generate to make sure it is not there. Weird.

----

I can only assume the second part of the problem might be some sort of caching issue but I could be wrong.

On a first boot after resetting the processor, running through U-Boot SPL, which then executes my bare-metal program, the processor after running through the various C initialisation routines tries to access the FPGA Manager registers to read GPI (0xffd03014), using a simple dereference "x = *((volatile unsigned int*)0xffd03014)".

This works fine, I get the value.

I then do this read again a few lines later, and again it works fine, I get the value. My software then runs perfectly fine.

In some instances, I have to call back to the start of the software without resetting the processor (a sort of manual warm reset) because I'm jumping between two bare-metal images (a recovery image and an application image which are both in on-chip RAM at the same time but different address regions).

If I jump to the entry point of my already loaded RAM image - e.g. `BX 0xFFE30040` - but not resetting the processor, it will then run the bare-metal program again from the start skipping the preloader (but no hardware was reset so this shouldn't matter). I was originally trying to do this using a warm reset but that was causing other issues, so now I'm trying to skip the reset all together.

After going through the various C library initialisation, it will happily do the first read from the GPI register perfectly fine.

But then on the second attempt to read the same register address, the processor locks up and the debugger is unable to communicate with it. I get the following from the console

interrupt
ERROR(TAD9-NAL30): 
! Unable to stop device Cortex-A9_0
! Cannot stop target.

If I repeat the process, but instead set a breakpoint just before the second attempt to read from the GPI register, I can use the Memory view in ARM Development Studio to read the GPI register, and it reads fine:

Then if I let the processor run again, it has no problems accessing the memory address itself and continues on running. But at this point it will then randomly lock up later in the program accessing memory in other registers (e.g. 0xC0000000 or 0xFF200000).

The trick of viewing the value of the register in the debugger before stepping over the processor line that accesses it doesn't work for accessing registers on the far side of the HPS bridge.

---

It's hard to explain because everything to do with the HPS on the Arria 10 seems to be so incredibly flakey.

I use a very similar approach on a Cyclone V device and don't recall having any of these issues, everything just works as you might expect.