Grandmaster, cut faster
Tue, 06 Mar 2018 22:28:59 +0000
No Nix content at all this week, as all I've done is flash (please refer back to blog post title) my TL-WR842ND back to the factory firmware in preparation for figuring out how to get NixWRT onto it.
There's some discussion of how to do this on the OpenWRT
wiki - attach
router to wired network, configure a tftp server to answer on
192.168.1.66 and respond to requests for a file called
wr842ndv1_tp_recovery.bin which was previously downloaded from the
TP-Link site, then turn the router on while holding RESET and wait for
stuff to happen.
As always, however, there is a wrinkle. The firmware I downloaded was a ZIP which contained a file called
wr842ndv1_en_3_12_25_up_boot(130322).bin, and according to most sources (most sources parrot the OpenWRT wiki)
in case the file name of this firmware file does contain the word “boot” in it, you need to cut off parts of the image file before flashing it:
specifically, remove the first 131584 bytes. Why that number? It doesn't say.
This is what binwalk is for
[dan@carobn:~]$ nix-shell -p python27Packages.binwalk --run "binwalk /tmp/wr842.bin"
DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 TP-Link firmware header, firmware version: 1.-3012.3, image version: "", product ID: 0x0, product version: 138543105, kernel load address: 0x0, kernel entry point: 0x80002000, kernel offset: 8258048, kernel length: 512, rootfs offset: 872767, rootfs length: 1048576, bootloader offset: 7077888, bootloader length: 0 110592 0x1B000 U-Boot version string, "U-Boot 1.1.4 (Mar 22 2013 - 09:09:03)" 110768 0x1B0B0 CRC32 polynomial table, big endian 131584 0x20200 TP-Link firmware header, firmware version: 0.0.3, image version: "", product ID: 0x0, product version: 138543105, kernel load address: 0x0, kernel entry point: 0x80002000, kernel offset: 8126464, kernel length: 512, rootfs offset: 872767, rootfs length: 1048576, bootloader offset: 7077888, bootloader length: 0 132096 0x20400 gzip compressed data, has original file name: "vmlinux.bin", from Unix, last modified: 2013-03-22 01:11:22 1180160 0x120200 Squashfs filesystem, big endian, lzma signature, version 3.1, size: 4675579 bytes, 562 inodes, blocksize: 65536 bytes, created: 2013-03-22 01:24:41
So there you are: the emergency tftp restore expects an image with a TP-Link firmware header followed by a kernel followed by a filesystem - which roughly corresponds with the description of
mtd5 in the openwrt flash layout - but the image on the TP-Link site prefaces that with about 128k of something that might be U-boot, which roughly corresponds with the layout of the entire flash chip
Going forward this is relevant insofar as it means we really have two problems not just one
- creating a firmware layout for NixWRT which is acceptable to some flashing tool or other - the tftp emergency flash, or the "Firmware upgrade" web ui in the OEM firmware, or some facility offered by OpenWRT if I flash that first.
- creating a kernel and fs which will boot successfully on the hardware and work well enough to bring up networking. Because, as previously mentioned, I have not yet been able to make the serial console work.
Currently thinking: we can tackle problem 2 first. Let's put OpenWRT on the machine (then at least I have ssh available) and then build a kernel/fs I can start with kexec and iterate on that until I know it works on the hardware. Once we have the right code then we can start figuring out how to put it at the right offset.
- last week: https://ww.telent.net/2018/2/28/musl_memory