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: fpga_bridge state returns enabled

I can also verify that the bridges are linked to the driver from this dmesg output: dmesg output

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: writing into l3regs

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?

  • How can the hardware be correct when the same system bootet with the pirginal hardware? Shouldn't the question be: How to use Linux debug tools to find out the source of the problem to fix it? Can you show the dmesg where the new board freezes and show what would have been the next step in the working system's dmesg?
    – Philippos
    Jun 2, 2023 at 14:05
  • @Philippos Thanks the issue has been resolved, It was a hardware issue after all.
    – SMAero22
    Jun 9, 2023 at 0:36

1 Answer 1


Thanks for the reply. This issue has been resolved.

On the development board we are using a 50Mhz oscillator to provide a clock to the HPS peripherals, while a 25MHz signal is generated from that same 50Mhz clock which is then connected to the HPS clock pin on the fabric.

On the new board, we have not used the 50Mhz oscillator but instead opted for a 25Mhz oscillator instead. This time a single track connects to the HPS clock pin on the fabric directly from the oscillator.

We did not have any other clock to supply toward the HPS peripherals.

Therefore, we routed the dedicated HPS clock internally toward the input pin on the peripherals of the HPS. This was a mistake as this cannot be done on the top level architecture of the Cyclone V as the dedicated HPS clock pin is not a GPIO.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .