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

Zynq UltraScale Plus MPSoC - PL Temperature and Voltage Monitor

January 7, 2018, 10:10 pm
$
0
0
...
Application creation steps
Create FSBL application either for A53 or for R5 processor
...
PMU Firmware applicationapplication. This creates a new custom module in PMU Firmware which initializes sysmon and monitors PL temperature and voltages periodically in continuous sequencer cycling mode. Please refer to "Custom Module Usage" section in chapter 10 in Zynq UltraScale+ MPSoC Software Developer Guide for reference
Enable scheduler module by defining ENABLE_SCHEDULER macro and rebuild the PMU Firmware application
Steps to create boot image
↧
Search

FSBL

January 7, 2018, 10:24 pm
$
0
0
...
A secondary boot device can be specified in the bif file as [boot_device] qspi24. This implies that FSBL would be loaded from the primary boot device but all other partitions will be loaded from the secondary boot device qspi24. Secondary boot requires and two bif files and hence two boot images. The first bif contains the partitions loaded by BootRom and also the “[boot_device] qspi24“statement specifying the secondary boot mode. The second bif file contains the FSBL partition followed by all the partitions to be loaded by FSBL.
"bootgen -bif_help boot_device" will list all the secondary boot options.
What are the peripherals/IPs required for FSBL
CSUDMA, ADMA_0 and any one instance of IPI are required IPs for FSBL. In addition, for ZCU102 and ZCU106 boards, I2C0 is needed for board-specific configuration done in FSBL. Hence these IPs are required in design and also should be not isolated from the processor for which FSBL is being created.
Related Links
PMU Firmware : http://www.wiki.xilinx.com/PMU+Firmware
1) XFSBL_PL_PWRUP_WAIT_MICROSEC macro added to provide wait time for PL to power up. The default value is zero but customers can set it as per their requirements.
csudma, amda_0 and any one instance of ipi are required IPs for FSBL.
# In addition, for ZCU102 and ZCU106, i2c0 is needed for board-specific
# configuration done in FSBL. Hence, print the required (for FSBL) IPs
# which are in design but are isolated from the selected processor.
↧
↧

Zynq UltraScale＋ MPSoC VCU 4k60 Design Example with HDMI Tx and Rx

January 8, 2018, 3:29 am
$
0
0
...
The reference design has been tested successfully with the following user-supplied components.
HDMI Monitor:
Make/Model
Resolutions
LG|| Make/Model || Resolutions ||
|| LG 27UD88
3840x2160 || 3840x2160 (30Hz)
Philips ||
|| Philips BDM4350UC
3840 || 3840 x 2160 @ 60Hz ||
Hardware and Software build flow
The following tutorials assume that the $TechTip_HOME environment variable has been set as below.
↧

Zynq UltraScale＋ MPSoC VCU 4k60 Design Example with HDMI Tx and Rx

January 8, 2018, 3:31 am
$
0
0
↧

Zynq UltraScale＋ MPSoC VCU 4k60 Design Example with HDMI Tx and Rx

January 8, 2018, 3:32 am
$
0
0
...
The reference design has been tested successfully with the following user-supplied components.
HDMI Monitor:
|| Make/Model || Resolutions ||
|| LGMake/Model
Resolutions
LG 27UD88 || 3840x2160
3840x2160 (30Hz) ||
|| Philips
Philips BDM4350UC || 3840
3840 x 2160 @ 60Hz ||
Hardware and Software build flow
The following tutorials assume that the $TechTip_HOME environment variable has been set as below.
↧
↧

Zynq UltraScale＋ MPSoC VCU 4k60 Design Example with HDMI Tx and Rx

January 8, 2018, 3:47 am
$
0
0
↧

Zynq UltraScale＋ MPSoC VCU 4k60 Design Example with HDMI Tx and Rx

