zephyr-cp: version.json UID is all zeros; board_name/hostname empty because CIRCUITPY_MDNS is off

[mikeysklar]

Observed on 10.3.0-alpha.4-57-gd96b766f32-dirty, board silabs_siwx917_dk2605a, web workflow up and serving.

GET /cp/version.json returns three fields unpopulated:

{"board_name": "", "hostname": "", "UID": "0000000000000000000000000000000000000000000000000000000000000000", ...}

Everything else in the payload is correct, including ip, board_id, mcu_name and creator_id. The workflow itself works: /fs/ returns 401 without credentials and 200 with them, and PUT/GET/DELETE round trip cleanly.

The all-zero UID also makes the short cpy-<uid>.local mDNS name useless, which is why only the full cpy-silabs_siwx917_dk2605a-<mac>.local form resolves.

hostname being empty is the more interesting one, since common_hal_wifi_radio_hostname is set during init in ports/zephyr-cp/common-hal/wifi/__init__.c and Zephyr's mDNS responder answers the name over the air.

[mikeysklar]

Correcting this after testing on hardware. Two of the three fields are not a port bug at all.

_reply_with_version_json() in supervisor/shared/web_workflow/web_workflow.c:919 sources both fields only from the CircuitPython mdns module:

const char *hostname = "";
const char *instance_name = "";
#if CIRCUITPY_MDNS
if (!common_hal_mdns_server_deinited(&mdns)) {
    hostname = common_hal_mdns_server_get_hostname(&mdns);
    instance_name = common_hal_mdns_server_get_instance_name(&mdns);
}
#endif

board_name comes from instance_name, hostname from hostname. There is no ports/zephyr-cp/common-hal/mdns, so CIRCUITPY_MDNS=0 and both stay "". That is upstream behavior on any port without an mdns implementation, not something specific to this board. It is a consequence of #37.

The data does exist. From the REPL on the same boot:

hostname: 'cpy-silabs_siwx917_dk2605a-c09b9ec2eec8'

So wifi.radio.hostname is correct and version.json simply does not read it. A fallback to net_hostname_get() and MICROPY_HW_BOARD_NAME when CIRCUITPY_MDNS is off would fix it without implementing mdns, and would help every other mdns-less port too.

The all-zero UID is separate and does look like a real port bug. common_hal_mcu_processor_get_uid() calls hwinfo_get_device_id() and zero-fills on failure or a short read. Both failure paths printk, which goes to RTT on this board, so the diagnostic is invisible on the serial console.

[mikeysklar]

The UID part of this is not new. It is #7, found during early porting:

microcontroller.cpu.uid returns all zeros; UID retrieval failed: -88 (-ENOSYS). Zephyr's hwinfo driver for this SoC is unimplemented, though Commander reads the UID fine over SWD (0000c09b9ec39910).

So common_hal_mcu_processor_get_uid() is behaving correctly. It calls hwinfo_get_device_id(), gets -ENOSYS because Zephyr has no hwinfo driver for siwx91x, and zero-fills. The silicon has a UID, nothing in CircuitPython can read it.

That means the version.json UID and the short cpy-<uid>.local mDNS name both stay broken until Zephyr gains an hwinfo driver for this SoC. Worth implementing upstream since it affects every SiWx917 user.

Closing the loop on this issue: all three fields have upstream causes rather than port bugs. board_name/hostname need either an mdns implementation (#37) or a non-mdns fallback in web_workflow.c. UID needs Zephyr hwinfo (#7).