element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Avnet Boards Forums
  • Products
  • Dev Tools
  • Avnet Boards Community
  • Avnet Boards Forums
  • More
  • Cancel
Avnet Boards Forums
ZUBoard ZUBoard PYNQ with SSD/M.2 - FOR YOU
  • Forum
  • Documents
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Avnet Boards Forums to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 328 subscribers
  • Views 96 views
  • Users 0 members are here
  • ssd
  • ZU Board 1CG
  • FPGA bit file
  • avnet
  • petalinux
  • pynq
  • m.2
  • ZUBoard
  • boot
  • SD card
  • zu1cgboard
  • ZU1CG
Related

ZUBoard PYNQ with SSD/M.2 - FOR YOU

tjaekel
tjaekel 5 days ago

ZUBoard running PYNQ (Python and PL bit files) with a AVNET SSD/M.2 - works.
No need to setup a build environment, no need to check out source code repositories like PYNQ, Petalinux BSP, in order to modify and build it...

I have placed all needed files in order to "patch" the original ZUBoard PYNQ image 3.0.1 to make the SSD/M.2 working,
plus the instruction steps to modify (see below):

patch_files.zip

Steps to do:

  1. Have a regular PYNQ image on SD card:
    - boot this regular image
    - you should be able to use network in order to copy the needed files to the
      PYNQ working (home) directory and to work from there then in an UART terminal
    - for instance: have all files from the ZIP extracted in a folder patch_files on $HOME directory
      (copy to ZUBoard PYNQ system running via network device)
  2. check if the boot partition of the SD card is mounted (often visible as /boot):
            lsblk
    if mmcblk0p1 is not mounted - mount it, e.g. as boot

    - sudo cp the files:
         BOOT.BIN
      image.ub
      boot.scr
      into this boot partition (on mmcblk0p1)
  3. take the tar file modules_pl and extract it into folder:
         /lib/modules
    - you should have a folder with the name 5.15.36-xilinx-v2022.2 now
    - the folder 5.15.19-xilinx-v2022.1 : you could delete later (when all works fine), rename it
      for now to make sure it is not used anymore
    - extract modules_pl via command:
          sudo tar -xvf modules_pl -C /lib/modules
    - check if you see now a folder /lib/modules/5.15.36-xilinx-v2022.2
  4. create an entry in sudoers in order to avoid to provide a password if you do 'sudo':
    edit the file /etc/sudoers and add this line:
         xilinx ALL=(ALL:ALL) NOPASSWD: ALL
  5. copy the file create_dri.sh into folder:
         /etc/profile.d
  6. do the command:
         sync && sync
  7. You can reboot:
    - stop the U-Boot (any key hit) and change the bootargs:
         setenv bootargs "console=ttyPS0,115200 earlycon clk_ignore_unused uio_pdrv_genirq.of_id=generic-uio root=/dev/mmcblk0p2 rw rootwait cma=512M"
      saveenv
      boot

    You should see now the SSD via
         lsblk
    as nvme0n1 !
    if not:
    - check if you see it as /dev/nvme0 :
       potentially, you might need to create a partition on SSD and to format it (use just ext4 format)

    As a cross check if all works:
    - check if the I2C interrupt is now set to 126:
             cat /proc/interrupts
    a0030000.i2c should use now 126 (not 121 anymore)!
    - check also if a folder
             /dev/dri/by-path
    was created.
    - check also if sudo does not ask anymore for a password, e.g.:
             sudo ls /dev/dri/by-path

    Now your system should be good to continue with the Python part.

  8. If you want to use a BITFILE in the Python scripts (as PL Overlay):
    sudo cp this BITFILE into folder:
         /lib/firmware
    remark: in the Python script we will load this via a shell command, but using ol.Overlay(..., download=False),
    and before you might need to load the device tree overlay dt.dtbo as well - if you want to use INTerrupts
    - keep the dt.dtbo together with your BITFILE in /home/xilinx/pynq/overlays/BITFILE_folder
  9. Your Python script should look like this:

    from pynq import Overlay, Interrupt, devicetree
    from cffi import FFI
    import os

    #load the FPGA file: works only manually with SSD module support:
    os.system("echo ZUBOARD_SPI.bit > /sys/class/fpga_manager/fpga0/firmware")

    #load the device tree to add 'fabric', needed if we want to use INTerrupts
    dt = devicetree.DeviceTreeSegment("/home/xilinx/pynq/overlays/BITFILE_folder/dt.dtbo")
    dt.insert()
    if dt.is_dtbo_applied():
        print("APPLIED")
    else:
        print("NOT applied")

    #create the Overlay but without to load!
    ol = Overlay("BITFILE.xsa", download=False)

  10. Now your BITFILE should be loaded and Python should be able to use all its features,
    including having INT signals and axi_intc in your design, etc.
  11. as a cross check after your BITFILE was loaded and works in Python... - check if you can use SSD:
         mkdir ssd
      sudo mount /dev/nvme0n1 ~/ssd
      ls ssd
    This should work (if SSD is partitioned and formatted). You should see the SSD working even you have
    loaded your BITFILE.
    (not sure?: if not: maybe we have to enable the PCIe in the user block diagram on the PS block, but I have not
    seen an issue so far with my own simple bit files)

