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,

By default, petalinux will generate a simple initrd image. Likely that's the reason why you have an RO filesystem. You can run 'petalinux-config' and select the filesystem type to ext4 (check the README in meta-adi), then it will use whatever you have formatted in your sdcard (but you should likely flash the ext4 filesystem generated by the build int your sdcard).

Have you done the above and still have RO?

- Nuno Sá

yes, we have changed the filesystem to be ext4 and it is still RO

Alright... I have some doubts that has anything to do with meta-adi. May very well be some petalinux configuration... But I'll have to test this on my end. I'll try to get some time for it next week.

- Nuno Sá

Thank you! We very much appreciate another data point.  We believe we know how to "drive" the PetaLinux build system since we can successfully generate a working build for ZCU102.   But following the recipe linked above and using the meta-adi layer, we are still very stuck for the ZU11EG.

I should also note that booting the image we build over the network and running from RAM, still results in the SD card being treated as R/O.  So, basically anything we build with PetaLinux cannot write to the SD card.   Running with the Kuiper Linux image, as I noted earlier, does work just fine with R/W access to the SD.

We are using SD card for now but ultimately will move to eMMC which we are putting on our carrier board on which we will mount the ZU11EG.

So, we would very much appreciate another view point and if you are successful, we can hopefully find what we are doing wrong.

Chris

Hi,

So I could not really reproduce this issue... I moved by image to ext4, flashed it on the sdcard and could boot and write into my home directory. 

zcu102adrv9002:~$ mount
/dev/mmcblk0p2 on / type ext4 (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1873244k,nr_inodes=468311,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=666)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=802280k,nr_inodes=819200,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,size=4096k,nr_inodes=1024,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/debug type cgroup (rw,nosuid,nodev,noexec,relatime,debug)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_prio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=2005696k,nr_inodes=1048576)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
tmpfs on /var/volatile type tmpfs (rw,relatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=401136k,nr_inodes=100284,mode=700,uid=1000,gid=1000)
zcu102adrv9002:~$

touch foo
zcu102adrv9002:~$ ls
foo
zcu102adrv9002:~$
zcu102adrv9002:~$ 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"

Note the mount options for rootfs... I did this test on a different project (adrv9002 + zcu102) but the only difference with the zu11eg project we support is the devicetree. And I'm fairly sure it does nothing related with the filesystem mount options. Could you paste the output of your mount command?

Something very odd is going on...

- Nuno Sá

Nuno,

Thank you so much for running the experiment.  We also have new information to report with positive progress.  It appears we had a typo in the path to the meta-adi layer that was added into the petalinux-config step.  This of course silently fails, with no complaint that it cannot find the layer and instead just does the whole build without it.   Clearly that does not work.    So, this has been found and fixed and now we are also able to boot with a r/w root filesystem.  That's progress.    However, now we have a new problem.   The system does boot all the way up and we see a signon banner and prompt for login (with automatic login as root) but seconds later, a couple errors relating to zynqmp-display appear and then the machine immediately attempts to reboot with a power down and then hangs.

eg,

PetaLinux 2023.2+release-S10121051 zu11eg-petalinux ttyPS0

zu11eg-petalinux login: root (automatic login)

[ 31.685899] audit: type=1006 audit(1667916029.239:2): pid=575 uid=0 old-auid=4294967295 auid=0 tty=(none) old-ses=4294967295 ses=1 res=1
[ 31.698223] audit: type=1300 audit(1667916029.239:2): arch=c00000b7 syscall=64 success=yes exit=1 a0=8 a1=7fc8ca7560 a2=1 a3=1 items=0 ppid=1 pid=575 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="(systemd)" exe="/lib/systemd/systemd" key=(null)
[ 31.723385] audit: type=1327 audit(1667916029.239:2): proctitle="(systemd)"
[ 32.382387] zynqmp-display fd4a0000.display: Runtime PM usage count underflow!
[ 32.389636] unregister bridge display which is owned by other component
[ 32.397566] unregister bridge display which is owned by other component
[ 32.405779] reboot: Power down

Any ideas on what causes that?    We do not have any display connected to this board-- our intention is a headless system embedded in another device and so we desire to only communicate with it via console serial and ethernet.  We do not want any GUI running and so display support is not required--  trying to determine how to turn that off.

Experiments in progress to try to zero in on this now.

Chris

Nuno,

Can you confirm that the instructions on this web page should be valid for building for ZU11EG?

https://github.com/analogdevicesinc/meta-adi/tree/main/meta-adi-xilinx

We are at a point now where a completely fresh build, making sure not to include our prior typo, still does not run on the ZU11EG.  We followed those instructions to the letter, using the HDL here,

https://github.com/analogdevicesinc/hdl/tree/main/projects/adrv9009zu11eg/adrv2crr_fmc

and the device-tree from here,

https://github.com/analogdevicesinc/linux/blob/main/arch/arm64/boot/dts/xilinx/zynqmp-adrv9009-zu11eg-revb-adrv2crr-fmc-revb-jesd204-fsm.dts

as they are side by side in the chart titled "Supported Projects".

We believe we have a ZU11EG rev C but there appears to be no mention of rev C on any of these pages.  Is that a potential problem?

In any case, with this fresh build, the machine begins to run the kernel but we get many errors about no spi_device_id, for many different adi,xxxxx devices.  eg,

[ 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

There are hundreds of these sprinkled throughout the boot dialog.

Finally the boot just hangs without the kernel coming up completely.

Chris

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

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

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