otpu-lock

otpu-lock [--dev path] [--wait SEC] [--prebuild MODEL:WF:HF]... [--prebuild-cfg cfg] -- command [args...]

otpu-lock runs a command while holding the openTPU device lock. Use it for steps that are not openTPU tools but must not overlap a run (a JTAG reload, a driver reload, a PCIe rescan), or for a sequence of runs that must not be interleaved with others. After `pip install -e .` in the FeSens/openTPU tree it is installed as a console script (`opentpu.host.runstate:hold_main`).While the lock is held, OTPU_LOCK_HELD is the device name and OTPU_LOCK_PID is otpu-lock's pid. OpenTPU tools inside the command see those variables and run under this lock instead of waiting for it. Signals delivered to otpu-lock are forwarded to the child; otpu-lock exits with the child's status.--prebuild first quantizes the named runs' 4-bit weights into the image cache at nice 19, before waiting for the lock, so the tools inside the command do not quantize while they hold the card. A failed prebuild is printed to stderr and the command still runs (it will quantize under the lock).

--dev path

XDMA device prefix (default `/dev/xdma0`).

Seconds to wait for the lock (default 3600).

Quantize into the image cache first, outside the lock. Repeatable. MODEL is a short name or checkpoint; WF and HF are layer and head weight formats.

Card configuration for --prebuild.

Command to run. Required. The `--` separator is optional when the command does not look like an option; the parser takes the remainder as the command.

With no command, the tool errors (`no command`). Nested otpu-lock on the same device keeps the outer holder named. The child is placed in its own process group when not in the foreground so signals can be forwarded. --prebuild needs the openTPU tree on PYTHONPATH. The lock is a host-side advisory lock around the XDMA device; it does not replace flock for unrelated files. The command is installed only via `pip install -e .` in the openTPU tree.

otpu-lock is part of the openTPU host tools (Apache-2.0, FeSens). Host runners such as otpu-chat and otpu-serve take the same device lock through `busy_exits`; otpu-lock exposes that lock so validation scripts, JTAG reloads, and otpu-setup --rescan can be serialized with those runners.

otpu-chat(1), otpu-serve(1), otpu-selftest(1), otpu-setup(1), flock(1)

Source code · Documentation