aboutsummaryrefslogtreecommitdiffstats
path: root/meta-xilinx-bsp/conf/machine/ultra96-zynqmp.conf
AgeCommit message (Collapse)Author
2022-07-28meta-xilinx: Clean up vendor specific machine configuration filesSandeep Gundlupet Raju
1. Add new metal-xilinx-vendor layer which supports vendor specific machine configuration files, device-tree, kernel, platform-init etc. 2. Moved below vendor machine conf files, dt and related configs from meta-xilinx-bsp and meta-xilinx-contrib to meta-xilinx-vendor layer. - microzed-zynq7.conf - minized-zynq7.conf - picozed-zynq7.conf - zedboard-zynq7.conf - zybo-zynq7.conf - zybo-linux-bd-zynq7.conf - ultra96-zynqmp.conf 3. Obsolete qemu-zynq7, s3adsp1800-qemu-microblazeeb, v350-versal and vc-p-a2197-00-versal from meta-xilinx-bsp layer. Users should use zynq-generic.conf for zynq7000 qemu boot should be functionally equivalent to qemu-zynq7. 4. Add new MAINTAINERS.md file and move maintainers, Mailing list and Patches content from meta-xilinx-* README.md to MAINTAINERS.md file. 5. Updated README.md file for supported board machines files in meta-xilinx-bsp, meta-xilinx-contrib and meta-xilinx-vendor layers. 6. Disabled old drm kernel patches for zybo-linux-bd-zynq mahcine in meta-xilinx-contrib layer as these patches doesn't apply on 5.x kernel, if we don't hear from patch submitter we will remove these patches from meta-xilinx-contrib layer. 7. Removed drm kernel cache metadate for zybo-linux-bd-zynq7 machine as these configs are already available in xilinx_zynq_defconfig. 8. Fixed build issue for u-boot by changing PREFERRED_PROVIDER_virtual/bootloader from u-boot to u-boot-xlnx. 9. Add meta-xilinx-vendor to bblayers.conf.sample Signed-off-by: Sandeep Gundlupet Raju <sandeep.gundlupet-raju@xilinx.com> Signed-off-by: Mark Hatle <mhatle@xilinx.com>
2022-01-14meta-xilinx-bsp: Covert ultra96-zynqmp and vck-sc-zynqmp from BOARD basedMark Hatle
Use the MACHINEOVERRIDES to add the BOARD name so that overrides elsewhere will work as expected. Eventually the overrides will need to be adjusted. Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
2022-01-14meta-xilinx-bsp: Convert all BSPs to use the generic configsMark Hatle
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
2022-01-14Deprecate BOARD and BOARD_VARIANT supportMark Hatle
If the BOARD and/or BOARD_VARIANT is set, continue to allow this to work, however warn the user it is deprecated. Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
2022-01-14ultra96-zynqmp: Default to zynqmp eg variantMark Hatle
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
2021-09-28ultra96-zynqmp/zynqmp-generic: Specify the ultra96 so BOARD can select itMark Hatle
Move the ultra96-zynqmp.conf into the zynqmp-generic (via a require). This approach can be used for other board specific overrides if necessary. Move MACHINE_FEATURES to the generic zynqmp-generic file, as that is requried to make a superset. Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
2021-09-28u-boot-zynq-uenv: Remove incorrect dependency processingMark Hatle
An RDEPEND can not be turned into a DEPEND directly. Indirectly the system is capable of doing this via various mapping, but the function in use can not do this safely. Also move ultra96 firmware from RRECOMMEND to RDEPEND. Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
2021-09-28ultra96-zynqmp: Move to using zynqmp-generic as the foundationMark Hatle
We use zynqmp-generic (via a require) as the default now, and only set the values that make the ultra96 unique. Note, the two RRECOMMEND dependencies at the end. These are requried for WiFi and Bluetooth. Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
2021-07-14*.conf: use weaker assignment for UBOOT_MACHINERaju Kumar Pothuraju
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>
2021-07-14embeddedsw: Rework plm/pmu/psm firmware and Linux packagingMark Hatle
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>
2020-12-22ultra96: Using BOARD level hiearchy for ultra96 overridesJaewon Lee
Using BOARD level hierarchy to rewire ultra96 specific overrides. Each package using BOARD override has to also redefine PACKAGE_ARCH using BOARD_ARCH Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
2020-04-03machines: Remove default SERIAL_CONSOLES_CHECKMark Hatle
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>
2020-04-03machines: Allow the user to override SERIAL_CONSOLESMark Hatle
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
2020-04-03machines: Move from SERIAL_CONSOLE (deprecated) to SERIAL_CONSOLESMark Hatle
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>
2020-03-13meta-xilinx-bsp: remove redundant PREFERRED_PROVIDERMark Hatle
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>
2020-03-13meta-xilinx-bsp: rename machine-xilinx-override to xilinx-soc-family.incMark Hatle
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>
2020-03-13meta-xilinx-bsp: Remove default valuesMark Hatle
Remove the default values, as they are already set by the soc include. Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
2020-03-13meta-xilinx-bsp: Rename soc configuration masquerading as a tune fileMark Hatle
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>
2020-02-07u-boot-xlnx:Update UBOOT-MACHINE to xilinx_zynqmp_virt_defconfig for all ↵Sai Hari Chandana Kalluri
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>
2019-12-09ultra96-zynqmp.conf: Include mipi as MACHINE_FEATURESai Hari Chandana Kalluri
Ultra96 provides support for MIPI Interface. To support the interface, additional kernel, device tree modifications are required and must be enabled only when mipi is included as MACHINE_FEATURE Signed-off-by: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com> Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com> Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
2019-12-09linux-firmware_git.bbappend: Add hook for wl18xx and bts fileManjukumar Matha
Ultra96 board needs the wl8xx and bts file to enable wireless and bluetooth on the TI part. This recipe uses linux-firmware and modify to include only wl18xx binaries. We also depend on TIInit_11.8.32 bts, add an append to fetch the right bt firmware Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
2019-12-09ultra96-zynqmp.conf: Add support for Ultra96 evaluation boardManjukumar Matha
Ultra96™ is an Arm-based, Xilinx Zynq UltraScale+™ MPSoC development board based on the Linaro 96Boards specification. The 96Boards’ specifications are open and define a standard board layout for development platforms that can be used by software application, hardware device, kernel, and other system software developers. Ultra96 represents a unique position in the 96Boards community with a wide range of potential peripherals and acceleration engines in the programmable logic that is not available from other offerings More info: http://zedboard.org/product/ultra96 This patch adds machine configuration file for Ultra96 board 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 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: Sai Hari Chandana Kalluri <chandana.kalluri@xilinx.com> Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>