DOCSEARCHbyAlgolia
Submit Docs

Xilinx Embedded Software

repository·master·Indexed 22 days ago

https://github.com/xilinx/embeddedsw

A repository of embedded software components for Xilinx hardware, featuring libmetal, a hardware abstraction layer (HAL) for device access, interrupts, and memory management across Linux userspace, RTOS, and bare-metal environments. Includes the libmetal_xlnx_extension for OpenAMP demos on ZynqMP, RFDC driver BSP creation guides, and utilities for Inter-Processor Interrupt (IPI) configuration and DDR self-refresh management using Xilpm APIs.

Tokens
59.2K
Snippets
70
Records
501
Agent score
78%

What's inside xilinx-embeddedsw

  1. Overview of HDCP Professional Repeater Example

    master

    This example application demonstrates the functionality of a Xilinx HDMI HDCP 2.2 Professional Repeater. It is designed to run on hardware where HDCP is configured as a Repeater.

    Key Features:

    • Implements the HDCP Professional, Revision 2.2 specification.
    • Acts as a Repeater: By default, the HDMI TX transmits the HDMI stream received from the SOURCE (via RX) to the SINK.
    • Color Bar Mode: Can be enabled via a UART menu. When selected, a test pattern generator IP generates a video stream (selectable via UART) which the HDMI TX then transmits to the downstream SINK.
    • Robustness Option: Users can choose not to start colorbar mode when the HDCP Repeater is enabled to make the HDCP authentication process more robust.
    • Dual HDCP Support: If HDCP (1.4, 2.2, or both) is enabled by the hardware, the application supports handling in both HDMI TX and RX, implemented as a Repeater where HDCP TX is driven by the HDCP RX.

    System Flow: SOURCE -> RX (Professional Repeater) -> TX (Professional Repeater) -> SINK.

  2. Overview of FreeRTOS LwIP TCP Server

    master

    The FreeRTOS LwIP TCP Server application implements a TCP server designed to handle TCP clients.

    Key Characteristics:

    • Concurrency: It can connect to any number of clients but can only serve one connection at a time.
    • Lifecycle: Once an IP address is assigned, the server begins listening for client connections.
    • Networking: If LWIP_DHCP is enabled, the board acquires an IP from a DHCP server. If DHCP fails or is disabled, the application defaults to the following static configuration:
      • IP Address: 192.168.1.10
      • Netmask: 255.255.255.0
      • Gateway: 192.168.1.1
      • MAC address: 00:0a:35:00:01:02

  3. Overview of the xilsecure library structure

    master

    The xilsecure library is organized into three main functional directories: server, client, and common. This architecture separates the implementation of cryptographic engines from the interfaces used to access them.

    • server: Contains the server-side interface APIs for cryptographic engines including AES, RSA, ECDSA, and SHA. It is further subdivided into core (platform-agnostic features) and platform-specific directories (e.g., versal, zynqmp, spartanup).
    • client: Contains the client-side interface APIs for interacting with the cryptographic engines (AES, RSA, ECDSA, SHA). It includes a mailbox directory for sending/receiving IPI requests and platform-specific directories.
    • common: Contains APIs shared between the client and the server, including both core features and platform-specific implementations.

  5. Overview of LwIP TCP Perf Server

    master

    The LwIP TCP Perf Server application implements a TCP server designed to work with TCP clients like Iperf 2.0.5 running on a host machine. Once a remote client connects, the server receives data and outputs connection details and data transfer statistics to the serial console.

    Configuration Options

    You can modify the following settings in tcp_perf_server.h:

    • INTERIM_REPORT_INTERVAL: The time interval in seconds for intermediate report displays (default is 5 seconds).
    • TCP_CONN_PORT: The port on which the server listens for client connections.

  6. Overview of the XilTPM library

    master

    The XilTPM library provides services to extend hashes or data to Trusted Platform Module (TPM) Platform Configuration Registers (PCRs).

    Platform Support: This library is strictly applicable only to the following platforms:

    • Versal
    • Versal_2VE_2VM

    If you are working on any other platform, this library is not applicable and should be ignored.

  7. Overview of EmacLite Example Applications

    master

    The EmacLite driver provides several example modes for testing transmission and reception of Ethernet frames:

    Interrupt-Driven Examples

    These examples use interrupts and callbacks for frame handling:

    • xemaclite_internal_loopback_example.c: Uses internal loopback with an incrementing payload (1 to 1500 bytes, excluding Ethernet Header and FCS).
    • xemaclite_intr_example.c: Uses interrupts and callbacks to transmit/receive a fixed 1000-byte payload.
    • xemaclite_phy_loopback_example.c: Uses MAC loopback in the PHY device with an incrementing payload (1 to 1500 bytes). Note: This requires the MDIO interface to be configured in the EmacLite core.

    Polled-Mode Examples

    These examples use polling instead of interrupts:

    • xemaclite_polled_example.c: Transmits/receives a fixed 1000-byte payload.
    • xemaclite_ping_req_example.c: Generates a ping request for a specified IP address.
    • xemaclite_ping_reply_example.c: Generates a ping reply when receiving a ping request from an external source.

    Other Utilities

    • xemaclite_selftest_example.c: Performs a basic self-test using the EmacLite driver.
    • xemaclite_example.h: A header file defining common data types and prototypes used across multiple examples.
    • xemaclite_example_util.c: Contains utility functions used by the examples.

  8. Understand the FreeRTOS source directory structure

    master

    The FreeRTOS port is organized into three main functional areas:

    1. Core Kernel Components: Located in FreeRTOS/Source/, these files are common to every port and contain the primary kernel logic:

      • list.c: List management.
      • queue.c: Queue management.
      • tasks.c: Task management.
      • croutine.c (Optional): Implements co-routine functionality, typically used only on highly memory-constrained systems.

    2. Hardware/Compiler Specifics: Located in FreeRTOS/Source/Portable/. This directory contains the files required to adapt the kernel to a specific microcontroller or compiler. For detailed instructions on selecting a port, refer to the readme file located within this directory.

    3. API Headers: Located in FreeRTOS/Source/include/. This directory contains the header files required to interface with the real-time kernel.

  9. Understand the SDI example design components

    master

    The SDI example design is composed of several functional layers:

    • Core Logic: xuhdsdi_example.c demonstrates the SDI Rx and Tx Subsystems.
    • User Interface: xsdi_menu.c and xsdi_menu.h implement a Xilinx Menu used to interact with the SDI design.
    • Hardware Abstraction/Platform:
      • platform.c provides low-level driver functions for Uart_16550 initialization and cache management (enabling/disabling).
      • platform.h contains prototypes for cache control.
      • platform_config.h defines IP instances such as the PS Uart.
    • Clock Management: si5324drv.c and si5324drv.h provide low-level driver functions to control the SiliconLabs Si5324 clock generator, specifically for the ZCU106 demo board.