How to use meta-adi with a board not in the list of supported boards

Hi,

ddickerhoof said:

I am having trouble understanding why meta-adi only supports a small list of known device trees.

Well, this is already a big list of supported projects. For other projects to be added, it needs to be one that we think it will have lot's of users. Also, adding a new project is fairly simple which means that if we get someone asking for an "official" project to be added in meta-adi, we'll do it at that moment.

ddickerhoof said:

Why would I need to delete *any* device tree nodes to use meta-adi? I'm going to want to use them!

Because petalinux generates a bunch of nodes based on your system.top.xsa and if the IP's are xilinx ones, than the nodes are probably fine. If they aren't, the nodes are useless (see for example the compatibles used) and so we remove them. Maybe you can leave them and there are no redefinition of nodes and things work. But it might happen that your build will fail because of possible redefinitions. As we just don't want to take any chance, we remove all the nodes petalinux auto generates in a way that you are still allowed to leave some nodes untouched (eg: you use xilinx IPs in your project where the nodes are being properly generated).

ddickerhoof said:

Perhaps I don't understand the purpose of meta-adi.  Isn't it providing the kernel patches to support the enhanced IIO subsystem to support various Analog Devices device drivers with the HDL spi-engine framework for performance?

It does not provide any patch. It just uses the ADI kernel with ADI defconfigs so that all ADI drivers (or most) are compiled builtin. Of course for a real system, you'll have to tweak things to your needs as you just want to enable the drivers that your system needs. With meta-adi, you can easily build a supported project and when booting it all the devices (for that project) will be up and running (probed). You already have things as libiio/iiod in your rootfs pre-installed.

ddickerhoof said:

Why would kernel enhancements be specific to a set of known device trees?

Not getting what you mean here... meta-adi just uses the complete ADI kernel tree.

- Nuno Sá

I'm still confused. My plan was to add the meta-adi layers to get the ADI kernel to use in conjunction with other PetaLinux/Yocto recipes for other software components I need in my system.

My HDL design contains non-Xilinx IP--but it is primarily IP derived from ADI HDL for both ADC and DACs.  There is also some custom IP for HDL providing other functions we need on our board designs.

So, are you saying that the "Adding a new Devicetree" section is meant for adding another supported devicetree/project for others to use?  And that for my purposes, I can just include the meta-adi layers, and provide other customizations as necessary, without having to delete any device tree nodes?

I'm just not understanding why there would be any "redefinition" of device tree nodes.  The Xilinx device tree generator should generate nodes for all the IP during petalinux-config --get-hw-description, and the device tree gets extended with more information to fully describe the various spi-engines, dmacs, DACs and ADCs interfaced by the FPGA (through a .dtsi).  The meta-adi layer should provide the enhanced ADI kernel and IIO susbsystem, and I need to provide driver modules specific for my IP.  Is this incorrect?

ddickerhoof said:

I'm just not understanding why there would be any "redefinition" of device tree nodes.  The Xilinx device tree generator should generate nodes for all the IP during petalinux-config --get-hw-description, and the device tree gets extended with more information to fully describe the various spi-engines, dmacs, DACs and ADCs interfaced by the FPGA (through a .dtsi). 

Yes, but as I said... Did you looked at those nodes that are generated in the pl.dtsi file? They are useless and won't work with any of ADI drivers and likely with your custom drivers. Just look at the dt compatible string and you'll notice that the auto generator just puts some name that won't work with our drivers. On top of this there are properties missing or just wrong... Now if any of these nodes happens to have the same name as the ones used by ADI kernel (this happens in some of the projects we have in our kernel), the build would fail unless we delete them. And that is exactly what meta-adi is doing and why we have those pl-delete-nodes files for every project. Now you can say that we could just overwrite the complete devicetree with our own and ignore pl.dtsi. We din't went' that way because 1) we wanted to keep the typical petalinux flow and 2) because someone might want to use xilinx IPs for which the nodes will be correctly auto-generated and thus there's no need to delete them. So you can fine tune what you delete or not in these files.

ddickerhoof said:

and I need to provide driver modules specific for my IP.  Is this incorrect?

That's correct but you'll also have to define that custom HW in devicetree and I'm fairly sure that the auto-generated nodes petalinux will give you, will be wrong.

ddickerhoof said:

So, are you saying that the "Adding a new Devicetree" section is meant for adding another supported devicetree/project for others to use? 

Correct, that's how I would do it and the cleanest way... 

ddickerhoof said:

And that for my purposes, I can just include the meta-adi layers, and provide other customizations as necessary, without having to delete any device tree nodes?

As I said, you might get things working without deleting any nodes as long as there are no nodes with the same name. But you'll still have unnecessary nodes though...

Another thing that I might ask is, are you planning to reuse some ADI devicetree or do you intend to only use the ones present in petalinux? If you just want to use petalinux there's another option for you (though it is not supported in meta-adi but easy to add):

* You could just bypass the devicetree recipe in meta-adi and solely use the petalinux flow. For this, you would have to redefine a lot of things in system-user.dtsi to fix the wrong nodes in pl.dtsi which in my opinion is more cumbersome. But it might work better for you, not sure...

- Nuno Sá

Thanks! That clears things up a lot.

Interestingly, yesterday I removed the meta-adi-xilinx/recipes-bps/device-tree/device-tree.bbappend recipe. We have to append to the autogenerated device tree for our project anyway, so this is simpler for us.

In fact, I'm looking at using the recipes-kernel recipe in our project directly to get the kernel, and not using the layer.  But I think I better understand it now.

ddickerhoof said:

Interestingly, yesterday I removed the meta-adi-xilinx/recipes-bps/device-tree/device-tree.bbappend recipe. We have to append to the autogenerated device tree for our project anyway, so this is simpler for us.

Well, if this is a usecase, I can just add a new control variable (that you would set in your petalinux .conf file) that would bypass the do_configure extension of meta-adi...

ddickerhoof said:

In fact, I'm looking at using the recipes-kernel recipe in our project directly to get the kernel, and not using the layer.  But I think I better understand it now.

libiio might also make sense. Even though it's already part of openembedded, meta-adi extension brings it much up to date.

- Nuno Sá