Left to my own devices#

Thu, 12 Jul 2018 00:10:47 +0000

I bought another GL-Inet router so that I would have a device for testing on. Because it was a tenner cheaper, I bought the MT300N instead of the 300A.

So far:

• I built a kernel and rootfs but booting it gave me nothing but LZMA ERROR 1 - must RESET board to recover. After an hour or so I realised that I've seen this before and the problem is that the Mediatek devices have different syntax for variable interpolation in U-boot. When you load the compressed kernel at address 0 and then try to unpack it into the same space, it probably should not be surprising that it fails. Certainly not surprising the second time, at least

• this got me a kernel that booted as far as Calibrating delay loop and then hung. I can't actually remember how I worked out this one, but it turned out to be because I've bought an MT300N version 2 and it's based on a completely different SoC to the v1. Having fixed that it boots to userland but the Ethernet didn't work.

[ 6186.097454] mtk_soc_eth 10100000.ethernet eth0: transmit timed out

• At this point I resorted to the all-purpose "google the error message" strategy: first it said I should try upgrading to kernel 4.14, so I did that with comparatively little pain but for absolutely no gain (i.e. it didn't fix the problem), then I stumbled across a post on the LEDE forum which said I needed to configure the switch before attempting to bring Ethernet up: and, lo and behold, that works

I am probably going to stick with 4.14 anyway even if it's not strictly necessary, it looks like Openwrt is already using it as default on ralink/mediatek boards and there seems no point in being intentionally out of date.

Current mood : quite stoked that a new device I received on a Friday is running nixwrt by the following Wednesday - maybe 10-12 hours of actual hacking time later.

Thinking about next: how to do upgrades of production devices without needing to take the covers off again. I think it's going to involve kexec

• reboot device with current kernel, feeding it memmap= parameters to reserve some ram for the rootfs

• when it comes up, copy the root fs into that area of physical ram

• reboot again into the new kernel with memmap= and phram= so that it is running a RAM-based system

• when the user is happy that it worked, they can do the actual flash step using nandwrite

• if it didn't work, they can turn it off and on again

• nothing gets bricked

Looks plausible so far, which probably means there's something I've forgotten.