Give the board a stable MAC and a USB port that works

[MrMati]

Two of the three things the README lists as wrong on a booted board.

The Type-C port did nothing in either direction

dr_mode = "otg" looks like the flexible choice and is not. The connector has no ID pin and there is no CC controller behind it, so with no extcon to consult dwc3 falls back to the OTG block's CONIDSTS, which follows the PHY's iddig input, which nothing on this board drives. It reads as grounded, dwc3 concludes it is the A-device, and xHCI comes up on a port with no VBUS to offer and no UDC for luckfox-usb-gadget.service to bind to:

phy phy-ff3e0000.usb2-phy.0: illegal mode
xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
...
no UDC available; is the controller in peripheral mode?

The illegal mode line is the same event seen from the other side: usb_add_hcd() offers the PHY PHY_MODE_USB_HOST_SS, which rockchip_usb2phy_set_mode() does not handle. It disappears with the host that produced it.

The port is also the board's power inlet, so peripheral is what the hardware is, and is what Luckfox's own devicetree says:

&usbdrd_dwc3 {
	dr_mode = "peripheral";
	status = "okay";
};

The Ethernet MAC was new on every boot

rk_get_eth_addr() reads the MAC out of Rockchip vendor storage, a reserved area at the end of the boot medium that the factory programs. Nothing ever programmed this one, and an SD card written by mk-image.sh has no such area at all, so every boot went:

rk_vendor_read eth mac address failed (-1)
generate random eth mac address: be:69:2e:54:8a:23
rk_vendor_write eth mac address failed (-1)

A new MAC means a new DHCP lease, so the board never keeps an address.

The SoC does have something unique and permanent: the 16-byte OTP id that rockchip-cpuinfo already hashes into /proc/cpuinfo's Serial. Patch 0003 teaches the driver to use it when the ethernet node names the cell, after vendor storage has had its turn:

	hash = crc32(0, soc_id, len);
	kfree(soc_id);

	addr[0] = 0x02;		/* unicast, locally administered */
	addr[1] = id;		/* one address per MAC on the SoC */
	addr[2] = hash >> 24;
	addr[3] = hash >> 16;
	addr[4] = hash >> 8;
	addr[5] = hash;

The id is neither a MAC nor an OUI, so it is hashed rather than copied. Boards with working vendor storage are unaffected, and boards that do not name the cell keep the old random address.

The gadget's own two MACs were a hard-coded constant, identical on every Pico Max; they now come from the same serial, so two boards plugged into one laptop are distinguishable.

The ACM half of the gadget had nothing behind it

Falling out of testing the above: the ACM function gives the board a /dev/ttyGS0 and the host a /dev/ttyACM0, but the image only ever enabled serial-getty@ttyS2, so a host that opened the port sat looking at a blank screen. The gadget unit now pulls the getty in, ordered after itself because the getty is BindsTo=dev-ttyGS0.device and that node only exists once up has created the function:

Wants=serial-getty@ttyGS0.service
Before=serial-getty@ttyGS0.service

The same BindsTo means down takes the getty with it, so no explicit stop is needed.

While there: the gadget's USB serial number came from boot_id, so it was new on every boot and so was the host's /dev/serial/by-id/... path. It now comes from the same SoC id the MACs do, which makes usb-Luckfox_Pico_Max_<serial>-if02 a name worth writing down.

Patch 0004 is unrelated to either but is the third USB line in the log: the probe asks for the muxed per-phy interrupt with platform_get_irq(), which logs error -ENXIO: IRQ index 0 not found on SoCs like the RV1106 that describe their interrupts per port instead. Every use of it is already guarded by rphy->irq > 0, so ask with platform_get_irq_optional().

Checked locally: all four patches apply to the pinned tree, both touched drivers cross-compile clean, and the DTB builds through kbuild. make check passes.

---

^{Need help on this PR? Tag @codesmith with what you need. Autofix is enabled.}