ZU11EG RFSOM Building Correct Vivado Project for use with Petalinux

Is the switch from the SD card adaptor on the write protected end?

Andrei

No, We have verified that it isn't the switch on the SD card itself. We have tried both the uSD card slot on the RFSOM itself and the SD card slot on the carrier. We have even tried 5 different SD cards.

Using the SD card provided from AD, it is able to work just fine. We are thinking it is something in the HDL code from AD since our same Petalinux build is able to work on a ZCU102 dev board.

Hi,

Yes, the build should be done like in the README. If it's a supported project, it should be pretty straight. This may be a real issue with the system/project... 

celmqui said:

[ 1.888456] SPI driver fb_seps525 has no spi_device_id for syncoam,seps525
[ 1.895834] SPI driver pulsar_adc has no spi_device_id for adi,pulsar,ad7988-5
[ 1.902400] SPI driver pulsar_adc has no spi_device_id for adi,pulsar,ad7988-1
[ 1.909624] SPI driver pulsar_adc has no spi_device_id for adi,pulsar,ad7984
[ 1.916666] SPI driver pulsar_adc has no spi_device_id for adi,pulsar,ad7983
[ 1.923712] SPI driver pulsar_adc has no spi_device_id for adi,pulsar,ad7982
[ 1.930759] SPI driver pulsar_adc has no spi_device_id for adi,pulsar,ad7980
[ 1.937806] SPI driver pulsar_adc has no spi_device_id for adi,pulsar,ad7949
[ 1.944853] SPI driver pulsar_adc has no spi_device_id for adi,pulsar,ad7946
[ 1.951900] SPI driver pulsar_adc has no spi_device_id for adi,pulsar,ad7942
[ 1.958947] SPI driver pulsar_adc has no spi_device_id for adi,pulsar,ad7699

...

[ 2.268667] SPI driver adis16475 has no spi_device_id for adi,adis16507-2
[ 2.275452] SPI driver adis16475 has no spi_device_id for adi,adis16507-3
[ 2.282239] SPI driver adis16475 has no spi_device_id for adi,adis16575-2
[ 2.289026] SPI driver adis16475 has no spi_device_id for adi,adis16575-3
[ 2.295811] SPI driver adis16475 has no spi_device_id for adi,adis16576-2
[ 2.302600] SPI driver adis16475 has no spi_device_id for adi,adis16576-3
[ 2.309383] SPI driver adis16475 has no spi_device_id for adi,adis16577-2
[ 2.316169] SPI driver adis16475 has no spi_device_id for adi,adis16577-3

Those are "ok". The only issue with it is that module autoload won't work but that should no matter to you (also some of those are already fixed upstream - eg: the adis16* stuff).

celmqui said:

[ 32.405779] reboot: Power down

This is highly suspicious. Can you disable this daemon from the build and see how it works?

- Nuno Sá

Nuno,  I disabled the fan control daemon as you suggested but that did not change anything.  Our current situation is that we just hang in the boot before we even get to the previous "Power down" issue.   It is very frustrating that two builds of the Petalinux, with only a "petalinux-build -x clean" in between, results in two completely different behaviors.   The first was that we got as far as the "power down" issue.  After the clean, now we do not even get that far and it is hanging after dumping all those complaints about "no spi_device_id".  The above log shows where we hang, at [2.316169]. No further output after that.

If we were to suspect our Vivado build, is there a way to get the same .xsa file at ADI uses for the ZU11EG project and the PetaLinux build?  We are building the HDL from the repo but now I am wondering if we can skip that in an attempt to get to exactly what ADI has used to get this board running?

I do not find .xsa files anywhere for these boards...    is there a place I am missing?

Chris

Hi Chris,

I will comment only on the HDL side:

celmqui said:

I do not find .xsa files anywhere for these boards...    is there a place I am missing?

After you mount the release image on your SD card, you can find the folder for this project in the "boot" partition. There we have an archive called bootgen_sysfiles.tgz, and there it is the system_top.xsa file.

For reference, our build guide https://analogdevicesinc.github.io/hdl/user_guide/build_hdl.html (ported from wiki as we are in the process of migrating our doc).

For the other questions, you should wait for a response from Nuno.

Best regards,
Iulia

