-
Notifications
You must be signed in to change notification settings - Fork 4
Firmware
Firmware available on Google Drive hosted by Jeremy.
You can make sure that the firmware compatible with the HGCROC is active by looking in /opt/ldmx-firmware/.
For example
[eichl008@umn-zcu102-ldmx ~]$ ls -l /opt/ldmx-firmware/
total 8
lrwxrwxrwx 1 root root 30 May 29 17:01 active -> /opt/ldmx-firmware/hcal-zcu102
drwxr-xr-x 3 root root 4096 May 29 17:01 hcal-zcu102
drwxr-xr-x 3 root root 4096 Apr 11 16:37 lpgbt-zcu102You can check the version of this firmware by inspecting the name of the installed RPM.
[eichl008@umn-zcu102-ldmx ~]$ rpm -qa '*dualtarget-zcu102*'
ldmxfw-hcal-zcu102-20250529_120007-10dbd92.noarch
Loading Firmware
On the ZCU, Jeremy has been packaging the firmware within RPMs which we can "install" and then "load".
- Copy the RPM from the Google Drive onto the ZCU somehow
- Install the RPM onto the system:
sudo dnf install /full/path/to/ldmxfw-dualtarget-zcu102-YYYYMMDD_HHMMSS-XXXXXXX.noarch.rpm - Load firmware:
sudo fw-loader reload
cat /proc/datadev_N # N is index of Bittware you are talking to
cat /proc/datadev_0 # eg
Loading Firmware
If a SLAC-based firmware is already loaded on the card, then we can use Rogue to interact with the card since the SLAC firmware enables this Rogue connection.
# needs an environment that has access to PyRogue
sudo python path/to/slaclab/axi-pcie-core/scripts/updatePcieFpga \
--dev /dev/datadev_0 \ # change `0` if more than one Bittware card
--path path/to/directory/of/firmware/images
If the card does not have SLAC firmware (or it seems to be broken for some reason), then we need to fallback to using Bittware's software toolkit. Below, I've copied a summary of what I've done at UMN. You may need to change the --device index if there are more than one Bittware card in the machine. You will need to create a Bittware account and share the Bittware card's serial number in order to get access to the bwconfig software.
# 1. clear old firmware
bwconfig --device=0 --type=fpga --index=0 --erase
# 2. load new firmware into boot space
bwconfig --device=0 --load=path/to/image.bit --type=flash --index=0
# 3. boot FPGA from flash
bwconfig --device=0 --type=flash --index=0 --start
Now that the FPGA is configured and booted (double check with bwconfig --list --device=0 to make sure FPGA 0 is "Loaded"), we need to have the system re-enumerate the PCIe busses connected to the system. Technically, you can do this with writing to some /sys files but that was not working on the host at UMN[0]. Instead we needed to do a soft reboot (sudo reboot). The soft is important - when doing a hard reboot (full power cycle) on the host at UMN, it seemed like the PCI enumeration happened before the FPGA is full powered up - only a soft reboot (where the FPGA is left powered on) allowed for the card to be observed by the kernel.
You can make sure the card is visible with lspci although this does not work if the firmware on the FPGA is broken in such a way to prevent it from communicating its headers to the kernel. Bittware provides some reference firmwares that are helpful for testing in case you are suspicious of the firmware you are attempting to load.
[0]: This amounts to doing three writes:
# 1. detach device from driver
echo <PCI-address> | sudo tee /sys/bus/pci/devices/<PCI-address>/driver/unbind
# 2. remove device from enumeration
echo 1 | sudo tee /sys/bus/pci/devices/<PCI-address>/remove
# 3. rescan the PCI busses
echo 1 | sudo tee /sys/bus/pci/rescan
where <PCI-address> looks like NNNN:MM:XX.Y and is what was presented in lspci as the Bittware or SLAC card (depending on the firmware that was loaded).
For the Bittware card with focus on HcalBackplane or Ecal Single Module Motherboard (SMM).
Add an extra "soft" optical-link reset
Functional Fast Control and DAQ for single-link
Update for EcalSMM and prep for Fast Control and DAQ
Original, able to do basic Slow Control motions with an HcalBackplane
This firmware is for the ZCU102 optically connected to an HcalBackplane or Ecal Single Module Motherboard (SMM).
- patched up trigger data capture block
- inclusion of basic any-high-peak trigger algorithm
- inclusion of firmware histogram block
- second
trigpath-1block for potential access to ECON-T2 of HcalBackplane (untested)
- latest build of same commit, unsure if there were uncommitted fixes to this build
- more attempts to get BER down to zero between TRG lpGBT and software (ended up being an lpGBT configuration issue)
- partial fix to optical fiber error counting (works on DAQ fibers, unsure if interpreting correctly on TRG fibers)
- Include capture of words from the the TRIG fiber and we can now observe ECON-T/lpGBT alignment: notes.
- Add
econd-buffer-1to enable data capture from SFP2/3
Update to patch synchronizing clock between DAQ and TRG links. TRIG_LINK_CLOCK and TRIG_LINK_WORD now match the DAQ_* rates (assuming appropriate setup procedures have been done).
Another update to fix shifting the readout pointer now that the ECOND and HGCROC are aligned, we could observe non-empty data packets.
Update to the dual target firmware to read empty data packets from the mounted ECOND.
Original "dual target" firmware supporting access to the HGCROC via the Hcal backplane board and its lpGBTs.
For the ZCU and focused on fiberless connections where the HGCROC Board is connected directly to the ZCU.
Patched an issue with the data alignment causing nibbles of data to be shuffled within a word.
You can actually observe the bug on prior versions of the firmware. After aligning the elinks, change the idle frame and then observe the elinks.
ELINKS
AUTO
EXIT
ROC
POKE
DIGITALHALF_0
IDLEFRAME
0x1234567
EXIT
ELINKS
SPY
0
This last command would return 0xa5274163 instead of the expected 0xa1234567.
Patched an issue where the readout pointer was not always being advanced.
Original