6 Troubleshooting
6.1 Port "xillybus_0_conduit_..." does not exist
During the compilation of the Xillydemo project with Quartus II, error messages like the following may appear:
Error (12002): Port "xillybus_0_conduit_M_AXI_ARADDR" does not exist in macrofunction "u0" File: xillybus.v Line: 442 Error (12002): Port "xillybus_0_conduit_M_AXI_ARBURST" does not exist in macrofunction "u0" File: xillybus.v Line: 442 Error (12002): Port "xillybus_0_conduit_M_AXI_ARCACHE" does not exist in macrofunction "u0" File: xillybus.v Line: 442 Error (12002): Port "xillybus_0_conduit_M_AXI_ARID" does not exist in macrofunction "u0" File: xillybus.v Line: 442 Error (12002): Port "xillybus_0_conduit_M_AXI_ARLEN" does not exist in macrofunction "u0" File: xillybus.v Line: 442 Error (12002): Port "xillybus_0_conduit_M_AXI_ARLOCK" does not exist in macrofunction "u0" File: xillybus.v Line: 442 Error (12002): Port "xillybus_0_conduit_M_AXI_ARPROT" does not exist in macrofunction "u0" File: xillybus.v Line: 442 Error (12002): Port "xillybus_0_conduit_M_AXI_ARREADY" does not exist in macrofunction "u0" File: xillybus.v Line: 442 Error (12002): Port "xillybus_0_conduit_M_AXI_ARSIZE" does not exist in macrofunction "u0" File: xillybus.v Line: 442 ...
The failure to find the ports probably indicates that a script that was supposed to run before compilation didn’t run. This is likely a result of a faulty change in the QSF file or an improper adoption of the sources into a custom Quartus II project. For more details, see paragraph 5.3.
6.2 Problems with USB keyboard and mouse
Almost all USB keyboards and mice meet a standard specification for compatible behavior, so it’s unlikely to face problems with devices that aren’t recognized. The first things to check if something goes wrong are:
-
Was the device connected when Linux performed boot? If not, reboot Linux with the mouse and/or keyboard connected.
-
Are you using the correct USB plug? It should be the one marked “HPS USB”, in the middle.
-
If a USB hub is used, attempt to connect only a keyboard or mouse directly to the USB cable that goes to the SoCKit board’s OTG port.
Helpful information may be present in the general system log file, /var/log/syslog. Viewing its content with “less /var/log/syslog” can be helpful at times. Even better, typing “tail -f /var/log/syslog” will dump new messages to the console as they arrive. This is useful in particular, as events on the USB bus are always noted in this log, including a detailed description on what was detected and how the event was handled.
Note that a shell prompt is also accessible through the USB UART, so the log can be viewed with a serial terminal if connecting a keyboard fails. Please refer to SoCKit board’s documentation regarding how to set up a UART link.
6.3 File system mount issues
Experience shows that if a proper microSD card is used, and the system is shut down properly before powering off the board, there are no issues at all with the permanent storage.
Powering off the board without unmounting the root file system is unlikely to cause permanent inconsistencies in the file system itself, since the ext4 file system repairs itself with the journal on the next mount. There is however an accumulating damage in the operating system’s functionality, since files that were opened for write when the power went off may be left with false content or deleted altogether. This holds true for any computer being powered off suddenly.
If the root file system fails to mount (resulting in a kernel panic during boot) or performs mount read-only, the most likely cause is a low quality microSD card. It’s quite typical for such storage to function properly for a while, after which random error messages begin to appear. If /var/log/syslog contains messages such as this one, the (Micro)SD card is most likely the reason:
EXT4-fs (mmcblk0p2): warning: mounting fs with errors, running ec2fsck is recommended
To avoid these problems, please insist on a Sandisk device.
6.4 “startx” fails (Graphical desktop won’t start)
Even though not directly related, this problem is reported quite frequently when the microSD card is not made by Sandisk. The graphical software reads a large amount of data from the card when starting up, and is therefore likely to be the notable victim of an microSD card that generates read errors.
The obvious solution is using a Sandisk microSD card.