Thank you Lulia.  The release you link to is for "Kuiper Linux".  Can we assume that the .xsa there is also going to be correct for PetaLinux?  Will it generate a correct device-tree?

I will try it of course but I thought I would need to find something specifically for the PetaLinux build.

Chris

OK! good news update.  Using the .xsa that Lulia pointed us to, we can now boot the system completely and correctly.  Yippee!  That's the good news.

The bad news is that this does point at the HDL / Vivado step that we initially suspected. We are somehow apparently generating a broken .xsa from the HDL that is referred to by this page, https://github.com/analogdevicesinc/meta-adi/tree/main/meta-adi-xilinx     My cohort, NaN952 is doing the Vivado build, so at our next opportunity, we will try to find the HDL that corresponds to the .xsa referenced above and build that ourselves to try it.

This does prove that the PetaLinux is in good standing though, which is a relief.  Thank you for the help so far.  We might be back if we cannot get the HDL to work-- since we ultimately need to start from that and add in our own features.

Chris

celmqui said:

The bad news is that this does point at the HDL / Vivado step that we initially suspected. We are somehow apparently generating a broken .xsa from the HDL that is referred to by this page, https://github.com/analogdevicesinc/meta-adi/tree/main/meta-adi-xilinx     My cohort, NaN952 is doing the Vivado build, so at our next opportunity, we will try to find the HDL that corresponds to the .xsa referenced above and build that ourselves to try it.

Good to know you're doing progress. iulia can hopefully confirm the hdl part of things but here it goes my suspicions... The hdl meta-adi points in the wiki corresponds to the one you see referenced in the devicetree so it should be the correct project to build. Now, it may be that you need som build parameter for hdl...

Alternatively, it may be some issue with the main branch combo of hdl + petalinux. If I'm not mistaken, the one iulia pointed out is the one in the sdcard which should correspond to the 2022_R2 release branch.

- Nuno Sá

Hi celmqui, NaN952 ,

