Mity CPU Platforms » MitySOM-5CSX Altera Cyclone V

Hi Bob,

The open("/dev/mem", ...) call itself doesn't touch any hardware, so it can't hang the system by itself. The hang almost certainly happens on the first read or write through the pointer you get back from mmap(). On the Cyclone V, an access across the lightweight HPS-to-FPGA bridge that nothing in the fabric answers stalls the bus, and the whole system locks up rather than giving you an error.

The usual causes are:

1. The FPGA isn't configured when Linux runs. U-Boot's fpgaload runs bridge enable even if loading the .rbf fails, so the bridges are open with no fabric behind them. Check your U-Boot log for errors around the fatload of dev_5cs.rbf, and make sure the .rbf on the FAT partition is the one built from your 4YA project.
2. The slave you access has no running clock or is held in reset. For example, if your delta_bus_cpu avalon_clock comes from a PLL or external clock that isn't running on the new build, any access to it waits forever.
3. Your code still uses addresses from the 42A design, such as the MEMCHECK component, that point somewhere different in the new design.

A quick way to narrow it down is to read the System ID from the Linux prompt (sysid_qsys is at offset 0x0 of the lightweight bridge):

memtool 0xFF200000 1

If that also hangs, the FPGA or bridge isn't set up (cause 1). If it returns your system ID, the bridge is fine and the problem is the specific component your application accesses (causes 2 or 3).

- Mike

Mike,

I checked all the clocks and resets and they seem fine.
Doesn't my /sys/class/fpga_bridge/ directory need entries like this?:

fpga_manager/fpga0/state = operating
/sys/class/fpga_bridge/br1/name = hps2fpga
/sys/class/fpga_bridge/br1/state = enabled
/sys/class/fpga_bridge/br0/name = lwhps2fpga
/sys/class/fpga_bridge/br0/state =enabled

As of now, I have NOTHING in the /sys/class/fpga_bridge/ directory.

root@mitysom-c5:~# cat /sys/class/fpga_bridge/br0/state
cat: /sys/class/fpga_bridge/br0/state: No such file or directory.

Could this be the source of my problem?
Please advise.
Thanks.

Bob N

By the way "memtool 0xFF200000 1" works fine and the U-boot build messages don't indicate that the RBF is not on the FAT portion.
I know that the RTL (for a particular RBF image) runs when Linux is loaded, because I have a blinking LED pattern (that I change every build) on the main base board that works when Linux comes up.

Bob,

The empty /sys/class/fpga_bridge/ directory is normal. Our device tree doesn't use the Linux bridge drivers, so those entries never show up. U-Boot turns the bridges on before Linux starts, which is why memtool 0xFF200000 1 works.

The lockup is not caused by open(). It happens when your program reads or writes an address that nothing in your FPGA design answers. The processor waits forever for a reply and the whole system freezes. So somewhere your code is using an address that doesn't exist in your new 4YA design. For example, the 42A design had a second bridge at 0xC0000000 for the FPGA RAM, and the 4YA design doesn't have it.

Did you also replace the preloader when you updated to the 4YA design?

To find the bad access, either:

• Read each address your program uses with memtool, like you did for 0xFF200000. The one that hangs is your problem.
• Or comment out the pointer reads and writes in your code, then add them back one at a time until the system hangs.

- Mike