Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Purpose of fix_u96v2_pwrseq_simple.patch #63

Closed
jan-kiszka opened this issue Sep 14, 2020 · 12 comments
Closed

Purpose of fix_u96v2_pwrseq_simple.patch #63

jan-kiszka opened this issue Sep 14, 2020 · 12 comments

Comments

@jan-kiszka
Copy link

What is https://github.com/Avnet/Ultra96-PYNQ/blob/master/Ultra96/petalinux_bsp_v2/meta-user/recipes-kernel/linux/linux-xlnx/fix_u96v2_pwrseq_simple.patch doing? It lacks a commit message and the commit introducing it as well. I suppose it's not related to the SD card but rather the SDIO-attached WIFI module, right?

@FredKellerman
Copy link
Collaborator

The patch performs the proper power up sequence before the sdio tuning occurs. If the wifi module is reset and powered up after the sdio is tuned it can no longer talk to the Zynq. It is combination of the way the Xilinx mmc/sdio and the Microchip wifi module works and the way PetaLinux brings up the system that unfortunately requires this. You can look at the datasheet for the wilc 3000 for more info on the sequence of the 2 pins that are manipulated.

@jan-kiszka
Copy link
Author

Ok, thanks. So how to get that into shape for upstream? This patch looks like it is not legally touching generic code, is it?

@FredKellerman
Copy link
Collaborator

That patch is modifying code that was somewhat intended for generic use but yes modifies it specifically for Ultra96 v2. A unique hook power up function and device tree options at a minimum would need to be done.

It would be nice to make this integration cleaner and easier for re-use but just know that it is more complicated than this patch to seamlessly integrate U96 v2 wifi into the mainstream Linux systems. What has been done for now with this patch and other work is to make it work for the 2 platforms we see the most demand for: PYNQ and the Xilinx PetaLinux bare bones bsps.

If there are people who want to do the work to make changes to upstream all of it and do it in a manner that is compatible with the Xilinx based distributions: I don't have the bandwidth to do all the work but I can certainly provide guidance.

@jan-kiszka
Copy link
Author

Yeah, wilc3000 upstreaming (linux4wilc/driver#104) is apparently a precondition for this change as well - unless you see other users of such a mechanism somewhere AND those are already upstream.

@FredKellerman
Copy link
Collaborator

It is more complicated than that even. The wilc3000 is not compatible with the Xilinx ARM CPUs and Petalinux. U96 required custom modifications to that driver as well. https://github.com/Avnet/u96v2-wilc-driver

@jan-kiszka
Copy link
Author

Yes, I'm playing with that right now. Politely expressed: I've seen nicer, less ad-hoc things...

@njpillitteri
Copy link

No one else expressed that

@FredKellerman
Copy link
Collaborator

Haven't we all seen nicer things and worse. Given all of the many not apparent constraints, compromises occurred. Very much looking forward to being able to just check a box and include the driver someday myself. If you can make that happen, very much appreciated!

@jan-kiszka
Copy link
Author

I'm likely barking at the wrong tree, sorry. You were most probably not asked when a wifi chip was selected for v2 which has no proper Linux driver so far. And if the way it was wired on the board was just too smart for Linux and the out-of-tree driver or if that was another mistake, I can't say.

Anyway, the result is a software stack that makes integration much harder than with the v1 where wifi just worked. I'm now fighting on the v2 with the wifi firmware not coming up on a 5.4.61 kernel and, consequently, the driver not working. I'm using the avnet fork, the related dtb adjustments and this kernel patch. Of course, pynq 2.5 image works, maybe a self-built 2.6 image as well (just generating), but that does not help in our integration scenarios.

So: happy debugging, rather than spending some cycles on consolidating and upstreaming...

@FredKellerman
Copy link
Collaborator

Your summary of why is not quite accurate and I simply cannot reveal all the details. It was much harder on me personally than just not asking about that. I sacrificed a lot to do this 'ad-hoc' work so that users would have some kind of wifi for the v2, even if it is not the most beautiful.

The firmware loading: with PYNQ it has to be copied over to the rootfs because of the way kernel modules are assimilated with PYNQ. For other contexts, such as Petalinux without PYNQ, the Yocto recipe does the job when used with this power-up patch.

All my ad-hoc is on the table and I've reminded you of all the relevant details I can think of. There was much less to work with when I started and got it working, you will figure it out.

@njpillitteri
Copy link

Fred, respectfully, fuck that guy

@zedhed
Copy link
Collaborator

zedhed commented Sep 16, 2020

In truth, @FredKellerman did some amazing work to mitigate some very hairy set of circumstances around the Wi-Fi that are beyond my comprehension.

Please don't continue to post to this Github thread since the friendly discussion is coming off the rails. If anyone is seeking further support on this topic, you can contact us via the Ultra96 support forums on the Element14.com website which is the preferred channel for Ultra96 support.

https://www.element14.com/community/community/designcenter/zedboardcommunity/ultra96

If anyone is interested in doing work and sharing publicly to enhance the Ultra96-V2 Wi-Fi experience, please PM me on Element14 site where my handle there is @zedhed and we will see if we can work out something to your benefit.

@Avnet Avnet locked as too heated and limited conversation to collaborators Sep 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants