The patches which are also useful to currently supported DSL routers, and some common ones we depend on, are all merged by now.
What's left are VR11 specific ones, and getting all of those merged depends on the licensing issue, without that OpenWrt cannot ship router images which contain the required DSL firmware.
Because the remaining patches mostly introduce new VR11 specific packages, the chances for conflicts between the vr11 and the evolving master branches are pretty low. So you can just rebase the vr11 branch on OpenWrt master and build that. While I rebase and push myself every now and then, that doesn't mean you have to wait for me to do so
Not shipping xDSL firmware and requiring the user to obtain it somehow and write it to the device has been a common occurrence in the past -- before Lantiq publish the redistributable VDSL firmware for VR9 and for users of VR9 connected to a DSLAM with mandatory vectoring it even still holds true up to today. This situation is not great, but still better than not supporting xDSL interfaces at all.
What I'm trying to say is: the lack of decently licensed firmware should not prevent us from merging patches and drivers which are licensed under GPLv2.
Hence, please lets go ahead and merge what we have by now, and then maybe also come up with helper scripts which allow users to easily download, extract and install non-redistributable xDSL firmware once when installing OpenWrt on VR11-based devices.
On the firmware situation, would it make sense to build USB mass storage support into the image (if it isn’t already)? Then it wouldn’t take much to install firmware from a USB stick: eg if a particular layout exists it’s automatically installed via a helper script, or can be done via a command. Then it just needs some instructions in what to copy to the USB stick.
The alternative is that the router would be operational for LAN purposes but not WAN, but that would be enough to scp the file over after having downloaded it from a machine that has internet.
That's a possibility, per default the images won't come with the required modules though.
But similar to the ltq-vdsl-fw package, you could add a new package which does all that while depending on the required modules. Once the PR is merged, users could then use imagebuilder to add that to their image so it's usable without inet connectivity. I won't pursue that option, but don't let me stop you from doing so
just cloned openwrt master and cherrypicked this EXCELENT pull request. will replace my bt homehub 5a since this fb 7530 has much more perfomance. thank you @moeller0 for pointing me to this thread! i'm totally happy and turris omnia + unstable allnet sfp module will go back to its sender. fritzbox 7530 just cost me 75€.
on bt homehub 5a i got only 33mbit download. (50/10 plan)
Currently DT's DLM system is intervening on your link and limiting the maximal allowed sync rates to 90/37 Mbps. The way this system is supposed to work is to adjust the maximal syncrates (as well as a few other less visible parameters) in proportion to the perceived 'instability' of a link (lower stability -> lower sync rates), but this adjustment is supposed to be dynamic. So in your case, with the likely cause for the intervention being an only partially suited modem that often resynct, I exxpect that in the next few weeks DLM will open up the allowed sync again. Could you please post the go-dsl output/screenshot in say a month, please?
One thing to be aware of though is that there is a variant of the 7520 called "Typ B". That one still uses an IPQ40xx SoC, and OpenWrt should probably run on it (the device tree is nearly identical). However, it has a Realtek modem (actually an entire second SoC) instead of the VRX518.
(Unfortunately, an open source archive for that model is not yet available. It would be interesting to see what's actually in there, because all the drivers on the Realtek side seem to be built into the kernel image. Although the host side drivers to get the Realtek SoC to boot at all would be more important for getting the modem running.)
I looked at this again, and in the end the code in qcom_pcie_prog_magic is actually not all that magic. The last line changes the vendor/device ID of the PCIe host, as already expected.
The code before that writes the Lantiq manufacturer ID 0x839 to a buffer, and configures the PCIe address translation unit so that it is visible at a memory range that contains chip identification on Lantiq SoCs.
The exact location of the value within the buffer is a bit strange though. On xrx200 the offset 0x340 from the MPS base address (which is actually referenced in some Lantiq bootloader sources as containing manufacturer ID) contains the value 0x1820. The manufacturer ID is actually at 0x344 and only shifted 1 bit to the left. But that might be different on GRX500.