DESK-XZ7-L/pdf
History[edit | edit source]
| DESK-XZ7-L History | |||
|---|---|---|---|
| Version | Issue Date | Notes | Refers to |
| 1.0.0-rc1 | Q1 2023 | DESK-XZ7-L-1.0.0 rc1 release | BORA SOM |
| Jan 2024 | DESK-XZ7-L-1.0.1 release | BORA SOM | |
| BORA Xpress SOM | |||
| BORA Lite SOM | |||
| Jun 2024 | DESK-XZ7-L-1.1.0 release | BORA SOM | |
| BORA Xpress SOM | |||
| BORA Lite SOM | |||
| 2.0.0 | Jun 2026 | DESK-XZ7-L-2.0.0 release |  BORA SOM
|
 BORA Xpress SOM
| |||
 BORA Lite SOM
| |||
General Information[edit | edit source]
Release Notes[edit | edit source]
DAVE Embedded Systems adds to the latest Vivado/Petalinux BSP from Xilinx the customization required to support the SOC platform. For this reason most of the documentation provided by Xilinx remains valid for the DESK development kit.
However, some customization is required, in particular at bootloader and linux kernel levels.
The following table reports the DESK releases information.
| DESK version | |
|---|---|
| Release number | 2.0.0 |
| Release type | Major |
| Status | Released |
| Release date | Jun 2025 |
| Release notes | Ver 2.0.0 |
| Product support | BORA / BORA Xpress / BORA Lite |
| Drivers |
SPI NOR Flash (boot) SD |
| Vivado version | 2024.2 |
| Petalinux version | 2024.2 |
| U-Boot version | U-boot Version v2024.01 |
| Linux version | Linux Kernel rebase version 6.6.40 |
| Build system | Yocto Scarthgap (5.0.10) |
(*): ask Sales department for a dedicated Application Note
DESK 2.0.0[edit | edit source]
Release notes:
- Major change to Xilinx BSP 2024.2
Known Limitations[edit | edit source]
The following table reports the known limitations of this DESK release:
| Issue | Description |
|---|---|
| NAND | Not supported yet |
Downloadable binary images[edit | edit source]
All binary images for DESK-XZ7-L are hosted on DAVE Embedded System mirror server. There you can find a sub directory for each version of this development kit.
A summary of images with a brief description can be found into the table below:
| Image | DESK-XZ-L version 2.0.0 | |||
|---|---|---|---|---|
| Platform | BORA Evaluation Kit | BORA Xpress Evaluation Kit | BORA Lite Evaluation Kit | |
| Boot storage device | SD / NOR | SD / NOR | SD / NOR | |
| bootscript | boot.scr | boot.scr | boot.scr | |
| boot.bin | BOOT.BIN | BOOT.BIN | BOOT.BIN | |
| Fit image | image.ub | image.ub | image.ub | |
| SD card image | petalinux-image-minimal.wic.bz2 | petalinux-image-minimal.wic.bz2 | petalinux-image-minimal.wic.bz2 | |
DESK 1.1.0[edit | edit source]
Release notes:
- fix bug for use all NAND size
- enable ETH1 in Linux for Bora and Borax platforms
Known Limitations[edit | edit source]
The following table reports the known limitations of this DESK release:
| Issue | Description |
|---|---|
| microSD hotplug | microSD hotplug functionality not work correctly |
Downloadable binary images[edit | edit source]
All binary images for DESK-XZ7-L are hosted on DAVE Embedded System mirror server. There you can find a sub directory for each version of this development kit.
A summary of images with a brief description can be found into the table below:
| Image | DESK-XZ-L version 1.0.1 | ||||
|---|---|---|---|---|---|
| Platform | BORA Evaluation Kit | BORA Xpress Evaluation Kit | BORA Lite Evaluation Kit | BORA Lite EVK with NAND support | BORA Lite Evaluation Kit |
| Boot storage device | SD / NOR | SD / NOR | SD / NOR | SD (NAND storage support) | NAND |
| bootscript | boot.scr | boot.scr | boot.scr | boot.scr | - |
| boot.bin | BOOT.BIN | BOOT.BIN | BOOT.BIN | BOOT.BIN | BOOT.BIN |
| Fit image | image.ub | image.ub | image.ub | image.ub | - |
| SD card image | dave-image-devel.wic.bz2 | dave-image-devel.wic.bz2 | dave-image-devel.wic.bz2 | dave-image-devel.wic.bz2 | dave-image-devel.tar.gz |
DESK 1.0.1[edit | edit source]
Release notes:
- Major change to Xilinx BSP 2021.2
Known Limitations[edit | edit source]
The following table reports the known limitations of this DESK release:
| Issue | Description |
|---|---|
| NAND | Zynq7000 NAND controller can access up to 512MB |
Downloadable binary images[edit | edit source]
All binary images for DESK-XZ7-L are hosted on DAVE Embedded System mirror server. There you can find a sub directory for each version of this development kit.
A summary of images with a brief description can be found into the table below:
| Image | DESK-XZ-L version 1.0.1 | ||||
|---|---|---|---|---|---|
| Platform | BORA Evaluation Kit | BORA Xpress Evaluation Kit | BORA Lite Evaluation Kit | BORA Lite EVK with NAND support | BORA Lite Evaluation Kit |
| Boot storage device | SD / NOR | SD / NOR | SD / NOR | SD (NAND storage support) | NAND |
| bootscript | boot.scr | boot.scr | boot.scr | boot.scr | - |
| boot.bin | BOOT.BIN | BOOT.BIN | BOOT.BIN | BOOT.BIN | BOOT.BIN |
| Fit image | image.ub | image.ub | image.ub | image.ub | - |
| SD card image | dave-image-devel.wic.bz2 | dave-image-devel.wic.bz2 | dave-image-devel.wic.bz2 | dave-image-devel.wic.bz2 | dave-image-devel.tar.gz |
Release types[edit | edit source]
DESK release type can be:
- Major, when substantial changes are applied to the BSP (eg: major kernel version upgrades) or to the development kit (eg: new features, build system updates, ..). This usually means that a new DVDK is created for the DESK release
- Maintenance, when minor updates and bug fixes are introduced. This usually means that the DVDK remains the same as provided with the previous major version, and only an update of the source tree repositories (and the tftp binaries) is required
As an example, DESK 1.1.0 is a maintenance release, so it provides the DVDK released with the 1.0.0 major release; customers can easily upgrade to the 1.1.0 release by updating the software components as described in Synchronizing git repositories.
Supported platforms[edit | edit source]
The following table reports the supported platforms in this DESK release:
| Platform | Description |
|---|---|
| BORA Evaluation Kit | Evaluation kit using BORA SOM |
| BORA Xpress Evaluation Kit | Evaluation kit using BORA Xpress SOM |
| BORA Lite Evaluation Kit | Evaluation kit using BORA Lite SOM |
Build host[edit | edit source]
Before run petalinux-build, please perform the following command
ssh -T git@git.dave.eu
We assume that:
- Xilinx Vivado 2024.2 is installed into
/opt/Xilinx/2024.2directory - Xilinx Petalinux 2024.2 is installed into
/opt/Xilinx/petalinux/2024.2directory - Ubuntu
20.04is used as build host
For more information about setup of host machine for build Petalinux, Vivado and Vitis, please see DESK-XZ7-L-AN-0001
ConfigID and UniqueID[edit | edit source]
ConfigID[edit | edit source]
ConfigID is a new feature of DAVE Embedded Systems products. Its main purpose is providing an automatic mechanism for the identification of the product model and configuration.
With ConfigID, we aim at:
- completing the hardware configuration information that the software can't normally auto-detect (i.e. RAM chip version,...), implementing a dedicated reliable detect procedure
- when required, overriding the auto-detected hardware configuration information
When implemented, this mechanism allows for:
- initializing in the proper way the hardware platform, based on the specific features and parameters of the product, using a common software base (eg: a typical case is the SDRAM controller parameters, which must be configured by U-Boot depending on the particular memory chip, which can be different for the various SOM models)
- getting the complete hardware configuration (combining ConfigID with the information collectable at runtime) of a product deployed on the field
In simple words, model identification means the capability of reading a numerical code, stored in an available device (SOC's OTP , I2C EEPROM, 1-wire memories, protected NOR flash, etc.)
There are two ConfigIDs:
- SOM ConfigID: which reflects the characteristics of the SOM (stored on the SOM itself)
- Carrier Board (CB) ConfigID: which reflects the characteristics of the carrier board that hosts the SOM (stored on the carrier board itself and read by the SOM at boot time)
UniqueID[edit | edit source]
An additional attribute is UniqueID, which is a read-only code which univocally identifies a single product and is used for traceability.
 It is worth remembering that ConfigID and UniqueID are independent from product serial number. |
Customer's action[edit | edit source]
DAVE Embedded Systems recommends to be up-to-date with Official SOM's BSPs for taking advantages of ConfigID/UniqueId features: this is the only required action.
- ConfigID advantage: to allow U-Boot bootloader to be executed only with the correct configuration (if the U-Boot loaded is not the proper one, it may stop execution avoiding incorrect behaviour)
- UniqueID advantage: to trace univocally each individual SOMs and, in turn, all the on-the-field equipments
ConfigID values[edit | edit source]
ConfigID is a N-bit (typically N>8) signed integer, that can have the following values:
- < 0: error
- -1: not initialized
- = 0: ConfigID legacy
- for prototypes (ConfigID not yet defined) or for products manufactured before the introduction of the ConfigID feature
- > 0: valid ConfigID
- values are reported accordingly with the specific product table
Hardware implementations of the ConfigID[edit | edit source]
The following paragraphs briefly describe the available solutions for storing the ConfigID.
OTP on the SOC[edit | edit source]
Some SOCs provides programmable OTPs (eg. for security, MAC address, boot modes, etc). Usually, some of these are general purpose registers and can be managed by the user.
This is the ideal implementation, because:
- ConfigID is stored in the most important component of the SOM
- the component that hosts the ConfigID is NOT optional
- typically, a very selective lock can be forced. In general, for reliability and/or security reasons, OTP areas used to store ConfigIDs may be locked during the manufacturing process.
OTP 1-wire memory[edit | edit source]
This implementation requires a 1-wire memory chip.
I2C Eeprom[edit | edit source]
This implementation requires connecting an EEPROM to an I2C bus of the SOC. Moreover, routing a write protect pin to the SOM connector is required.
NOR Flash SPI[edit | edit source]
This implementation requires a NOR flash connected to the SPI bus of the SOC.
DAVE Embedded Systems' hardware implementation[edit | edit source]
DAVE's SOCs implement the ConfigID feature depending on hardware Capabilities of the SOCs. The following list shows the priority used for its implementation:
- OTPs
- example: AXEL family processor (i.MX6) implements ConfigID using processor's OTP
- AXEL uses GP1 eFuse register to store ConfigID
- NOR Flash SPI
- example: DIVA family processor (AM335x) implements ConfigID using NOR SPI (if present)
- DIVA and BORA use the first 32bytes OTP block on NOR SPI to store ConfigID (and its CRC32), UniqueID (and its CRC32)
- I2C Eeprom
- example: DIVA family processor (AM335x) or BORA Lite processor (ZYNQ) implements ConfigID using I2C Eeprom when NOR SPI is not present (module boots from NAND or SD)
- DIVA and BORA Lite use the first 32bytes on I2C EPROM to store ConfigID (and its CRC32), UniqueID (and its CRC32)
- 1-wire
- example: latest AXEL Lite, AXEL ULite and BORA/BORA Xpress/BORA Lite Evaluation Kits implement CB ConfigID using the onboard 1-wire device (DS2431)
Software implementation[edit | edit source]
U-Boot[edit | edit source]
u-boot integrates the software routines for reading and displaying the ConfigID: hereunder an example of SOM ConfigID at startup:
U-Boot 2013.04-00010-gcb05b30 (Jun 26 2015 - 12:49:26)-xelk-2.1.0 CPU: Freescale i.MX6Q rev1.5 at 792 MHz CPU: Temperature 47 C, limits (-40 C, 125 C), calibration data: 0xc0 Reset cause: POR Environment: SPI Flash I2C: ready DRAM: 2 GiB Now running in RAM - U-Boot at: 8ff35000 NAND: 512 MiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 SF: Detected S25FL256S with page size 64 KiB, total 32 MiB In: serial Out: serial Err: serial Power: found PFUZE100 (devid=10, revid=21) SOM ConfigID#: 00000003 SOM UniqueID#: df646299:0b0579d4
For accessing these information on Linux procfs, the device tree must be modified (using u-boot fdt command): for example:
DIVA# setenv fdtfixup 'fdt addr ${fdtaddr}; run fdtfixup_configid'
DIVA# setenv fdtfixup_configid 'fdt set / som_configid ${som_configid#}; fdt set / som_uniqueid ${som_uniqueid#}; fdt set / cb_configid ${cb_configid#}; fdt set / cb_uniqueid ${cb_uniqueid#}'
Linux[edit | edit source]
It is possible to read the ConfigID/UniqueID via procfs; for example:
root@axel-lite:~# cat /proc/device-tree/som/configid && echo 00000003 root@axel-lite:~# cat /proc/device-tree/som/uniqueid && echo df646299:0b0579d4 root@axel-lite:~#
Legacy device tree, has a sightly different procfs structure:
root@axel-lite:~# cat /proc/device-tree/som_configid && echo 00000003 root@axel-lite:~# cat /proc/device-tree/som_uniqueid && echo df646299:0b0579d4 root@axel-lite:~#
A real case example of ConfigID benefit[edit | edit source]
The ConfigID benefit is clear when:
- there is a number of products deployed on the field
- the products deployed on the field needs a SW update
The ideal scenario is that all products are equal and there are no differences on the Bill Of Material (BOM):
- All products have the same BOM with a single Config ID
ConfigID A
ConfigID A
ConfigID A
ConfigID A
ConfigID A
ConfigID A
In this case there are no problems to deploy a new SW update on the field: all products have the same HW configuration, then the same SW configuration.
Unfortunately, this is an ideal scenario. The reality is that:
- component obsolescence
- product shortage
- second source strategies
force to have an on-the-field different version of product (with same functionalities but with different HW configuration) which doesn't permit to realize what proposed in the ideal case.
|
The usage of the ConfigID technique, allows the running SW to identify the underlying HW configuration and automatically adapt the BSP (i.e. the driver layer) to properly use the HW subsystems: this, maintaining the overall product features identical to the final User point-of-view. |
- All products are similar BUT there are different Config ID between the 2 product versions
ConfigID A
ConfigID A
ConfigID B
ConfigID B
ConfigID A
ConfigID B
With a scenario, like the one described above, if you would like to update the SW you need to implement a strategy for understanding what platform version is going to be updated. The Config ID is used exactly for this goal.
The ConfigID provides to the software update routine the information on which product version is so the update can be adapted to the exact product version.
In this way, you can distribute one single version of the software update which will automatically adapt itself to the currently running platform.
How to handle After Sales with Config ID[edit | edit source]
One of the mos common questions about Config ID is how to handle the Config ID issue. Below is described with an example how to handle it.
This product is returned from the field with a problem on the display:
After Sales Dept analizes the product and decide to substitute the display. The problem is that the existing display is not available - because of is End Of Life (EOL) - and it is required to move to a different display: in the product a different Config ID will be written because of the 2 displays requires a dedicated SW version and cannot be distinguished automatically during the startup. The final result is to have the similar product:
As indicated, the new display requires a different Config ID (from A to B) so it can be updated with an easy software routine before start the SW update. This Config ID update routine can be implemented in manufacturing facility typically using a dedicated USB pen drive which modify the saved ConfigID to the new one depending on the storage memory in use
ConfigID[edit | edit source]
This article describes how the ConfigID is implemented in the products supported by the DESK-XZ7-L Linux Kit.
Hardware implementation[edit | edit source]
BORA family uses the first 32bytes OTP block on NOR SPI to store ConfigID (and its CRC32), UniqueID (and its CRC32). For BORA Lite module configured for booting from NAND, the ConfigID is stored on internal I2C EPROM: see here for more information.
U-Boot integrates the software routines for reading and displaying the ConfigID. Hereunder an example of SOM ConfigID at startup:
... SOM ConfigID#: 00000002 SOM UniqueID#: fffffefc:fffffefc CB ConfigID#: 00000001 CB UniqueID#: a600000f:24188b2d ...
Generally speaking[edit | edit source]
- SOM ConfigID is used to identify the configuration of the basic features of the SOM
- CB ConfigID is used to identify the peripherals and the I/O interfaces.
Booting from NFS[edit | edit source]
This configuration is very helpful during software development (both for kernel and applications). The kernel image is downloaded via TFTP while the root file system is remotely mounted via NFS from the host. It is assumed that the development host:
- is connected with the target host board through an ethernet LAN
- exports the directory containing the root file system for the target through the NFS server
- runs a TFTP server
- has a proper subnet IP address
DESK-XZ7-L Virtual Machine is properly configured for the TFTP and NFS debug.
In any case, some variables have to be configured on the target and the VM itself has to be configured with respect to the network environment.
Host (Virtual Machine) configuration[edit | edit source]
The DESK-XZ7-L Virtual Machine has the tftp and nfs services already running. Optionally, their configuration has to be changed according to the network configuration to which the target is connected.
Check and properly configure the items describe in VirtualBox Network Configuration
Target configuration[edit | edit source]
The IP address for the server and target should be configured: as an example (for a network subnet 192.168.0.x)
u-boot=> setenv serverip 192.168.10.100 u-boot=> setenv ipaddr 192.168.10.56 u-boot=> setenv gatewayip 192.168.10.254 u-boot=> setenv netmask 255.255.255.0 u-boot=> setenv netdev eth0
serveripis the IP address of the host machine running the tftp/nfs serveripaddris the IP address of the targetgatewayipis the gateway address of the targetnetmaskis the netmask address of the targetnetdevis the name of the ethernet interface of the target
For using the DVDK Virtual Machine, a static IP address configuration has been selected, so the U-Boot variable ip_dyn has to be set to no:
u-boot=> setenv ip_dyn no
Boot via NFS with PXE protocol[edit | edit source]
Booting via pxe protocol is a very simple and efficient way to save a lot of time to update. In this case, the following artifacts will be downloaded from our mirror server or built with Petalinux:
zImage, this file has to be installed in your host device directory for tftp server, configurated forpxe, for example/tftpboot/bora/system.dtb, this file has to be installed in your host device directory for tftp server, configurated forpxe, for example/tftpboot/bora/rootfs.tar.gz, this file has to be decompressed in your host device directory/home/dvdk/nfsroot
For more information about boot and configuration files see DESK-XZ7-L-AN-0003: using PXE protocol for boot
Boot via NFS with Petalinux[edit | edit source]
In the case of NFS Boot, the root file system is mounted through NFS but the bootloader (FSBL, bitstream, U-Boot) and kernel can be downloaded using various methods, for example with JTAG, micro SD or tftp server.
To boot your target via NFS, you need to update your configuration file with the following command:
petalinux-config
Here below there are properties that you have to update:
CONFIG_SUBSYSTEM_ROOTFS_NFSSUBSYSTEM_NFSROOT_DIRCONFIG_SUBSYSTEM_NFSSERVER_IPCONFIG_SUBSYSTEM_TFTPBOOT_DIR
For more information about NFS Boot with Petalinux see Petalinux guide.
Development[edit | edit source]
Synchronizing the repository[edit | edit source]
In DESK-XZ7-L, the following source trees are clones of the correspondent DAVE Embedded Systems git repositories:
| Component | GIT Remote |
|---|---|
| Vivado | git@git.dave.eu:desk-xz-l/vivado.git
|
| Petalinux | git@git.dave.eu:desk-xz-l/petalinux.git
|
| U-Boot | git@git.dave.eu:desk-xz-l/u-boot-xlnx.git
|
There are two main repositories to:
- track and reproduce hardware design with Vivado
- track and reproduce Petalinux/Yocto build
Additional repositories will be used to track other piece of software that requires customization (e.g. U-Boot bootloader, Linux kernel, sample application and so on)
Access to DAVE Embedded Systems' git repositories is granted to the development kit's owners only. Please refer to this page for detailed instructions on how to get access.
Instructions[edit | edit source]
The components listed in the table above can be kept in sync and up to date with DAVE Embedded Systems' repositories.
Once the git account has been enabled, the developer can:
- clone the repository with the
git clone <git_remote_repository> -b desk-xz7-l-2.0.0command. In case of clone aboutPetalinuxuse the--recursiveoption - synchronize a source tree entering the repository directory and launching the
git fetch origincommand
Please note that git fetch doesn't merge the commits on the current branch. To do that, the developer should run the git merge command or replace the fetch-merge process with a single git pull command. Please note that the recommended method is the fetch-merge process. For further information on Git, please refer to the official Git Documentation
|
Vivado installation path, in this documentation, is the |
Creating and building the Vivado project[edit | edit source]
The Vivado repository allows to:
- track hardware/fpga related sources/configuration
- reproduce hardware design output (FPGA bitstream, XSA) using TCL scripts
Development kit TCL scripts supported are the following one:
| Script | Boot |
|---|---|
recreate_prj_bora.tcl
|
uSD and QSPI-NOR |
recreate_prj_bora_ETH1.tcl
|
uSD and QSPI-NOR with ETH1 support |
recreate_prj_borax_BASE.tcl
|
uSD and QSPI-NOR |
recreate_prj_borax_ETH1.tcl
|
uSD and QSPI-NOR with ETH1 support |
recreate_prj_boralite_BASE.tcl
|
uSD and QSPI-NOR |
recreate_prj_boralite_NAND.tcl
|
uSD and NAND |
As an example, to reproduce the build for the Bora platform, here below are the steps:
- clone the repository:
git clone git@git.dave.eu:desk-xz-l/vivado.git -b desk-xz7-l-2.0.0
cd vivado
or clone the Vivado repository when you clone Petalinux repository
git clone --recursive git@git.dave.eu:desk-xz-l/petalinux.git -b desk-xz7-l-2.0.0
cd petalinux/vivado
- (only once as first tools setup) copy Bora hardware definition into Vivado installation path:
cp -r boards/ <vivado directory installation>/Xilinx/2024.2/Vivado/2024.2/data/
- lunch Vivado Design Suite with the following commands and parameters:
source <vivado directory installation>/Xilinx/2024.2/Vivado/2024.2/settings64.sh
vivado -mode tcl -source scripts/recreate_prj_bora_BASE.tcl -notrace -tclargs "gen_bitstream"
- at the end of the bitstream build process, the script automatically exports the Xilinx Support Archive (XSA) hardware design
- the Vivado project
vivado/bora.xpris ready for customization through the Vivado GUI - the bitstream files are
vivado/bora.runs/impl_1/bora_wrapper.bitvivado/bora.runs/impl_1/bora_wrapper.bin
- the hardware design file
vivado/bora.xsais ready for the import into Petalinux
- the Vivado project
CAN0 and UART0 routing example project[edit | edit source]
The following pictures show a simple PL design used to route PS' CAN0 and UART0 signals through EMIO.
|
Petalinux installation path, in this documentation, is the |
Creating and building the Petalinux project[edit | edit source]
Documentation reference[edit | edit source]
- PetaLinux Tools Documentation Reference guide UG1144
Petalinux environment setup[edit | edit source]
To reproduce the Petalinux build:
- clone the repository
git clone --recursive git@git.dave.eu:desk-xz-l/petalinux.git -b desk-xz7-l-2.0.0
cd petalinux
- setup the Petalinux environment
source <petalinux installation path>/Xilinx/petalinux/2024.2/settings.sh
- initialize the configuration file
You can use the proper configuration file from the following table:
| Config file | Boot |
|---|---|
config_bora
|
uSD and QSPI-NOR |
config_bora_ETH1
|
uSD and QSPI-NOR with ETH1 support |
config_borax
|
uSD and QSPI-NOR |
config_borax_ETH1
|
uSD and QSPI-NOR with ETH1 support |
config_boralite
|
uSD and QSPI-NOR |
config_boralite_NAND
|
NAND |
config_boralite_nand_usd
|
uSD with NAND support |
In order to select a configuration file use the following command:
cp project-spec/configs/<configuration file> project-spec/configs/config
Update the hardware description[edit | edit source]
The hardware description comes from the Vivado project. The Vivado project is already cloned into the Petalinux project.
To build the Hardware description file, please look at this page: Creating and building the Vivado project
You can use the following command to update the hardware description:
petalinux-config --get-hw-description vivado/vivado/<path to .xsa>
When applying the hardware description, the standard menuconfig interface will pop up: just save the current configuration to proceed. If the menuconfig interface will not bring up, send the following command:
petalinux-config --get-hw-description vivado/vivado/<path to .xsa> --silentconfig
Run the Petalinux build[edit | edit source]
To build petalinux-image-minimal use the following command:
petalinux-build
For building only the Linux kernel, use the following command
petalinux-build -c kernel
For building only U-Boot use the following command:
petalinux-build -c u-boot
For generating the BOOT.BIN artifact, run the following command:
petalinux-package boot --u-boot --fsbl --fpga --force
Note: BOOT.BIN includes the files below. In this case, the system.bit bitstream was generated with Vivado and imported in Petalinux with xsa file.
fsbl.elfsystem.bitu-boot.elf
In case of boot from NAND for the BORA Lite SOM, be careful on using the following command:
petalinux-package boot --u-boot --boot-script --offset 0xFC0000 --kernel --offset 0x1080000 --fpga --force
Note: BOOT.BIN includes the files below. In this case, the bitstream system.bit was generated with Vivado and imported in Petalinux with xsa file.
fsbl.elfsystem.bitu-boot.elfimage.ub
The offset 0x1080000 for kernel is a default setting for NAND device installed on the SoM.
SD card image[edit | edit source]
To generate the SD card wic image, execute the following command:
petalinux-package wic --bootfiles "BOOT.BIN boot.scr image.ub"
How to create a bootable microSD card[edit | edit source]
The process is relatively straightforward: it consists of writing the WIC file of interest generated by Petalinux onto the SD card. There are multiple ways to do that.
The most common is to use the well-known BalenaEtcher tool (download BalenaEtcher). The following instruction explains how to use it on a Windows host. The procedure is similar when working with a Linux host.
- Download the desired binary image to flash (
*.wicor*.wic.bz2). In case you have a*.wic.bz2, unzip the file in order to have a*.wicfile- Among the binaries made available in the mirror there are several
*.wic.bz2files for the available releases. In particular, there is thedesk-xz7-l-1.0.1_bora_dave-image-devel.wic.bz2file. This image is the one used to program the microSD card delivered along with the evaluation kit.
- Among the binaries made available in the mirror there are several
- Connect the microSD card to the PC Host
- Open BalenaEtcher tool
- Once the tool is open:
- Select the binary to flash by clicking on "Flash from file"
- Select the microSD to flash by clicking on "Select target"
- Flash the uSD by clicking o "Flash".
Application examples[edit | edit source]
Hello World C[edit | edit source]
This page shows how to create and cross-compile the first C source code application: the classic Hello World!
python3[edit | edit source]
Python3 general purpose language can be used with BORA family with the already installed python3 in the development root file system.
Package management[edit | edit source]
It is possible to install other - already built - packages in the target using dnf package manager
Deployment[edit | edit source]
Standalone boot[edit | edit source]
This document was written and tested with the software/hardware combination described in the history table above. However, it contains general concepts that can be adapted to any DAVE Embedded Systems' Linux platform.
|
The following programming examples are intended for laboratory usage or for preliminary deployment strategy. |
We'll explain how to program and configure a SOM to boot in standalone mode, without the need for a system microSD card, with the following option:
- booting with Quad-SPI NOR
- in this configuration the primary boot images will be fetched from Quad-SPI NOR flash storage, while the root file system will be fetched from microSD
- booting with NAND
- in this configuration the primary boot images and rootfs will be fetched from NAND flash storage
Program the Quad-SPI NOR flash[edit | edit source]
This chapter is compatible with BORA, BORA Xpress and BORA Lite platforms, but below there is log for BORA Xpress SOM.
First of all, create a bootable microSD card as described here. Alternatively you can download binaries from mirror and install it on microSD or into tftpboot directory in your host device.
Then, boot the board with the microSD card and stop the automatic boot process of U-Boot in order to access the console.
U-Boot 2024.01-desk-xz7-l-2.0.0 (Jun 10 2025 - 15:58:48 +0000) CPU: Zynq 7z020 Silicon: v3.1 Model: Bora DRAM: ECC disabled 1 GiB Core: 23 devices, 17 uclasses, devicetree: board Flash: 0 Bytes NAND: 0 MiB MMC: mmc@e0100000: 0 Loading Environment from FAT... OK In: serial@e0001000 Out: serial@e0001000 Err: serial@e0001000 SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB SOM UniqueID not found, using default SOM UniqueID not found, using default SOM ConfigID#: 00000001 SOM UniqueID#: ffffffff:ffffffff CB ConfigID#: 00000001 CB UniqueID#: 3b000043:73db012d SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB Warning: MAC addr not found in SPI NOR at block 8 Net: ZYNQ GEM: e000b000, mdio bus e000b000, phyaddr 7, interface rgmii-id Warning: ethernet@e000b000 (eth0) using random MAC address - 62:bd:95:67:66:9c eth0: ethernet@e000b000 Hit ENTER within 2 seconds to stop autoboot Zynq>
Programming Quad-SPI NOR flash from microSD[edit | edit source]
- Initialize and format Quad-SPI NOR flash memory
Zynq> sf probe SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB Zynq> sf erase 0 0x1000000 SF: 16777216 bytes @ 0x0 Erased: OK
- Install
BOOT.BINon Quad-SPI NOR flash memory
Zynq> fatload mmc 0:1 $kernel_addr_r BOOT.BIN 5221272 bytes read in 296 ms (16.8 MiB/s) Zynq> sf write $kernel_addr_r 0x0 $filesize device 0 offset 0x0, size 0x4fab98 SF: 5221272 bytes @ 0x0 Written: OK
- Install
image.ubon Quad-SPI NOR flash memory
Zynq> mw $kernel_addr_r 0x0 $filesize Zynq> fatload mmc 0:1 $kernel_addr_r image.ub 6250683 bytes read in 358 ms (16.7 MiB/s) Zynq> sf write $kernel_addr_r 0x700000 $filesize device 0 offset 0x700000, size 0x5f60bb SF: 6250683 bytes @ 0x700000 Written: OK
- Install
boot.scron Quad-SPI NOR flash memory
Zynq> mw $kernel_addr_r 0x0 $filesize Zynq> fatload mmc 0:1 $kernel_addr_r boot.scr 3830 bytes read in 14 ms (266.6 KiB/s) Zynq> sf write $kernel_addr_r 0xFC0000 $filesize device 0 offset 0xfc0000, size 0xef6 SF: 3830 bytes @ 0xfc0000 Written: OK
Programming Quad-SPI NOR flash from ethernet[edit | edit source]
- Initialize and format Quad-SPI NOR flash memory
Zynq> sf probe SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB Zynq> sf erase 0 0x1000000 SF: 16777216 bytes @ 0x0 Erased: OK
- Properly define the ethernet configuration parameter:
Zynq> setenv ipaddr 192.168.0.89 Zynq> setenv serverip 192.168.0.99
- download via TFTP the
BOOT.BINbinary image and writeBOOT.BINon Quad-SPI NOR flash memory
Zynq> tftpboot $kernel_addr_r desk-xz7-l/bora_BOOT.BIN
Using ethernet@e000b000 device
TFTP from server 192.168.0.99; our IP address is 192.168.0.89
Filename 'desk-xz7-l/bora_BOOT.BIN'.
Load address: 0x2000000
Loading: #################################################################
...
#################################################################
#############################################
5.3 MiB/s
done
Bytes transferred = 5221272 (4fab98 hex)
Zynq> sf write $kernel_addr_r 0x0 $filesize
device 0 offset 0x0, size 0x4fab98
SF: 5221272 bytes @ 0x0 Written: OK
Zynq>
- download via TFTP the
image.ubbinary image and writeimage.ubon Quad-SPI NOR flash memory
Zynq> mw $kernel_addr_r 0x0 $filesize
Zynq> tftpboot $kernel_addr_r desk-xz7-l/bora_image.ub
Using ethernet@e000b000 device
TFTP from server 192.168.0.99; our IP address is 192.168.0.89
Filename 'desk-xz7-l/bora_image.ub'.
Load address: 0x2000000
Loading: #################################################################
...
###################################################
5.3 MiB/s
done
Bytes transferred = 6250683 (5f60bb hex)
Zynq> sf write $kernel_addr_r 0x700000 $filesize
device 0 offset 0x700000, size 0x5f60bb
SF: 6250683 bytes @ 0x700000 Written: OK
Zynq>
- download via TFTP the
boot.scrbinary image and writeboot.scron Quad-SPI NOR flash memory
Zynq> mw $kernel_addr_r 0x0 $filesize
Zynq> tftpboot $kernel_addr_r desk-xz7-l/bora_boot.scr
Using ethernet@e000b000 device
TFTP from server 192.168.0.99; our IP address is 192.168.0.89
Filename 'desk-xz7-l/bora_boot.scr'.
Load address: 0x2000000
Loading: #
623 KiB/s
done
Bytes transferred = 3830 (ef6 hex)
Zynq> sf write $kernel_addr_r 0xFC0000 $filesize
device 0 offset 0xfc0000, size 0xef6
SF: 3830 bytes @ 0xfc0000 Written: OK
Zynq>
Once change boot mode and restarted, the complete boot log can be like this one:
U-Boot 2024.01-desk-xz7-l-2.0.0 (Jun 10 2025 - 15:58:48 +0000)
CPU: Zynq 7z020
Silicon: v3.1
Model: Bora
DRAM: ECC disabled 1 GiB
Core: 23 devices, 17 uclasses, devicetree: board
Flash: 0 Bytes
NAND: 0 MiB
MMC: mmc@e0100000: 0
Loading Environment from SPIFlash... SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
*** Warning - bad CRC, using default environment
In: serial@e0001000
Out: serial@e0001000
Err: serial@e0001000
SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
SOM UniqueID not found, using default
SOM UniqueID not found, using default
SOM ConfigID#: 00000001
SOM UniqueID#: ffffffff:ffffffff
CB ConfigID#: 00000001
CB UniqueID#: 3b000043:73db012d
SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
Warning: MAC addr not found in SPI NOR at block 8
Net:
ZYNQ GEM: e000b000, mdio bus e000b000, phyaddr 7, interface rgmii-id
Warning: ethernet@e000b000 (eth0) using random MAC address - 7a:53:47:88:07:8e
eth0: ethernet@e000b000
Hit ENTER within 2 seconds to stop autoboot
SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
device 0 offset 0xfc0000, size 0x40000
SF: 262144 bytes @ 0xfc0000 Read: OK
QSPI: Trying to boot script at 3000000
## Executing script at 03000000
Trying to load boot images from qspi
SF: Detected s25fl256s1 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
device 0 offset 0x700000, size 0x600000
SF: 6291456 bytes @ 0x700000 Read: OK
## Loading kernel from FIT Image at 10000000 ...
Using 'conf-system-top.dtb' configuration
Verifying Hash Integrity ... OK
Trying 'kernel-1' kernel subimage
Description: Linux kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x100000ec
Data Size: 6228192 Bytes = 5.9 MiB
Architecture: ARM
OS: Linux
Load Address: 0x00200000
Entry Point: 0x00200000
Hash algo: sha256
Hash value: 7449b0f03f22fedb3e928e4fa02b3c8a74d6714780d21cf72b84ba3c052291a7
Verifying Hash Integrity ... sha256+ OK
## Loading fdt from FIT Image at 10000000 ...
Using 'conf-system-top.dtb' configuration
Verifying Hash Integrity ... OK
Trying 'fdt-system-top.dtb' fdt subimage
Description: Flattened Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x105f0ad8
Data Size: 20567 Bytes = 20.1 KiB
Architecture: ARM
Hash algo: sha256
Hash value: 9fd8a85d99438d1229ea21f6762f14d7557e27d18b3f6349f55c06ffe08e88cb
Verifying Hash Integrity ... sha256+ OK
Booting using the fdt blob at 0x105f0ad8
Working FDT set to 105f0ad8
Loading Kernel Image
Loading Device Tree to 2fff7000, end 2ffff056 ... OK
Working FDT set to 2fff7000
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 6.6.40-xilinx-g2b7f6f70a62a (oe-user@oe-host) (arm-xilinx-linux-gnueabi-gcc (GCC) 13.3.0, GNU ld (GNU Binutils) 2.42.0.20240716) #1 SMP PREEMPT Tue Oct 29 11:52:30 UTC 2024
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Bora
[ 0.000000] earlycon: cdns0 at MMIO 0xe0001000 (options '115200n8')
[ 0.000000] printk: bootconsole [cdns0] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 16 MiB at 0x3f000000 on node -1
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000000000000-0x000000002fffffff]
[ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000000000000-0x000000003fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003fffffff]
[ 0.000000] percpu: Embedded 16 pages/cpu s35988 r8192 d21356 u65536
[ 0.000000] Kernel command line: console=ttyPS0,115200 earlycon root=/dev/mmcblk0p2 ro rootwait
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 260608
[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[ 0.000000] Memory: 1008176K/1048576K available (9216K kernel code, 828K rwdata, 2720K rodata, 1024K init, 171K bss, 24016K reserved, 16384K cma-reserved, 245760K highmem)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] ftrace: allocating 37947 entries in 112 pages
[ 0.000000] ftrace: allocated 112 pages with 3 groups
[ 0.000000] trace event string verifier disabled
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.000000] Rude variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] efuse mapped to (ptrval)
[ 0.000000] slcr mapped to (ptrval)
[ 0.000000] GIC physical location is 0xf8f01000
[ 0.000000] L2C: platform modifies aux control register: 0x72360000 -> 0x72760000
[ 0.000000] L2C: DT/platform modifies aux control register: 0x72360000 -> 0x72760000
[ 0.000000] L2C-310 erratum 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 1 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x76760001
[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 0.000000] zynq_clock_init: clkc starts at (ptrval)
[ 0.000000] Zynq clock init
[ 0.000001] sched_clock: 64 bits at 167MHz, resolution 6ns, wraps every 4398046511103ns
[ 0.005666] clocksource: arm_global_timer: mask: 0xffffffffffffffff max_cycles: 0x26703d7dd8, max_idle_ns: 440795208065 ns
[ 0.016730] Switching to timer-based delay loop, resolution 6ns
[ 0.023141] Console: colour dummy device 80x30
[ 0.027092] Calibrating delay loop (skipped), value calculated using timer frequency.. 333.33 BogoMIPS (lpj=1666666)
[ 0.037631] CPU: Testing write buffer coherency: ok
[ 0.042461] CPU0: Spectre v2: using BPIALL workaround
[ 0.047523] pid_max: default: 32768 minimum: 301
[ 0.052292] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.059450] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.068213] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.074273] RCU Tasks: Setting shift to 1 and lim to 1 rcu_task_cb_adjust=1.
[ 0.080013] RCU Tasks Rude: Setting shift to 1 and lim to 1 rcu_task_cb_adjust=1.
[ 0.087578] Setting up static identity map for 0x100000 - 0x100060
[ 0.093789] rcu: Hierarchical SRCU implementation.
[ 0.098315] rcu: Max phase no-delay instances is 1000.
[ 0.104816] smp: Bringing up secondary CPUs ...
[ 0.109136] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.109163] CPU1: Spectre v2: using BPIALL workaround
[ 0.118963] smp: Brought up 1 node, 2 CPUs
[ 0.122899] SMP: Total of 2 processors activated (666.66 BogoMIPS).
[ 0.129113] CPU: All CPU(s) started in SVC mode.
[ 0.134577] devtmpfs: initialized
[ 0.143370] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 0.145729] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.155316] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[ 0.163076] pinctrl core: initialized pinctrl subsystem
[ 0.169390] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.175494] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.181676] thermal_sys: Registered thermal governor 'step_wise'
[ 0.181773] cpuidle: using governor ladder
[ 0.190185] cpuidle: using governor menu
[ 0.199124] platform axi: Fixed dependency cycle(s) with /axi/interrupt-controller@f8f01000
[ 0.208114] platform replicator: Fixed dependency cycle(s) with /axi/etb@f8801000
[ 0.210099] amba f8801000.etb: Fixed dependency cycle(s) with /replicator
[ 0.217155] platform replicator: Fixed dependency cycle(s) with /axi/tpiu@f8803000
[ 0.224499] amba f8803000.tpiu: Fixed dependency cycle(s) with /replicator
[ 0.231568] platform replicator: Fixed dependency cycle(s) with /axi/funnel@f8804000
[ 0.239084] amba f8804000.funnel: Fixed dependency cycle(s) with /axi/ptm@f889d000
[ 0.246547] amba f8804000.funnel: Fixed dependency cycle(s) with /axi/ptm@f889c000
[ 0.254111] amba f8804000.funnel: Fixed dependency cycle(s) with /replicator
[ 0.261489] amba f8804000.funnel: Fixed dependency cycle(s) with /axi/ptm@f889c000
[ 0.268841] amba f889c000.ptm: Fixed dependency cycle(s) with /axi/funnel@f8804000
[ 0.276634] amba f8804000.funnel: Fixed dependency cycle(s) with /axi/ptm@f889d000
[ 0.283983] amba f889d000.ptm: Fixed dependency cycle(s) with /axi/funnel@f8804000
[ 0.292342] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
[ 0.299441] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.306568] e0000000.serial: ttyPS1 at MMIO 0xe0000000 (irq = 26, base_baud = 3125000) is a xuartps
[ 0.315733] e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 27, base_baud = 3125000) is a xuartps
[ 0.329047] printk: console [ttyPS0] enabled
[ 0.329047] printk: console [ttyPS0] enabled
[ 0.333360] printk: bootconsole [cdns0] disabled
[ 0.333360] printk: bootconsole [cdns0] disabled
[ 0.350991] SCSI subsystem initialized
[ 0.355159] usbcore: registered new interface driver usbfs
[ 0.360734] usbcore: registered new interface driver hub
[ 0.366106] usbcore: registered new device driver usb
[ 0.371584] mc: Linux media interface: v0.10
[ 0.375941] videodev: Linux video capture interface: v2.00
[ 0.381524] pps_core: LinuxPPS API ver. 1 registered
[ 0.386520] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.395709] PTP clock support registered
[ 0.399716] EDAC MC: Ver: 3.0.0
[ 0.403675] FPGA manager framework
[ 0.407409] Advanced Linux Sound Architecture Driver Initialized.
[ 0.414940] vgaarb: loaded
[ 0.418213] clocksource: Switched to clocksource arm_global_timer
[ 0.439917] NET: Registered PF_INET protocol family
[ 0.445313] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)
[ 0.455262] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.463870] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.471662] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[ 0.479574] TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
[ 0.487068] TCP: Hash tables configured (established 8192 bind 8192)
[ 0.493568] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 0.500269] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 0.507555] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 0.514046] RPC: Registered named UNIX socket transport module.
[ 0.519993] RPC: Registered udp transport module.
[ 0.524699] RPC: Registered tcp transport module.
[ 0.529414] RPC: Registered tcp-with-tls transport module.
[ 0.534820] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.541348] PCI: CLS 0 bytes, default 64
[ 0.545815] armv7-pmu f8891000.pmu: hw perfevents: no interrupt-affinity property, guessing.
[ 0.554614] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
[ 0.564793] workingset: timestamp_bits=30 max_order=18 bucket_order=0
[ 0.572297] jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
[ 0.579870] bounce: pool size: 64 pages
[ 0.583740] io scheduler mq-deadline registered
[ 0.588274] io scheduler kyber registered
[ 0.592372] io scheduler bfq registered
[ 0.597440] zynq-pinctrl 700.pinctrl: zynq pinctrl initialized
[ 0.607970] dma-pl330 f8003000.dma-controller: Loaded driver for PL330 DMAC-241330
[ 0.615601] dma-pl330 f8003000.dma-controller: DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
[ 0.639752] brd: module loaded
[ 0.654629] loop: module loaded
[ 0.660227] spi-nor spi0.0: found s25fl256s1, expected s25fl128s1
[ 0.666605] spi-nor spi0.0: s25fl256s1 (32768 Kbytes)
[ 0.671812] 1 fixed-partitions partitions found on MTD device spi0.0
[ 0.678208] Creating 1 MTD partitions on "spi0.0":
[ 0.683046] 0x000000000000-0x000002000000 : "qspi-boot"
[ 0.694238] CAN device driver interface
[ 0.812941] macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 42 (7a:53:47:88:07:8e)
[ 0.823185] e1000e: Intel(R) PRO/1000 Network Driver
[ 0.828152] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 0.835223] usbcore: registered new interface driver usb-storage
[ 0.842514] ULPI transceiver vendor/product ID 0x0424/0x0006
[ 0.848228] Found SMSC USB331x ULPI transceiver.
[ 0.852881] ULPI integrity check: passed.
[ 0.857944] ci_hdrc ci_hdrc.0: EHCI Host Controller
[ 0.859718] i2c_dev: i2c /dev entries driver
[ 0.862909] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[ 0.867343] cdns-i2c e0004000.i2c: can't get pinctrl, bus recovery not supported
[ 0.883896] hwmon hwmon0: temp1_input not attached to any thermal zone
[ 0.892211] rtc-ds3232 0-0068: registered as rtc0
[ 0.897246] rtc-ds3232 0-0068: setting system clock to 2025-06-12T10:39:54 UTC (1749724794)
[ 0.902808] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[ 0.905933] cdns-i2c e0004000.i2c: 400 kHz mmio e0004000 irq 44
[ 0.911311] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.06
[ 0.925314] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.932567] usb usb1: Product: EHCI Host Controller
[ 0.937486] usb usb1: Manufacturer: Linux 6.6.40-xilinx-g2b7f6f70a62a ehci_hcd
[ 0.944735] usb usb1: SerialNumber: ci_hdrc.0
[ 0.946125] cdns-wdt f8005000.watchdog: Xilinx Watchdog Timer with timeout 10s
[ 0.949924] hub 1-0:1.0: USB hub found
[ 0.956807] EDAC MC: ECC not enabled
[ 0.960143] hub 1-0:1.0: 1 port detected
[ 0.964631] cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 666666 KHz, changing to: 666667 KHz
[ 0.978597] Xilinx Zynq CpuIdle Driver started
[ 0.984228] sdhci: Secure Digital Host Controller Interface driver
[ 0.990427] sdhci: Copyright(c) Pierre Ossman
[ 0.994859] sdhci-pltfm: SDHCI platform and OF driver helper
[ 1.001632] ledtrig-cpu: registered to indicate activity on CPUs
[ 1.008205] clocksource: ttc_clocksource: mask: 0xffff max_cycles: 0xffff, max_idle_ns: 537538477 ns
[ 1.017444] timer #0 at (ptrval), irq=47
[ 1.021960] usbcore: registered new interface driver usbhid
[ 1.027536] usbhid: USB HID core driver
[ 1.036024] mmc0: SDHCI controller on e0100000.mmc [e0100000.mmc] using ADMA
[ 1.036340] fpga_manager fpga0: Xilinx Zynq FPGA Manager registered
[ 1.051397] NET: Registered PF_INET6 protocol family
[ 1.058012] Segment Routing with IPv6
[ 1.061821] In-situ OAM (IOAM) with IPv6
[ 1.065862] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 1.072833] NET: Registered PF_PACKET protocol family
[ 1.077891] can: controller area network core
[ 1.079699] mmc0: new high speed SDHC card at address aaaa
[ 1.082329] NET: Registered PF_CAN protocol family
[ 1.088608] mmcblk0: mmc0:aaaa SA16G 14.8 GiB
[ 1.092554] can: raw protocol
[ 1.099868] can: broadcast manager protocol
[ 1.100711] mmcblk0: p1 p2
[ 1.104066] can: netlink gateway - max_hops=1
[ 1.111797] Registering SWP/SWPB emulation handler
[ 1.155065] of-fpga-region fpga-region: FPGA Region probed
[ 1.161337] of_cfs_init
[ 1.163904] of_cfs_init: OK
[ 1.167072] clk: Disabling unused clocks
[ 1.172145] ALSA device list:
[ 1.175115] No soundcards found.
[ 1.418616] EXT4-fs (mmcblk0p2): orphan cleanup on readonly fs
[ 1.431415] EXT4-fs (mmcblk0p2): mounted filesystem 85e9dc48-645a-4268-8e0a-cfb6132365ab ro with ordered data mode. Quota mode: disabled.
[ 1.443906] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 1.452228] devtmpfs: mounted
[ 1.463807] Freeing unused kernel image (initmem) memory: 1024K
[ 1.470192] Run /sbin/init as init process
INIT: version 3.04 booting
[ 1.669238] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[ 1.870614] usb 1-1: New USB device found, idVendor=0781, idProduct=5591, bcdDevice= 1.00
[ 1.878981] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1.886257] usb 1-1: Product: SanDisk 3.2Gen1
[ 1.890808] usb 1-1: Manufacturer: USB
[ 1.894652] usb 1-1: SerialNumber: 0101c87a64b5cb45bccaae1bd784c1bad724ebe2453b86693086a660b9568077c3bd000000000000000000005c22d5f9ff81320091558107a1aaf0ca
[ 1.909818] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 1.917055] scsi host0: usb-storage 1-1:1.0
[ 2.390609] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Starting udev
[ 2.771513] udevd[87]: starting version 3.2.14
[ 2.908493] usb 1-1: Get one byte OTG status failed
[ 2.990452] scsi 0:0:0:0: Direct-Access USB SanDisk 3.2Gen1 1.00 PQ: 0 ANSI: 6
[ 3.000008] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 3.013722] sd 0:0:0:0: [sda] 240353280 512-byte logical blocks: (123 GB/115 GiB)
[ 3.022087] sd 0:0:0:0: [sda] Write Protect is off
[ 3.027584] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 3.044355] sda: sda1
[ 3.047280] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 4.118255] random: crng init done
[ 4.179467] udevd[88]: starting eudev-3.2.14
[ 6.353866] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 7.137243] EXT4-fs (mmcblk0p2): re-mounted 85e9dc48-645a-4268-8e0a-cfb6132365ab r/w. Quota mode: disabled.
INIT: Entering runlevel: 5
Configuring network interfaces... done.
Starting system message bus: dbus.
Starting Dropbear SSH server: dropbear.
Starting openvpn:.
Starting rpcbind daemon...done.
Starting atd: OK
egrep: warning: egrep is obsolescent; using grep -E
starting DNS forwarder and DHCP server: dnsmasq... done.
Starting internet superserver: inetd.
Starting ntpd: done
Starting system log daemon...0
Jun 12 10:39:53 bora kernel: L2C: platform modifies aux control register: 0x72360000 -> 0x72760000
Jun 12 10:39:53 bora kernel: L2C: DT/platform modifies aux control register: 0x72360000 -> 0x72760000
Jun 12 10:39:53 bora kernel: armv7-pmu f8891000.pmu: hw perfevents: no interrupt-affinity property, guessing.
Jun 12 10:39:53 bora kernel: spi-nor spi0.0: found s25fl256s1, expected s25fl128s1
Jun 12 10:39:55 bora kernel: FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Jun 12 10:39:55 bora kernel: usb 1-1: Get one byte OTG status failed
Jun 12 10:39:59 bora kernel: FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Starting internet superserver: xinetd.
Starting Postfix...postfix/postfix-script: starting the Postfix mail system
Successful
Starting Lighttpd Web Server: lighttpd.
* starting FTP Server: vsftpd... done.
Starting crond: OK
Starting tcf-agent: OK
********************************************************************************************
The PetaLinux source code and images provided/generated are for demonstration purposes only.
Please refer to https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/2741928025/Moving+from+PetaLinux+to+Production+Deployment
for more details.
********************************************************************************************
PetaLinux 2024.2+release-S11061705 bora ttyPS0
bora login: root (automatic login)
root@bora:~#
root@bora:~# uname -a
Linux bora 6.6.40-xilinx-g2b7f6f70a62a #1 SMP PREEMPT Tue Oct 29 11:52:30 UTC 2024 armv7l GNU/Linux
root@bora:~# cat /etc/os-release
ID=petalinux
NAME="PetaLinux"
VERSION="2024.2+release-S11061705 (scarthgap)"
VERSION_ID=2024.2-release-s11061705
VERSION_CODENAME="scarthgap"
PRETTY_NAME="PetaLinux 2024.2+release-S11061705 (scarthgap)"
CPE_NAME="cpe:/o:openembedded:petalinux:2024.2+release-S11061705"
BUILD_VERSION="desk-xz7-l-2.0.0"
root@bora:~# cat /etc/buildinfo
-----------------------
Build Configuration: |
-----------------------
DISTRO = petalinux
DISTRO_VERSION = 2024.2+release-S11061705
MACHINE = zynq-generic-7z020
IMAGE_BASENAME = petalinux-image-minimal
-----------------------
Layer Revisions: |
-----------------------
meta = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-poky = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-microblaze = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-core = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-standalone = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-standalone-sdt = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-bsp = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-vendor = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-virtualization = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-mali400 = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-demos = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-multimedia = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-tools = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-amd-adaptive-socs-core = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-amd-adaptive-socs-bsp = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-arm = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-arm-toolchain = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-perl = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-python = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-filesystems = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-gnome = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-multimedia = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-networking = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-webserver = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xfce = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-initramfs = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-oe = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-contrib = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-virtualization = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-kria = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-embedded-plus = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-security = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-tpm = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-xilinx-tsn = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-petalinux = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-openamp = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-qt5 = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-aws = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-jupyter = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-rauc = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-system-controller = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-ros-common = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-ros2 = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-ros2-jazzy = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-system-controller-restricted = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-user = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
meta-dave = HEAD:988f0475300d2f5ff4cea89df5eebfb16e8ad28d
workspace = HEAD:13055268986ea93853c7dfc2d70253a9ae0a266a -- modified
root@bora:~#
root@bora:~# shutdown -h now
Broadcast message from root@bora (ttyPS0) (Thu Jun 12 10:41:44 2025):
The system is going down for system halt NOW!
INIT: Switchinroot@bora:~# Stopping Dropbear SSH server: stopped /usr/sbin/dropbear (pid 481)
dropbear.
Stopping Postfix...postfix/postfix-script: stopping the Postfix mail system
Successful
Stopping atd: OK
Stopping system message bus: dbus.
egrep: warning: egrep is obsolescent; using grep -E
stopping DNS forwarder and DHCP server: dnsmasq... stopped /usr/bin/dnsmasq (pid 499)
done.
Stopping internet superserver: inetd.
Stopping ntpd: done
Stopping system log daemon...0
Stopping tcf-agent: OK
Stopping internet superserver: xinetd.
Unmounting remote filesystems...
Stopping crond: OK
Stopping rpcbind daemon...
done.
Stopping Lighttpd Web Server: stopped /usr/sbin/lighttpd (pid 605)
lighttpd.
Stopping openvpn:.
Deconfiguring network interfaces... done.
* stopping FTP Server: vsftpd... no /usr/sbin/vsftpd found; none killed
Sending all processes the TERM signal...
Sending all processes the KILL signal...
Deactivating swap...
Unmounting local filesystems...
[ 118.470386] reboot: System halted
How to configure the network interfaces[edit | edit source]
For deploying an Embedded System, one of the most important configuration is the Network Interface configuration.
Once the Embedded Device is finally configured for stand-alone bootstrap, the network interface should be configured for reaching the device remotely via network connections like ssh, telnet, ftp, http, etc.
This Application Note briefly describes how it is possible to simply configure the network interfaces on SystemV (aka SysV) or systemd
Resources[edit | edit source]
For further details on network configuration, please refer - for example - to:
Examples[edit | edit source]
The following configuration assumptions are used in the paragraphs shown below:
- IP address range of the LAN network 192.168.1.0 - 192.168.1.255
- IP address of the gateway 192.168.1.254
- IP address of the device 192.168.1.100
SysV[edit | edit source]
The configuration files for SysV can be found in pre-defined directorys as written here
Basically, for network configuration, it should be enough to properly configure the /etc/network/interfaces file.
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
Here below an example of configuration file:
Static IP address[edit | edit source]
The network interface is configured with a static IP address by creating the configuration entry in the /etc/network/interfaces file as the following:
auto eth0 iface eth0 inet static address 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.254
Dynamic IP addres (DHCP)[edit | edit source]
The network interface is configured - using a proper DHCP server on the network - by creating the configuration entry in the /etc/network/interfaces file as the following:
allow-hotplug eth0 iface eth0 inet dhcp
When the Linux kernel detects the physical interface eth0, the iface causes ifup to use DHCP to configure the interface.
DNS[edit | edit source]
If the resolvconf package is not installed, the DNS configuration can be done manually by editing the /etc/resolv.conf as the following:
nameserver 192.168.1.1
For example, it can be done on the command line echoing the string in this way:
root@axel-lite:~# echo "nameserver 192.168.1.1" > /etc/resolv.conf
loopback network interface[edit | edit source]
The following configuration entry in the /etc/network/interfaces file brings up the loopback network interface lo upon booting the system.
# The loopback interface auto lo iface lo inet loopback
This one always exists in the /etc/network/interfaces file.
systemd[edit | edit source]
The network configuration for systemd are basically found in the /etc/systemd/network/ directory.
The most simply way for configuring the network interface is to create/edit the file /etc/systemd/network/20-eth0.network as per the following paragraphs.
For more example and usage hints on systemd, please refer to our wiki page.
Static IP address[edit | edit source]
[Match] Name=eth0 # Prevent the interface loading if the kernel boots from nfs KernelCommandLine=!nfsroot [Network] Address=192.168.1.100 Gateway=192.168.1.254 DNS=192.168.1.1
Once modified, the networkd service should be resarted:
systemctl restart systemd-networkd
Dynamic IP addres (DHCP)[edit | edit source]
The network interface is configured - using a proper DHCP server on the network - by using the DHCP key in the configuration file as the following:
[Match] Name=eth0 # Prevent the interface loading if the kernel boots from nfs KernelCommandLine=!nfsroot [Network] DHCP=yes
When systemd network starts, it tries to use a DHCP server present in the network to configure the interface.
DNS[edit | edit source]
The DNS key (in the configuration file) is used only if the systemd-resolved service is enabled and the /etc/resolv.conf has a symbolic link to /run/systemd/resolve/stub-resolv.conf
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
Once modified, the resolved service should be resarted:
systemctl restart systemd-resolved
loopback network interface[edit | edit source]
systemd contains native implementations of various tasks that need to be executed as part of the boot process.
For example, it sets the hostname or configures the loopback network device.
Apply configuration changes[edit | edit source]
After editing the above files, changes are applied after reboot or by restarting systemd-networkd.service:
root@imx6qdlxelk:~# systemctl restart systemd-networkd.service
Peripherals[edit | edit source]
Peripheral Console[edit | edit source]
The Zynq-7000 main UART device (UART1) is mapped to the ttyPS0 device.
Accessing the peripheral[edit | edit source]
Linux messages at boot time[edit | edit source]
... [ 0.000000] Kernel command line: console=ttyPS0,115200 earlycon root=/dev/mmcblk0p2 ro rootwait ... [ 0.315743] e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 27, base_baud = 3125000) is a xuartps [ 0.329053] printk: console [ttyPS0] enabled ...
Peripheral Ethernet[edit | edit source]
The ethernet interface 0 is made available through the gem0 interface, this interface should be initialized on the device tree.
Device tree configuration[edit | edit source]
Here below an example of device tree for ethernet interface 0 configuration used on standard DAVE's kit for the BORA, BORA Xpress and BORA Lite:
From bora.dtsi:
&gem0 {
status = "okay";
phy-mode = "rgmii-id";
phy-handle = <ðernet_phy>;
ethernet_phy: ethernet-phy@7 {
reg = <0x07>;
device_type = "ethernet-phy";
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy0: phy@7 {
rxc-skew-ps = <0x744>;
txc-skew-ps = <0x744>;
micrel,led-mode = <0x01>;
compatible = "micrel,ksz9031";
device_type = "ethernet-phy";
reg = <0x07>;
};
};
};
};
Accessing the peripheral[edit | edit source]
Linux messages at boot time[edit | edit source]
eth0
[ 0.819308] macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 42 (0a:f0:60:47:15:fd) ... [ 8.793934] macb e000b000.ethernet eth0: PHY [e000b000.ethernet-ffffffff:07] driver [Micrel KSZ9031 Gigabit PHY] (irq=POLL) [ 8.793999] macb e000b000.ethernet eth0: configuring for phy/rgmii-id link mode
Cable connection:
... ... [ 12.994170] macb e000b000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Check the interface with ifconfig[edit | edit source]
root@bora:~# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.89 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fe80::8f0:60ff:fe47:15fd prefixlen 64 scopeid 0x20<link>
ether 0a:f0:60:47:15:fd txqueuelen 1000 (Ethernet)
RX packets 2309 bytes 150380 (146.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 119 bytes 13662 (13.3 KiB)
TX errors 0 dropped 0 overruns 0 carri
Test with iperf3[edit | edit source]
root@bora:~# iperf3 -t 5 -c 192.168.0.114 Connecting to host 192.168.0.114, port 5201 [ 5] local 192.168.0.89 port 44352 connected to 192.168.0.114 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 75.1 MBytes 629 Mbits/sec 0 194 KBytes [ 5] 1.00-4.25 sec 0.00 Bytes 0.00 bits/sec 0 205 KBytes [ 5] 4.25-6.40 sec 0.00 Bytes 0.00 bits/sec 0 205 KBytes [ 5] 6.40-7.37 sec 0.00 Bytes 0.00 bits/sec 0 215 KBytes [ 5] 7.37-8.13 sec 128 KBytes 1.38 Mbits/sec 0 215 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-8.13 sec 611 MBytes 631 Mbits/sec 0 sender [ 5] 0.00-8.18 sec 611 MBytes 627 Mbits/sec receiver iperf Done. root@bora:~#
Peripheral SD[edit | edit source]
The SD device, if present, will be associated by the Linux kernel to the mmcblk0 device:
Accessing the peripheral[edit | edit source]
Linux messages at boot time[edit | edit source]
[ 1.033849] mmc0: SDHCI controller on e0100000.mmc [e0100000.mmc] using ADMA [ 1.086200] mmc0: new high speed SDHC card at address aaaa [ 1.092748] mmcblk0: mmc0:aaaa SA16G 14.8 GiB [ 1.104330] mmcblk0: p1 p2
Additional information[edit | edit source]
Once detected, it can be mounted and accessed via usual Linux commands:
root@bora:~# mkdir -p /mnt/mmcblk0p1 root@bora:~# mkdir -p /mnt/mmcblk0p2 root@bora:~# mount /dev/mmcblk0p1 /mnt/mmcblk0p1 root@bora:~# mount /dev/mmcblk0p2 /mnt/mmcblk0p2 root@bora:~# ls /mnt/mmcblk0p1 BOOT.BIN System Volume Information boot.scr image.ub root@bora:~# ls /mnt/mmcblk0p2 bin dev home lost+found mnt run sys usr www boot etc lib media proc sbin tmp var root@bora:~# dd if=/dev/zero of=test_file_100MB bs=1M count=100 100+0 records in 100+0 records out 104857600 bytes (105 MB, 100 MiB) copied, 0.956393 s, 110 MB/s root@bora:~# time cp test_file_100MB /mnt/mmcblk0p1 real 0m1.980s user 0m0.000s sys 0m1.918s root@bora:~#
Peripheral CAN[edit | edit source]
CAN is routed through the PL using the TCL scripts for the Vivado project example here below:
recreate_prj_bora_BASE.tclrecreate_prj_boralite_BASE.tclrecreate_prj_boralite_NAND.tclrecreate_prj_borax_BASE.tcl
Accessing the peripheral[edit | edit source]
Linux messages at boot time[edit | edit source]
root@bora:~# dmesg | grep -i can [ 0.545770] CAN device driver interface [ 0.752012] can: controller area network core [ 0.761010] can: raw protocol [ 0.763989] can: broadcast manager protocol [ 0.768236] can: netlink gateway - max_hops=1
Enable the interface and check status[edit | edit source]
The following commands can be issued from the command line to enable the CAN interface on BORA:
root@bora:~# ip link set can0 type can bitrate 500000 root@bora:~# ifconfig can0 up
To test the CAN interface it is possible to use a PCAN-USB device connected to the DESK-XZ7-L-MVM. The following commands can be issued from the command line to enable the CAN interface on the MVM:
dvdk@vagrant:~# sudo ip link set can0 type can bitrate 500000 dvdk@vagrant:~# sudo ifconfig can0 up
Usage with can-utils[edit | edit source]
cansend[edit | edit source]
This is an example of using a BORA Evaluation Kit to send data connected to a PCAN-USB device (that receives the data).
- the following commands can be issued from the command line on BORA to send data to PCAN-USB
root@bora:~# cansend can0 -i 0x7ff 00 01 02 03 04 05 06 07 interface = can0, family = 29, type = 3, proto = 1 <0x7ff> [8] 00 01 02 03 04 05 06 07
- the following commands can be issued from the command line on MVM to receive data from BORA with PCAN-USB
dvdk@vagrant:~# candump can0 can0 7FF [8] 00 01 02 03 04 05 06 0
candump[edit | edit source]
This is an example of using a PCAN-USB device to send data to a connected BORA Evaluation Kit (that receives the data).
- the following commands can be issued from the command line on MVM to send data with PCAN-USB
dvdk@vagrant:~# cansend can0 7ff#0001020304050607 can0 7FF [8] 00 01 02 03 04 05 06 07
- the following commands can be issued from the command line on BORA to receive data from PCAN-USB
root@bora:~# candump can0 interface = can0, family = 29, type = 3, proto = 1 <0x7ff> [8] 00 01 02 03 04 05 06 07
Peripheral NOR[edit | edit source]
Device tree configuration[edit | edit source]
Here below an example of device tree for the Quad-SPI NOR flash configuration used on standard DAVE's kit for the BORA, BORA Xpress and BORA Lite:
From bora.dtsi:
...
...
&qspi {
flash0: flash@0 {
// we need to use 128Mbit (16MiB) device compatibile even if
// the real hardware has a 256Mbit (32MiB) device because of
// Zynq QSPI controller limits
compatible = "spansion,s25fl128s1", "jedec,spi-nor";
#address-cells = <1>;
#size-cells = <1>;
reg = <0>;
spi-tx-bus-width = <1>;
spi-rx-bus-width = <4>;
spi-max-frequency = <25000000>;
};
};
...
...
Accessing the peripheral[edit | edit source]
Linux messages at boot time[edit | edit source]
[ 0.659256] spi-nor spi0.0: found s25fl256s1, expected s25fl128s1 [ 0.665661] spi-nor spi0.0: s25fl256s1 (32768 Kbytes) [ 0.670919] 1 fixed-partitions partitions found on MTD device spi0.0 [ 0.677282] Creating 1 MTD partitions on "spi0.0": [ 0.682146] 0x000000000000-0x000002000000 : "qspi-boot"
Check the mtd partitions[edit | edit source]
root@bora:~# cat /proc/mtd dev: size erasesize name mtd0: 02000000 00010000 "qspi-boot"
Peripheral NAND[edit | edit source]
Device tree configuration[edit | edit source]
|
If user use |
Here below an example of device tree configuration used on standard DAVE's kit for the BORA Lite NAND flash:
From bora.dtsi:
...
...
&nand0{
partition@nand-bootbin {
label = "bootbin";
reg = <0x00000000 0x01600000>;
};
partition@nand-ubootenv {
label = "ubootenv";
reg = <0x01600000 0x00040000>;
};
partition@nand-rootfs {
label = "rootfs";
reg = <0x01640000 0x0>;
};
};
...
...
Accessing the peripheral[edit | edit source]
Linux messages at boot time (boot from SD with NAND flash support)[edit | edit source]
[ 0.709510] nand: device found, Manufacturer ID: 0xef, Chip ID: 0xd3 [ 0.712698] nand: Winbond W29N08GV [ 0.714412] nand: 1024 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 ... [ 0.741479] 3 fixed-partitions partitions found on MTD device W29N08GV [ 0.748115] Creating 3 MTD partitions on "W29N08GV": [ 0.753138] 0x000000000000-0x000001600000 : "bootbin" [ 0.760908] 0x000001600000-0x000001640000 : "ubootenv" [ 0.776202] 0x000001640000-0x000040000000 : "rootfs"
Check the mtd partitions[edit | edit source]
root@boralite:~# cat /proc/mtd dev: size erasesize name mtd0: 01600000 00020000 "bootbin" mtd1: 00040000 00020000 "ubootenv" mtd2: 3e9c0000 00020000 "rootfs"
Linux messages at boot time (boot from NAND flash)[edit | edit source]
[ 0.705403] nand: device found, Manufacturer ID: 0xef, Chip ID: 0xd3 [ 0.708607] nand: Winbond W29N08GV [ 0.710317] nand: 1024 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 ... [ 1.076003] 3 fixed-partitions partitions found on MTD device W29N08GV [ 1.082625] Creating 3 MTD partitions on "W29N08GV": [ 1.087662] 0x000000000000-0x000001600000 : "bootbin" [ 1.101780] 0x000001600000-0x000001640000 : "ubootenv" [ 1.111817] 0x000001640000-0x000040000000 : "rootfs" ... [ 1.209392] ubi0: attaching mtd2 [ 3.943763] ubi0: scanning is finished [ 3.970955] ubi0: attached mtd2 (name "rootfs", size 1001 MiB) [ 3.976801] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes [ 3.983713] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512 [ 3.990409] ubi0: VID header offset: 512 (aligned 512), data offset: 2048 [ 3.997277] ubi0: good PEBs: 8010, bad PEBs: 4, corrupted PEBs: 0 [ 4.003395] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128 [ 4.010637] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1501637841 [ 4.019766] ubi0: available PEBs: 0, total reserved PEBs: 8010, PEBs reserved for bad PEB handling: 156 [ 4.029253] ubi0: background thread "ubi_bgt0d" started, PID 54 [ 4.048733] UBIFS (ubi0:0): Mounting in unauthenticated mode [ 4.054771] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 55 [ 4.098540] UBIFS (ubi0:0): recovery needed [ 4.252929] UBIFS (ubi0:0): recovery completed [ 4.257516] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "ubifs" [ 4.264862] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes [ 4.274857] UBIFS (ubi0:0): FS size: 1011419136 bytes (964 MiB, 7839 LEBs), journal size 9033728 bytes (8 MiB, 71 LEBs) [ 4.285664] UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB) [ 4.291525] UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0), UUID 18F323BA-5A9C-422A-912C-2C06647F3EDF, small LPT model ...
Check the mtd partitions[edit | edit source]
root@boralite:~# cat /proc/mtd dev: size erasesize name mtd0: 01600000 00020000 "bootbin" mtd1: 00040000 00020000 "ubootenv" mtd2: 3e9c0000 00020000 "rootfs"
Peripheral UART[edit | edit source]
The Zynq-7000 second UART device (UART0) is routed through the PL and it is mapped to the ttyPS1 device. This feature is available in the Vivado project example using the TCL scripts here below:
recreate_prj_bora_BASE.tclrecreate_prj_bora_ETH1.tclrecreate_prj_boralite_BASE.tclrecreate_prj_boralite_ETH1.tclrecreate_prj_boralite_NAND.tclrecreate_prj_borax_BASE.tclrecreate_prj_borax_ETH1.tcl
Accessing the peripheral[edit | edit source]
Linux messages at boot time[edit | edit source]
... [ 0.306574] e0000000.serial: ttyPS1 at MMIO 0xe0000000 (irq = 26, base_baud = 3125000) is a xuartps [ 0.315743] e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 27, base_baud = 3125000) is a xuartps ...
Usage with stty[edit | edit source]
N.B. UART mapping respect to ttyPSX is the following one:
UART0 (RS232) <-> ttyPS1 UART1 (Serial Port) <-> ttyPS0
root@bora:~# stty -F /dev/ttyPS1 115200 -echo root@bora:~# cat /dev/ttyPS1 & [1] 722 root@bora:~# echo "Test loopback" > /dev/ttyPS1 root@bora:~# Test loopback
Helloworld from UART0[edit | edit source]
On target we need to loopback pin 4 and 6 of PMOD A.
Here below an example on C code for initializing and using UART0 through FPGA:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
int main()
{
int fd;
char *portname = "/dev/ttyPS1";
int numchar;
char msg[] = "Hello World from DESK-XZ7-L-2.0.0 (FPGA PS0 UART)!\r";
fd = open(portname, O_RDWR | O_NOCTTY | O_SYNC);
if (fd < 0)
{
printf("error %d opening %s: %s", errno, portname, strerror (errno));
exit(1);
}
numchar = write(fd, msg, strlen(msg));
exit(errno);
}
For compile it, please use the following instruction:
dvdk@vagrant:~$ wget https://mirror.dave.eu/desk-xz-l/desk-xz7-l-2.0.0/Petalinux/bora_sdk.sh --2025-06-13 09:27:27-- https://mirror.dave.eu/desk-xz-l/desk-xz7-l-2.0.0/Petalinux/bora_sdk.sh Resolving mirror.dave.eu (mirror.dave.eu)... 84.46.251.143 Connecting to mirror.dave.eu (mirror.dave.eu)|84.46.251.143|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 963331875 (919M) [text/x-sh] Saving to: ‘bora_sdk.sh’ bora_sdk.sh 100%[====================================================================================================>] 918.70M 236KB/s in 27m 56s 2025-06-13 09:55:23 (561 KB/s) - ‘bora_sdk.sh’ saved [963331875/963331875] dvdk@vagrant:~$ chmod 755 bora_sdk.sh dvdk@vagrant:~$ ./bora_sdk.sh PetaLinux SDK installer version 2024.2 ====================================== Enter target directory for SDK (default: /opt/petalinux/2024.2): You are about to install the SDK to "/opt/petalinux/2024.2". Proceed [Y/n]? Extracting SDK.......................................................................................................................................................................................................................done Setting it up...done SDK has been successfully set up and is ready to be used. Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g. $ . /opt/petalinux/2024.2/environment-setup-cortexa9t2hf-neon-xilinx-linux-gnueabi dvdk@vagrant:~$ dvdk@vagrant:~$ source /opt/petalinux/2024.2/environment-setup-cortexa9t2hf-neon-xilinx-linux-gnueabi dvdk@vagrant:~$ vi hello_UART0.c dvdk@vagrant:~$ $CC -O hello_UART0.c -o hello_UART0 dvdk@vagrant:~$ file hello_UART0 hello_UART0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=3bf1e4927e775fe0a2afb1474737d77bfd391789, for GNU/Linux 5.15.0, with debug_info, not stripped
Copy hello_UART0 on target and perform the following command:
root@bora:~# ./hello_UART0 root@bora:~# Hello World from DESK-XZ7-L-2.0.0 (FPGA PS0 UART)!
Additional information[edit | edit source]
Serial ports can be used through the standard serial programming API.
For detailed information, please refer to the Serial Programming HOWTO at Serial-Programming-HOWTO
Peripheral USB OTG[edit | edit source]
Device tree configuration[edit | edit source]
Here below an example of device tree configuration used on standard DAVE's kit for the BORA, BORA Xpress and BORA Lite:
From bora.dtsi:
...
...
/ {
...
...
usb_phy0: phy0@e0002000{
compatible = "ulpi-phy";
#phy-cells = <0x00>;
reg = <0xe0002000 0x1000>;
view-port = <0x170>;
drv-vbus;
};
...
...
};
...
...
&usb0 {
dr_mode = "otg";
usb-phy = <&usb_phy0>;
};
...
...
Accessing the peripheral[edit | edit source]
Linux messages in host mode[edit | edit source]
When a USB2.0 peripheral is inserted, in the following example a memory mass storage device, the kernel recognizes the device (i.e. class, vendor id, product id, etc.)
[ 3649.090990] ci_hdrc ci_hdrc.0: EHCI Host Controller [ 3649.091077] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 [ 3649.118348] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 [ 3649.119094] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.06 [ 3649.119148] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3649.119185] usb usb1: Product: EHCI Host Controller [ 3649.119214] usb usb1: Manufacturer: Linux 6.6.40-xilinx-g2b7f6f70a62a ehci_hcd [ 3649.119241] usb usb1: SerialNumber: ci_hdrc.0 [ 3649.121015] hub 1-0:1.0: USB hub found [ 3649.121168] hub 1-0:1.0: 1 port detected [ 3649.808344] usb 1-1: new high-speed USB device number 2 using ci_hdrc [ 3650.010627] usb 1-1: New USB device found, idVendor=0781, idProduct=5591, bcdDevice= 1.00 [ 3650.010686] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3650.010723] usb 1-1: Product: SanDisk 3.2Gen1 [ 3650.010752] usb 1-1: Manufacturer: USB [ 3650.010778] usb 1-1: SerialNumber: 0101c87a64b5cb45bccaae1bd784c1bad724ebe2453b86693086a660b9568077c3bd000000000000000000005c22d5f9ff81320091558107a1aaf0ca [ 3650.013156] usb-storage 1-1:1.0: USB Mass Storage device detected [ 3650.015390] scsi host1: usb-storage 1-1:1.0 [ 3651.068638] usb 1-1: Get one byte OTG status failed [ 3651.070809] scsi 1:0:0:0: Direct-Access USB SanDisk 3.2Gen1 1.00 PQ: 0 ANSI: 6 [ 3651.073643] sd 1:0:0:0: Attached scsi generic sg0 type 0 [ 3651.083081] sd 1:0:0:0: [sdb] 240353280 512-byte logical blocks: (123 GB/115 GiB) [ 3651.084294] sd 1:0:0:0: [sdb] Write Protect is off [ 3651.084361] sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00 [ 3651.085540] sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 3651.098041] sdb: sdb1 [ 3651.098893] sd 1:0:0:0: [sdb] Attached SCSI removable disk [ 3652.215600] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Additional information[edit | edit source]
If the root file system configuration does not automatically mount the partition, it is possible to mount the device using the following command:
root@bora:~# mkdir -p /mnt/usb root@bora:~# mount /dev/sda1 /mnt/usb root@bora:~# ls -la /mnt/usb/ total 110916 drwxrwx--- 3 root disk 32768 Jan 1 1970 . drwxr-xr-x 5 root root 4096 Jun 12 11:47 .. -rwxrwx--- 1 root disk 104857600 Jun 12 10:21 linux_testfile.txt -rwxrwx--- 1 root disk 13 Mar 9 2018 uboot_testfile.txt root@bora:~#
Accessing the device[edit | edit source]
Usage with mass-storage[edit | edit source]
root@bora:~# dd if=/dev/zero of=/tmp/mass count=16 bs=1M
16+0 records in
16+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 0.111122 s, 151 MB/s
root@bora:~# mkfs.ext4 /tmp/mass
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 16384 1k blocks and 4096 inodes
Filesystem UUID: 03af7a9e-aa46-4041-8ef4-aa062ac8d1a8
Superblock backups stored on blocks:
8193
Allocating group tables: done
Writing inode tables: done
Creating journal (1024 blocks): done
Writing superblocks and filesystem accounting information: done
root@bora:~# mkdir -p /tmp/loop
root@bora:~# mount /tmp/mass /tmp/loop
root@bora:~# echo "Hello from desk-xz7-l" > /tmp/loop/usb.txt
root@bora:~# umount /tmp/loop
root@bora:~#
then insert the g_mass_storage kernel module driver enabling an Windows PC to see it as a removable device
root@bora:~# modprobe --first-time g_mass_storage file=/tmp/mass iSerialNumber=USBOTGCHECK
Once the USB cable is connected to the PC, the kernel prints the following messages:
[ 110.975128] Mass Storage Function, version: 2009/09/11 [ 110.975153] LUN: removable file: (no medium) [ 110.975314] LUN: file: /var/volatile/tmp/mass [ 110.975333] Number of LUNs=1 [ 110.975610] g_mass_storage gadget.0: Mass Storage Gadget, version: 2009/09/11 [ 110.975632] g_mass_storage gadget.0: g_mass_storage ready
and the Windows PC activate the driver and the disk is available as a Drive Unit (with the usb.txt file available).
Peripheral Temperature sensors[edit | edit source]
BORA and BORA Xpress SOMs has a TMP421AIDCN temperature sensor onboard.
Accessing the peripheral[edit | edit source]
The temperature information can be accessed through the sysfs interface:
read the PCB temperature[edit | edit source]
root@bora:~# cat /sys/devices/soc0/axi/e0004000.i2c/i2c-0/0-004f/hwmon/hwmon1/temp1_input
the returned value has to be divided by 1000 for a °C temperature
read the CPU temperature[edit | edit source]
root@bora:~# cat /sys/devices/soc0/axi/e0004000.i2c/i2c-0/0-004f/hwmon/hwmon1/temp2_input
the returned value has to be divided by 1000 for a °C temperature
internal SoC temperature[edit | edit source]
Moreover, the SoC has an internal temperature sensor device which can be read using the following shell script:
root@bora:~# cat temp.sh
#!/bin/sh
# Tcpu
TEMP_RAW=`cat /sys/devices/soc0/axi/f8007100.adc//iio\:device1/in_temp0_raw`
TEMP_OFFSET=`cat /sys/devices/soc0/axi/f8007100.adc//iio\:device1/in_temp0_offset`
TEMP_SCALE=`cat /sys/devices/soc0/axi/f8007100.adc//iio\:device1/in_temp0_scale`
TEMP=`awk "BEGIN {print (($TEMP_RAW+$TEMP_OFFSET)*$TEMP_SCALE)/1000}"`
echo "Cpu Temp: ${TEMP}"
root@bora:~# chmod u+x temp.sh
root@bora:~# ./temp.sh
Cpu Temp: 58.0752
Peripheral Power meter[edit | edit source]
BORA, BORA Xpress and BORA Lite EVBs has a INA226 device connected to the I2C bus. The following commands can be saved as a shell script (e.g. read_power_values.sh) and run to collect the measurements data:
root@bora:~# cat read_power_values.sh
#!/bin/sh
path_dev=/sys/bus/iio/devices/iio\:device0/
IN_VOLT0_RAW=$(cat "$path_dev/in_voltage0_raw")
IN_VOLT0_SCALE=$(cat "$path_dev/in_voltage0_scale")
IN_VOLT1_RAW=$(cat "$path_dev/in_voltage1_raw")
IN_VOLT1_SCALE=$(cat "$path_dev/in_voltage1_scale")
IN_VOLT0=$(echo "$IN_VOLT0_RAW*$IN_VOLT0_SCALE" | bc)
IN_VOLT1=$(echo "$IN_VOLT1_RAW*$IN_VOLT1_SCALE" | bc)
VOLTAGE=`awk "BEGIN {print ($IN_VOLT1-$IN_VOLT0)/1000}"`
IN_CURRENT3_RAW=`cat $path_dev/in_current3_raw`
IN_CURRENT3_SCALE=`cat $path_dev/in_current3_scale`
CURRENT=`awk "BEGIN {print ($IN_CURRENT3_RAW*$IN_CURRENT3_SCALE)/1000}"`
IN_POWER2_RAW=`cat $path_dev/in_power2_raw`
IN_POWER2_SCALE=`cat $path_dev/in_power2_scale`
POWER=`awk "BEGIN {print ($IN_POWER2_RAW*$IN_POWER2_SCALE)/1000}"`
echo "Voltage: ${VOLTAGE}, Current: ${CURRENT}, Power: ${POWER}"
root@bora:~# ./read_power_values.sh Voltage: 3.31448, Current: 0.7235, Power: 2.38125 root@bora:~#
