[bitcoin3us]

What

Two one-line fixes in index.html, and a short note on the ESP32-P4 option. Both fixed lines came in with the 0.20.0 release (5dbd6c5).

ESP32-P4 option. The ESP32-P4 option on the installer does not load. Its radio button points to /manifests/esp32/MicroPythonOS_esp32p4_0.20.x.json. That file does not exist, so the request returns 404. esp-web-tools then shows "Failed to download manifest".

The 0.20.0 release added the manifest at manifests/esp32p4/, next to firmware_images/esp32p4/. Each chip has its own directory. This PR points the option to /manifests/esp32p4/MicroPythonOS_esp32p4_0.20.x.json. When the next release's entries are made from these lines, the P4 one has the right directory.

This fixes the 404 listed under "Web installer" in MicroPythonOS/MicroPythonOS#344. It does not add the v3 option from that item.

Default selection. Two radios have checked="checked": the 0.20.0 ESP32-S3 option, and the 0.19.0 ESP32-S3 option, which moved into the old releases section. The browser keeps the later one. So on load the hidden 0.19.0 option is selected, and none of the visible options looks selected. On master, the install button defaults to the 0.20.0 ESP32-S3 manifest. This PR removes the attribute from the 0.19.0 option, as the 0.19.0 release did for 0.18.1. The 0.20.0 ESP32-S3 option is then selected on load, and it matches the button.

Checked

• I served this branch with Python's http.server and loaded index.html. Every option's manifest returns 200 and parses as JSON. Every part path returns 200. I resolved the paths as esp-web-tools does: the manifest against the page, the parts against the manifest. Each option's label matches its manifest's chip and version.
• In a browser, on load the only selected option is 0.20.0 ESP32-S3, the same manifest as the button's default. Selecting the ESP32-P4 option sets the install button's manifest to the new path. The console shows no errors. I did not click "Connect and install".
• On https://install.micropythonos.com, the manifest at the new path returns 200. Its part, /firmware_images/esp32p4/MicroPythonOS_esp32p4_0.20.0.bin, returns 200. Both are byte-identical to the files in this repo. The .bin has the same SHA-256 as the 0.20.0 release asset.
• The manifest declares chipFamily: "ESP32-P4". The page loads esp-web-tools@10, which unpkg resolves to 10.4.0. Its esptool-js names that chip ESP32-P4, so the build matches. It bundles two ESP32-P4 flasher stubs and picks one by chip revision.
• I have not flashed a board through the installer.

Chip revision

The 0.20.0 esp32p4 image runs only on chip revisions v0.x and v1.x. Its bootloader and app headers set the maximum to v1.99. A board with a v3.2 chip reset in a loop with it. MicroPythonOS/MicroPythonOS#344 tracks v3.x support. It also reports that Waveshare now ships this board with v3.x chips, and that writing Waveshare's factory image back restores the board.

esp-web-tools 10.4.0 does not check the chip revision. With this fix, the installer will write the image to a v3.x board too. So the third commit adds one sentence to the option's label: "Only for ESP32-P4 chip revisions v0.x and v1.x, not v3.x." It wraps to a second line on a desktop browser and on a 375 px wide phone screen, without horizontal scrolling. Drop that commit if you would rather keep the labels uniform.

MicroPythonOS/docs#13 adds a page for the ESP32-P4 board that says how to read the revision. That page currently says this option fails to load, and its steps use esptool. It needs a change once this fix is live.

Deploy

The release checklist deploys this repo with upload_install.sh. The live index.html is the one from 5dbd6c5, not 5ee3d6d: its install button still defaults to the 0.19.x ESP32-S3 manifest. GitHub Pages also builds master, but install.micropythonos.com resolves to a different server. These fixes reach the site with the next upload.

🤖 Generated with Claude Code

With thanks to the scientists and engineers who did the hard, unglamorous work that got us here.