06:53 <russell--> weird, i have an mr24 with a recent build, but eth0 stopped working and i'm seeing a weird macaddr on the ethernet interface

06:58 <russell--> eth0 macaddr should come from the board-config ubi volume

06:59 <russell--> i tried r26938-192afd31e3 and it is back to normal

07:10 <russell--> r27664-c1c2b61254 and i have the wrong eth0 macaddr

07:16 <russell--> [ 2.038230] /plb/opb/emac-rgmii@ef601500: input 0 in rgmii-id mode

07:16 <russell--> [ 2.049596] eth0: EMAC-0 /plb/opb/ethernet@ef600c00, MAC 00:01:73:01:23:41

07:18 <russell--> that's the wrong mac (from u-boot-env, not board-config)

07:18 <russell--> # fw_printenv | grep ethaddr

07:18 <russell--> ethaddr=00:01:73:01:23:41

07:48 <owrt-images-builds> Build [#386](https://buildbot.openwrt.org/images/#/builders/80/builds/386) of `master_armsr/armv8` completed successfully.

11:12 <russell--> 8d302f5ebc6e2787d01d6c6a8ef6bcc403949705 is the commit that broke the macaddr

11:24 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_mpc85xx.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)

15:44 <f00b4r0> so the Archer AX55 Pro v2 is apparently filogic-based, which would theoretically make it OpenWrt capapble

19:00 <colo> hi

19:01 <colo> I am trying to get Intel's i915 driver firmware loading properly working in OpenWrt, becasue that seems to be failing on my machine due to a race condition between the rootfs and i915 loading

19:02 <colo> kernel docs describe a fallback interface, where userspace can provide firmware data after the fact that it had been requested by a driver, in this document: https://www.kernel.org/doc/html/latest/driver-api/firmware/fallback-mechanisms.html

19:02 <colo> I implemented that in a small shell script for the i915 firmware parts I need, and that does work

19:03 <colo> it involved waiting for sysfs paths becoming available, and then opening them an writing data into the resulting fds - you have one "signal"-style file, and one "data channel"-style file (for dumping fimrware data into), and that has to happen during a ~60 seconds long window

19:04 <colo> my question is, is there an established OpenWrt mechanism that uses this already?

19:04 <colo> (maybe something involving hotplug?)

19:05 <colo> in case someone wants to check it out, this is my shellscript that I call early from /etc/rc.local that does the trick for me: https://paste.debian.net/plain/1331450

19:05 <colo> the sysfs paths that it waits for look like this:

19:05 <colo> - /sys/devices/pci0000:00/0000:00:02.0/firmware/i915!kbl_dmc_ver1_04.bin/loading

19:06 <colo> - /sys/devices/pci0000:00/0000:00:02.0/firmware/i915!kbl_dmc_ver1_04.bin/data

19:06 <colo> this can probably be safely generalized (path name component before the ! is the module, after it is the expected firmware filename), but I am not certain of this

19:17 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_lantiq.html has been updated. (3.3% images and 99.9% packages reproducible in our current test framework.)

19:20 <hurricos> schmars / blogic: RE: designing an OpenWrt One case: if you can more readily publish the board designs and requirements, I may have someone who is interested, and may take on this work for reduced pay so long as the resulting design remains OSHW.

19:21 <hurricos> we're aware of the links here: https://docs.banana-pi.org/en/OpenWRT-One/BananaPi_OpenWRT-One -- the PDFs don't do it for him.

19:24 <hurricos> our questions would be: 0) (SCH/ASSY files needed); 1) which ports must be externally accessible while the board is in its case?, 2) I'm familiar with the NWA55AXE orientation (antenna, ports, button point down). Is copying that here desired?

19:28 <schmars[m]> nice! blogic is the one with all the board info, i know next to nothing about that. but ya'll can point to me about billing :-) i can also send a nwa55axe or cudy ap3000 outdoor for reference/ideas

19:30 <schmars[m]> about the nwa55axe, i like that everything points down and is protected from weather by design. but the cudy seems to do fine as well with only the antennas pointing up (little sealing ring on each hole)

19:33 <schmars[m]> as for the accessible ports (blogic might have more precise ideas), i think it would be nice to have poe and 2x eth, reset button, and maybe console (usb or pins). the cudy design makes it really easy to pull the board out, so anything else would still be somewhat accessible

19:36 <schmars[m]> bonus points for mounting it on ubiquiti rocket sector antennas

19:54 <schmars[m]> ASSY seems to be here https://drive.google.com/drive/folders/10DPyCAaEFxPb7vHBYOzMmLEbG_FAAJAA

19:55 <schmars[m]> ok you probably mean the source files that the PDFs were exported from

21:10 <schmars[m]> hurricos: https://one.openwrt.org/hardware/