I'm currently working on porting OpenWrt to the AVM FRITZ!Box 3390. This device is similar to the 7490, but lacks a few features. As the 7490, it has a separate Atheros SoC for WiFi offloading, which makes things a bit more complicated. I've been hacking around the device for a few days now, here is the current status and a bunch a questions:
Lantiq SoC working, not extensively tested
Communication with Atheros SoC working, but a bit hacky (see below)
Second OpenWrt RAM image running on Ahteros SoC (boots, nothing more tested)
The upload of the stage 1 firmware to the Atheros device works via MDIO. I had to create a fake PHY driver that exposes the MDIO registers to sysfs and patched the Lantiq ethernet driver to fake a fixed PHY id at a specified address. I don't like this part, any suggestions how this could be improved?
The upload of the stage 2 firmware works over raw ethernet frames, this works quite nicely. I can upload and boot an OpenWrt initramfs image.
Now the questions:
How can I improve the MDIO kernel driver to be less hacky?
The Atheros SoC has no flash storage! How could the two OpenWrt instances communicate or how could the Atheros SoC save configuration data?
I tested WiFi only very briefly, but ath9k fails to load because of missing EEPROM data. Obviously, there is nor ART partition, so how can I provide the needed data?
I wonder if they really need to talk to each other at all? What about keeping them independent, making the lantiq host just bridge the ath79 system to LAN and punting all wireless jobs to the ath79 instance (think, lantiq as wired router/ modem, ath79 as dumb AP - two IPs, two webinterfaces).
Have you found the calibration data somewhere on your host? it must be somewhere, once identified you hardcode it into your initramfs image for now (a proper generic solution might need some kind of communication channel between lantiq and ath79, maybe ssh/ scp to copy it over, before handing it off to owl-loader as needed).
I'd delay that question as much as possible, closer to getting your changes merged. It's kind of complex, but there are a couple of potential solutions (and maybe even more):
lantiq host --> ath79, it' possible to append data to an initramfs
sadly this doesn't allow saving the changes back to the host, if changed on the ath79 SOC
scp with ssh keys, if scp is only initiated from the ath79 system you can largely avoid mutexes.
this is a bit tricky to get working in a way that doesn't hardcode keys into the published images
rpcd (with proper ACLs) might allow some kind of network communication as well.
The OpenWrt developers might come up with better ideas, that's why I'd suggest to leave this question until later (and to work with hardcoded settings until then), when you're confident to have everything else but this (and probably integration into the buildsystem) running and sorted. It's difficult to do properly - and there are multiple potential solutions, some easier than others.
I'd first check the NOR/ NAND partitions, then the OEM rootfs, maybe you're lucky (the calibration data might, but doesn't need to, contain your WLAN MAC address(es)).
I found the calibration data in the Lantiq SPI flash, transferred it via SSH to my ath79 target and WiFi works! The MAC addresses are also in the SPI flash, but not in the calibration section. However, I couldn't figure out which calibration data corresponds to which WiFi interface - any hints on this?
Basically, everything is up and running but still a very manual process. I need to figure out how to boot the ath79 SoC automatically and how to transfer configuration files to the target. Further, the default IP address of the ath79 target conflicts with the Lantiq SoC (both get 192.168.1.1 by default).
One option I'm considering is booting the ath79 with an nfsroot. That would allow read-write on the ath79 and would solve the issue with the ath9k firmware. Any hints on how to automate this process in the build system?
I think using a uci-defaults script might help here, to configure it as needed - both on the host (to add a static DHCP lease for the ath79 SOC) and on the ath79 to use DHCP (that's still not without issue, if the user later decides to change the subnet - but at least it provides a means to configure the ath79 address from the lantiq system.
Fixed it, the 5GHz WiFi now works on the Lantiq side. Needs another kernel patch, though: For whatever reason, a second GPIO is needed for the reset of the PCIe PHY (it's called "gpio_avm_pcie_chip_reset0") in the OEM dts file.
I patched the Lantiq PCIe driver to support reading a second reset GPIO from DT.
Had I known how much hassle (fun?) adding support for this device is, I would have never bought it...
@slh What do you think about the following approach regarding configuration of the ath79 target:
The Lantiq image, at first, does not contain an ath79 target image
The user has to run a script on the Lantiq that
downloads an ath79 target firmware
decompresses the rootfs
extracts the ath9k eeprom from flash and places it to the rootfs
configures a default IP address
offers the user some WiFi configuration options
reassembles kernel and initramfs
an init-script on the Lantiq starts the upload process
Basically, that gets rid of all network auto-configuration and allows the user to fully configure the ath79 target. The real downside is that it requires a separate LuCI module for configuring the ath79.
That is probably the easiest way to get patches merged - and leaves the door open for later refinement (I think the preconfiguration steps can be improved quite a bit via uci-defaults, after all the ath79 basically only needs to request a predictable DHCP lease from lantiq, everything else should work just fine via a second luci instance).