Hi Martin, Thanks for all of the input. I do like the UHD build system. Make seems cryptic and convoluted at first glance, but it starts making sense pretty quickly, even if you don’t understand some of the more nuanced blocks. I agree with your assessment of the other build systems, and I never really could put my finger on what it was that kept me from buying in. I think it was our discussion with Marcus that gave me a clue as to what it might be. Up to this point, I’ve never been particularly “for” or “against” Make; it is simply something that is pretty much everywhere. The other build systems don’t have that. More people are familiar with Make; it is installed by default on every Linux distribution I can think of, and I can pretty much take my code to any Linux machine with Vivado and build it.
> I'm glad to hear you weren't put off by the `rfnoc_image_builder` workflow > on top of make (I\ > assume you've been using that given the UHD 4.7 dependency?) and it's nice\ > to hear you've been successful building stuff. Hahaha I have to admit, I haven’t run `rfnoc_image_builder `yet, since I haven’t changed anything in the data-path. To be honest, I don’t have much experience with RFNoC because I always design the data-path from scratch depending on what’s needed by the processing blocks and the larger system. Not that I don’t re-use modules; it’s simply that I enjoy FIFOs, gearboxes, managing clock domains, flow-control, loopback, timing constraints, etc. Is it weird that I’ve never felt like I wished there were something that could just take care of that for me? Hahaha Maybe. :-) > That said if you find something unnecessarily annoying with our build\ > system, please let us know. We know that building custom bitfiles for USRPs\ > hasn't always been the easiest/nicest option in the past, and we would\ > really like to make the FPGA computational capacities available to more\ > people. There really wasn’t anything that annoyed me…which is rare. :-) It did take me a bit to figure out how to get the new bitfile and device tree into the rootfs build system, but I think I figured it out well enough. What might help people is maybe adding an environment variable (or some similar mechanism) that both build tools use to point to the UHD build output (usrp_x410_fpga_xxx.bit and usrp_x410_fpga_xxx.dts). The UHD build could export them, and they could be imported from there by the KAS config or in a meta-ettus recipe. Maybe that’s similar to how it works already? It just wasn’t obvious to me, so I modified our KAS config yaml, `uhd-fpga-images.inc`, and `uhd-fpga-images_%.bbappend`. The reason I suggest that is because anyone that may be comfortable using the PetaLinux tools, but hasn’t yet experienced the “joy” (terror?) of their first pure Yocto experience is used to an `export_hardware` style relation ship between Vivado and PetaLinux that simplifies getting the PL device tree and bitfile into the image. Mike
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
