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.
- 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 loopand 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
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
- 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.