# OptiStick X5M: repacking a signed pack for SEI's Windows burn tool (one-step burn + eFuse)

Author: Wilber Zheng · 2026-11-05 · for Frank

## What it is for

SEI's factory tool (Aml_Burn_Tool V3.3.8, "secureboot" package) burns the image and writes the eFuse in one pass.
To do the eFuse part, it needs to find a key name inside the pack. Our build packs (e.g. prd100046) have no such entry,
so the tool reports "no secureboot or flag" and writes no eFuse. The fix is to add one small item to the pack. Nothing
else in the pack changes, and nothing is re-signed.

SEI's tool package: https://drive.google.com/file/d/1f9RAQ_houotGBduW44O5ebqUiEZ5dTo5/view?usp=sharing

## How the SEI tool finds the eFuse data (read from the tool package SEI sent)

1. The pack item `conf/keys` (`keys.conf`) holds a key **name**.
2. The tool looks that name up in `KeysProviderCfg.ini`, section `[OnlyOneManager]`, which maps it to a file under `license/`.
3. That file holds `efuse_obj` lines. The tool sends each line to the device during the burn as a fastboot
   `oem efuse_obj ...` command, which our U-Boot executes.

| keys.conf content | Maps to (in SEI's tool) | Result |
|---|---|---|
| `secure_boot_set` (what SEI first asked us to put in) | `SECURE_BOOT_SET` | That file is **not** in their `license/` folder, so nothing is written |
| `secure_boot_objects` (what their Gen4 pack uses) | `device.all.efuse.obj` | File present. Its sha256 `64cd069b…` equals our prod eFuse pattern (ota-trust `pattern.txt`) |

So the pack must say `secure_boot_objects`.

## Steps (Linux, Amlogic SDK packer)

Tool: `aml_image_v2_packer_new` from the Amlogic SDK (the same packer our build uses).

1. Check the source pack first: sha256/md5 match the published ROM, and
   `sb_check_bootloader.py --packer <aml_image_v2_packer_new> --inspect <pack.img>` passes
   (4 bootloader items at the prod root `abe6fe5d…`, ARB 0).
2. Unpack: `aml_image_v2_packer_new -d <pack.img> work/`
3. Write `work/keys.conf` with exactly `secure_boot_objects`: 19 bytes, **no trailing newline**
   (`printf 'secure_boot_objects' > work/keys.conf`).
4. Add one line to the `[LIST_NORMAL]` section of `work/image.cfg` (in the repacked result it is listed after `gpt.bin`):
   `file="keys.conf"		main_type="conf"		sub_type="keys"	file_type="normal"`
5. Repack: `aml_image_v2_packer_new -r work/image.cfg work/ <new.img>`
6. Verify:
   - Unpack `<new.img>` again. Every item must be sha256-identical to the source (DDR.USB, bootloader, boot, vbmeta,
     system...). The only new item is `keys.conf` (19 B).
   - Run `sb_check_bootloader --inspect` on `<new.img>`. It must pass with the same root `abe6fe5d…`.
   - Write the `.sha256` and `.md5` files next to the image.
7. Zip the image with its `.sha256`/`.md5` for SEI.

## Result for prd100046

- Source: `optistick-x5m-prd100046-1g-5103dea85-ab-all.img` (TO build, tag rom/prd100046).
- Output: `optistick-x5m-prd100046-1g-5103dea85-ab-all-sbobj.img`
  sha256 `d71e988105723d2c8f116dfc82a27801dc1605a23c2fc0c80c7db2dd959a26d6`, md5 `84c3a7089e3d5c082282173866c42092`.
- 15 of 16 items are byte-identical to the source. Only `keys.conf` is new. The bootloader still sits at prod root
  `abe6fe5d…`, ARB 0. The signatures are untouched, because `keys.conf` is outside the signed bootloader.

## Notes

- Effect on our firmware: none on the device. `keys.conf` is read only by the burn tool. It is not written to any
  partition, and the bootloader, boot, vbmeta and system are unchanged.
- The eFuse is written by our own U-Boot (fastboot `oem efuse_obj`), driven by SEI's tool. The data comes from SEI's
  `device.all.efuse.obj`, which equals our prod pattern.
- SEI has burned this pack with their Windows tool successfully.
- What we did prove on our side: a fused stick refuses an unsigned pack at BL1 ("Fail in first sect"), and the signed
  prd100046 burns and boots green.
- Do this for every new prod ROM, or add the `keys.conf` item to the build's pack step so the tool step is not manual.