What AutoRun.txt actually isAutoRun.txt 到底是什麼

The camera already had a shell相機本來就有一個 shell

Inside Ver.5.02 there is a debug and factory shell with 77 top-level commands — the thing a service technician would drive over a serial line. It is not hidden behind a jumper or a signed unlock. The command table sits at 0xC0BAC14C as 77 entries of { char name[0x14]; void *handler; }, and the dispatcher tokenises a line, compares the name, and calls the handler.

Ver.5.02 裡面有一個除錯兼工廠用的 shell,帶著 77 個頂層指令 —— 就是維修技師會透過序列埠去操作的那種東西。
它沒有藏在跳線或簽章解鎖後面。指令表放在 0xC0BAC14C, 是 77 筆 { char name[0x14]; void *handler; }; 分派器把一行文字切成 token、比對名字、然後呼叫對應的 handler。

Those commands read and write memory, poke hardware registers, drive the sensor's readout modes, and set menu values. The full list is written down, with the usage text asked from a live camera rather than reconstructed — that is the firmware's own help, printing itself.

這些指令能讀寫記憶體、戳硬體暫存器、驅動感光元件的讀出模式、設定選單數值。 完整清單記在這裡, 其中的用法說明是跟實機要出來的,不是重建的 —— 那是韌體自己的說明,自己印出來的。

And it reads a script off the card而且它會從卡片讀一個腳本

At boot the firmware calls XC_ShellScriptAutoRun, which looks for AutoRun.txt at the root of the SD card and feeds every line of it to that same dispatcher, on a shell task, with no permission gate of any kind.

開機時韌體會呼叫 XC_ShellScriptAutoRun, 它去找記憶卡根目錄下的 AutoRun.txt, 把裡面每一行餵給同一個分派器,在一個 shell 任務上執行, 而且沒有任何形式的權限關卡。

So a card is not a modified firmware. It is a list of commands the camera was always willing to run, in a file the camera always looked for.

所以一張卡不是被改過的韌體。 它是一份相機本來就願意執行的指令清單,放在一個相機本來就會去找的檔案裡。

From running commands to adding a recording mode從執行指令,到加進一個錄影模式

Shell commands alone will not give you a new sensor mode — there are too many writes, and a text file of them would take minutes to execute. So the AutoRun.txt is a loader. It writes a small stage-one routine into an unused region of RAM, hands it the payload sitting next to it in fpSup.BIN, and branches to it.

光靠 shell 指令做不出一個新的感光元件模式 —— 要寫的東西太多了,寫成文字檔要跑好幾分鐘。
所以 AutoRun.txt 是一個載入器: 它把一小段第一階段的程式寫進 RAM 沒在用的區域, 把旁邊 fpSup.BIN 裡的酬載交給它,然後跳過去執行。

fpSup.BIN is a plain container: the tag "VBIN", a section count, the entry address, the payload length, then one (destination, length) record per section with the blobs aligned to four bytes. The region it writes into is mapped out byte by byte:

fpSup.BIN 是一個很單純的容器:標記 "VBIN"、 區段數量、進入點位址、酬載長度,接著每個區段一筆 (目的位址, 長度) 記錄,資料本體對齊到四位元組。 它寫進去的那塊區域,是逐位元組畫出來的:

Depending on what is on the card, the AutoRun is 135, 189 or 195 commands, and the camera reaches its banner in about ten seconds. The progress bar you watch at boot is the loader reporting which block it is on.

看卡上放了什麼,AutoRun 會是 135、189 或 195 條指令, 相機大約十秒鐘會走到開機畫面。
你開機時看到的那條進度條,就是載入器在回報它正在處理第幾個區塊。

Why the camera is not at risk為什麼相機不會有風險

All of it lands in RAM. There is no flashing step, which is why there is no un-flashing step: the camera rebuilds the whole thing from the card on every power-on, and a boot without the file is a boot without any of the code.

全部都落在 RAM 裡。沒有燒錄這一步,所以也沒有「反燒錄」這一步: 相機每次開機都從卡片重新建立整套東西,而沒有那個檔案的開機,就是完全沒有那些程式碼的開機。

One thing does survive, and it is worth being precise about. A mode that appears in the camera's own menus is selected the way any setting is selected, and the camera records that choice in its own settings storage — the same storage that remembers your ISO and your file format, which was always non-volatile and which nothing here writes to directly. Delete the card's files and that choice is still there, now pointing at a mode with no code behind it. So a clean removal is settings back to stock first, file second. It is recoverable either way: load the card again and the mode exists again.

有一樣東西確實會留下來,這點值得講精確。 一個出現在相機自家選單裡的模式,選它的方式就跟選任何設定一樣, 而相機會把那個選擇記進它自己的設定儲存區 —— 就是記住你的 ISO 和檔案格式的那個儲存區,它本來就是非揮發性的, 而這裡的東西不會直接去寫它。
把卡上的檔案刪掉,那個選擇還在,只是現在指向一個背後已經沒有程式碼的模式。 所以乾淨的移除方式是 先把設定設回原廠,再刪檔案。
不過兩種順序都救得回來:把卡再載入一次,那個模式就又存在了。

The firmware does have a command that writes non-volatile storage — prom write, which can destroy the camera's calibration. Nothing shipped here goes anywhere near it, and the reference marks it accordingly. The worst a mistake in RAM can do is require the battery to come out.

