I have been working on a Altera DE1-SoC Development Board for 8 months. The system I was working on includes a Cyclone V FPGA chip, particularly the 5CSEMA5F31C6N. It was running an embedded Linux operating system on chip.
All was well and development was on-going. Two weeks ago, a new custom board was put together by a hardware engineer in the company. The design and components were mostly similar to that of the Development Board. All HPS related pins are wired the same way, with one main difference being that the default console port was UART1 instead. That issue has since been resolved and I now am able to receive the U-boot and Kernel messages through UART1.
But the system did not completely boot. I have pinpointed this to multiple reasons. Firstly, I had an init.d script that would export the GPIO LEDs and create a sysfs file. Exporting the gpio pin works, however, changing the direction, or changing the value, or reading from it, causes the system to freeze. I disabled that function on the init.d script and rebooted the device. This time the boot failed on another init.d script line. This line was going to change the value of a register in the lightweight bridge. The command was devmem 0xFF200XXX 32 1, with XXX being the specific register.
I tried using devmem on all bridges but all attempts would freeze Linux. I tried using devmem on the UART register of HPS, on the SDCard register of HPS (referenced here), and it does not freeze.
I can verify that the bridge is enabled by reading the state sysfs file of each bridge:
I can also verify that the bridges are linked to the driver from this dmesg output:
[ 1.198534] fpga_manager fpga0: Altera SOCFPGA FPGA Manager registered
[ 1.205910] altera_hps2fpga_bridge sopc@0:fpgabridge@0: fpga bridge [hps2fpga] registered
[ 1.214385] altera_hps2fpga_bridge sopc@0:fpgabridge@1: fpga bridge [lwhps2fpga] registered
[ 1.222994] altera_hps2fpga_bridge sopc@0:fpgabridge@2: fpga bridge [fpga2hps] registered
I have enabled all three bridges in the hps configuration using Quartus Platform Designer.
I also have the following lines in my u-boot.scr:
fatload mmc 0:1 $fpgadata soc_system.rbf;
fpga load 0 $fpgadata $filesize;
setenv fdtimage soc_system.dtb;
run bridge_enable_handoff;
run mmcload;
run mmcboot;
I have also attempted enabling the bridges through the U-boot command line following these instructions.
However, I am unable to write anything into $l3regs:
SOCFPGA_CYCLONE5 # mw $l3remap 4l3remap_handoff
mw $l3remap $l3remap_handoff
SOCFPGA_CYCLONE5 # md $l3remap
ff800000: 00000000 00000000 00000000 00000000 ................
ff800010: 00000000 00000000 00000000 00000000 ................
ff800020: 00000000 00000000 00000000 00000000 ................
ff800030: 00000000 00000000 00000000 00000000 ................
ff800040: 00000000 00000000 00000000 00000000 ................
ff800050: 00000000 00000000 00000000 00000000 ................
ff800060: 00000000 00000000 00000000 00000000 ................
ff800070: 00000000 00000000 00000000 00000000 ................
ff800080: 00000000 00000000 00000000 00000000 ................
ff800090: 00000000 00000000 00000000 00000000 ................
ff8000a0: 00000000 00000000 00000000 00000000 ................
ff8000b0: 00000000 00000000 00000000 00000000 ................
ff8000c0: 00000000 00000000 00000000 00000000 ................
ff8000d0: 00000000 00000000 00000000 00000000 ................
ff8000e0: 00000000 00000000 00000000 00000000 ................
ff8000f0: 00000000 00000000 00000000 00000000 ................
SOCFPGA_CYCLONE5 #
I am building the OS using Buildroot 2016.05 with a 4.4 Linux Kernel. To create the .rbf, .dts, .dtb, preloader-mkpimage.bin, and u-boot files, I am using SoC EDS 18.1 [Build 625].
I have run out of things to try.
I would consider the issue solved if I am able to toggle an LED on and off from the Linux OS, using sysfs files.
Assuming that the hardware is correct, what else could be the cause and how do I fix it?