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.

I'm not familiar with the Petalux flow. I'm waiting for a comment from someone who is.
I don't see any reason why this would be a HDL issue. More of an bootloader config issue.
My recommendation is to check for similar issues/thread on Xilinx forums.

Andrei

We think it is a HDL issue because the card is showing up as hardware write protected even though the hardware clearly says it isn't. The same hardware and SD card works fine when we put a prebuilt Kuiper Linux image on it. So, electrically the card is not protected but the software thinks it is. By HDL, I mean what is in the .xsa file that comes out of the build-- which is both FPGA bitstream and device-tree. Those two components are the suspects-- might be only one of them but because they come together as a set in the .xsa, that is what is the raw input to our PetaLinux build. When we do the same PetaLinux build for ZCU102, the system works, using the .xsa we build in Vivado. When we use the template HDL for ZU11EG, build in Vivado and provide that .xsa to the PetaLinux build, we end up with an SD card that is R/O on the ZU11EG

We think it is a HDL issue because the card is showing up as hardware write protected even though the hardware clearly says it isn't. The same hardware and SD card works fine when we put a prebuilt Kuiper Linux image on it. So, electrically the card is not protected but the software thinks it is. By HDL, I mean what is in the .xsa file that comes out of the build-- which is both FPGA bitstream and device-tree. Those two components are the suspects-- might be only one of them but because they come together as a set in the .xsa, that is what is the raw input to our PetaLinux build. When we do the same PetaLinux build for ZCU102, the system works, using the .xsa we build in Vivado. When we use the template HDL for ZU11EG, build in Vivado and provide that .xsa to the PetaLinux build, we end up with an SD card that is R/O on the ZU11EG

Hi NaN952 ,

In this case the ADRV9009-based SOM is a custom board, have you added all the corresponding descriptions (dts/dtsi) that are present on the GitHub repository (for that board) in corresponding system-user.dtsi of the petalinux project (project-spec/meta-user/recipes-bsp/device-tree/files/)(including the elements that will be used in the PL and has a connection to memory through AXI's ports of the ZynqMPSoC in this case). Thanks.

Best regards,

Alin

Hi-- I am working with NaN952 on this problem and we have followed the recipe here, https://github.com/analogdevicesinc/meta-adi/tree/main/meta-adi-xilinx, which is ADI's meta-layer for the various boards they support, including ZU11EG.  Therefore, we believed that the HDL and the device tree source were being properly integrated into the PetaLinux build.    For this effort, we are not changing the HDL at all, and simply want to build the reference design version of PetaLinux to run on this board as it comes out of the box.   So far, we are unable to do that, with the result always generating an image that finds the SD card read-only.   We have confirmed that the hardware is NOT read-only because as was mentioned, we can put the Kuiper Linux from here https://www.analog.com/en/resources/evaluation-hardware-and-software/software/kuiper-linux.html on the same SD card and it will boot and run read-write without issue.   So, we believe our hardware is in a correct configuration.

Do people believe that more work is required to modify the .dts/.dtsi files that are a part of the ADI meta-layer before it will build a successful, working image?  If so, where do we find that correct .dts and .dtsi files if they are not in the meta-layer as linked to above?

Thank you,

Chris

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á