韌體確實有一個會寫非揮發性儲存的指令 —— prom write, 它可以毀掉相機的校正資料。
這裡發行的東西完全不會靠近它,參考文件也標明了這點。 在 RAM 裡出錯,最糟也不過是要把電池拿出來。

What went wrong: the freeze出過的錯:凍結

An early USB shell froze the camera. Not immediately — it would run, record, and then some minutes later lock up hard enough that only pulling the battery helped. There were six different observed behaviours, and they contradicted each other. Being connected to a host prevented it, unless you recorded. Never connecting a host at all also prevented the shutdown case, but not the idle one.

早期的 USB shell 會把相機凍住。不是馬上 —— 它會正常跑、正常錄, 然後過幾分鐘卡死到只有拔電池才有用。
觀察到的行為有六種,而且彼此矛盾:接著主機就不會發生,除非你在錄影; 完全不接主機也能避免關機時那一種,但避不掉閒置那一種。

All six came down to a single mechanism. The worker had claimed two USB endpoints by writing the enable register directly, which meant it sat outside the firmware's own USB state machine entirely. The camera stayed alive only while the host held the link up and the native configuration was never re-run. Anything that tore the link down — idle suspend, the USB reconfiguration that happens when recording starts, the soft disconnect at shutdown — ran into the worker still arming endpoints the firmware had just disabled underneath it. The command register never cleared, a 60-second busy-spin started, and the interrupt storm took the camera with it.

六種全部歸結到同一個機制。
那個 worker 是直接寫致能暫存器去佔用兩個 USB 端點的, 這表示它完全站在韌體自己的 USB 狀態機外面。 相機能活著,只是因為主機一直把連線撐著、而原生的組態設定從來沒有被重跑。
任何會把連線拆掉的事情 —— 閒置暫停、錄影開始時發生的 USB 重新組態、關機時的軟中斷 —— 都會撞上那個 worker:它還在對端點下命令,而韌體剛剛在它底下把那些端點關掉了。 命令暫存器永遠清不掉,一個 60 秒的忙等開始跑,然後中斷風暴把相機一起帶走。

The fix was to stop owning anything. The shell that ships is parasitic on the camera's own PTP gadget: the firmware keeps the endpoints, creates and re-creates them across a recording reconfiguration, and the shell simply rides along. Recording survives it, and so does unplugging the cable. The full analysis is here, six symptoms to one mechanism, every step confirmed in the disassembly.

修法是什麼都不要擁有。現在發行的 shell 是 寄生在相機自己的 PTP gadget 上:端點由韌體持有, 錄影重新組態時由韌體去建立與重建,shell 只是搭順風車。
這樣錄影撐得過去,拔線也撐得過去。 完整分析在這裡 —— 六個症狀收斂到一個機制,每一步都在反組譯裡確認過。

What went wrong: the card that was quietly wrong出過的錯:一張悄悄是錯的卡

A build script used to emit a combined open-gate-plus-gyro card directly, and for weeks it emitted the wrong one. It called one builder while the gyro release had been built by a different one, and the two produce completely different payloads. The card was named as a release. Its manifest said “gyro”. The gyro inside it was not the gyro that had been shipped and tested.

以前有一支建置腳本會直接產生「open gate 加陀螺儀」的合併卡, 而它有好幾週產生的都是錯的那一個。
它呼叫的是某一支建置器,但陀螺儀的發行版是另一支建置出來的, 兩者產生的酬載完全不同。
那張卡掛著發行版的名字,它的清單上寫著「gyro」, 但裡面的陀螺儀不是那個發行過、測試過的陀螺儀。

Nothing failed. No error, no crash, no bad footage anyone noticed. It was found by comparing the two artefacts section by section, long after the fact.

沒有任何東西出錯。沒有錯誤訊息、沒有當機、沒有人注意到畫面不對。 它是很久以後,靠著逐個區段比對兩個產出物才被發現的。

That is the reason merged cards are now produced in exactly one place — fpSup-Merge — and why it checks its own output against the shipping releases byte for byte before it will even render. The build scripts can still create a card; what they no longer do is combine two.

這就是為什麼合併卡現在只在一個地方產生 —— fpSup-Merge —— 也是為什麼它在渲染之前,會先把自己的輸出逐位元組對照發行版檢查一遍。
建置腳本還是可以做一張卡;它們不再做的事,是把兩張合起來。

The menus are the camera's own選單是相機自己的

The new resolution is not an overlay drawn on top of the interface. Every menu item in the fp carries its own metadata in ROM, immediately after its name string — which means a mode can be given a real entry that behaves like the others, in Settings and in Quick Set. How that was worked out.

那個新解析度不是畫在介面上面的疊圖。
fp 裡每一個選單項目都在 ROM 裡帶著自己的 metadata,就緊接在它的名稱字串後面 —— 這表示一個模式可以擁有一個真正的選單項目, 行為跟其他項目一樣,在 Settings 和 Quick Set 裡都是。 這是怎麼弄清楚的。

Credit致謝

Open gate on an fp was first done by Vitaly Li. The work here is a different implementation, and it started from knowing it was possible.

在 fp 上做出 open gate 的第一個人是 Vitaly Li。
這裡的工作是另一套實作,而它的起點,是知道這件事做得到。