# brintOS SOM programming station
This machine programs an Emcraft STM32F7 SOM through a debug adapter attached to
this machine over WebUSB: an Olimex ARM-USB-TINY-H by default (JTAG), a SEGGER
J-Link (JTAG or SWD), or a standalone ST-LINK/V2 (SWD).
som-mfg-f7 # program a whole SOM, unattended: U-Boot, kernel, boot test, MAC
som-mfg-f7 --dry-run # check the set-up first; touches no board
som-program-f7 # write U-Boot into the SOM's eNVM and verify it
som-program-f7 --adapter jlink # the same through a J-Link (JTAG)
som-program-f7 --adapter jlink --transport swd # ... over SWD
som-program-f7 --adapter stlink # the same through an ST-LINK/V2 (SWD)
som-program-f7 --help # --adapter, --transport, --speed, --backup, --readback, --dry-run
openocd here also carries the nRF53/nRF91 flash driver. A Nordic target is
SWD-only, so select SWD before its config. On an nRF9160-DK, put an external
J-Link on its Debug in header; its own on-board J-Link cannot be used from
brintos.io yet (guide §4.3):
openocd -f interface/jlink.cfg -c "transport select swd" -f target/nordic/nrf91.cfg
It can also open the SOM's serial console, once the carrier's USB-serial bridge
(P1) is granted to this machine too:
som-console # the SOM's console in picocom, 115200 8N1; C-a C-x leaves
som-console --list # every USB-serial port this machine has
minicom -b 115200 -D $(som-console --find)
The full procedure — what connects where, the host set-up, the kernel half, and
what to do when it does not work:
/usr/share/brintos-som-station/flashing-an-stm32f7-som-from-brintos.md
A USB Ethernet adapter granted the same way puts this machine on your network,
with a TFTP client and server (Developer mode needed; no DHCP):
ip link set eth1 up; ip addr add
/24 dev eth1
curl --tftp-blksize 8192 -o /tmp/ tftp:///
/etc/init.d/tftpd-hpa start # serves /var/lib/tftpboot
Cabled straight to the SOM's RJ-45, the adapter is how the SOM gets its kernel:
its U-Boot fetches `stm32f7/rootfs.uImage` from this machine with `run update`
(the flashing guide's section 6, which also times full SOM programming).
`som-mfg-f7` does all of it in one run, the way Emcraft's production station
does: with the Olimex (P3), the board's console (P1) and the Ethernet adapter
attached, it writes U-Boot, writes the kernel, boots the board and pings this
machine from it, and leaves the environment the board ships with. It gives each
board the next MAC address from the station's list,
`/var/lib/brintos-som/mac/maclist`, which you fill in once (flashing guide
section 6.4).
How, what was measured, and what does not work yet:
/usr/share/brintos-som-station/usb-ethernet-and-tftp.md
What the station carries:
| Path | What it is |
|---|---|
| `/var/lib/brintos-som/mac/maclist`, `lastmac` | the MAC range `som-mfg-f7` hands out, and the last one it gave |
| `/var/lib/brintos-som/som-mfg-f7.exp` | if present, runs in place of `som-mfg-f7`: a fixed script without a new image |
| `/usr/share/brintos-som/stm32f7/u-boot.bin` | the firmware `som-program-f7` writes |
| `/usr/share/brintos-som/stm32f7/PROVENANCE` | where that binary came from, and its sha256 |
| `/usr/share/brintos-som/stm32f7/rootfs.uImage` | the SOM's kernel, which its U-Boot fetches from this machine over TFTP and writes into NOR |
| `/usr/share/brintos-som/stm32f7/rootfs.uImage.PROVENANCE` | which release the kernel is, its sha256, and the CRC32 U-Boot prints over it |
| `/var/lib/tftpboot/stm32f7` | a link to that directory: the TFTP server serves both files as `stm32f7/` |
| `/usr/share/openocd/scripts/mfg-jtag.cfg` | the one place the JTAG adapter is named |
| `/usr/share/openocd/scripts/interface/jlink.cfg` | the J-Link, for `--adapter jlink` |
| `/usr/share/openocd/scripts/interface/stlink.cfg` | the ST-Link, for `--adapter stlink` |
| `/usr/share/openocd/scripts/target/nordic/` | the Nordic target configs, under upstream's newer path |
| `/usr/share/openocd/scripts/board/emcraft-som-stm32f7.cfg` | the SOM's openocd board config |
| `/boot/hardwarejs.html`, `/boot/hardwarejs.js` | the HardwareJS runtime this machine launches with in Developer mode |
| `/usr/share/brintos-hardwarejs-runtime/PROVENANCE` | the HardwareJS commit that runtime was built from, and its sha256 sums |
To check the station itself, with no board attached:
brintos-selftest 99-som-station.test 99-som-console.test 99-minicom.test
With P1's bridge granted, the last two also exchange a line with the board.
Snapshots and Developer mode:
- This machine runs in **Developer mode** (the machine's Settings). The site then
runs the HardwareJS in this image's `/boot` (its commit is in `PROVENANCE`)
rather than its own release. `expect`, `openocd` and USB devices need it. A
snapshot is the filesystem only, so a fork has to turn Developer mode on too.
- `latest` is the current station. It moves only after a change passes the
station's test plan on brintos.io.
- Fixed snapshots are tags named by date and content (`2026-10-01-minicom-serial`).
They never change, each has a note of what it holds and its known issues, and
only the last few are kept. A tag ending in `-dev` carries a patched runtime.