| Age | Commit message (Collapse) | Author |
|---|
|
In arm-trusted-firmware recipe, ATF_CONSOLE_DEFAULT variable has
override and setting this variable value from local.conf and
machine.conf will not be effective during variable pre-expansion values.
Hence use ATF_CONSOLE instead of ATF_CONSOLE_DEFAULT in machine conf
files.
Signed-off-by: Sandeep Gundlupet Raju <sandeep.gundlupet-raju@amd.com>
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
|
|
1. Add missing space to append operation for machine files generated
by gen-machineconf tool.
2. Update all machine conf file using gen-machineconf tool by parsing
latest xsa.
a. Reorder the variables to match the gen-machineconf tool output.
b. Add any missing or new variables.
3. Remove machine overrides for XSCTH_PROC variable.
Signed-off-by: Sandeep Gundlupet Raju <sandeep.gundlupet-raju@amd.com>
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
|
|
Using BOARD variable are deprecated, hence remove it. Machine conf
files using BOARD overrides now will be replaced with machineoverrides.
Signed-off-by: Sandeep Gundlupet Raju <sandeep.gundlupet-raju@amd.com>
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
|
|
1. Update below zynqmp eval board machine conf file using
gen-machineconf tool by parsing respective xsa.
- zcu102-zynqmp
- zcu104-zynqmp
- zcu106-zynqmp
- zcu111-zynqmp
- zcu1275-zynqmp
- zcu1285-zynqmp
- zcu208-zynqmp
- zcu216-zynqmp
2. Move variables which changes based on xsa before required
inclusion file to handle pre-expansion values.
3. Disable U-boot SPL boot and kernel device tree by default.
User has to set explicitly to use it.
4. Use use soc variant based generic machine inclusion
Signed-off-by: Sandeep Gundlupet Raju <sandeep.gundlupet-raju@amd.com>
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
|
|
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
Add the override expected by device-tree and other recipes to each machine.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
|
|
This is the result of automated script (0.9.0) conversion:
oe-core/scripts/contrib/convert-overrides.py .
converting the metadata to use ":" as the override character instead of "_".
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
|
|
Using weaker assingnment for UBOOT_MACHINE to update this value in
petalinux without _forcevariable.
Signed-off-by: Raju Kumar Pothuraju <raju.kumar-pothuraju@xilinx.com>
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
|
|
In order to allow standalone (meta-xilinx-standalone), XSCT
(meta-xilinx-tools), and future items to work in the same way
the recipes have been restructured.
A *-firmware recipe will generate the firmware and stage it to do_deploy.
A *fw recipe will take the deployed version and package it for the Linux
side of things. This allows the firmware generation to be easily extended
without requiring packaging knowledge. Similarly packaging can be
extended for alternative boot/upgrade mechanisms as required.
In all cases, the MACHINE configuration will specify the default way
the components are to be built, along with the names of the item in
the deploy directory.
The PLM/PSM/PMU_IMAGE_NAME is the name for the generated firmware.
PLM/PSM/PMU_DEPLOY_DIR is the path to the constructed firmware. This along
with the IMAGE_NAME above can be used to specify the location of an
externally generated set of firmware.
Addtionally the dependencies for building the plmfw/psmfw/pmufw can be
changed easily using PLM/PSM/PMU_DEPENDS and PLM/PSM/PMU_MCDEPENDS. The
former specifies dependencies in the same multiconfig, while the later
allows the component to require another multiconfig to have finihed.
The system has a referenced default, if multiconfig is enabled it will
automatically use it, otherwise it will try to use the recipe in the
main configuration. (This will fail unless meta-xilinx-tools is available.)
Also two multiconfigs hve been implemented: versal-fw and zynqmp-pmufw
They can be enabled using BBMULITCONFIG += "zynqmp-pmufw" or versal-fw.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
By default the machines should not check and remove declared consoles
that are not available on first boot. It's up to the user to add this
to their build configuration.
The recommended user behavior is:
SERIAL_CONSOLES_CHECK = ${SERIAL_CONSOLES}
but the side effect of this is that if the device configuration changes
after the first boot, the additional devices will not be available.
(Note, this may result in warning messages with getty unable to connect
to certain devices.)
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
Usage of 'SERIAL_CONSOLE' was deprecarted in late 2013. Move to the
using 'SERIAL_CONSOLES', where the format is slightly different.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
PREFERRED_PROVIDER_virtual/kernel and PREFERRED_PROVIDER_virtual/bootloader
are normally set by machine-xilinx-default.inc. Only set these if necessary.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
The machine-xilinx-override is really just an extension to the standard
soc-family.inc file. So rename this, move the include of soc-family.inc
to this file, move the include to the soc includes to each soc file, and
finally adjust the machines to remove machine-xilinx-override as it's no
longer necessary.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
The tune files were really soc configuration files. Tune files should
only specify toolchain flags that affect optimiation and abi.
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
|
|
zynqmp machines
Update UBOOT MACHINE defconfig to xilinx_zynqmp_virt_defconfig instead of using
custom machine specifc defconfigs.
Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com>
|
|
Adding boot.scr to IMAGE_BOOT_FILES so boot.scr is included in the wic
sd card generation, if wic image generation is enabled
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Separating out sample boot.cmd file for the three supported arch (zynq,
zynqmp, versal), Updating devicetree, kernel, ramdisk load addresses for
zynq, and dynamically setting DEVICE_TREE_NAME to either system.dtb or
kernel dtb, depending on if dtg is used or not.
This u-boot-zynq-scr implementation is put in to set the default boot
and boot quicker than having to wait for the distro_bootcmd to cycle to
the correct boot medium. For example, zynq arch has boot_targets set to
"mmc mmc0 qspi usb0 pxe dhcp xilinx" and it takes about 30 seconds to
try the 'xilinx' target which will run the correct bootargs.
To use the boot.scr file, zynqmp boards must have BOOT.bin, Image,
system.dtb, and boot.scr in the boot partition and a rootfs extracted in
the second partition. Zynq boards must have BOOT.bin, uImage,
system.dtb, boot.scr, and uramdisk.image.gz in the boot partition.
(uramdisk.image.gz is the ${IMAGE}.cpio.gz.u-boot in deploy directory)
Adding u-boot-zynq-scr dependency to all zynq and zynqmp machine confs.
Conditionally adding system.dtb to IMAGE_BOOT_FILES for zcu102 to
support boot.scr in qemu flow.
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Set SPL_BINARY with ?= instead of = to allow overwrite for this variable
without using forcevariable. When not using xilinx-bootbin to generate
the boot.bin, this variable should be set to '', to deploy spl boot.bin.
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Bhargava Sreekantappa Gayathri <bhargava.sreekantappa-gayathri@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
This include has a single line which adds the virtual/bootloader to
EXTRA_IMAGEDEPENDS. Move this append into the individual machines and
drop the include. This makes using the meta-xilinx-bsp default machine
configuration much simpler for external users as well as making the use
of a bootloader explicit on a per machine basis.
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Replace the definition of IMAGE_BOOT_FILES in machine-xilinx-board.inc
with the use of a function which automatically selects available images
that should be included. This includes the existing implementation of
`get_dtb_list` and replaces it with a function that covers all image
files including the existing default for KERNEL_IMAGETYPE(S) and
UBOOT_BINARY.
Also remove the use of `get_dtb_list` from individual machines which is
replaced by the default value.
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
IMAGE_BOOT_FILES
Replaced the hard-coded devicetree files in IMAGE_BOOT_FILES with a function,
which formats the KERNEL_DEVICETREE list properly.
Signed-off-by: Franz Forstmayr <f.forstmayr@gmail.com>
Reviewed-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
When building pmu firmware using multiconfig setup, the binaries can be
deployed in different build directory. Provide variables to set the
binaries in the required path for QEMU.
Fix SPL dependency on pmu-firmware. Since the pmu-firmware is being built
as a part of multiconfig provide variables to fetch appropriate
pmu-firmware binaries.
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
components
The zynqmp-pmu class was being used to build standalone components (PMU)
for several devices, with the introduction of the meta-xilinx-standalone
layer and the xilinx-standalone distro, this is not necessary anymore.
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
Add appropriate SOC_VARIANT for each machine configuration. This is
required from the introduction of overrides based on SOC_VARIANT.
Available SOC_VARIANT's for UltraScale+ MPSoC:
"cg" - Zynq UltraScale+ CG Devices
"eg" - Zynq UltraScale+ EG Devices
"ev" - Zynq UltraScale+ EV Devices
Add SOC_VARIANT to zcu102 board. Default variant is EG device.
Add SOC_VARIANT to zcu104 board. Default variant is EV device.
Add SOC_VARIANT to zcu106 board. Default variant is EV device.
Available SOC_VARIANT's for zynq:
"7zs" - Zynq-7000 Single A9 Core
"7z" - Zynq-7000 Dual A9 Core
Add SOC_VARIANT to zc702 board. Default variant is 7z device.
Add SOC_VARIANT to zc706 board.Default variant is 7z device.
Add SOC_VARIANT to microzed board.Default variant is 7z device.
Add SOC_VARIANT to picozed board.Default variant is 7z device.
Add SOC_VARIANT to zedboard board.Default variant is 7z device.
Add SOC_VARIANT to zybo board.Default variant is 7z device.
Add SOC_VARIANT to qemu-zynq7 board.Default variant is 7z device.
Signed-off-by: Vineeth Chowdary Karumanchi <vineethchowz.chowdary@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
|
The ZCU106 Evaluation Kit enables designers to jumpstart designs for
video conferencing, surveillance, Advanced Driver Assisted Systems
(ADAS) and streaming and encoding applications. This kit features a
Zynq® UltraScale+™ MPSoC EV device and supports all major peripherals
and interfaces, enabling development for a wide range of applications.
The included ZU7EV device is equipped with a quad-core ARM® Cortex™-A53
applications processor, dual-core Cortex-R5 real-time processor,
Mali™-400 MP2 graphics processing unit, 4KP60 capable H.264/H.265 video
codec, and 16nm FinFET+ programmable logic.
This patch adds machine configuration file for ZCU106 Evaluation Kit
with required setting of board specific yocto variables needed for
compilation of bootloader, kernel and device-tree.
- linux-xlnx is the kernel provider
- u-boot-xlnx is the u-boot provider which will also generate SPL boot.bin
- hwcodec is provided by libomxil-xlnx recipe, this will pull in
additional dependencies of VCU kernel modules, control software,
firmware binaries
Depending on the application need you may want to pass the appropriate
CMA size in bootargs or set CONFIG_CMA_SIZE_MBYTES in kernel.
While using SPL flow, you may need to provide additional hack to pass
the PMU config object. This is similar to all ZU+ boards, due to gap in
SPL flow unable to load PMU config object.
Signed-off-by: Devarsh Thakkar <devarsht@xilinx.com>
Tested-by: Maulik Desai <maulik.desai@xilinx.com>
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
|
Sandeep Gundlupet Raju
Mark Hatle
Sai Hari Chandana Kalluri
Raju Kumar Pothuraju
Jaewon Lee
Nathan Rossi
Franz Forstmayr
Manjukumar Matha
Alejandro Enedino Hernandez Samaniego
Vineeth Chowdary Karumanchi
Devarsh Thakkar