Need advice for adding analog devices drivers to OpenWrt zynq7000 target

Dear reader,

I am trying to get OpenWiFi in OpenWrt to run on the adrv9361z7035 board (Zynq 7000 architecture). This requires me to install a couple of drivers (with each possibly having dependencies). The drivers + dependencies are found in the Analog Devices linux kernel fork (which in itself is a fork of the Xilinx linux kernel). (2022_r2_release is based on linux kernel 5.15, the same version as used currently when creating an OpenWrt image for zynq7000 target)

The main driver is under drivers/iio/adc/ad9361.c. Unfortunately, the other drivers have a lot of dependencies on other analog devices linux kernel only drivers (cf_axi_dds, jesd204, adjustable-clock,...).

I have been thinking about ways to properly implement this in OpenWrt. My current best solution was to add kernel packages. Each packages applied a patch to the kernel source. This gave issues with patches failing because of chronological order. It would have been nice if the analog devices drivers where a seperate folder from the usual kernel drivers, so you could build the analog devices drivers with the include from the kernel (with some patches also).

My question is, what is the proper/good way to implement this?

Kind regards

1 Like

Since you are using the Zynq provided firmware, you need to ask them about this process. You'll need to use their SDK in order to get it to work with their firmware.

To be clear, their fork of OpenWrt is not the same as official OpenWrt, and it will not operate the same way. This is why you need to refer to their documentation, support channels, and sdk.

If you "only" add th AD driver to the Openwrt kernel, you'll have to maintain it, forever.

Better to get it into mainline, if possible.

1 Like

Maybe I stated my question in a confusing way. (I rephrased my original question, I hope in a more clear manner now)
OpenWrt already has a Zynq target (Zynq7000).
The analog devices linux fork is just a linux kernel. It is not an OpenWrt fork.

My goals is to be able to build OpenWrt for the Zynq7000 board, with the OpenWiFi driver, which requires some Analog Devices drivers. The analog devices driver source code resides in the analog devices fork of the 'vanilla' linux kernel.

1 Like

Hi frollic,

Thank you for answering. So you suggest getting it into the mainline/vanilla linux kernel?

Three questions come into mind with that:

  • The driver was written for the 5.15 kernel, I cannot just commit it on the latest linux kernel release right?
  • Is this what Analog Devices wants? Since adding all Analog Devices related stuff to the mainline kernel would dramatically increase it's size and file/folder count.
  • In case I do get it into mainline, how do I get it into the zynq7000 build target without having to upgrade the target to the latest linux kernel?

Kind regards

Probably not, but that's not a question for this forum.

No idea.

That's not an issue, at least not for Openwrt.

You won't, from an Openwrt point of view. The v5 kernel ship has sailed, next release will be using a v6 LTS kernel.

It would be awesome to have the OpenWifi project build into OpenWrt.
Could you first add support for the adrv9361z7035 as a single pull request without the SDR part? When this got accepted, you could add the OpenWifi driver as a optional driver module.
Your Zynq board is special because it have the AD9361 already build into. Making it more modular for the OpenWrt codebase would be the better way because there are also boards out there like the Zedboard that are already supported by OpenWrt and the AD9361 is modular and can be attached and removed.

You are using your board connected to the ADRV1CRR-FMC?

1 Like

Thank you for answering!

The board is connected to the ADRV1CRR-BOB (Break Out Board).

The current plan would be to add the adrv9361z7035 support, analog devices related stuff and OpenWiFi as three independent pull requests.

Concerning the analog devices drivers, the ad9361, cf_axi_dds and adjustable clock need the analog devices linux kernel variant to work correctly. Right now I have separate Makefile for all of them. I think the most logical would be to integrate them into one Makefile containing 1 normal Package (providing the analog devices linux kernel sources) and 3 KernelPackages.

The OpenWiFi sources have a similar issue.

What would be the best way to proceed?

Perfect

Because life experience tells that many people want to do many great things at once, at the end no a single of those things got done.
Could you first send the pull request for the board? If something bad happens and you cant continue then, the OpenWrt support for the board would be there.
While you are waiting then for the OpenWrt developers to merge your pull request for the board, you could start writing and then submitting support for the AD936* SDR part. Also this second part alone would be beneficial. At the moment there is to my knowledge not a single SDR supported by OpenWrt that could transmit. Here are the packages listed that are already in OpenWrt supporting SDR: https://openwrt.org/docs/guide-user/advanced/sdr
This second SDR-pull-request would again be beneficial on its own. For the first time people could transmit signals with OpenWrt on a different frequency then 2.4,5 and 6 Ghz by using a AD936* SDR. You would also then get comments from the OpenWrt developers about your makefile-questions based on code. Those comments you can at the final end directly take care when creating the third and OpenWifi pull request.

I have high hopes at you and am really happy to see soon SDR and OpenWifi support build into OpenWrt. You already commited to the OpenWifi project here https://github.com/open-sdr/openwifi/pull/393 :+1:

Thanks you for your enthusiasm.

I am glad to hear that there is definitely a desire for the work I am doing.

Before contributing is possible, my master thesis guide must agree with university and others on how and what will be contributed under who his name. It’s it not within my power to decide.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.