DE10-Nano U-boot-socfpga: Enable bridges lwhps2fpga

[anchea1]

Hi,

As described in the below link managed to compile the v2018.05 version of u-boot.

DE10 Nano U-Boot issues

I’ve been building sdcard images for the DE10 Nano using u-boot v2018.05 with no issues, but if I try to use a newer version it builds just fine but doesn’t work. In order to build u-boot I’m using the following commands: make ARCH=arm CROSS_COMPILE=${CC} distclean make ARCH=arm CROSS_COMPILE=${CC} socfpga_de10_nano_defconfig make ARCH=arm CROSS_COMPILE=${CC} u-boot-with-spl.sfp Where ${CC} is a variable pointing to linaro gcc. After some debugging I found out that if I edit the “socfpga_d…

Source From:

GitHub - altera-opensource/u-boot-socfpga: Official Intel SOCFPGA U-Boot...

Upon completing the boot, all three bridges are registered.

dmesg |grep 2fpga
[ 1.090025] altera_hps2fpga_bridge sopc@0:fpgabridge@0: fpga bridge [hps2fpga] registered
[ 1.098459] altera_hps2fpga_bridge sopc@0:fpgabridge@1: fpga bridge [lwhps2fpga] registered
[ 1.106976] altera_hps2fpga_bridge sopc@0:fpgabridge@2: fpga bridge [fpga2hps] registered

But i see that they are disabled by default:

cat /sys/class/fpga_bridge/br*/state
disabled
disabled
disabled
disabled

Corresponding Bridge names:

cat /sys/class/fpga_bridge/br*/name
hps2fpga
lwhps2fpga
fpga2hps
fpga2sdram

After kernel boot and running application code, the LWHPS2FPGA accesses are resulting in Bus Error as below:

[ 271.701829] Unhandled fault: external abort on non-linefetch (0x818) at 0xb6085004
[ 271.709377] pgd = ee7a0000
[ 271.712075] [b6085004] *pgd=3fceb831
Bus error

Two questions:

1. How to enable these bridges : hps2fpga, lwhps2fpga, fpga2hps, fpga2sdram ?
2. Does this enabling to be done during U-boot or can it be handled by application after Linux kernel boot?

CC:Requesting @rafael_Mello to comment.

Using the GHRD DTB from the Golden Reference Design (with u-boot v2018.05)

cat /sys/class/fpga_bridge/br*/name
hps2fpga
lwhps2fpga
fpga2hps
fpga2sdram
cat /sys/class/fpga_bridge/br*/state
disabled
disabled
disabled
disabled
cat /proc/device-tree/model
Terasic DE10 NANO

Using u-boot v2013.01, these bridges are enabled after u-boot

cat /sys/class/fpga_bridge/br*/name
hps2fpga
lwhps2fpga
fpga2hps
fpga2sdram
cat /sys/class/fpga_bridge/br*/state
enabled
enabled
enabled
enabled
cat /proc/device-tree/model
Terasic DE10 NANO

[anchea1]

The best reference to enable these bridges in U-Boot i found below:

Boot successful but FPGA not configured

@Muhammad_Atif Hi, I’m fine. Hope that you are also fine. You can create scripts directly in the u-boot terminal to load the fpga. Right now I’m using a variable that holds the rbf file path, so if you change the variable you load another rbf file. If you add the following variables to you u-boot env and call the “loadfpga” in your “bootcmd”, it should work. fpgadata=0x2000000 fpgafile=/boot/TESTE2.rbf loadfpga=echo Loading fpga with ${fpgafile} bitstream;if test -e mmc 0:2 ${fpgafile}; the…

[rafael_Mello]

@anchea1
One way to enable the bridges is to use the command bridge enable in u-boot.
Another way to enable the bridges is to add the line bridge-enable = <1> on every bridge that you want to enable douring boot
If you want to enable the bridges from linux, you can create a devicetree overlay to enable the bridges adding the same line described before.
You can check some information from the kernel documentation

Right now I´m unable to create a good example, but I´ll try to upload one asap.

[davidb]

Thanks for this. I’ve been bashing my head against a wall trying to get the Intel TSE in fabric working from the HPS and wondering why I could not access the control registers through the LW H2F bridge, had assumed it was the TSE in reset or not clocked properly.

Given that the Quartus handoff file does seem to indicate that the LW H2F bridge is in use by way of the “init-val = <1>” property in the “hps_fpgabridge1” entry (even if it does not automatically populate the TSE device tree node), is there any sensible reason why u-boot does not automatically enable these bridges as part of its start up, just like it does for the hard peripherals?

The reset_manager.c source includes the socfpga_reset_deassert_bridges_handoff() to do this based on the device tree properties, but this is only run as a result of calling the cli “bridge enable” command. Having to create a script to enable the bridges through the cli before booting Linux seems odd. It also means you can’t use something like the TSE from u-boot as its already gone past the Net configure step and failed before it gets to the interactive (or scripted) u-boot prompt.