Quantcast
Channel: Xilinx Wiki : Xilinx Wiki - all changes
Viewing all 11776 articles
Browse latest View live

Zynq UltraScale Plus Restart solution

$
0
0
...
2) Start the wdt_heartbeat daemon to provide heartbeats to FPD wdt by writing key (0x1999) to FPD WDT restart offset (0xFD4D0008)
# wdt_heartbeat &
...
script (e.g /etc/init.d/)/etc/rcS.d/S*/)
Fake Hanging
We can do a fake hanging of the system by killing wdt_heartbeat application, which will trigger FPD WDT expiry resulting in the recovery attempt by the PMU-firmware.
# killall wdt_heartbeat
Note: Kill the application that is providing the heartbeats to WDT. wdt_heartbeat is just an example here.
Triggering Escalation
Escalation can be trigger by failing the recovery. These can be done by two ways (just for testing purpose)
1) Use the ATF without ZYNQMP_WARM_RESTART flag or set the value of the flag to 0. Followed by Fake Hanging.
During the recovery the PMU firmware will try to raise an IPI which ATF will have to handle but will do nothing as warm restart flag is disable.
The WDT timer will expire again as there was not heartbeat for it. The PMU firmware will now do the escalation as previous ATF was not able to hand back to PMU firmware in the last attempt.
2) Do not set the healthy bit after reboot, followed by fake hanging.
During the recovery the PMU firmware will do the escalation as healthy bit is not set, which implies last boot was not successful.

NODE_ETH_0
1

OpenAMP 2017.3

$
0
0
...
in Linker Flags, add --sysroot=<plnx proj>/build/tmp/sysroots/plnx_aarch_64
Copy the following files for OpenAMP application for ZynqMP into the directory:
...
from here
helper.c from here