REMARK:
There is already a bit file loaded during boot (obviously needed for the PCIe/SSD). It has also blocks
like I2C or GPIO in it (like a system.bit file). On one of the I2C blocks (I guess the second) we have changed the INT vector number!
(we must do so in order to have INT working in our bitfile overlay)
So, one of the I2Cs in system.bit file cannot use anymore INT! (I guess it is intended for reading the I2C DNA chip on an external module).

The files:
    dt.dtsi
  boot.txt
  boot2.txt
are just source files to create the binary file versions needed (via dtc and mkimage, on Linux host).
The files
       boot2.txt and boot2.cmd (binary)
are not anymore used (U-BOOT is doing the device tree modification which is now in file boot.scr).

  1. Options:
    You have the option, after you have partitioned and formatted the SSD module (as ext4), to "copy" the entire Linux rootfs file system,
    the content of the SD card partition 2, visible as /dev/mmcblk0p2, to the SSD module:
    - SSD cannot have a boot partition, so you create just one primary ext4 partition for the Linux files system
       (we could not boot anyway from SSD, so no boot partition needed)
    - best is not to use cp - instead use tar, at best dd, with keeping symbolic links correct in tar archive or "copy" directly as it is
    - ATTENTION:
       you cannot tar or dd the entire active root directory, starting from /, when you want to store also the tar file on the same device in use
       (a recursive tar!)
       ==> use an USB memory stick as temporary storage:
    - format the USB memory stick as ext4 (for large file size and Linux file system)
    - tar the entire rootfs / to a tar file on USB stick
    - now you can use tar to unpack the USB stick tar file into the SSD partition
    - BTW: instead of tar, better to use:
           dd if=... of=... ...
    to do it.
    - after the SSD has now the same rootfs - check if you see the / and all files on SSD device, nvme0n1, after you have mounted the SSD
       you have to boot but stop the U-Boot (by hitting keys right at the beginning of the boot process, watch the UART terminal)
    - now you have to set the bootargs for the U-Boot to use the SSD for the rootfs:
           setenv bootargs "console=ttyPS0,115200 earlycon clk_ignore_unused uio_pdrv_genirq.of_id=generic-uio root=/dev/nvme0n1 rw rootwait cma=512M"
       saveenv
       boot
    - now, it should boot from SD card but it uses the main Linux filesystem rootfs on SSD - much faster!
      The SD card is still needed to boot (partition 1 with BOOT files) but their second partition mmcblk0p2 is now free as a regular device.

REMARK:
For me, only one specific SSD/M.2 module works on ZUBOARD:
- try to find the KingSpec 256G module with B+M key
- it must have a B (+M) key, as PCIe Gen3x2 (2-lanes, not 4! and not just an M key!)

