DT5215 — Firmware update and SD card: what is inside each
The DT5215 FERS concentrator (rev. 3, USB) is delivered through two different packages. They overlap in what they carry, but they are not interchangeable: one refreshes a board that is already working, the other builds a board from an empty internal memory.
Which one do I need
| Situation | Package |
|---|---|
| The board works, I want a newer version | Firmware update (dt5215-upgrade.niu), uploaded from the web interface. Keeps the board identity and the saved configuration. |
| The board is new, unbootable, or must be re-imaged | SD card (sdcard.img). Boots the board from the card and reinstalls the whole system on the internal memory, erasing it. |
Firmware update — dt5215-upgrade.niu
An encrypted archive uploaded to a running board from the web interface. The board unpacks it, replaces the boot files and reboots on the new version. Nothing is repartitioned and nothing is erased.
What it contains
| Path | Content |
|---|---|
/caen/boot/BOOT.BIN | Boot image: FSBL, FPGA bitstream, PMU firmware and U-Boot |
/caen/boot/image.ub | Linux kernel and device tree |
/caen/firmware/bitstream.bin | FPGA firmware: links towards the FERS boards, DMA data path, board I/O |
/caen/software/fers_bridge.elf | Bridge application: chain enumeration, data streaming, REST API |
/caen/www/ | Web interface served by the board |
/caen/scripts/ | Startup, USB gadget and AD9545 clock generator tools |
/caen/config/ref*.txt, regs_i.txt | Clock reference profiles for the AD9545 |
/caen/version, /caen/config/package_version.inf | Version stamp shown in the web interface |
/etc/udhcpd.conf, /etc/udhcpd2.conf | DHCP server serving the USB connection |
What it does not contain
- The Linux root filesystem: the operating system userland stays as it is
- The partition layout of the internal memory
- The board identity and the saved configuration, which are left untouched
Applying it
Upload the .niu file from the web interface of the board. It is encrypted, so it can only be
applied by a DT5215; there is nothing to unpack by hand. Once accepted, the board writes the new
boot image and kernel, replaces the pages of the previous web interface with redirects to the new
one, and reboots on its own.
The connection drops while the board restarts. After the reboot the version shown in the web interface is the one that was uploaded. If the browser still shows an old page, force a reload: the previous interface may be cached.
SD card image — sdcard.img
A bootable card written with a disk imaging tool. The board boots from it instead of its internal memory and runs an installer that wipes the internal memory and writes a complete system onto it. The card is only needed during the installation.
How the card is laid out
| Partition | Content |
|---|---|
| 1 — FAT32, 128 MB, bootable | BOOT.BIN, image.ub, boot.scr and bic.cfg: what the board needs to start from the card |
| 2 — ext4, 1 GB | The installer system: a complete Linux root filesystem with the same /caen tree as the update, the installer scripts, and the two archives that will be written on the internal memory |
What gets installed on the board
| Source | Destination |
|---|---|
bootpart.tar.gz | Boot partition: boot image, kernel and the U-Boot script for the internal memory |
rootfs.tar.gz | Root partition: the whole operating system, plus the FPGA firmware, the bridge application, the web interface and the board scripts |
bic.cfg | /caen/config/bic.cfg: board identity, copied from the card at the end of the installation |
What it does not preserve
- Everything on the internal memory is erased, including the saved configuration
- Network settings return to the factory defaults
- The board identity comes from the card, not from the board
Set the board identity before installing from a card.
bic.cfgon the card carries the identity of the board being installed: product id, model code, PCB revision, number of links and the 10G MAC address. The file shipped in the image has the product id set to the placeholder##REPLACE_WITH_BIC##and must be filled in for the specific board, otherwise the installed system starts without a valid identity.
What happens when the board boots from the card
| # | Step | Front panel LEDs |
|---|---|---|
| 01 | Three second window on the serial console. Pressing any key on /dev/ttyPS0 stops the installer and leaves the board in emergency mode, running plain Linux from the card. Nothing is erased. | — |
| 02 | The internal memory is wiped and repartitioned into a 512 MB bootable FAT partition and an ext4 partition on the remaining space. | 0xFE |
| 03 | The two filesystems are formatted, FAT32 for boot and ext4 for root. | 0xFC → 0xF8 |
| 04 | The boot partition is written with the boot image, the kernel and the U-Boot script. | 0xF0 → 0xE0 |
| 05 | The root filesystem is unpacked onto the internal memory. | 0xC0 |
| 06 | The board identity is copied from the card into /caen/config/bic.cfg. | 0x80 |
| 07 | Installation complete. The front panel LEDs blink continuously: power the board off, remove the card, and start it again. | blinking |
The values are the front panel LED pattern driven over I2C while the installation runs, so the progress can be followed without a serial console attached. Fewer lit LEDs means further along.
What each one replaces
| On the board | Firmware update | SD card |
|---|---|---|
| FPGA firmware | Replaced | Replaced |
| Bootloader and Linux kernel | Replaced | Replaced |
| Linux root filesystem | Left as it is | Replaced |
| Bridge application and web interface | Replaced | Replaced |
| Clock reference profiles | Reset to the shipped profile | Reset to the shipped profile |
Board identity bic.cfg | Preserved | Taken from the card |
| Saved configuration | Preserved | Lost |
| Partition layout of the internal memory | Untouched | Recreated |
Both packages are built from the same components and carry the same version stamp, so a board installed from a card and a board updated in the field end up running identical firmware, application and web interface. The difference is only what is preserved on the way there.
DT5215 Firmware Update
Aggregator of the DT5215 release: pulls the FPGA firmware, the bridge application, the web interface, the rootfs overlay and the PetaLinux boot binaries, assembles them in the layout
License:
Trending Products
DAQ141
High-performance, fully integrated digitizer developed by Nuclear Instruments for advanced SiPM-based muon detection systems
DAQ141-6
High-performance, 6-channel waveform digitizer developed by Nuclear Instruments for demanding scientific and industrial data acquisition.
DAQ121
High-performance, fully integrated digitizer developed by Nuclear Instruments for advanced SiPM-based muon detection systems.