And the Linux files for one of the three OpenAMP applications in the link:
OpenAMP echo-test
...
petalinux-config -c rootfs
2. Enable the required rootfs packages for the application. If you are running the sample applications from UG1186, the packages would be enabled by the following:
Filesystem Packages--> libs--> libmetal--> [Packages-->libs-->libmetal-->[ * ] libmetal openamp--> [libmetalopenamp--> [ * ] open-amp misc--> openamp-fw-echo-testd-->open-ampmisc--> openamp-fw-echo-testd--> [ * ] openamp-fw-echo-testd openamp-fw-mat-muld--> [openamp-fw-echo-testdopenamp-fw-mat-muld-->[ * ] openamp-fw-mat-muld openamp-fw-rpc-demod--> [openamp-fw-mat-muldopenamp-fw-rpc-demod-->[ * ]
...
* ] rpmsg-echo-test rpmsg-mat-mul--> [rpmsg-echo-testrpmsg-mat-mul-->[ * ] rpmsg-mat-mul rpmsg-proxy-app--> [rpmsg-mat-mulrpmsg-proxy-app-->[ * ] rpmsg-proxy-app rpmsg-proxy-module--> [rpmsg-proxy-apprpmsg-proxy-module-->[ * ] rpmsg-proxy-module rpmsg-user-module--> [rpmsg-proxy-modulerpmsg-user-module-->[ * ]
3. Then build the petalinux project.
petalinux-build

Xilinx V4L2 Demosaic driver

$
0
0
...
(This path is relative to your linux kernel source root directory)
Limitations
10,1212 and 16 color depth width is not
...
to 8-bit and 10-bit in this
Fringe Tolerant Interpolation is not supported. Only High Resolution Interpolation is supported by the driver.
Supported Features
...
ZCU102 Rev 1.0
Technical Reference Designs
Coming SoonreVision Getting Started
Related Links
Sensor Demosaic Product Guide

PS and PL based Ethernet in Zynq MPSoC

$
0
0
...
2.4.1.4 Edit device for PS EMIO
Follow below process for PS-EMIO only.
2.4.1.5 Apply FSBL patch
Follow this process for applying patch in FSBL.
Create folder named files in <proj dir>\project-spec\meta-user\recipes-fsbl\fsbl.
Add fsbl_patch here which configure clock and SFP.
Open fsbl_%.bbapend
Modifications to system-user.dtsi
Modify the system-user.dtsi by navigating to the the
file from <proj dir>\project-spec\meta-user\recipes-fsbl\fsbl and add below lineusing 'vi project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi' ,
i) For the PS-PL EMIO 1000BASE-X, make the following modifications
to it.
SRC_URI += "file://0001-fsbl-si570-clk.patch"
Bitbake will add this patch
system-user.dtsi,
/include/ "system-conf.dtsi"
/ {
};
&gem0 {
phy-handle = <&phy9>;
phy9: phy@9 {
reg = <0x9>;
xlnx,phy-type = <0x5>;
};
};
&i2c1 {
status = "okay";
clock-frequency = <400000>;
i2cswitch@74 { /* u34 */
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x74>;
i2c@3 { /* i2c mw 74 0 8 */
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
si570_2: clock-generator3@5d {
#clock-cells = <0>;
compatible = "silabs,si570";
reg = <0x5d>;
temperature-stability = <50>;
factory-fout = <156250000>;
clock-frequency = <125000000>;
};
};
};
};
ii) For the PS-PL EMIO SGMII, make the following modifications
to FSBL before compilation.
Please refer Appendix A for more details about applying patch in fsbl.
system-user.dtsi,
/include/ "system-conf.dtsi"
/ {
};
&gem0 {
phy-handle = <&phy9>;
phy9: phy@9 {
reg = <0x9>;
xlnx,phy-type = <0x4>;
};
};
&i2c1 {
status = "okay";
clock-frequency = <400000>;
i2cswitch@74 { /* u34 */
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x74>;
i2c@3 { /* i2c mw 74 0 8 */
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
si570_2: clock-generator3@5d {
#clock-cells = <0>;
compatible = "silabs,si570";
reg = <0x5d>;
temperature-stability = <50>;
factory-fout = <156250000>;
clock-frequency = <125000000>;
};
};
};
};

2.4.1.6 Build
Build images using PetaLinux.
...
Device Drivers> DMA Engine Support > <> Xilinx AXI DMAS Engine
Save the changes and exit.
2.5.1.4 Apply FSBL patch
Follow this process for applying patch in FSBL.
Create folder named files in <proj dir>\project-spec\meta-user\recipes-fsbl\fsbl.
Add fsbl_patch here which configure clock and SFP.
Open fsbl_%.bbapend
Modifications to system-user.dtsi
Modify the system-user.dtsi by navigating to the the
file from <proj dir>\project-spec\meta-user\recipes-fsbl\fsblusing 'vi project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi',
For PL 1G 1000BASE-X
and add below line to it.
SRC_URI += "file://0001-fsbl-si570-clk.patch"
Bitbake will add this patch
PL 1G SGMII, make the following modifications to FSBL before compilation.
Please refer Appendix A for more details about applying patch in fsbl.
system-user.dtsi,
/include/ "system-conf.dtsi"
/ {
};
&i2c1 {
status = "okay";
clock-frequency = <400000>;
i2cswitch@74 { /* u34 */
compatible = "nxp,pca9548";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x74>;
i2c@3 { /* i2c mw 74 0 8 */
#address-cells = <1>;
#size-cells = <0>;
reg = <3>;
si570_2: clock-generator3@5d {
#clock-cells = <0>;
compatible = "silabs,si570";
reg = <0x5d>;
temperature-stability = <50>;
factory-fout = <156250000>;
clock-frequency = <125000000>;
};
};
};
};

2.5.1.5 Build
Build all images using PetaLinux.
...
Device Drivers> DMA Engine Support> <> Xilinx AXI DMAS Engine
Save the changes and exit.
2.6.1.4 Apply FSBL patch
Follow this process for applying patch in FSBL.
Create folder named files in <proj dir>\project-spec\meta-user\recipes-fsbl\fsbl.
Add fsbl_patch here which configure clock and SFP.
Open fsbl_%.bbapend file from <proj dir>\project-spec\meta-user\recipes-fsbl\fsbl and add below line
Modifications to it.
SRC_URI += "file://0001-fsbl-si570-clk.patch"
Bitbake will add this patch
system-user.dtsi
Modify the system-user.dtsi by navigating to the the file using 'vi project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi' ,
For PL 10G, make the following modifications
to FSBL before compilation.
Please refer Appendix A for more details about applying patch in fsbl.
system-user.dtsi,
/include/ "system-conf.dtsi"
/ {
};
&xxv_ethernet_0 {
local-mac-address = [00 0a 35 00 00 00];
};

2.6.1.5 Build
Build all images using PetaLinux.

PS and PL based Ethernet in Zynq MPSoC

$
0
0
...
&xxv_ethernet_0 {
local-mac-address = [00 0a 35 00 00 00];
};
2.6.1.5 Build
Build all images using PetaLinux.

PS and PL based Ethernet in Zynq MPSoC

$
0
0
...
2.3.2 xapp1306
{xapp1306.jpg}
...
and PS EMIOEMIO(1000BASE-X and SGMII) Ethernet
2.4.1
...
EMIO Ethernet BSPBSP(1000BASE-X and SGMII) installation
PS-Ethernet/PS+PL Ethernet project provides installable BSP, which includes all necessary design sources, configuration files, tested hardware images and software images.
2.4.1.1 Create PS MIO and PS EMIO Ethernet project from PetaLinux BSP
...
petalinux-create -t project -s <path-to-bsp>
bash> cd $XAPP_HOME/xapp1305-ps-pl-based-ethernet-solution/software
...
PS emio 1000BASE-X
bash> petalinux-create
...
project -s bsps/xapp1305_ps_pl_eth_1g/xilinx-zcu102-2017.1-ps-emio.bspbsps/xapp1305_ps_emio_ethernet_1g/ps_emio_eth_1g.bsp
// for PS emio SGMII
bash> petalinux-create -t project -s bsps/xapp1305_ps_emio_ethernet_sgmii/ps_emio_eth_sgmii.bsp(for SGMII)

//for PS MIO
...
project -s bsps/xapp1305_ps_eth_1g/xilinx-zcu102-2017.1-ps-mio.bspbsps/xapp1305_ps_ethernet_1g/ps_eth_1g.bsp
2.4.1.2 Configure PetaLinux
...
PS emio 1000BASE-X
bash> mv xilinx-zcu102-2017.1 xapp1305_ps_emio_ethcd ps_emio_eth_1g
// for PS emio SGMII

bash> cd xapp1305_ps_emio_ethps_emio_eth_sgmii
//for PS mio
bash> mv xilinx-zcu102-2017.1 xapp1305_ps_mio_eth
bash>
cd xapp1305_ps_mio_ethps_eth_1g
bash> petalinux-config
Set one of local directory as tmp directory, Save the changes and exit.
NOTE: Above step may take a longer time depending on the network bandwidth.
2.4.1.3 Configure the kernel
...
2.4.1.5 Modifications to system-user.dtsi
Modify the system-user.dtsi by navigating to the the file using 'vi project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi' ,
...
For the PS-PLPS EMIO 1000BASE-X,
/include/ "system-conf.dtsi"
/ {
...
};
};
...
For the PS-PLPS EMIO SGMII,
/include/ "system-conf.dtsi"
/ {
...
2.4.1.7 Create Zynq-mp Boot image (BOOT.bin)
bash> cd images/linux
...
PS emio 1000base-x
bash> petalinux-package --boot --fsbl=zynqmp_fsbl.elf --fpga=ps_emio_eth_1g_wrapper.bit --u-boot
// for PS emio SGMII
bash> petalinux-package --boot --fsbl=zynqmp_fsbl.elf --fpga=ps_emio_eth_sgmii_wrapper.bit --u-boot

//for PS mio
bash> petalinux-package --boot --fsbl=zynqmp_fsbl.elf --fpga=ps_emio_eth_1g_wrapper.bit --u-boot
...
For PS mio
Copy BOOT.BIN and image.ub from $PETALINUX/ xapp1305_ps_mio_eth/images/linux to SD partition
...
PL Ethernet 1G1G(1000BASE-X and SGMII)
PL Ethernet project provides installable BSP, which includes all necessary design sources, configuration files, tested hardware images and software images.
The design supports with the auto-negotiation for speeds of 10/100/1000 Mbps and full duplex mode.
NOTE : Check-sum offload in enabled in the default configuration.
...
for 1000Base-X (1G)and SGMII
PL Ethernet project provides installable BSP which includes all necessary design sources and configuration files, including pre-built and tested hardware and software images, ready for download to your board.
2.5.1.1 Create PL Ethernet project from petalinux installable BSP
...
petalinux-create -t project -s <path-to-bsp>
bash> cd $XAPP_HOME/xapp1305-ps-pl-based-ethernet-solution/software
...
project -s bsps/xapp1305_pl_eth_1g/xilinx-zcu102-2017.1-pl_eth.bspbsps/xapp1305_pl_ethernet_1g/pl_eth_1g.bsp
bash> petalinux-create -t project -s bsps/xapp1305_pl_ethernet_sgmii/pl_eth_sgmii.bsp(for SGMII)

2.5.1.2 Configure petalinux
bash> mv xilinx-zcu102-2017.1 xapp1305_pl_eth_1gcd pl_ethernet_1g
bash> cd xapp1305_pl_eth_1gpl_ethernet_sgmii(for SGMII)
bash> petalinux-config
Set one of local directory as tmp directory, Save the changes and exit.
NOTE: Above step may take a longer time depending on the network bandwidth.
2.5.1.3 Configure the kernel
...
Save the changes and exit.
2.5.1.4 Modifications to system-user.dtsi
...
using 'vi project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi',project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi' in your petalinux project,
For PL ETHERNET 1G 1000BASE-X and PL ETHERNET 1G SGMII,
/include/ "system-conf.dtsi"
/ {
...
bash> cd images/linux
bash> petalinux-package --boot --fsbl=zynqmp_fsbl.elf --fpga=pl_eth_1g_wrapper.bit --u-boot
bash> petalinux-package --boot --fsbl=zynqmp_fsbl.elf --fpga=pl_eth_sgmii_wrapper.bit --u-boot
2.5.1.7 SD Images
SD Deployable binaries:-
...
petalinux-create -t project -s <path-to-bsp>
bash> cd $XAPP_HOME/xapp1305-ps-pl-based-ethernet-solution/software
...
project -s bsps/xapp1305_pl_eth_10g/xilinx-zcu102-2017.1-pl-10g.bspbsps/xapp1305_pl_ethernet_10g/pl_eth_10g.bsp
2.6.1.2 Configure petalinux
bash> mv xilinx-zcu102-2017.1 xapp1305_pl_eth_10g
bash>
cd xapp1305_pl_eth_10gpl_ethernet_10g
bash> petalinux-config
Set one of local directory as tmp directory, Save the changes and exit.
NOTE: Above step may take a longer time depending on the network bandwidth.
Zynq UltraScale+ MPSoC
2.6.1.3 Configure the kernel
Add patch to enable 10G support in axi Ethernet driver.
Please follow appendix A for more details about applying patch to kernel.
This patch is provided as part of package.

bash> petalinux-config -c kernel
Enable the Xilinx PHY driver and Disable the AXI DMA driver
...
UG1085, Zynq UltraScale+ MPSoC Technical Reference Manual
Netperf , Netperf page
Appendix A
How to patch Device Tree in petalinux2017.1:
Create PetaLinux BSP for PS-EMIO and PL Ethernet project
This section describes how to create PetaLinux BSP from scratch. It is assumed that PetaLinux environment is set properly.
NOTE : The instructions remain the same for both PL Ethernet and PS EMIO designs.
1 Create Ethernet project
bash> petalinux-create -t project -n <project-name>
bash> cd <project-name>
2 Sync HW description
bash> petalinux-config --get-hw-description=<path-to-hw-description-hdf>
Point to SDK Export directory for the relevant design.
Set one of local directory as tmp directory of petalinux and Save the changes and exit.
3. Petalinux Configuration
a. Disable kernel autoconfig settings
bash> petalinux-config
Auto Config Settings --->
[ ] kernel autoconfig
Uncheck kernel autoconfig
b. Ethernet Setting -- >Subsystem AUTO Hardware Settings ---> Ethernet Settings --->
[ ] Obtain IP address automatically
Unchecked obtain IP address automatically
4. Configure petalinnux to apply patch in FSBL and kernel
a. How to patch Linux kernel in petalinux 2017.1:
To patch Linux kernel instruct tool to clone Linux kernel from git and then apply patch on it.
To do that, copy patch file in <PROJ_DIR>\project-spec\meta-user\recipes-kernel\linux\linux-xlnx location.
After that add below lines to to <PROJ_DIR>\meta-user\recipes-kernel\linux\linux-xlnx_%.bbapend file.
SRC_URI = "git://github.com/Xilinx/linux-xlnx.git"
SRCREV = "xilinx-v2017.1"
SRC_URI += "file://0001-kernel-10G-axienet.patch"
The first line instruct petalinux to clone new kernel copy from the git link provided here.
Second line tell to checkout the tag on git repository. Xilinx-v2017.1 is used for 2017.1 release of petalinux.
Third line is name of patch file which to be applied on this cloned kernel. This should have same name as the file present in <PROJ_DIR>\project-spec\meta-user\recipes-kernel\linux\linux-xlnx.
In the project, the patch name is 0001-kernel-10G-axienet.patch.
b. How to patch FSBL in petalinux 2017.1:
To patch FSBL we must instruct tool to apply patch on it. FSBL soruce code is part of project only. There is not need of extra cloning of the same.
To do that, copy patch file in <PROJ_DIR>\project-spec\meta-user\recipes-fsbl\fsbl\files location.
After that add below lines to to <PROJ_DIR>\meta-user\recipes-fsbl\fsbl_%.bbapend file.
SRC_URI += "\
file://0001-fsbl-si570-clk.patch \
"
This should have same name as the file present in <PROJ_DIR>\project-spec\meta-user\recipes-fsbl\fsbl\.
In my case, the patch name is 0001-fsbl-si570-clk.patch.
c. How to patch Device Tree in petalinux2017.1
Rename the respective <project>/software/<project>.dts file to system-top.dts in <PROJ_DIR>\project-spec\meta-user\recipes-dt\files\ directory.
For example, if the project is PL 1G project, rename PL_1G.dts to system-top.dts in <PROJ_DIR>\project-spec\meta-user\recipes-dt\files\ directory.
5 Build the Petalinux project
bash> petalinux-build -v
6 Create Zynqmp Boot image
Bellow command will create image.ub.
bash> petalinux-package --image
To create boot.bin, go to <petalinux_project>/images/linux
Create bif file with below content.
the_ROM_image:
{
[fsbl_config] a53_x64
[bootloader] zynqmp_fsbl.elf
[destination_device=pl] system_wrapper.bit
[destination_cpu=a53-0,exception_level=el-3,trustzone] bl31.elf
[destination_cpu=a53-0,exception_level=el-2] u-boot.elf
}
run below command in same directory to create boot.img
bash> bootgen -arch zynqmp -image boot.bif -w -o boot.bin
7 Package BSP
bash> petalinux-package --bsp -p <project-name> -o <project-name>.bsp

SRC_URI += "file://0001-fsbl-si570-clk-156MHz.patch"
$XAPP_HOME/xapp1305-ps-pl-ethernet-based-solution

Performance tests procedure and results with LWIP

$
0
0
...
Performance numbers for all combinations are on below link.
With Linux ( xapp 1305):
1. 2016.42017.1
With LWIP (xapp 1306):
1. 2016.4

Zynq mp Ethernet Performance 2016.4

$
0
0

XAPP1305 2016.42017.1
This wiki page summarizes the performance of PS-MIO, PS-EMIO and PL Ethernet(1G and 10G) with CSO and jumbo frame support.
These measurements are obtained against Fedora-20 high performance peer machine. The NIC on motherboard has been used with default offload options

Performance tests procedure and results with LWIP

$
0
0
...
1. 2017.1
With LWIP (xapp 1306):
1. 2016.42017.1
2. Setting up and testing PS Ethernet
2.1 PS Ethernet with Linux

Ethernet performance for LVIP on zynqmp with 2016.4

$
0
0

XAPP1306 2016.42017.1
This wiki page summarizes the performance of PS-MIO, PS-EMIO and PL Ethernet(1G and 10G) with CSO and jumbo frame support.
These measurements are obtained against Fedora-20 high performance peer machine. The NIC on motherboard has been used with default offload options

Video Framebuffer Write

$
0
0
= {under.jpg}
=

Overview
...
the AXI4-interface.
Location
...
Xilinx Linux kernel:
https://github.com/Xilinx/linux-xlnx/tree/2017.1_video_ea
kernel:<tbd>
Supported IP Features
...
which verification within
within
the context
...
4:2:2, YUV 4:4:4
Memory
4:4:4, YUV 4:2:0
Memory
Video Format Support: RGB8, BGRX8, RGBX8, YUYV8, YUVX8, RGBX10, YUVX10, Y_UV8, RGB8
Programmable
Y_UV8_420, UYVY8, YUV8, Y_UV10, Y_UV10_420, Y8, Y10
Programmable
memory video format
Support

Support
for 8-bit or 10-bit per color
...
memory interface
Resolutions up to 3840x2160
Unsupported IP Features
The following list of IP constraints either has no driver support or has not yet been verified to work in any existing technical reference design:
Streaming Video Format Support: YUV 4:2:0
Memory Video Format Support: YUVX8, RGBX10, YUVX10, Y_UV8_420, YUV8, Y_UV10, Y_UV10_420, Y8, Y10
Support for 10-bit per color component on stream or memory interface

Resolutions up to 8192x4320
Known Issues
...
{kernek_config.png}
Device Tree Configuration
...
may be found: <linux_root>/Documentation/devicetree/bindings/dma/xilinx/xilinx_frmbuf.txt
found:
<linux_root>/Documentation/devicetree/bindings/dma/xilinx/xilinx_frmbuf.txt
Below is a device tree example for a Framebuffer Write instance configured with
32-bit wide DMA descriptors and support for RGB8 as well as RGBX8 memory
formats:

Example:
v_frmbuf_rd_0: v_frmbuf_rd@80000000 {
...
reset-gpios = <&gpio 80 1>;
reg = <0x0 0x80000000 0x0 0x10000>;
xlnx,dma-addr-width = <32>;
xlnx,vid-formats = "bgr888","xbgr8888";

};
Implementation Overview
The
Interfacing with the Video Framebuffer Driver from DMA Clients
The
Linux driver
...
As such, additional datathe Video Framebuffer driver exports an API interface that must be used by DMA clients in addition to the Linux DMA Engine interface for proper programming. (see <linux_root>/include/linux/dma/xilinx_frmbuf.h).
The general steps for preparing DMA to write to a specific memory buffer:
Using the Video Framebuffer API, configure the DMA device with the expected memory format for write
Prepare an interleaved template describing the buffer location (note: see section DMA Interleaved Template Requirements below for more details)
Pass the interleaved template to the DMA device using the Linux DMA Engine interface
With the DMA descriptor which
is passed throughreturned from step 3, add a callback and then submit to the dma engineDMA device via the dma channel object as private data (see <linux_root>/include/linux/dma/xilinx_dma.h).
/*
DMA Engine interface
Start the DMA write operation
Terminate DMA write operation when frame processing deemed complete by client
/* Abstract
V4L2 Client Code Example */
#ifdef CONFIG_XILINX_FRMBUF

struct xilinx_xdma_config dma_config;
/*Consumed by frmbuf dma driver, if present*/
dma_config.fourcc
dma_chan *frmbuf_dma = dma->format.pixelformat;
dma_config.type
to_frmbuf_dma_chan(xdev);
struct dma_interleaved_template dma_tmplt;
dma_addr_t addr
= XDMA_V4L2;
dma->dma->private
vb2_dma_contig_plane_dma_addr(vb2_buffer_ptr, 0);
u32 flags
= &dma_config;
#endif
Technical Reference Designs
Coming soon
Insert your code here.
Related Links
Title 1 & Link 1
Title 1 & Link
DMA_PREP_INTERRUPT | DMA_CTRL_ACK;
/* Step
1– Configure the dma channel to write out packed RGB */
xilinx_xdma_v4l2_config(frmbuf_dma, XVIP_VF_RBG);
/* Step 2 – Describe the buffer attributes for a 1080p frame */
dma_tmplt.dir = DMA_DEV_TO_MEM;
dma_tmplt.src_sgl = false;
dma_tmplt.dst_sgl = true;
dma_tmplt.dst_start = addr;
dma_tmplt.frame_size = 1; /* single plane pixel format */
dma_tmplt.numf = 1080; /* 1920x1080 frame */
dma_tmplt.sgl[0].size = 1080;
dma_tmplt.sgl[0].icg = 0;
/* Step 3 – Submit the buffer description to the dma channel */
desc = dmaengine_prep_interleaved_dma(frmbuf_dma, &dma_tmplt, flags);
desc->callback = dma_complete;
desc->callback_param = buf;
/* Step 4 – Submit the returned and updated descriptor to the dma channel */
dmaengine_submit(desc);
/* Step 5 – Start dma to memory operation */
dma_async_issue_pending(frmbuf_dma);
/* Step 6 – Halt DMA when required frame processing completed */
dmaengine_terminate_all(frmbuf_dma);

Video Framebuffer Write

$
0
0
...
/* Step 6 – Halt DMA when required frame processing completed */
dmaengine_terminate_all(frmbuf_dma);
DMA Interleaved Template Requirements
The Video Framebuffer IP supports two dma address pointers for semi-planar formats: one for luma and one for chroma. As such, data for the two planes need to be strictly contiguous which permits for alignment of plane data within a larger buffer. However, all frame data (luma and chroma) must be contained within a contiguous frame buffer and luma plane data should be arranged to come before chroma data. Note that this is not a limitation imposed by the IP but by the driver at this moment. When preparing a struct dma_interleaved_template instance to describe a semi-planar format, the following members must be filled out as follows:
linux/dmaengine.h:
struct dma_interleaved_template:
dst_start = <physical address from which to start reading frame data (any offsets should be added to this value)>
src_sgl = false
dst_sgl = true
numf = <height of frame in pixels; height of luma frame for semi-planar formats>
frame_size = < 1 or 2 depending on whether this is describing a packed or semi-planar format>
sgl = <see struct data_chunk below>
struct data_chunk:
sgl[0].size = <number of bytes devoted to image data for a row>
sgl[0].icg = < number of non-data bytes within a row of image data; padding>
sgl[0].dst_sgl = <the offset in bytes between the end of luma frame data to the start of chroma plane data; only needed for semi-planar formats>
Below is a code example for semi-planar YUV 422 (i.e. NV16) demonstrating how steps 1 and 2 of the above code snippet change in such a case:
/* Step 1 – Configure the dma channel to write out semi-planar YUV 422 */
xilinx_xdma_v4l2_config(frmbuf_dma, V4L2_PIX_FMT_NV16M);
/* Step 2 – Describe the buffer attributes for a 1080p frame */
dma_tmplt.dir = DMA_DEV_TO_MEM;
dma_tmplt.src_sgl = false;
dma_tmplt.dst_sgl = true;
dma_tmplt.dst_start = luma_addr;
dma_tmplt.frame_size = 2; /* two plane pixel format */
dma_tmplt.numf = 1080; /* height of luma frame */
dma_tmplt.sgl[0].size = 1080;
dma_tmplt.sgl[0].icg = 0;
frame_height = dma_tmplt.numf;
stride = dma_tmplt.sgl[0].size + dma_tmplt.sgl[0].icg;
dma_tmplt.sql[0].dst_icg = chroma_addr – luma_addr – (frame_height * stride);
Driver Operation
The Framebuffer driver manages buffer descriptors in software keeping them in one of four possible states in the following order:
pending
staged
active
done
When a DMA client calls dma_commit(), the buffer descriptor is placed in the driver’s “pending” queue. Multiple buffers can be queued in this manner by the DMA client before proceeding to the next step (see step 4 of Interfacing with the Video Framebuffer Driver from DMA Clients).
When dma_async_issue_pending() is called (step 5), the driver begins processing all queued buffers on the “pending” list. A buffer is plucked from the pending list and then stored as “staged”. At this moment, driver programs the registers with data provided within the “staged” buffer descriptor. During normal processing (i.e. all frames except the first frame*), these values will not become active until the currently processed frame completes. As such, there is a one-frame delay between programming and the actual writing data to memory. Hence the term “staged” to describe this part of the buffer lifecycle.
When the currently active frame completed, the buffer descriptor is classified as “active” in the driver. At this point, a new descriptor is plucked from the pending list and this new buffer is marked as “staged” with its values programmed into the IP registers as described earlier. The buffer marked “active” represents the data currently being written to memory. Other than being held in the “active” state, no other action is taken with the buffer.
When the active frame completes, it is moved to the “done” list. The driver utilizes a tasklet which is called at the end of the frame interrupt handler. The tasklet will process any buffer descriptors on the done list by removing them from the list and calling any callback the client has linked to the descriptor.
This completes the lifecycle of a buffer descriptor. As can be seen, with four possible states, it is best to allocate at least four buffers to maintain consistent frame processing. Fewer buffers will result in gaps within the pipeline and result in frame data within a given buffer being overwritten one or more times (depending on how few buffers are queued and the number of resulting gaps in the driver’s buffer pipeline).
* Note: normally, registers programmed while the IP is running will not take effect until the next frame. The very first frame, however, is an exception: the IP is not yet running and, as such, the values take effect immediately. Nevertheless, there is no additional special treatment given the first frame buffer. As such, it will be written to, in effect, twice.

Video Framebuffer Write

$
0
0
...
=
Overview
...
the AXI4-interface.
Location
The driver is currently located in a special branch of the standard Xilinx Linux kernel:<tbd>

Video Framebuffer Write

$
0
0
= {under.jpg}
=

{under.jpg}
=

Overview
Video Framebuffer Write IP cores are designed for video applications requiring frame buffers and is designed for high-bandwidth access between the AXI4-Stream video interface and the AXI4-interface.
...
The driver is currently located in a special branch of the standard Xilinx Linux kernel:<tbd>
Supported IP Features
...
which verification
within the context of the listed reference designs has been performed (see below):
...
YUV 4:2:0
Memory

Memory
Video Format
...
Y8, Y10
Programmable

Programmable
memory video format
Support

Support
for 8-bit
...
memory interface
Resolutions up to 3840x2160
Unsupported IP Features
...
{kernek_config.png}
Device Tree Configuration
ComprehensiveComplete documentation regardingon the device tree configurationrequirements may be
found:
<linux_root>/Documentation/devicetree/bindings/dma/xilinx/xilinx_frmbuf.txt
found in the Linux source located at <linux_root>/Documentation/devicetree/bindings/dma/xilinx/xilinx_frmbuf.txt
Below is
...
configured with
32-bit
32-bit wide DMA
...
RGBX8 memory
formats:
Example:
formats:
v_frmbuf_rd_0: v_frmbuf_rd@80000000 {
#dma-cells = <1>;
...
xlnx,vid-formats = "bgr888","xbgr8888";
};
...
DMA Clients
The

The
Linux driver
...
(see <linux_root>/include/linux/dma/xilinx_frmbuf.h).
The general steps for preparing DMA to write to a specific memory buffer:
Using the Video Framebuffer API, configure the DMA device with the expected memory format for write
...
When the active frame completes, it is moved to the “done” list. The driver utilizes a tasklet which is called at the end of the frame interrupt handler. The tasklet will process any buffer descriptors on the done list by removing them from the list and calling any callback the client has linked to the descriptor.
This completes the lifecycle of a buffer descriptor. As can be seen, with four possible states, it is best to allocate at least four buffers to maintain consistent frame processing. Fewer buffers will result in gaps within the pipeline and result in frame data within a given buffer being overwritten one or more times (depending on how few buffers are queued and the number of resulting gaps in the driver’s buffer pipeline).
* Note:Note: normally, registers
...
effect, twice.

Video Framebuffer Write

$
0
0
...
linux/dmaengine.h:
struct dma_interleaved_template:
...
to this value)>value)
src_sgl = false
dst_sgl = true
...
sgl[0].size = <number of bytes devoted to image data for a row>
sgl[0].icg = < number of non-data bytes within a row of image data; padding>
...
semi-planar formats>
Below is a code example for semi-planar YUV 422 (i.e. NV16) demonstrating how steps 1 and 2 of the above code snippet change in such a case:
/* Step 1 – Configure the dma channel to write out semi-planar YUV 422 */
...
When a DMA client calls dma_commit(), the buffer descriptor is placed in the driver’s “pending” queue. Multiple buffers can be queued in this manner by the DMA client before proceeding to the next step (see step 4 of Interfacing with the Video Framebuffer Driver from DMA Clients).
When dma_async_issue_pending() is called (step 5), the driver begins processing all queued buffers on the “pending” list. A buffer is plucked from the pending list and then stored as “staged”. At this moment, driver programs the registers with data provided within the “staged” buffer descriptor. During normal processing (i.e. all frames except the first frame*), these values will not become active until the currently processed frame completes. As such, there is a one-frame delay between programming and the actual writing data to memory. Hence the term “staged” to describe this part of the buffer lifecycle.
...
with the buffer.buffer
When the
...
the descriptor.
This completes the lifecycle of a buffer descriptor. As can be seen, with four possible states, it is best to allocate at least four buffers to maintain consistent frame processing. Fewer buffers will result in gaps within the pipeline and result in frame data within a given buffer being overwritten one or more times (depending on how few buffers are queued and the number of resulting gaps in the driver’s buffer pipeline).
Note: normally, registers programmed while the IP is running will not take effect until the next frame. The very first frame, however, is an exception: the IP is not yet running and, as such, the values take effect immediately. Nevertheless, there is no additional special treatment given the first frame buffer. As such, it will be written to, in effect, twice.

Video Framebuffer Write

$
0
0

Escalation.jpg

Healthybit.jpg

Zynq UltraScale Plus Restart solution

$
0
0
...
Default Scheme
Default escalation scheme, checks for the successful pm_system_shutdown call from ATF for APU only restart; failure of which will trigger System level reset. System level reset here means PS only reset if PL is present otherwise System restart if PL is not present.
Following flow chart showsdiagram illustrate the successful recovery; i.e Escalation is NOT needed.
<todo>
Following
flow chart shows an unsuccessful recovery; i.e. Escalation is needed.
<todo>
of the control in case of default escalation scheme
{Escalation.jpg}

Healthy Bit Scheme
Default scheme doesn’t guarantee the successful reboot of the system, it just guarantees the successful role of ATF during the recovery to idle the CPU. But if the boot stuck elsewhere, like fsbl, u-boot, Linux init state; then PMU firmware cannot determine if the last boot was successful or not and the current WDT expiry should be treated as first expiry or escalation.
...
To enable Healthy Bit based escalation scheme, PMU firmware should be built with following flag
CHECK_HEALTHY_BOOT
Following diagram illustrate the flow chart showsof the successful recovery (with Healthy bit scheme); i.e Escalation is NOT needed.
<todo>
Following flow chart shows an unsuccessful recovery (with
control in case of Healthy bit scheme); i.e. Escalation is needed.
<todo>
escalation scheme
{Healthybit.jpg}

Modifying Escalation Scheme
To modify the behavior of the escalation scheme one should modify the code in XPfw_RecoveryHandler function in xpfw_restart.c file.

Booting via Serial ATA (SATA) on ZCU102 Evaluation Platform

$
0
0
This wiki page outlines the general workflow required to configure the ZCU102 evaluation platform to boot via the serial ATA (SATA) interface available on the Zynq UltraScale+ MPSoC device. In general, these steps follow those outlined on the main landing page of the Xilinx wiki. Where needed, alterations to the workflow are noted.
...
future releases. These steps have been tested on ZCU102 - REV1.0 Prod-Silicon Board, Rev1.0 ES2 Board, RevD2 Prod Board.
SATA is enabled by default in Vivado 2017.1 Board files. Same holds true for the Default ZCU102 Board Template HDF used in Petalinux 2017.1 and SDK 2017.1.
Build Images using PetaLinux 2017.1
Viewing all 11776 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>