Adding support for VRX518 (and maybe VRX320)

For Developers
383

If the full patch from the original post doesn't work, that could mean that my adaptation to OpenWrt is broken, or that the magic may be there for another reason.

One way to rule out the latter would be to try running the vendor firmware without the magic and check if anything breaks (if it causes the dc_ep_clk_on failed error, that should be easily visible in kernel messages from support data).

Since this just requires changing the device tree of the kernel, it is actually not that hard too do.

Instructions to modify vendor firmware kernel to disable magic

Modifying the kernel:

  • Download https://github.com/Freetz-NG/freetz-ng
  • Run make tools
  • Download and unpack Fritzbox firmware image (it is just a tar archive), find "kernel.image" in "var/tmp"
  • Run path/to/freetz-ng/tools/unpack_kernel -u kernel.image to unpack the kernel image
  • Open kernel.image.unpacked in hex editor and find avm,host_magic.
    Replace all occurences except the first (i.e. just the ones in DTB) by another string (changing one character is enough)
  • Run path/to/freetz-ng/tools/lzma e kernel.image.unpacked kernel.image.packed to compress the modified image again
  • Run path/to/freetz-ng/tools/lzma2eva 0x80208000 0x80208000 kernel.image.packed kernel.image.new to convert the compressed image to the format expected by the bootloader

Installation:
(The same firmware version that was used for modification already needs to be installed.)

  • Boot OpenWrt initramfs image
  • Copy the modified image to the device (e.g. using scp)
  • Run mtd write kernel.image.new "uboot$(fritz_tffs_nand -b -d /dev/mtd7 -n linux_fs_start)" to write the modified kernel to the active kernel partition
  • Reboot to run the vendor firmware with modified kernel

The latest vendor firmware helpfully includes kernel messages that show whether the magic is enabled or not, so it is easy to see if the modification worked (see the updated pcie-qcom.c from the latest source code release).

Kernel log from unmodified vendor firmware 
…
[    0.294461][2] PCI change magic executed
…
[    0.499963][2] pci 0000:00:00.0: [1bef:0030] type 01 class 0x060400
…
[   26.668227] vrx518_tc: Total 1 VRX518 EP detected
[   26.668274] Function platform_init called
…
Kernel log from vendor firmware with modified kernel image (without magic) 
…
[    0.294202][0] PCI change magic disabled. No host_magic set
…
[    0.499963][0] pci 0000:00:00.0: [17cb:1001] type 01 class 0x060400
…
[   26.725834] vrx518_tc: Total 1 VRX518 EP detected
[   26.725986] Function platform_init called
…

So, in my test, the modification worked, as shown by the kernel messages. It doesn't look like anything broke here. There's also no dc_ep_clk_on failed message in the place where it would occur (but as I tested on a device which doesn't show that error on OpenWrt, this is the expected result).

By the way, the recent open source archive contains some other interesting information. There are DTS files for a 7530 Typ B. I have no idea if it is out in the wild (maybe not, since there is no public firmware), but it may still be good to keep in mind for anyone looking to find a supported device. (There's also a 7530 AX Typ B, based on IPQ50xx+VRX518 like the 7510, but of course that is not that interesting until OpenWrt supports that SoC.)

1 Like