To Arms#
Tue 03 Oct 2023 07:10:23 PM UTC
Progress on Liminix ARM support. The device I'm starting with is the Belkin RT3200 (also known as Linksys E8450) which seems to be a reasonably featureful piece of kit, and which I snagged for a very good price on the Bay of E.
Where are we right now?
- we can TFTP boot it to userland
- ethernet works
- ~~2.4GHz wifi works~~ we thought we'd added 2.4GHz wifi but it was a sad misunderstanding and a lesson in why you should unplug the old test device before starting with the new one
What else needs doing?
- the hardware supports 5GHz wifi, so add that
- we're only running in RAM, probably need to add some kernel config to support the flash
- initramfs support is not yet implemented
- the flash is NAND flash and it's quite large compared with the existing Liminix devices, so we're going to add UBIFS which will use it better than JFFS2 does
- there are some interesting hardware affordances for hardware offload that it would be fun to play with
- the initial work is on a branch and needs to be cleaned up a lot before I'm letting it into main
What have we found?
There are some significant differences between this and the MIPS devices (yes, other than an entirely different architecture), mostly to do with "legacy boot" support or the lack thereof. For example:
-
there aren't any options like
MIPS_RAW_APPENDED_DTBto glom together a kernel and device tree (FDT), because the bootloader is expected to be able to provide a FDT following "standards". U-Boot will do this, provided that we use the newer "FIT" uImage format which allows a kernel and DTB and initrd to be combined in the same container. (Sadly we can't use FIT everywhere because a lot of MIPS devices use really old forks of U-Boot that don't understand it) -
for tftpboot, on MIPS we use the
memmap=kernel command line option to reserve some RAM for the root filesystem. On Arm there's no such option, so we have to add a reserved-memory node in the device tree instead. Which means, given that we only want to do this when tftp booting (the memory is wasted otherwise), we have to rewrite the device tree in that scenario. -
then it turns out that phram doesn't (didn't) work anyway, because it calls ioremap() and you can't use ioremap on system memory on ARM. In newer kernels this is fixed: there is a conditional here to use whichever of ioremap or memremap is appropriate for the memory passed to phram, but it looks non-trivial to backport so I've gone for a much less sophisticated approach.
-
we're using DSA instead of the OpenWrt swconfig program. There was actually surprisingly little work needed to adjust to this.
Other than that, it was mostly the usual process of "did the kernel crash silently, or has it just been unable to open a console device?". In this regard, one neat trick: even though U-Boot on this device doesn't support pstore, we can use it anyway if we turn off compression. We enable
PSTORE = "y";
PSTORE_RAM = "y";
PSTORE_CONSOLE = "y";
PSTORE_DEFLATE_COMPRESS = "n";
then boot with panic=3 oops=panic, then when it resets use the
U_Boot md command to see what happened:
MT7622> md 0x42ff0000
42ff0000: 43474244 00000000 00000ff4 3d3d3d3d DBGC........====
42ff0010: 39342e31 36373031 500a442d 63696e61 1.491076-D.Panic
42ff0020: 50203123 31747261 3e363c0a 20505050 #1 Part1.<6>PPP
42ff0030: 20445342 706d6f43 73736572 206e6f69 BSD Compression
[... etc ...]
42ff0ca0: 20676e69 73756e75 6b206465 656e7265 ing unused kerne
42ff0cb0: 656d206c 79726f6d 3731203a 0a4b3832 l memory: 1728K.
42ff0cc0: 523e363c 2f206e75 74696e69 20736120 <6>Run /init as
42ff0cd0: 74696e69 6f727020 73736563 3e373c0a init process.<7>
[... etc etc ...]
What next?
Wifi. And, er, test it properly this time?