recent "main" flash "FAILED" (but it didn't)

[nerdCopter]

I flashed HDZERO_GOGGLE-75-205-9.5.0-c38aedd.bin over HDZERO_GOGGLE-75-205-9.5.0-b8e02a8.bin reported FAILED in red, so i re-compiled re-flashed and received same message, but noticed it actually properly running c38aedd on fresh boot. Thinking the "FAILED" report is false-positive. Goggles v1 late 2023.

[pitts-mo]

I discovered update_.sh script may fail when it is replaces itself. It is still possible to report failure for first update >=c38aedd depending on the variant of update_.sh that was previously installed. This should be resolved going forward as long as the update_*.sh scripts maintain running content within a single function.

I have just retested a few scenarios cycling c38aedd, b8e02a8, 6aae295 and could not actually reproduce a failure message.

You might be hitting a file system issue because installing new github builds will keep breaking permissions on binary executables. We can dig at this more on discord or use this develop.sh on the sd card once after each update if you just want to see if it will fix problems.

# Load via SD Card if found
chmod -R +x /mnt/app/services/
rm -rf /mnt/app/services/scripts/install/install.done
#
if [ -e /mnt/extsd/HDZGOGGLE ]; then
	/mnt/extsd/HDZGOGGLE &
else
	/mnt/app/app/HDZGOGGLE &
fi

[nerdCopter]

i presume i need to ssh to execute? if no, then how?

[pitts-mo]

Sorry,
The OS looks for the develop.sh file on the SD card at boot time to allow for side-loading dev applications without the need to install/update the goggle. I added two rows to this develop.sh that @SumolX suggested for fixing permissions issues.

develop.sh

See the readme.md for more info about develop.sh and loading HDZGOGGLE app from SD card:
https://github.com/hd-zero/hdzero-goggle?tab=readme-ov-file#loading-the-firmware

Note: if develop.sh does not find HDZGOGGLE on the SD card it will just continue to load the installed application.

[nerdCopter]

i saved .sh for SD, rebooted. updated same c38aedd over itself with same FAILED message, but i wont worry too much about it.

[nerdCopter]

1. Flashed latest locally compiled, reported FAILED in red, but actually boots fine with new version.
2. Flashed github actions build, reported SUCCESS -- maybe my gcc weird

closing

[nerdCopter]

in hindsight i think i know the issue-source.

if i rename the .bin file to anything other than the output filename, it reports FAILED.

i.e. the github file HDZERO_GOGGLE-75-205-9.5.0-02f488b.bin flashed with SUCCESS, then i renamed it HDZERO_GOGGLE-75-205-9.5.0-02f488b_github.bin and it FAILED.

so when i always rename my local build with _MAIN, it too reports FAILED.

Can the "checks" be rectified?

[nerdCopter]

@pitts-mo , Take it with a grain of salt, this is some AI interrogation results (Claude Sonnet 4.5 preview):
if nothing else, may just give some ideas

---

Fix Implementation Guide - Issue #562 Fix

Quick Summary

Problem: Renamed firmware files (e.g., *_MAIN.bin, *_github.bin) report FAILED but actually work.

Cause: System utility hdz_upgrade_app.sh rejects non-standard filenames, preventing "all done" output.

Solution: Normalize filenames in update scripts before validation.

---

Implementation (Option 1 - Recommended)

Files to Modify

Apply the same changes to all 3 scripts:

• mkapp/app/script/update_goggle.sh
• mkapp/app/script/update_goggle2.sh
• mkapp/app/script/update_boxpro.sh

Change 1: Add Normalization (Line ~197)

Find:

if [ ! -z "$HDZ_BIN" ]; then
	echo "Flashing $HDZ_BIN"
	echo "0" > /tmp/progress_goggle
	echo "0"
	untar_file "$HDZ_BIN"

Replace with:

if [ ! -z "$HDZ_BIN" ]; then
	# Normalize filename to strip suffixes after .bin (Issue #562)
	HDZ_BIN_ORIGINAL="$HDZ_BIN"
	HDZ_BIN_NORMALIZED=""
	HDZ_BIN_DIR=$(dirname "$HDZ_BIN")
	HDZ_BIN_NAME=$(basename "$HDZ_BIN")
	
	if echo "$HDZ_BIN_NAME" | grep -qE '\.bin[_\.]'; then
		HDZ_BIN_NORMALIZED=$(echo "$HDZ_BIN_NAME" | sed 's/\(\.bin\).*/\1/')
		ln -sf "$HDZ_BIN_NAME" "${HDZ_BIN_DIR}/${HDZ_BIN_NORMALIZED}" 2>/dev/null || \
			cp "$HDZ_BIN" "${HDZ_BIN_DIR}/${HDZ_BIN_NORMALIZED}"
		HDZ_BIN="${HDZ_BIN_DIR}/${HDZ_BIN_NORMALIZED}"
	fi
	
	echo "Flashing $HDZ_BIN"
	echo "0" > /tmp/progress_goggle
	echo "0"
	untar_file "$HDZ_BIN"

Change 2: Add Cleanup (Line ~217)

Find:

	hdz_upgrade_app.sh
	echo "100"
	echo "100" > /tmp/progress_goggle
	echo "all done"
else
	echo "skip"
fi

Replace with:

	hdz_upgrade_app.sh
	echo "100"
	echo "100" > /tmp/progress_goggle
	echo "all done"
	
	# Cleanup normalized file (Issue #562)
	if [ ! -z "$HDZ_BIN_NORMALIZED" ]; then
		rm -f "${HDZ_BIN_DIR}/${HDZ_BIN_NORMALIZED}" 2>/dev/null
	fi
else
	echo "skip"
fi

---

Implementation (Option 2 - C Code Alternative)

File to Modify

src/ui/page_version.c - Function flash_hdzero() (line ~213)

Add after variable declarations:

static int flash_hdzero(const char *dst_path, const char *dst_file,
                        const char *src_path, const char *src_file,
                        const char *update_script, bool is_zipped) {
    uint8_t ret = 2;
    char cmd_buff[1024] = {0};
    char normalized_dst_file[256] = {0};
    
    // Normalize filename - strip anything after .bin (Issue #562)
    const char *bin_ext = strstr(dst_file, ".bin");
    if (bin_ext && bin_ext[4] != '\0') {
        size_t len = (bin_ext - dst_file) + 4;
        if (len < sizeof(normalized_dst_file)) {
            strncpy(normalized_dst_file, dst_file, len);
            normalized_dst_file[len] = '\0';
            dst_file = normalized_dst_file;
        }
    }
    
    // Continue with rest of function...

---

Testing

Test Case	Expected Result
HDZERO_GOGGLE-75-205-9.5.0-02f488b.bin	✅ SUCCESS
HDZERO_GOGGLE-75-205-9.5.0-02f488b_MAIN.bin	✅ SUCCESS (was FAILED)
HDZERO_GOGGLE-75-205-9.5.0-02f488b_github.bin	✅ SUCCESS (was FAILED)
HDZERO_GOGGLE-75-200-9.5.0-58d2221_main_525_PR525.bin	✅ SUCCESS (was FAILED)

---

Why Option 1 is Recommended

• ✅ No C recompilation needed
• ✅ Can be tested directly on goggles
• ✅ Backwards compatible
• ✅ Minimal risk - only adds normalization layer
• ✅ Works for all goggle variants (V1, V2, BoxPro)

---

GitHub Issue: #562

[pitts-mo]

Sorry @nerdCopter , I still don't completely understand the root of the actual problem or this proposal. It seems like the related sections of script structure have been relatively similar since 2022-12...

It is desirable to allow users to rename their update files. Please submit PR with your preferred changes and I'll find some time for before/after update file name tests.

[SumolX]

I was a little confused at first but agree with @pitts-mo. I would treat this as an enhancement and it think the code need to be updated as well to handle long file names and display them properly within the dialogue.

[pitts-mo]

Actually, is the name issue even occurring at this level?

Until someone shows me where/why the name is causing issue I suspect the proposed changes may be an inappropriate fix.