Date: Wed, 18 Aug 2010 00:21:06 +0800 From: Adrian Chadd <adrian.chadd@gmail.com> To: freebsd-mips@freebsd.org Subject: WIP: AR91XX (and AR724X, maybe) support Message-ID: <AANLkTi=xyR8RVRjHBs-2qU8-WodHVysmmE=H66f7DfEi@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi everyone, I've purchased a TP-LINK TL-WR1043ND which has an AR9132 SoC (+ on-chip AR9100 11n) in it. I've begun porting AR91xx and AR724X support over from Linux. Sans USB support, the kernel boots to mountroot>. This (currently GPL-tainted, so don't commit it!) patch is against -head: http://people.freebsd.org/~adrian/rspro/ar91xx-support.1.diff The patch introduces a set of CPU operations which implement the main per-chip differences. The dmesg (without USB; so it doesn't panic early in startup): http://people.freebsd.org/~adrian/rspro/dmesg-TL-WR1943ND.txt USB panics shortly after probe: ehci0: <AR71XX Integrated USB 2.0 controller> at mem 0x1b000000-0x1bffffff irq 1 on nexus0 ehci0: [ITHREAD] usbus0: set host controller mode usbus0: EHCI version 0.42 Trap cause = 5 (address error (store) - kernel mode) [ thread pid 0 tid 100000 ] Stopped at generic_bs_w_4+0x4: sw a3,0(a1) I've tested this patch on my AR7161 (in the routerstation pro) and have booted it to multi-user mode. Platform stuff that needs doing: * Need to finish porting the AR91xx related stubs * Need to finish porting (but not test :/) the AR724X related stubs * The USB code panics, figure out what is missing there * Add stubs for USB DDR flushing (which aren't used at the moment, but I'll get to it) * Add a stub to control the peripherals currently controlled via GPIO pins. At least USB differs between the two. * Modify if_arge to use the cpu op struct to get and set the pll * Add in the WMAC specifics for the AR91xx * If I can find an AR724x, find the PCIe specifics General stuff: * Go digging through the rest of the Linux headers and figure out what other differences there are; implement those * Finish rewriting the GPL chunks that are left Board stuff: * Find the flash device details; modify the flash driver to support that * Find out why arge0/arge1 aren't being correctly probed (arge0 has no PHY; arge1 has a bogus MAC) and rectify the situation enough so one of the interfaces is usable Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=xyR8RVRjHBs-2qU8-WodHVysmmE=H66f7DfEi>