The HDL that is referenced in the table from the meta-adi-xilinx folder, is this one, with the following parameters set: https://github.com/analogdevicesinc/hdl/blob/main/projects/adrv9009zu11eg/adrv2crr_fmc/system_project.tcl#L28-L36 
Those are the default values, which are on the Kuiper Linux image for the SD card as well, if not indicated otherwise in their folder, by some "readme.txt" file or "make_parameters.txt" file. (I don't have right now the possibility to check on a card)

If you want to change them, you need to run the "make" command with parameters (see an example here).

I hope this answers your question.

Best regards,
Iulia

iulia ,

We generated our XSA file using that repo that you sent. We used make to generate the adrv2crr_fmc project and everything. We still got a broken XSA. Is there a specific branch/commit that we should be using? We have been working off the main branch as I couldn't find any documentation on what ranch we should be using. We used to most up to date branch that is using Vivado 2023.2

Ohh, ok, I understood now, sorry for the delay.

Unknown said:

Alternatively, it may be some issue with the main branch combo of hdl + petalinux. If I'm not mistaken, the one iulia pointed out is the one in the sdcard which should correspond to the 2022_R2 release branch.

What Nuno said here is right -- what I gave you, was an already built xsa from hdl_2022_r2_p1 (https://github.com/analogdevicesinc/hdl/tree/2022_r2_p1) . Still, can you try building the project from this? With Vivado 2022.2, it is very important to be this version.

https://github.com/analogdevicesinc/hdl/releases here we have our release notes

We have now built using Vivado 2022.2, after checking out the HDL on branch "hdl_2022_r2".   I do not see any branch labeled "2022_r2_p1" so tried  what seemed closest.    This fails to build correctly in Vivado, ending with "ERROR: Timing Constraints NOT met!" but does generate a "system_top_bad_timing.xsa" file.   Is that what is really being used?  or should we get a clean build with no errors?

Please advise the way to checkout and move to the correct branch in the HDL before we build...   eg,

git clone github.com/.../hdl.git

cd hdl

git checkout ?????     <-- I don't think we know this branch name correctly

cd projects/adrv9009zu11eg/adrv2crr_fmc

make

-- Chris

We have now built using Vivado 2022.2, after checking out the HDL on branch "hdl_2022_r2".   I do not see any branch labeled "2022_r2_p1" so tried  what seemed closest.    This fails to build correctly in Vivado, ending with "ERROR: Timing Constraints NOT met!" but does generate a "system_top_bad_timing.xsa" file.   Is that what is really being used?  or should we get a clean build with no errors?

Please advise the way to checkout and move to the correct branch in the HDL before we build...   eg,

git clone github.com/.../hdl.git

cd hdl

git checkout ?????     <-- I don't think we know this branch name correctly

cd projects/adrv9009zu11eg/adrv2crr_fmc

make

-- Chris

Sorry, I wrote the tag name wrong, but I put the correct link. 2022_r2_p1 is actually a tag, and it has the contents of hdl_2022_r2 with a patch on top.

The link I gave you was for 2022_r2_p1 tag: git checkout 2022_r2_p1

But anyway you should get a clean build with no errors (system_top.xsa). I compared hdl_2022_r2 and 2022_r2_p1 and the difference between them is 2 commits but those commits do not influence your project at all. I ran "make" on both of them, with Vivado 2022.2 in my $PATH, and I had no issues regarding timing constraints not met.

Can you run

hdl/projects/adrv9009zu11eg/adrv2crr_fmc$ make clean-all 
hdl/projects/adrv9009zu11eg/adrv2crr_fmc$ make

again? I'm guessing there was something left from previous builds, with Vivado 2023.2 or there weren't enough resources at the time when these constraints were checked...

yes! thank you.  I figured out the error of my ways while you were responding. I had been looking for a branch with that name, not a tag and so it never showed up on my branch list... In any case, I have now checked out the tag and rebuilt without any Vivado errors.  I then rebuilt PetaLinux using this new .xsa and Bingo! we have a success.  It has been a long slog but we appreciate everyone's help and patience.  We have a baseline now from which to go forward.   There is a concern that we are locked to Vivado 2022.2 with this solution but Nan952 is going to investigate how we might get to 2023.2, which from which he needs some features.

FWIW, I had done a clean-all prior to building with the 2022_r2 branch but that still resulted in the timing constraint error.   But, that's old news now and we are happily past that.

Thanks again for all of the help!

Chris

Glad to hear that. I raised this issue to the testing team for them to check whether it is an issue related to the latest HDL from main or if it's something coming from PetaLinux.

I'll try to keep you updated with the news, but if a couple of weeks pass and I still haven't replied, please remind me.

Best regards,
Iulia

iulia said:

Glad to hear that. I raised this issue to the testing team for them to check whether it is an issue related to the latest HDL from main or if it's something coming from PetaLinux.

Thanks for doing that iulia. I'll also do a test myself next week with petalinux. It may very well be that there was some change on the hdl that requires devicetree changes in petalinux.

- Nuno Sá

Hi   ,

Did you get to test it? So far -- I have no updates, as it doesn't seem to be an HDL bug.

Best regards,
Iulia

Hi iulia 

I just tested it with an hdl from our internal artifactory and it works fine for me...

root@talisesom:~# cat /etc/os-release
ID=petalinux
NAME="PetaLinux"
VERSION="2023.2+release-S10121051 (langdale)"
VERSION_ID=2023.2-release-s10121051
PRETTY_NAME="PetaLinux 2023.2+release-S10121051 (langdale)"
DISTRO_CODENAME="langdale"
root@talisesom:~#
root@talisesom:~# iio_attr -c
IIO context has 14 devices:
        hwmon0, ff0e0000ethernetffffffff00: found 1 channels
        hwmon1, ff0e0000ethernetffffffff01: found 1 channels
        hwmon2, adm1266: found 17 channels
        hwmon3, axi_fan_control: found 3 channels
        iio:device0, xilinx-ams: found 30 channels
        iio:device1, hmc7044-car: found 8 channels
        iio:device2, hmc7044-ext: found 4 channels
        iio:device3, hmc7044: found 10 channels
        iio:device4, adrv9009-phy: found 25 channels
        iio:device5, adrv9009-phy-b: found 25 channels
        iio:device6, axi-adrv9009-rx-hpc: found 8 channels
        iio:device7, axi-adrv9009-rx-obs-hpc: found 4 channels
        iio:device8, axi-adrv9009-tx-hpc: found 24 channels
        iio_sysfs_trigger: found 0 channels

- Nuno Sá