- 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 are 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.