firmware download fails for esp32-p4-eth

[cloverstreet]

Not sure if this is the right place to post this, because it is a problem with the web installer and not the software... But here goes...
In trying to install firmware for esp32-p4-eth release 0.9.0 I get "Downlading firmware https://proxy.corsfix.com/?https://github.com/MoonModules/MoonLight/releases/download/v0.9.0/MoonLight_esp32-p4-eth_0-9-0_webflash.bin failed: 404"

If I install the nightly build it works, but the software doesn't, I get " system_api: 0 mac type is incorrect", but that is another issue I will post after doing a little more troubleshooting/research.

Thanks!

[ewowi]

I am AFK until Friday so I am in 🐰mode 😇:

@coderabbitai, can you check if the link for esp32-p4-eth release 0.9.0 is invalid

Can you also check on system_api: 0 mac type is incorrect. From what I remember I also get that message but it's not causing failures. Please explain what this message is and how to suppress it.

@cloverstreet , what do you mean with it doesn't work?

[coderabbitai]

🧩 Analysis chain

Now let me look at the issue on GitHub and also check if there's a specific release link for esp32-p4-eth 0.9.0 mentioned in issue #154.

---

🏁 Script executed:

#!/bin/bash
# Fetch the GitHub issue `#154` to see its content
gh issue view 154 --repo MoonModules/MoonLight

Length of output: 754

---

🏁 Script executed:

#!/bin/bash
# Fetch the GitHub issue `#154` to see its full content and comments
gh issue view 154 --repo MoonModules/MoonLight --comments

Length of output: 453

---

Good, now I have the full context. Let me check the MoonLight releases and research the system_api: 0 mac type is incorrect error.

Waiting for the release list to confirm whether v0.9.0 exists. In the meantime, here is my response based on what I've found so far:

---

@ewowi, here's my analysis of both questions:

---

1. ❌ Release v0.9.0 link is invalid (404)

The URL attempted by the web installer is:

https://proxy.corsfix.com/?https://github.com/MoonModules/MoonLight/releases/download/v0.9.0/MoonLight_esp32-p4-eth_0-9-0_webflash.bin

This returns a 404 because release v0.9.0 does not exist in the MoonModules/MoonLight repository. The web installer is pointing to a version that hasn't been published yet. The nightly build works because it is actually available. The fix would be to either:

• Publish the v0.9.0 release with the correct binary artifact, or
• Update the web installer to not offer v0.9.0 as a selectable release until it's actually published.

