I think I have the same problem as: PCAM 5C failed initialize with custom overlay kv260. With exactly the same board set up and the Digilent PCam 5C, however, my MIPI related error persists even with the .dtsi file in the working repo.
Just wondering If I have the .dtsi file added and named correctly?
As well as this, I have been playing around with the rest of the notebooks (great introduction and very user friendly by the way) and have a few questions about the KV260 and the possible input and outputs.
Is the KV260 tailored towards a Display Port output? As a USB webcam with a Display Port output works fairly consistently, crashing the odd time leaving to a black screen but not as bad as with an HDMI.
Sometimes it presents this error when used with the MIPI only, or when HDMI is used as the output for a USB webcam It will work well the first time. By this I mean it displays video after the .start command and can apply livefeed filtering from the pipeline, but when the .stop command is sent it freezes. When it freezes it displays the last captured frame until the board is powered off and on, even if the kernel is disconnected and all leads to the board disconnected. Or sometimes sporadically it will present the error along the lines of “source and sink resolutions Dont match”
Could this be an issue with the video drivers on my Ubuntu installation rather than a glitch in the code?
Just wondering If I have the .dtsi file added and named correctly?
dtsi is the source file, you need to provide the compiled version (dtbo). The Makefile should do this.
Is the KV260 tailored towards a Display Port output?
DisplayPort and HDMI have the same source on the PS which is DisplayPort, then in the carrier card there’s a splitter to duplicate the video signal.
but when the .stop command is sent it freezes. When it freezes it displays the last captured frame until the board is powered off and on, even if the kernel is disconnected and all leads to the board disconnected. Or sometimes sporadically it will present the error along the lines of “source and sink resolutions Dont match”
I’ve seen this error before, but I tried to address it. I thought it was fixed in the latest commits
Ah my bad, I found the dtbo file in beside the makefile I will drag and drop it in instead. I have all the files extracted from running the makefile on a seperate device as I couldn’t on the Kria so I have taken over the .bit.hwh.json and .dtbo files now. Is that all I should need?
Will update the thread on the performance after trying with the dtbo imported>
Thanks,
Cameron
I have just noticed aswell, totally unrelated and might need it’s own thread, that I don’t seem to have any of the dfx blocks loaded in but the regions still appear.
I’m not sure whether these issues are a result of the fact the bitstream and the cloned repository is already located in the /usr directory from before (see the warning when loading the overlay). The files I have added via drag and drop were from a generated makefile on another device.
Can you spot anything obvious? Or should I delete the initial site of the repository to make the new files the focus?
You may not be importing your own bitstream, Overlay searches in certain locations and may be using the precompiled overlay. To avoid ambiguity, please use the fullpath Ovelray(<fullpath/*.bit>), also the ignore version is an argument to Overlay()
VSink.HDMI is not a valid sink for KV260, only VSink.DP. The phyiscal HDMI get the same image as DP. I see that the error message is wrong and something I’ll fix.
I suggest you run make zip where you built the project and then move the zip file and unziped on the board. You need the partial bitstreams and associated hwh files
Does MIPI work with the pre-compiled version? As I mentioned this branch is not fully tested and MIPI is something that was not tested at all.
I have just noticed aswell, totally unrelated and might need it’s own thread, that I don’t seem to have any of the dfx blocks loaded in but the regions still appear.
The DFX regions is something that can be inferred from the main hwh. However, the functionality is only added to the dictionary when the .bit and .hwh file exist
Thanks for the info, Will try adjusting the path of the overlay and test for the VSink.DP with the HDMI connected to see if I get an output.
Does running make zip restart the makefile and regenerate the project again? Or does it just zip up the products of the makefile? Could I potentially zip the folder with all product files I have extracted onto my windows device using 7zip and transfer with USB.
I will try now to test the MIPI with the precompiled bitstream and cloned repo but I’m near certain It didn’t work beforehand.
With regards to the DFX regions, do you think then it is searching in the wrong place for the .hwh file as I have it in the working jupyter directory alongside the .bit?
Does running make zip restart the makefile and regenerate the project again?
No, it only zips the overlay folder
With regards to the DFX regions, do you think then it is searching in the wrong place for the .hwh file as I have it in the working jupyter directory alongside the .bit?
No, it only searches where the main bitstream is. From the image you shared, these files are not there.
Ok so the plan is to zip the overlay folder and transfer it to the board and unzip, then dictate the fill path of the bitstream that’s within this folder and thus it should be able to use all the partial .hwh files?
Just for clarification then you need all the partial .hwh files on the board not just the main .hwh?
Ok so the plan is to zip the overlay folder and transfer it to the board and unzip, then dictate the fill path of the bitstream that’s within this folder and thus it should be able to use all the partial .hwh files?
Yes
Just for clarification then you need all the partial .hwh files on the board not just the main .hwh?
If you want to use the functions that are in the DFX regions, then yes.
