01:43 <vulpes2[m]> I've got a dual-firmware device, and the stock u-boot does not seem to have any failover behavior whatsoever. It does not maintain a failed boot counter, nor will it switch to the other slot after a few consecutive failed boots. Given the usable overlay space is incredibly tiny if we just use a single slot, would it be acceptable to just use both partitions in my dt?

01:44 <vulpes2[m]> Instructions will be provided for switching to the correct slot before flashing.

01:45 <slh> that (imho) mostly depends on two questions, can you still revert to the OEM firmware relatively easily and what happens in terms of (if present) push-button tftp recovery, does it always rewrite the first partition (e.g. nbg6817) or does it try round-robin writes

01:47 <vulpes2[m]> push-button tftp recovery is not present, you must solder wires to the board to access the serial console

01:48 <slh> that probably sorts the second question

01:48 <vulpes2[m]> you can revert to the OEM firmware easily if you had a backup, which can be done within the stock firmware

01:49 <slh> keep in mind, most users won't do that - even if told to do so... bonus points if there is a way to flash the OEM firmware download somehow

01:49 <vulpes2[m]> no stock upgrade files were ever provided by the vendor so I'll have to reverse engineer it later

01:53 <vulpes2[m]> about backups, it's actually pretty annoying to get the backups out of the device anyway, since you'd have to upload it to a local server

01:53 <vulpes2[m]> the device doesn't have any USB ports which makes it slightly more cumbersome to do backups

01:53 <slh> yeah, that's no fun

01:54 <slh> I quite religiously do full backups of everything on a new device, if possible before touching it, but most users won't, especially if it isn't dead-easy

01:55 <vulpes2[m]> the console is silent by default too, and it's not even wired to any of the test pads, I found it with bruteforce (tried every low-voltage pads on the board)

01:58 <vulpes2[m]> I guess I could put a note in the flashing instructions telling people to back up their stuff, because with less than 1MB of free space the device is going to be annoying to use.

03:10 <vulpes2[m]> I got openwrt up and running but my ethernet interface doesn't work. This is a mt7621 device, I've enabled port 0, 1, 2, 3, 4 on the builtin switch, but none of them worked. The device has a single ethernet port that goes directly into the soc, so there's no external phy involved.

03:18 <vulpes2[m]> Figured it out, it was on port 0, and the reason I don't have working connectivity is I didn't put the interface under br-lan in `/etc/config/network`

13:27 <owrt-snap-builds> Build [#387](https://buildbot.openwrt.org/master/images/#builders/72/builds/387) of `imx/cortexa9` completed successfully.

14:20 <mrkiko> vulpes2[m]: congrats for your effort. Go ehad! so you now have live console?

14:23 <mrkiko> soxrok2212: sorry to hear that. Guess chances are they burned the related mtk eFuse and now you can't replace u-boot and maybe the rest

14:35 <mrkiko> related to PR #11218 - no arp answer; any toughts? How might we proceed? I was tempted to ask for tcpdump from PC and router's perspective.

14:58 <soxrok2212> mrkiko: i was wrong, its just xz compressed

14:59 <soxrok2212> apparently mtk now xz compresses BL2 and FIP are now compressed

14:59 <soxrok2212> oops, english

15:07 <mrkiko> soxrok2212: oh! so you where able to go ahead

16:50 <vulpes2[m]> mrkiko: unfortunately that's only 1/3 of the work, there are two other major hurdles I need to resolve before it's usable

16:51 <vulpes2[m]> MAC addresses aren't in factory and it's AES encrypted. The key is likely somewhere in the rootfs but I need to find it first.

16:52 <vulpes2[m]> And given I have no stock firmware update files, I need to reverse engineer the program that does fw updates too.

16:53 <vulpes2[m]> I've learned a lot but this is still one of the most obnoxious devices I've ever dealt with.

18:31 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html

18:44 <vulpes2[m]> turns out the device mac isn't encrypted, it's just at a different offset within factory

18:44 <vulpes2[m]> but they used the device mac to encrypt the device config which I think is pretty useless

18:44 <vulpes2[m]> not sure what they were thinking

19:44 <mrkiko> vulpes2[m]: great progress, go ahead! :D

19:46 <vulpes2[m]> hauke: I've got more LED related questions, would it be acceptable if I map a brightness control GPIO as another LED?

19:47 <vulpes2[m]> The hardware has a GPIO that allows the user to change the brightness of all LEDs, it's either bright or dim. I'd like to expose this to the users if at all possible.

22:54 <vulpes2[m]> do I have to add an entry to `ramips_setup_macs()` in `base-files/etc/board.d/02_network` if the MAC addresses are all correctly configured via dt?