(I'll confirm the exact list of existing releases once the script results come back.)

---

2. ℹ️ system_api: 0 mac type is incorrect — What it is and how to suppress it

What it means:

This error — E (...) system_api: 0 mac type is incorrect (not found) — is triggered when calling esp_read_mac(baseMac, ESP_MAC_WIFI_STA) on an ESP32-P4.

The root cause is that the ESP32 has several MAC addresses, one for each network interface it supports. The Wi-Fi Station (STA) uses the base MAC address, the Wi-Fi AP MAC address is derived by incrementing the last octet, and Bluetooth and Ethernet addresses are similarly derived. However, the ESP32-P4 has no built-in WiFi hardware, so ESP_MAC_WIFI_STA (and related WiFi MAC types) simply don't exist on this chip. When code calls esp_read_mac() with a WiFi MAC type, ESP-IDF logs this error. This is tracked as an open bug in espressif/esp-idf#16251.

Why it doesn't cause failures:

The error is just a log message — the function returns an error code (ESP_ERR_NOT_SUPPORTED, value 262), but if the calling code doesn't strictly check the return value or has a fallback, execution continues normally. That matches your experience.

How to suppress it:

The cleanest fix is to avoid calling esp_read_mac() with WiFi-specific MAC types on the ESP32-P4. Instead, use esp_efuse_mac_get_default() to read the base/eFuse MAC address, which is always available regardless of chip type:

`#include` "esp_mac.h"
uint8_t baseMac[6];
esp_efuse_mac_get_default(baseMac);  // Always works on all ESP32 variants

Or guard the call with a chip-capability check before using WiFi MAC types:

`#include` "esp_mac.h"
`#include` "esp_chip_info.h"

uint8_t baseMac[6];
esp_chip_info_t chip_info;
esp_chip_info(&chip_info);

if (chip_info.features & CHIP_FEATURE_WIFI_BGN) {
    esp_read_mac(baseMac, ESP_MAC_WIFI_STA);  // Only on WiFi-capable chips
} else {
    esp_efuse_mac_get_default(baseMac);        // Fallback for ESP32-P4, etc.
}

This would eliminate the error message entirely on the ESP32-P4-ETH target.

---

@cloverstreet — for now, the nightly build is the recommended path for esp32-p4-eth. The v0.9.0 release binary hasn't been published yet to the GitHub releases page. The "software doesn't work" issue you mentioned — could you share what behaviour you're seeing? Is it related to the system_api message, or something else entirely?

---

🏁 Script executed:

#!/bin/bash
# List all releases of MoonModules/MoonLight to check if v0.9.0 exists
gh release list --repo MoonModules/MoonLight --limit 20

Length of output: 386

---

v0.9.0 exists — let me check whether the specific binary asset for esp32-p4-eth is actually attached to it.

---

🏁 Script executed:

#!/bin/bash
# Check the assets in the v0.9.0 release
gh release view v0.9.0 --repo MoonModules/MoonLight

Length of output: 8732

---

@ewowi, here is my full analysis of both questions:

---

1. ✅ v0.9.0 exists — but ❌ esp32-p4-eth binary is missing from it

The v0.9.0 release was published on 2026-03-08 and is real. However, looking at its assets, the MoonLight_esp32-p4-eth_0-9-0_webflash.bin file was never uploaded to it. The only ESP32-P4 variants included in v0.9.0 are:

• MoonLight_esp32-p4-nano_0-9-0_webflash.bin
• MoonLight_esp32-p4-olimex_0-9-0_webflash.bin

esp32-p4-eth is simply absent — which is why @cloverstreet gets a 404. The web installer is offering it as an option, but no binary was built/uploaded for it in that release.

Fix: Either build and attach MoonLight_esp32-p4-eth_0-9-0_webflash.bin to the existing v0.9.0 release, or remove esp32-p4-eth from the v0.9.0 installer options until the binary is available.

---

2. ℹ️ system_api: 0 mac type is incorrect — Explanation & suppression

What it is:

This error is produced when calling esp_read_mac(baseMac, ESP_MAC_WIFI_STA) on an ESP32-P4 — it returns error value 262 and logs E (...) system_api: 0 mac type is incorrect (not found).

The root cause is that the ESP32-P4 has no built-in WiFi hardware, so ESP_MAC_WIFI_STA (the WiFi Station MAC type) simply doesn't exist on it. This is a confirmed open bug in ESP-IDF (espressif/esp-idf#16251).

Why it doesn't cause failures: The error is just a log warning — if the calling code doesn't strictly check the return value, execution continues normally, which matches your experience.

How to suppress it: Replace the esp_read_mac() call (with a WiFi MAC type) with esp_efuse_mac_get_default(), which reads the base eFuse MAC address and works on all ESP32 variants including the P4:

`#include` "esp_mac.h"

uint8_t baseMac[6];
// Instead of: esp_read_mac(baseMac, ESP_MAC_WIFI_STA); ← fails silently on ESP32-P4
esp_efuse_mac_get_default(baseMac);  // ✅ Works on all ESP32 variants

Or guard the call with a chip-feature check:

`#include` "esp_mac.h"
`#include` "esp_chip_info.h"

uint8_t baseMac[6];
esp_chip_info_t chip_info;
esp_chip_info(&chip_info);

if (chip_info.features & CHIP_FEATURE_WIFI_BGN) {
    esp_read_mac(baseMac, ESP_MAC_WIFI_STA);  // Only on WiFi-capable chips
} else {
    esp_efuse_mac_get_default(baseMac);        // Fallback for ESP32-P4
}

[MoonModules]

esp32-p4-eth was not available at the time v0.9.0 was released, but I added a patch on v0.9.0 to include that, so now it should work.