FAQs - 2024.1 English

Porting Guide for embeddedsw Components System Device Tree Based Build Flow (UG1647)

Document ID
UG1647
Release Date
2024-06-21
Version
2024.1 English
Why is AMD shifting to a system device tree based flow?
The earlier approach of using .mdd, .mld, and .mss files along with the .xsa as a handoff file involved AMD proprietary tools that were required to build the software stack. This approach only uses open source file formats and tools once the handoff file is generated by the hardware persona.
How is the system device tree different than the Linux device tree?
The Linux device tree contains only the Linux/APU (or MicroBlazeâ„¢ processor) related peripheral information at a time. The system device tree contains the whole system information (includes information related to all processors such as APU, RPU, MicroBlaze, and PMC)
How to check if the component is a driver, library, or an application?
The type key in YAML determines this. Available options for this key are: driver, library, apps, and os.
How is the driver probed or picked while building libxil?
Lopper backend checks for a given node compatible against the compatibility specified in the driver YAML file under the properties section. If there is a match, it picks the driver and generates _g.c file in the subsequent process.
How are the _g.c entries and the xparameters generated for drivers?
Lopper backend generates the _g.c entries based on the properties specified in the "required" section of the YAML file. Make sure these entries adhere to the driver config structure order. Refer to Options Available in the "required" Section and Sample YAML for a Driver for more details.
If the config structure entry has a dependency on another node base address, then how to handle it?
The metadata representation for this is <property-name>: phandle. If a property dependent on a child node is available, it reads the reg property of that node and generates its value in this entry; otherwise, it generates zero. Refer to Options Available in the "required" Section and Sample YAML for a Driver for more details.
If the config structure has more than one base address in sequence, then how to add that information in the metadata to generate proper addresses in the config structure?
The metadata representation for the above requirement is reg:<number of entries>. Refer to Options Available in the "required" Section for more details.
If the property mentioned in the required section is not present in the device tree node, then what value is generated in the _g.c file?
Zero (0x0)
How to add multiple configurations for a library?
Addition of <library_name>.cmake and x<library_name>_config.h.in facilitates the library software configuration. Refer to the Src Folder in Libraries section for more information.
How to use platform or a processor specific piece of code?
CMAKE_MACHINE and CMAKE_SYSTEM_PROCESSOR variables inside CMAKE can be used to differentiate a platform or a processor specific piece of code. Refer to CMAKE_MACHINE and CMAKE_SYSTEM_PROCESSOR to know the available values for this CMAKE variable.
Where are the library-related configuration-specific macros located? It is missing in xparameters.h?
Those have been relocated to the <library>_config.h file. Refer to the Src Folder in Libraries section for more information.
How to define dependencies of a library or an application?
The depends and depends_libs keys in a library YAML describes the hardware and software dependency of the library, respectively. Refer Data Folder in Libraries (or under Porting a Template Application) section with CMAKE_MACHINE and CMAKE_SYSTEM_PROCESSOR for more details.
How to define the archiver dependencies of the application?
collect(PROJECT_LIB_DEPS xil) statements in Application CMakeLists define this dependency. This statement means that the application depends on libxil.a.
How is the linker script generated?
An intermediary file named lscript.ld.in kept within the embeddedsw repository is copied into the application source folder. This file and the <Application>Example.cmake generates the final lscript.ld. Refer to Application: Hardware Dependency and Linker Script Generation for more details.
How to set a different stack and heap size for the application that does not fit in the default size?
The linker_constraints key in the application YAML is used to modify the default stack and heap sizes. Refer to Application: Hardware Dependency and Linker Script Generation for more details.