[shteudguy]

Why this is needed

Following #518, G-010S-A has a dedicated browser UART-console helper, but it still needs its own firmware-writing procedure. YMODEM itself is usable on Nokia; the Huawei rooting flow, flash map and boot-selection assumptions cannot be reused.

The existing Huawei layout uses image 0 at 0x0c0000 with length 0x740000, and image 1 at 0x800000 with length 0x800000. Nokia uses two 0x600000 slots at 0x0c0000 and 0x6c0000, followed by persistent partitions from 0xcc0000. Applying the Huawei erase ranges to Nokia would erase part of the other image, or the configuration/identity partitions.

What this adds

• A dedicated /ont-nokia-g-010s-a-ymodem page and Vue component, linked from the Nokia page and the Huawei YMODEM warning.
• A shared verified FALCON console transport, preserving the existing UART helper and adding bounded binary reads/writes for YMODEM.
• A YMODEM/CRC sender at 115200 8-N-1, with packet retries, sequence-number wrap, receiver cancellation, overall/local deadlines, and the U-Boot ACK/CRC-request variants.
• Image inspection before connecting: complete-file SHA-256 allowlist, uImage header/payload CRCs, MIPS/Linux/LZMA format, SquashFS bounds and the 6 MiB slot limit.
• Device preflight: an interactive FALCON => challenge, exact inspected U-Boot build, known boot scripts and slot map, valid committed/trial state, UART settings, RAM bounds, required commands and 16 MiB SPI flash.
• A review step showing the protected and target slots, erase range, image/hash, boot mode and required migration. It offers a sanitised original-boot-settings JSON download and requires acknowledgement of a separate full device backup.
• Transfer to RAM, verification of the receiver's exact byte count and whole-file CRC, erasure of only the opposite committed slot, writing of the actual file length, and readback verification of the entire 6 MiB slot, including its erased tail.
• Three modes: stage without saving environment, try once while retaining the committed image, or make the verified image the default. No automatic reset or bootm is sent.

The original committed image, bootloader and Nokia configuration/calibration regions are preserved by the flash procedure. Firmware first-boot behaviour may still change configuration. Saved c_img is not used to infer which slot to protect; ambiguous or pending trial states are rejected. Device state is rechecked after review and after the long transfer. Each important command requires a fresh success marker, and all activation values are read back before saveenv.

Cancellation after erase/write or after environment mutation produces an explicit uncertain-state error, not a success or an ordinary cancellation. A received bad-environment CRC warning also blocks both Nokia tools.

Firmware evidence

Three supplied model-specific images were inspected. Each is 4,456,683 bytes (0x4400eb), has valid uImage and fwtool CRCs, and a successfully decompressed root filesystem:

Image	SHA-256
Nokia G-010S-A	5c0d6853645d72748cf844f9e64fc57c38924cc7938ef14a40a827015bbc1248
Huawei MA5671A	1a7a582e20d0605c1b1d7159b5473dc77a42b79a2b5ad0ce9a8c7b5356c756f2
Alcatel G-010S-P	d7c047e07912619c29896db627365cc7fcb20cbe5fa2d736a976b5b16908aa46

Their kernel/header bytes are identical (SHA-256 f1a9b5da90ed7ee6cdcf2313d5e2dabf138ccf677c4deec03d008a663c8ac61d), and all advertise generic SFP metadata. Eleven root-filesystem paths differ, including hardware/optics and upgrade handling. A filename or generic uImage header therefore cannot establish model compatibility. The new validator accepts the inspected Nokia file and rejects both actual Huawei/Alcatel files, including renamed copies.

The initial supported image is deliberately limited to that Nokia SHA-256 and the exact U-Boot 2015.04-lantiq-gpon-1.3.6.1 (Feb 07 2018 - 17:12:06) build with a known legacy or migrated boot profile. Structural validity alone does not add support for other stock/custom images.

The supplied Nokia backup comprises overlapping MTD exports. Its non-overlapping regions reconstruct the 16 MiB map; both saved environment records have valid CRCs. rootfs/rootfs_data must not be concatenated as additional physical partitions. No private dump, identifiers, passwords, calibration, firmware binaries or extracted filesystems are included in this PR.

Independent public samples

These artifacts were downloaded and compared as binary data:

Model / source	What was actually checked
Alcatel full SPI dump	A full 16 MiB dump, SHA-256 df1dc75189a73b79b0051701d3ad5610fa725cbc999e00afc792f54563d84bf4. Both environment CRCs are valid and directly establish the 0x740000 / 0x800000 slot allocation.
Huawei rooted partition images	mtd2: 0x740000 bytes, SHA-256 8ddf47bf45715ce316a6bad84b28e1fc76c6a1d51573575092c5cc3f9b5cfeda; mtd5: 0x800000 bytes, SHA-256 12132f28b803f29624d37d6e99fe06ff0621192b62fa712dd650b2a5c6fab4bb. These are rooted partition dumps, not a full factory SPI backup.
Nokia BGCB22 partition	One 0x600000 slot, SHA-256 ed6fe3cb46465c55348a5ed3c0f3aafea1bdf51a3717ca1796059991e7232ba1; also matched an independently published copy. The BFGB21 owner attachment likewise contains one 6 MiB slot, not a full MTD collection.
Nokia 2018 U-Boot	Byte-for-byte identical to the supplied Nokia mtd0, SHA-256 c6c461ede9f5d9f3fd8117452a0e9c97e01bb29be40a9e4a2df4e9d39216a837. The 2017 build differs and is not accepted.
wteiken's original Nokia environment	Independently confirms the Nokia map. Its 689-byte legacy select_image is exactly identical to the supplied module's, including whitespace; SHA-256 of that value is 4c24a9dbefbc32b5f56e4b8e64d2765bc75998ac4d823a827b11b2eb0f63c786. A different codekow environment variant is not treated as the same profile.

An independent full 16 MiB Huawei or Nokia SPI dump was not obtained. The evidence above should not be described as three complete factory dumps. Public filenames were also checked against contents: a Huawei image labelled “Official” matches the known rooted mtd5, and a file named uboot_env.bin is actually the 1224ABORT recovery executable, not saved environment data.

Why the boot-script migration matters

Static inspection of the matching Nokia loader shows that its bootm path increments and saves boot_fail, and can switch/mark an image invalid at the failure threshold. Resetting the counter once is insufficient.

The supported Nokia image's /lib/upgrade/common.sh (SHA-256 51f4a401e9c60025d641f95cb394473c2de2ec1b962b8b1cda2242605af5b054) migrates selection to committed_image and resets boot_fail on each normal boot. This migration normally runs in Linux sysupgrade; it is not automatically applied by first boot after a raw UART write.

For trial/default activation, this tool applies those exact reviewed settings only after flash readback succeeds. It does not invoke a second sysupgrade that could overwrite the previous slot. Quoted assignments preserve literal ${...} expressions; the complete command plus acknowledgement marker is checked against the inspected bootloader's input limit. Staging leaves environment and boot scripts unchanged.

Validation and remaining work

• 134/134 tests passed on Node 22.23.4 (node --test --test-reporter=spec tests/*.test.js).
• npm run build passed on Node 22.23.4, including static rendering and image optimisation.
• Tests cover both slots and boot profiles, unknown versions/maps, invalid image structures, state changes, command/readback failures, interrupted flash/environment writes, real Web Streams console-to-YMODEM transitions, fragmented/coalesced responses, retransmissions, packet-number wrap, deadlines and cancellation cleanup. Existing UART-helper regression tests also pass.
• The real supplied Nokia/Huawei/Alcatel files were run through the image validator; only the reviewed Nokia image was accepted.
• git diff --check passes.

Draft: end-to-end validation on a physical G-010S-A is still pending. Static binary analysis and simulated serial tests establish the implementation's intended behaviour, not a successful hardware flash. The page states this limitation. The remaining validation is a real transfer/readback and cold boot of the new image, verification of UART/network/GPON access, and trial/default-selection behaviour on the supported loader/profile.