January 8, 2018, 3:49 am
$
0
0
...
% petalinux-build
Create a boot image (BOOT.BIN) including FSBL, ATF, bitstream and u-boot.
% cd images<span class="sy0">**/**</span>linuximages/linux
% petalinux-package --boot --bif=vcu.bif
Copy the generated boot image and Linux image to the SD card directory.
↧

Zynq UltraScale＋ MPSoC VCU 4k60 Design Example with HDMI Tx and Rx

January 8, 2018, 3:50 am
$
0
0
↧
Search

Zynq UltraScale＋ MPSoC VCU 4k60 Design Example with HDMI Tx and Rx

January 8, 2018, 5:20 am
$
0
0
...
Figure below shows the ZCU106 board with interfaces highlighted.
{boardsetup.png}
SettingPreparing SD card for Board1**
Copy BOOT.BIN, image.ub which are prepared above to SDCard.
Copy the xmedia-ctl binary from the design file directory Design_files/prebuilt_binaries/Board1 to SD card .
Mark this as “Board1 SDcard”.
Copy following scripts from Design_files/prebuilt_binaries/Board1 to “Board1 SDCard”
configure_qos.sh
hdmi_config_4k_new.sh
receive_data.sh
send_data.sh
Preparing SD card for Board2
Copy BOOT.BIN, image.ub which are prepared above to SDCard.
Copy the xmedia-ctl binary from the design file directory Design_files/prebuilt_binaries/Board2 to SD card .
Mark this as “Board2 SDcard”.
Copy following scripts from Design_files/prebuilt_binaries/Board2 to “Board2 SDCard”
configure_qos.sh
hdmi_config_4k_new.sh
receive_data.sh
send_data.sh
Preparing USB Sticks
Copy following video files from Design_files/video_files folder to both the USB sticks
bbb_sunflower_1080p_60fps_normal.mp4
snake.mp4
Setting up the ZCU106 BoardBoards
Connect the Micro USB cable into the ZCU106 Board Micro USB port J83, and the other end into an open USB port on the host PC. This cable is used for UART over USB communication.
Insert the SD card with the images copied into the SD card slot J100.
...
Connect one end of HDMI cable to board’s P7 stacked HDMI connector (lower port) and another end to HDMI source.
Connect one end of HDMI cable to board’s P7 stacked HDMI connector (upper port) and another end to HDMI monitor.
Connect one end of Ethernet cable to Board1’s J67 connector, and connect the other end of Ethernet cable to Board2’s J67 connector
Set up a terminal session between a PC COM port and the serial port on the evaluation board (See the COM Port section for more details).
Switch ON SW1 to power the ZCU106 board.
FigureFollow the same above steps for setting up the second ZCU106 board.But insert the" Board2 SD card" in the second board SD card slot.
Connect one end of Ethernet cable to Board2’s J67 connector, and connect the other end of Ethernet cable to Board1’s J67 connector.
Figure below shows the ZCU106 boardboards connections.
{http://www.wiki.xilinx.com/site/embedthumbnail/placeholder?w=640&h=503} http://www.wiki.xilinx.com/file/view/vcu_trd_17p3_fig24.jpg/623733495/640x503/vcu_trd_17p3_fig24.jpg
It takes about a minute for Linux to boot. User may miss the boot sequence while the terminal session is being configured.
...
Close the Device Manager by clicking the red X in the upper right corner of the window.
Launch any Terminal application like Tera term to view the serial messages
...
the USB-to-serial bridge.bridge to both the boards
Set the COM port to 115200 Baud rate, 8, none, 1 –Set COM port.
Power ON both the boardboards which has
...
on board.
Copy the above built images on to a SD card.
Insert your code here.
Related Links
Title 1 & Link 1
Title 1 & Link 1
After linux is bootsup , teraterm screen looks like as shown below.
figure :
export TechTip_HOME=</path/to/downloaded/zipfile>/Design_files
Execution on Boards:
Run below command on both the boards
# cd /media/card/
Run below script on both the boards
# ./receive_data.sh &
Run below script on both the boards
# ./send_data.sh &
NOTE:
Restart the board and follow the execution steps.
If any of the board is not receiving the data OR not displaying the output
Check whether the HDMI-TX is locked to 4Kp60 (Blue screen should be appeared on screen)
Kill the processes of receive_data.sh and execute the script again, then the blue screen gets displayed.
Check whether the HDMI-RX is locked to 4Kp60, using below command
# media-ctl-d /dev/media1 -p
Observations:
What you will observe is
SMP Linux boots up.
On ZCU106Board1
HDMI video capture (4Kp60) data will be encoded by VCU H.265 encoder and the encoded data is transmitted over Ethernet from Board1 to Board2.
Receives the video data from Board2, decodes and displays on 4K monitor connected to HDMI-TX on Board1.
On ZCU106Board2
HDMI video capture (4Kp60) data will be encoded by VCU H.265 encoder and the encoded data is transmitted over Ethernet from Board2 to Board1.
Receives the video data from Board1, decodes and displays on 4K monitor connected to HDMI-TX on Board2.

↧
↧

PS and PL based Ethernet in Zynq MPSoC

January 8, 2018, 6:33 am
$
0
0
...
Device Drivers> DMA Engine Support > <> Xilinx AXI DMAS Engine
Save the changes and exit.
2.5.1.4 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' in your petalinux project,
For PL ETHERNET 1G 1000BASE-X and PL ETHERNET 1G SGMII, make the following modifications to 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.
bash> petalinux-build -v
2.5.1.62.5.1.5 Create Zynq-mp
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.72.5.1.6 SD Images
SD Deployable binaries:-
a) BOOT.bin
↧

pm_cfg_obj.c

January 8, 2018, 3:01 pm
↧

Isolation+Configuration.svg

January 8, 2018, 3:10 pm
↧

Isolation+Configuration.png

January 8, 2018, 3:12 pm
↧
↧

ZU＋ Example - Deep Sleep with Periodic Wake-up

January 8, 2018, 3:18 pm
$
0
0
...
{rpu_deep_sleep_with_periodic_wakeup.c}
Build application elf.
Configuration Object -
The sub-system configuration is captured in a Configuration Object, which is generated by the Vivado and PetaLinux toolchain. The Configuration Object contains the following information:
The PM Masters that are present in the system (APU and/or RPU). Any PM Master not specified in the Configuration Object will be ignored by the PMU.
Configurable permissions for each PM Master, such as:
o Which PM Master can use which PM Slave? (A PM Master can use all the PM Slaves that belong in the same sub-system.)
o Access to MMIO address regions.
o Access to peripheral reset lines.
• Pre-allocated PM Slaves. The PM Master can use these PM Slaves without requesting for them first. These PM Slaves are needed by the PM Master in order to boot.
The toolchain makes sure that the APU can access the L2 cache and DDR banks without first requesting for them. The same is true for the RPU accessing all the TCM banks.
During boot, the Configuration Object is passed from the FSBL to the PMU firmware.
Configuration Object Generation
The PMF Configuration Object is generated as follows:
The user specifies their custom PMF Configuration using the PCW tool.
PCW generates the HDF file.
At build time, the HDF Parser parses the HDF file and insert the configuration object into the FSBL code.
{Isolation+Configuration.png}
Default Configuration - By default, there are 3 sub-systems, and each has one PM Master: APU, R5-0 and R5-1. All three sub-systems contain all the PM Slaves (meaning that the sub-systems completely overlap each other.)
This is the default configuration generated by PCW when the “Enable Isolation” box is unchecked.
Note that the default PetaLinux kernel is “PM-capable”, but R5-0 and R5-1 must be also running “PM-capable” applications, or be powered down.
Otherwise, the PMU will not power down any PM Slaves.
Note that it *is* possible to create a configuration that would not allow the processors to boot and run. Novice users should start with the APU-only configuration shown above and customize it as they go.
RPU Lock-step vs. Split Mode
The toolchain infers the RPU run modes from the PCW Isolation Configuration as follows:
• No RPU present in any subsystem: Config Object contains no RPU.
• Only R5-0 present in subsystem(s): Config Object contains R5-0 running in lock-step mode.
• Both R5-0 and R5-1 in subsystems: Config Object contains R5-0 and R5-1 running in split mode.
• Only R5-1 present in subsystem(s): Config Object contains R5-1 running in split mode.
The default Configuration Object contains two RPU PM Masters: R5-0 and R5-1, and the PMU assumes that the R5-0 and R5-1 are running in split mode.
However, the boot image actually determines whether the RPU runs in lock-step or split mode at boot time.
The RPU run mode from the boot image must match the number of RPU PM Masters in the Configuration Object.
Otherwise, the power management framework will not work properly.
Configuration Object file Generated by PetaLinux tool chain and Vivado is attached below.
{pm_cfg_obj.c}
Detailed Explanation of Configuration Object (pm_cfg_obj.c)-
Configuration Object mainly consists of 7 main sections which are as follows - 1) Master Section 2) Slave Section 3) Prealloc Section 4)Power Section 5) Reset Section 6) Shutdown Section and 7) Set Section.
Each sections has assigned a section ID.
First section which is nothing but Master section which consists of 3 Masters which are 1) APU 2) RPU0 and 3) RPU1.These 3 Masters creates 3 subsystems.
Each of these masters have there IPI mask, Suspend timeout, Suspend permission mask and wake up permission mask.
Second section is Slave section which includes Memory Slaves such as On Chip Memory Bank(OCM), Tightly coupled Memory(TCM), Double Data Rate Memory (DDR).
Various Protocol Slaves such as I2C, SPI,UART, GPIO, CAN and some other Slaves includes Real Time Clock(RTC), Direct Memory Access Controller (DMA).
Each Slave has shareable flag which indicates that slave shares a node with Master. Also each slave has inter-processor interrupt Mask i.e. IPI Mask.
Third section is Prealloc Section means pre-allocated slave resources for a particular Master.
So each master have pre-allocated slave resources with current and default requirements also it uses a flag to indicated that Master is using that slave or that slave already allocated to particular Master.
PM_CAP_ACCESS and PM_CAP_CONTEXT are the capabilities for RAM which is defined in pm_defs.h which is present in fsbl_bsp.
Fourth section is Power section which includes the list of Power Node such as APU, RPU,FPD and LPD. Each of these node has force power down permissions to power down the other node using Inter-Proessor Interrupts.
Fifth section is a Reset section which has total 116 slaves which can be reset if APU and RPU both are not using that Slave. This is nothing but Resetting of unused Slave having particular Reset ID.
Reset ID such as XILPM_RESET_PCIE_CFG are defined in pm_defs.h which is present in fsbl_bsp.
Sixth section is Shutdown section. This section will be used if you want to Shutdown Slave Node.
Seventh section is set section. This section is nothing but setting required Slave Node depending on requirements having Particular Set ID.
Note : For the set section you can refer Reset section.
Steps to run demo example (APU running Linux) using SD boot mode
Create RPU application rpu.elf from SDK as described in above section.
...
Related Links
More design examples
Default Configuration
By default, there are 3 sub-systems, and each has one PM Master: APU, R5-0 and R5-1. All three sub-systems contain all the PM Slaves (meaning that the sub-systems completely overlap each other.) This is the default configuration generated by PCW when the “Enable Isolation” box is unchecked. Note that the default PetaLinux kernel is “PM-capable”, but R5-0 and R5-1 must be also running “PM-capable” applications, or be powered down. Otherwise, the PMU will not power down any PM Slaves.
Note that it *is* possible to create a configuration that would not allow the processors to boot and run. Novice users should start with the APU-only configuration shown above and customize it as they go.
RPU Lock-step vs. Split Mode
The toolchain infers the RPU run modes from the PCW Isolation Configuration as follows:
• No RPU present in any subsystem: Config Object contains no RPU.
• Only R5-0 present in subsystem(s): Config Object contains R5-0 running in lock-step mode.
• Both R5-0 and R5-1 in subsystems: Config Object contains R5-0 and R5-1 running in split mode.
• Only R5-1 present in subsystem(s): Config Object contains R5-1 running in split mode.
The default Configuration Object contains two RPU PM Masters: R5-0 and R5-1, and the PMU assumes that the R5-0 and R5-1 are running in split mode.
However, the boot image actually determines whether the RPU runs in lock-step or split mode at boot time.
The RPU run mode from the boot image must match the number of RPU PM Masters in the Configuration Object.
Otherwise, the power management framework will not work properly.
↧

ZU＋ Example - Deep Sleep with Periodic Wake-up

January 8, 2018, 3:21 pm
$
0
0
↧
Search

ZU＋ Example - Deep Sleep with Periodic Wake-up

January 8, 2018, 3:24 pm
$
0
0
...
{rpu_deep_sleep_with_periodic_wakeup.c}
Build application elf.
...
Object -
The The sub-system configuration
The PM Masters that are present in the system (APU and/or RPU). Any PM Master not specified in the Configuration Object will be ignored by the PMU.
Configurable permissions for each PM Master, such as:
↧

ZU＋ Example - Deep Sleep with Periodic Wake-up

January 8, 2018, 4:15 pm
$
0
0
...
Start with an empty RPU application (like the Hello World example here).
Configure the RPU to run from TCM (see above.)
(Default{tcm_sections.png}
(Default HDF has
...
and other sections
sections are in BTCM) {tcm_sections.png}
Replace the main.c with this file:
{rpu_deep_sleep_with_periodic_wakeup.c}
...
The toolchain makes sure that the APU can access the L2 cache and DDR banks without first requesting for them. The same is true for the RPU accessing all the TCM banks.
During boot, the Configuration Object is passed from the FSBL to the PMU firmware.
...
Object Generation {Isolation+Configuration.png}
The PMF Configuration Object is generated as follows:
The user specifies their custom PMF Configuration using the PCW tool.
PCW generates the HDF file.
At build time, the HDF Parser parses the HDF file and insert the configuration object into the FSBL code.
{Isolation+Configuration.png}
Default Configuration - By default, there are 3 sub-systems, and each has one PM Master: APU, R5-0 and R5-1. All three sub-systems contain all the PM Slaves (meaning that the sub-systems completely overlap each other.)
This is the default configuration generated by PCW when the “Enable Isolation” box is unchecked.
↧
↧

ZU＋ Example - Deep Sleep with Periodic Wake-up

January 8, 2018, 5:26 pm
$
0
0
...
{rpu_deep_sleep_with_periodic_wakeup.c}
Build application elf.
Configuration Object - The sub-system configuration is captured in a Configuration Object, which is generated by the Vivado and PetaLinux toolchain. The Configuration Object contains the following information:
The PM Masters that are present in the system (APU and/or RPU). Any PM Master not specified in the Configuration Object will be ignored by the PMU.
Configurable permissions for each PM Master, such as:
o Which PM Master can use which PM Slave? (A PM Master can use all the PM Slaves that belong in the same sub-system.)
o Access to MMIO address regions.
o Access to peripheral reset lines.
• Pre-allocated PM Slaves. The PM Master can use these PM Slaves without requesting for them first. These PM Slaves are needed by the PM Master in order to boot.
The toolchain makes sure that the APU can access the L2 cache and DDR banks without first requesting for them. The same is true for the RPU accessing all the TCM banks.
During boot, the Configuration Object is passed from the FSBL to the PMU firmware.
Configuration Object Generation {Isolation+Configuration.png}
The PMF Configuration Object is generated as follows:
The user specifies their custom PMF Configuration using the PCW tool.
PCW generates the HDF file.
At build time, the HDF Parser parses the HDF file and insert the configuration object into the FSBL code.
Default Configuration - By default, there are 3 sub-systems, and each has one PM Master: APU, R5-0 and R5-1. All three sub-systems contain all the PM Slaves (meaning that the sub-systems completely overlap each other.)
This is the default configuration generated by PCW when the “Enable Isolation” box is unchecked.
Note that the default PetaLinux kernel is “PM-capable”, but R5-0 and R5-1 must be also running “PM-capable” applications, or be powered down.
Otherwise, the PMU will not power down any PM Slaves.
Note that it *is* possible to create a configuration that would not allow the processors to boot and run. Novice users should start with the APU-only configuration shown above and customize it as they go.
RPU Lock-step vs. Split Mode
The toolchain infers the RPU run modes from the PCW Isolation Configuration as follows:
• No RPU present in any subsystem: Config Object contains no RPU.
• Only R5-0 present in subsystem(s): Config Object contains R5-0 running in lock-step mode.
• Both R5-0 and R5-1 in subsystems: Config Object contains R5-0 and R5-1 running in split mode.
• Only R5-1 present in subsystem(s): Config Object contains R5-1 running in split mode.
The default Configuration Object contains two RPU PM Masters: R5-0 and R5-1, and the PMU assumes that the R5-0 and R5-1 are running in split mode.
However, the boot image actually determines whether the RPU runs in lock-step or split mode at boot time.
The RPU run mode from the boot image must match the number of RPU PM Masters in the Configuration Object.
Otherwise, the power management framework will not work properly.
Configuration Object file Generated by PetaLinux tool chain and Vivado is attached below.
{pm_cfg_obj.c}
Masters Section
1) APU
2) R5-0
3) R5-1
Slaves Section
1) OCM Bank 0, 1, 2 and 3
2) TCM Bank 0 - A and B
3) TCM Bank 1 - A and B
4) L2 Cache
5) GPU PP0 and PP1
6) USB0 and USB1
7) TTC 0, 1,2 and 3
8) SATA
9) ETH 0, 1,2 and 3
10) UART0 and UART1
11) SPI0 and SPI1
12) I2C0 and I2C1
13) SD0 and SD1
14) DP
15) GDMA and ADMA
16) NAND
17) QSPI
18) GPIO
19) CAN0 and CAN1
20) DDR
21) PCIE
22) VCU
23) RTC
24) PL
Subsystems -
Linux Subsystem
Master - APU
Slaves - DDR,
L2 Cache,
OCM Bank 0, 1, 2 and 3,
I2C0,
I2C1,
SD1,
QSPI,
PL
R5-0 Subsystem
Master - RPU0
Slaves - TCM Bank 0 - A
TCM Bank 0 - B
R5-1 Subsystem
Master - RPU1
Slaves - TCM Bank 1 - A
TCM Bank 1 - B
Power Section
APU,
RPU,
FPD,
PLD
Detailed Explanation of Configuration Object (pm_cfg_obj.c)-
Configuration Object mainly consists of 7 main sections which are as follows - 1) Master Section 2) Slave Section 3) Prealloc Section 4)Power Section 5) Reset Section 6) Shutdown Section and 7) Set Section.
...
The RPU run mode from the boot image must match the number of RPU PM Masters in the Configuration Object.
Otherwise, the power management framework will not work properly.
OCM_BANK_0,
↧

xpfw_mod_plsysmon.c

January 8, 2018, 11:38 pm
↧

xpfw_mod_plsysmon.c

January 9, 2018, 3:27 am
↧
Viewing all 11776 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>