The correct way is actually:

  • update the Petalinux BSP in PYNQ
  • add the PCIe and NVME to it
  • build a new PYNQ image and
  • provide a newer ZUBoard PYNQ image - thank you
  • Sign in to reply
  • Cancel
  • tjaekel
    0 tjaekel 5 days ago

    patch your ZUBoard PYNQ image with newer Petalinux boot files and get SSD, M.2 working...

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Reject Answer
    • Cancel
  • tjaekel
    0 tjaekel 5 days ago

    For all the people which are curious what we do here via this "patching" - the details.

    1. Original PYNQ image for the ZUBoard:
      unfortunately, it does NOT support eMMC neither SSD/M.2!
    2. But, there is a TEST image, as a Petalinux image, which will enable and see the
      eMMC and SSD/M.2:
      But it is NOT a PYNQ system! (the PYNQ, Python layer is missing)
      And:
      This TEST image does NOT have the FPGA_Manager enabled!
      (so, we cannot load a BITFILE on the fly)
      This is the biggest problem at the end.
    3. What do we do via this "patching"?:
      - we take the Petalinux TEST BOOT.BIN and image.ub files (which is the kernel loaded to RAM)
      So, the modified PYNQ image should boot and see the SSD/M.2 (or eMMC: for eMMC - there is an
      easier way to enable eMMC on PYNQ, via the PYNQ build with a newer BSP version and adding a simple
      device tree node)
      Enabling PCIe, NVME seems to be much more complex to add to PYNQ build (I tried - no success).
    4. The problems come as:
      - the Petalinux TEST image boot files are newer (2022_2, not 2022_1) and they look for
        some dynamic drivers, modules, e.g. via modprobe.
        Some modules, drivers are marked with an "m", to load later, dynamically (manually).
      - but they do not find the correct module or complain about a magic number mismatch because our
        /lib/modules directory has not the newer module directory available
      Therefore we extract the newer TEST Petalinux folder into our older PYNQ folder for the modules.
    5. The next problem is:
      The TEST Petalinux image loads an FPGA bit file (e.g. system.bit).
      A bit obvious because the PCIe (needed for SSD/M.2, as nvme) needs the GT lanes enabled
      plus the firmware for it. So, the PS system must be enabled for PCIe and GT lanes.
      So, a bit file seems to be loaded (sitting in image.ub) but it creates IP blocks such as I2C and GPIO.
      They use INT signals! So, one I2C device "occupies" the vector 121.
      But this one is needed for our own overlay, if we have INT signals!
      So, during boot (via boot.scr) we "patch" the device tree and move this INT vector away, so that
      vector 121 becomes free (but this I2C block will not be working anymore, but we do not use it anyway).
    6. The next problem is:
      In order to use INTerrupts: we need this vector 121, which is handled by the node "fabric".
      But "fabric" is NOT there in the TEST Petalinux image device tree!
      So, we have to load a device tree overlay which adds the "fabric" node, handling this vector 121.
    7. The next problem is:
      The TEST Petalinux image is NOT PYNQ. It does NOT have FPGA_Manager enabled.
      So, the directory /dev/dri/by-path is not there and even we would create it: it does NOT work to load
      a bit file in Python the regular way.
      But we have this option to place our bit file into /lib/firmware and do this "echo BITFILE > /sys/class/...".
      So, this loads our bit file.
    8. The next problem is:
      We cannot load anymore the bit file via Overlay in Python. We have to use this "download=False".
      But for INTerrupts we need also the "fabric" node in device tree:
      Therefore we load a device tree overlay as dt.dtbo in order to add this.
    9. We need also this UIO device (which should come via "fabric" added), but it needs this definition in bootargs.
    10. Unfortunately, if we use "download=False" on Overlay() - the Python is still looking for the existence 
      of the /dev/dri/by-path directory (even Python should not use it: it seems to be a bug in the Python scripts?).
      So, during startup of the system we create this directory just to make Python happy.
      There is this shell script create_dir.sh doing it for us (if this directory would not be there).
    11. As a drawback, the Python scripts looks now a bit different in terms of how to load a bit file.
      And: unfortunately, we have to copy our bit file into folder /lib/firmware and do this "echo BITFILE > /sys/class..."
      (but luckily we can do this in Python itself via os).
    12. Some commands need root privileges: and if we would use sudo in a shell script - it would ask us for the password.
      Therefore we add something to the sudoers file so that we do not need to enter the password anymore.

    So, the main problem is actually:

    • the ZUBoard PYNQ image was NOT build with a (newer) BSP supporting:
      - eMMC
      - SSD/M.2
      - and the newer Petalinux BSP (for boot) does NOT have the FPGA Manager enabled

    Why the directory /dev/dri/by-path is not there?
    Potentially, another device tree node missing, e.g. the zocl or the drivers for it are not there...?

    So, even patching the PYNQ system with some Petalinux components (mainly the boot files) is not really complete:

    • the FPGA_Manager is still NOT there
      (and NOT POSSIBLE to load a bit file via Python and Overlay - very disappointing)
    • the TEST Petalinux boot occupies the INT vector 121 (and we have to move it away)
    • the UIO devices is not really there and the "fabric" is missing (so we have to add it via device tree overlay)

    The best way is actually:
    add all this stuff to the BSP (Petalinux) for/in the PYNQ build repository, add the eMMC nodes in device tree,
    enable and add the PCIe, NVME support (potentially also needing Firmware and device tree nodes, maybe also a system.bit file) ...
    build it and release it to us as a
        new PYNQ image
    supporting eMMC as well as SSD/M.2 (the regular way).

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube