Version strings — display, sources and gating¶
What the System Info screen shows¶
| field | value on SMEG5.43.A.R2 | source |
|---|---|---|
| Main SMEG software | 5.43.A.R2 |
smeg.inf -> VER: |
| Display version | 32.00 |
smeg.inf -> GUI_VER: |
| CD / Media version | 26482 |
media.inf -> VER: |
| Bluetooth | 1.2.0 |
Bluetooth firmware |
| BootROM / uBoot / Renesas | as flashed | their own images |
The application does not carry these strings for display. The image contains the
path /SYSTEM/Data_base/smeg.inf, i.e. it reads the media partition copy. So:
- Patching
AppBin/f_BigQuick.binnever changes any version string. - Changing
VER:/GUI_VER:in a modulesmeg.inf(AUDIO_BT/smeg.inf) is used by the updater but does not change what the screen shows — the displayed copy isData_base/smeg.infinsidesystem.bin. - A visible marker therefore requires a media-partition edit (see
MEDIA_PARTITION.md). TheSIZE:fields are no longer a blocker — they are computable — but the packing tool is still to be written (issue #35).
AUDIO_BT/smeg.inf and the tar's Data_base/smeg.inf currently hold identical content,
which is why it is easy to assume editing one affects the other.
The updater gates on these strings¶
From upgrade.out strings:
(UpgradeTask) The version on media.inf not allows an upgrade
(UpgradeTask): Actual BSP (%f) is very old... The new version of the BSP need to format the NAND.
(GetUBootVersionMedia): field 'VER:' not found!
(ManageHarmoniesVersions) Harmonies are not compatibles, new Harmony must be erased
(ManageRenesasUpdateAndReboot) Renesas version '%s' == Mot. File version '%s'
manageBootRomUpdateAndReboot: BootRom already done.
ManageBigQuickUpdate: '%s' is a cantidate!
So versions are compared, and the comparisons drive more than "update or skip":
media.infhas an explicit gate — "not allows an upgrade" — so a wrong value there can block the package.- UBoot versions are parsed numerically (
%02d.%02d) and a missing/unparsableVER:is an error, so an invented series is not guaranteed to parse. - Harmony compatibility and BSP age are version-driven, and those branches do destructive things (erase the harmony images, format the NAND).
Why not to invent a version¶
- Bumping
smeg.infVER:to e.g.5.43.A.R3makes the application look newer, so the updater applies it — but it changes nothing visible (display reads the media copy) and nothing functional (content is whatever was patched). - An unrecognised series such as
5.43.X.R1may not parse, landing on the "not allows an upgrade" path or, worse, triggering a harmony/BSP re-flash. media.infis the one with the hard gate; do not edit it as a marker.
If a visible marker is wanted, the safe field is GUI_VER (Display version) — it is
presentation-only and nothing gates on it. It still lives in the media partition, so it
is the same rebuild job. Recommendation for now: rely on the updater's own progress
screens as evidence that the application was written, and judge by behaviour.