I’ve been trying to use the Intel TSE on an Arria 10 but kept getting aborts in both u-boot and Linux if I enable the driver. After much hunting I found this post DE10-Nano U-boot-socfpga: Enable bridges lwhps2fpga which suggested the LW H2F bridge was not enabled, and indeed it was not. This meant that the CPU tried to access ctrl registers in the TSE on a bus in reset, hence the bus error/abort. Enabling the bridge in u-boot with “bridge enable” fixed the issue in Linux, but not in u-boot.
It look like even though the u-boot device tree created from the Quartus handoff file contains enough information for u-boot to determine that a bridge is in use and therefore should be enabled (“init-val = <1>” property in the “hps_fpgabridge1” entry) it does not do this programatically. The socfpga_reset_deassert_bridges_handoff() function which enables the bridges based on the DT property is only ever called from the interactive “bridge enable” command.
This is not so much of an issue for using the TSE only from Linux as the “bridge enable” command can be added to the default bootcmd list and then it all works, but for u-boot this is not run until after it tries to probe the TSE and aborts because the bridge/bus is in reset.
So a few questions arise from this:
Firstly is there a way to run the “bridge enable” command earlier in u-boot, before it probe the network (“Net: …”) given this seems to be the only way to bring the bridges out of reset in the reset_manager.c?
Why is the bridge enabling not done automatically as part of the u-boot initialisation process and before it tries to probe the TSE if that’s enabled?
Where might be a safe place to put a call to socfpga_reset_deassert_bridges_handoff() in u-boot to do this as part of it’s initialisation?
Am I just missing something obvious here which would otherwise make this work?
Any help most welcome.