Hi Piotr, Martin,
I’ve had some success in getting the driver installed in the kernel. It is
pretty straightforward, and Piotr’s suggestions regarding `xlnx_dpu.c` and
`xlnx_dpu.h` were spot on.
Currently, the driver fails while loading during boot. Some Google searches
suggest either the
Hi Piotr,
I’m looking into the DPU driver kernel mods now. I’ll keep you posted.
Cheers,
Mike
per...@o2.pl wrote:
> Hello Mike,
>
> After short look at current linux-xlnx - it seems that there are not that
> many changes needed for DPU to work. The driver is in one C file + C header:\
> li
Hey Piotr!
I was able to patch the meta-mender layer to fix the PSEUDO_ABORT bug. I’m
still not sure it’s a bug in Mender, but it only seems to occur when I have the
graphviz recipe included, which is required by the Vitis-AI library recipes.
I’m really glad to have Mender images now. Tha
is actually
> good that you already are able to run those builds with ‘kas’ but
> without docker.
>
> Piotr
>
> W dniu 10.10.2024 o 17:51, mruane--- via USRP-users pisze:
>
> > Hi Piotr!
> >
> > So sorry for the delay!
> >
> > Wow, that’s a lot of go
Hi Piotr,
I just noticed that I had a typo in my reply to you.
Regarding the statement,
> you could just set it to transmit samples as soon as it gets them (i.e. the
> wr_data_en signal would be equal to the inverted FIFO empty flag)
I called the control signal ‘wr_data_en‘, thinking of the en
Hi Piotr,
I’m really glad you mentioned xlnx_dpu.c and xlnx_dpu.h. I found those a few
days ago (in the linux-xlnx github repo, I think), and I was trying to find a
recipe that installs them, but no luck. I didn’t think of manually copying
them to the NI kernel and adding them to the NI rec
Hi Piotr,
Thanks. The PXE boot info is fantastic. I don’t have it set up yet, but I’m
going to start setting everything up today. I’ll start with just getting JTAG
tftpboot running, and then start setting up NFS/PXE boot.
Once this is working, it will REALLY simplify testing the rootfs.
Hi Piotr!
So sorry for the delay!
Wow, that’s a lot of good information! Thanks for the starting point
information. I spent some time trying to find a common starting point. I
have also been looking at the kernel config parameters in the defconfig and
.cfg files. In the linux-xlnx kern
Hi Martin,
Thanks for the recipe links. As of yesterday, I figured that the linux-x4xx
files were the place to start. The files linux-usrp_5.10.bb and
linux-yocto_5.2.\* got me turned around at first, but I found my way out
eventually. :-)
I don’t usually do much with the kernel, except us
Hi Martin,
> Be advised that bad configurations of kernel and/or FPGA (or device tree\
> info) can lead to boot loops which are pretty annoying to auto-fix.
>
> \--M
\:-) You caught me daydreaming about automating the tedious debug I’m about to
start. :-)
___
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
Piotr,
Every time I see a clever set of build scripts or a really good Make
integration I think about trying to adapt it to my workflow and incorporate it
into my build process. I really do like the Ettus UHD setup. It seems
remarkably flexible. They clearly put a lot of thought into it.
Hi Piotr,
> This was especially important when dealing with kernel and bootloader. As I
> didn’t have much experience with editing kernel and u-boot sources, it was
> indispensable to be able to check my changes and applied patches quickly (the
> additional difficulty was that I didn’t have a X
> Now the situation is different: most recent linux-xlnx is 6.6 and USRP still
> uses the same kernel.
Yeah…I’ll have to look at that. I’m actually building UHD 4.7.0, but there’s
nothing newer than 5.10 in meta-ettus, and my current 4.7 image on the board is
showing 5.10.37-x4xx. I’m build
Hi Piotr,
I’m not familiar enough with RFNoC to be of assistance there, but your thought
about controlling the flow of samples between the ADC and the radio block seems
to have some merit. We frequently timestamp the sample stream so that we can
then tell the radio to, “Give me samples betwee
Hi Piotr,
I looked through the code in your repo, and it’s a perfect template for the
types of patches and mods I need to make. I had seen the x410_defconfig file
in the kernel recipes and was wondering if I could edit it, or if it was
automatically generated. Seeing that you added a few Xi
Well put. The abstraction really is at the heart of it, isn’t it? Perhaps
that’s why Make was adopted by the hardware world more slowly. Over the last
decade or two, FPGAs have gotten so large, and the external connectivity
options so numerous (1GE, 10GE, 40G, 100G), that hardware designs
Hi Marcus!
Hahaha I thoroughly enjoyed the rant! I think you are correct about Make
and its variations. Indispensable seems an understatement for something that
is so pervasive in software development. As I mentioned, I am primarily an
FPGA developer. At some point, when the Zynq a
Hi Piotr,
Thanks! That actually does help quite a bit. You hit perfectly on my main
dilemma: Is it more straightforward to patch the linux-xlnx kernel with the UHD
mods, or do I patch the UHD kernel with the linux-xlnx mods?
The fact that you’ve successfully added linux-xlnx features to the
Hi all!
I’m an FPGA developer, dragged into the Yocto world a few years ago with the
move to Zynq and ZynqMP architectures. As a research group, we mainly develop
on Xilinx dev boards like the ZCU102 MPSoC, and ZCU111 RFSoC.
Having recent success adding the Xillinx Deep-Learning Processor (DP
20 matches
Mail list logo
