Xilinx Zynq or ZynqMP


Giuseppe

Recommended Posts

Did anyone try to support a Xilinx Zynq (ARM A9 + FPGA) or ZynqMP (ARM A53 + FPGA) board?

https://www.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html

 

Xilinx provides Petalinux (https://www.xilinx.com/products/design-tools/embedded-software/petalinux-sdk.html), but I like the flexibility of Armbian. If I had to try to support one of those boards, what should I look at?

 

Thank you

Link to post
Share on other sites
Armbian is a community driven open source project. Do you like to contribute your code?

12 hours ago, Giuseppe said:

Xilinx provides Petalinux (https://www.xilinx.com/products/design-tools/embedded-software/petalinux-sdk.html), but I like the flexibility of Armbian. If I had to try to support one of those boards, what should I look at?

 

step by step procedure? 

  1. get familiar with the build-script
  2. sort out sources
  3. try and fail 'a few' times
  4. get it working
  5. convince others that armbian support for this SoC is interesting (I failed on this for the mt7623, whereas @hjc got the firefly merged :P )

example:

 

 

special boards like this one with a FPGA might be interesting for a smaller part of the community, so you might need more arguments to convince people here but if you think it's worth, you can try it. :) 

From a 'board bring up' standpoint, it depends highly on sources. Is the bootloader in a 'good shape' how much kernel work needs to be done (for sure you'll spend some time in the kernelconfig menu to figure out what is needed, especially if there isn't some sort of a 'default config').. U-boot (assuming there's u-boot available for this SoC can be straight forward or: see mt7623 - where you've to deal with an outdated out of tree u-boot just to get the board booting and a lot of plumber work until it does what you want --> flattened DT there was frustrating, get it finally working was fun).

 

Is it fun? Hell yeah

Is it frustrating? hell yeah!!!

will it get merged? we'll see - I would assume chances are rather low but even when it doesn't get merged, the knowledge you gain would allow to maintain it 'out of the armbian tree' in case you're interested.

Does it make sense? Well, that's up to you to decide..

Link to post
Share on other sites
Just now, hjc said:
23 minutes ago, chwe said:

whereas @hjc got the firefly merged

It is probably because armbian already planned to support RK3399 boards at that time.

or you did the better job.. :P 

 

Both threads should show that it is possible, but you've to do the work on your own, we might help you where possible with some hints cause we know the buildscript a bit better. E.g. @zador.blood.stained gave me a small hint here to fix flattened device tree and I gave @hjc a small hint to fix kernelconfig for the firefly cause I faced the same issue during the work for the mt7623 (others, for sure, contributed much more to bring up the firefly. It's just an example). 

 

The thing here is: IMO it doesn't matter. Once you figured out how to bring up a board on your own, you're 'somehow' familiar with the buildscript (not every detail, but at least basically). From this point it doesn't matter much if your board/SoC is inside armbians repo or not. Cause chances are high that no maintainer will have this board means they can't fix your issues anyway. The reason mt7623 got never merged is mostly cause I never tried it.. :P I don't think it makes much sense to merge it when nobody else has an interest in this board/SoC. U-boot would need some fixing to have it properly supported (e.g. load env.txt is still not implemented due to me being lazy and nobody else cares as well). DSA for networking may need some adjustments upstream cause performance sucks (I never got multiple CPU ports working to see if this helps and the upstream people don't see a gain for this feature, otherwise this would be mainlined

 

For the Xilinx. I've no idea how the sources look like (and honestly, no interest in figure it out, I don't own the board and I'm not that much interested in FPGAs I'm a chemist not an EE :lol:). It seems that those sources are behind some log-in so you had to clarify if you're allowed to host this sources on a public available git-server, split it into multiple repos for kernel, bootloader, atf (for arm-64 boards), hope that there's a git history (makes things easier). And then figure out if debian/ubuntu makes sense for a FPGA. There's no Armian magic: means as soon as it boots 'armbian' everything is perfect.. :D The reason armbian performs better on some boards is due to people patch things which are crappy. If you're the only one who uses this board, you've to fix the crappy parts cause nobody else will do it. :P The only 'magic' armbians buildscript delivers is that it delivers you some toolchains in various versions and some general rootfs tweaks (e.g. log2ram, etc.). But from a kernel-side there's no magic.. that's hard work where people either write patches on their own or spot those patches from everywhere before they reach mainline and implement them. That's not magic that's hard work. The less people are interested in a board, the more hard work is on your side to spot this patches or write them on your own. But if you expect: I can bring up the board and then others will go out and spot the patches for me, fix it, keep it updated... well, then we don't provide such a service.. :) 

Link to post
Share on other sites
Guest
This topic is now closed to further replies.