mirror of
https://github.com/Klipper4FlashForge/firmware.git
synced 2026-10-22 21:32:16 -05:00
MonstrofilandClaude Opus 5
e20ed98dac
A printer still on 1.9.4 does not come up on this package: the board firmware that release pairs with differs from the one klippy is built to talk to, the MCU never connects, and the failure is at the bottom of the stack -- no Klipper, so no screen and no Mainsail. From the outside it is indistinguishable from a bad flash, and the only way out is flashing stock again. So it is refused before anything is written, with the fix in the message: install FlashForge's own current firmware first, then this. That costs one more flash and leaves a working printer either way. WHAT IS READ is /usr/prog/PROGRAM/software, which holds one directory named for the version of FlashForge's software component -- install_component wipes the previous one before renaming the new one in. No package of ours ever ships a software component, so it goes on describing the printer rather than the mod. The highest is taken when a machine somehow holds two, so a leftover from an interrupted install cannot refuse a printer that should go ahead, and the comparison is field-by-field numeric because a string compare makes 1.9.10 older than 1.9.6. AN UNREADABLE VERSION IS INSTALLED ON. The two failures are not the same size: letting one through costs a printer that has to be flashed back to stock, while refusing on one would break the install path on every machine whose layout is not the one being read. THE REFUSAL HAS TO BE VISIBLE. It happens before the panel is switched to start.img and app_startup.sh goes on booting the printer, so from the outside the flash would just have done nothing. installer/stock-too-old.img is the frame it paints instead -- the same raw 480x800@32 framebuffer dump start.img is, rendered by the same ffscreen.py, so it needs nothing on the printer but `cat > /dev/fb0`. The version in it is DRAWN, so bin/pack.sh carries the command to re-render it when MIN_STOCK_VER changes. anvil-NOT-INSTALLED.txt on the USB stick is the copy that survives the power cycle. Three tests, on the replica. The machine there is a real one in the way that matters -- its /usr/prog/PROGRAM/software holds FlashForge's own 1.9.7 -- so "current firmware installs" needs no setup, the refusal swaps that directory for one holding 1.9.4 and restores it, and the third asserts that a stale 1.9.4 left BESIDE the real version does not refuse. The control matters more than the refusal: a gate that refused everything would pass the refusal test and brick every flash. qa/replica/test_upgrade.py is 19/19; the lane's 10 other failures are the ones master has on this bake. Claude-Session: https://claude.ai/code/session_01Fn1k6kaHWhUrsmBfpxjUcG Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
