- Aug 08, 2023
-
-
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0 The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1] describes interfaces (ABIs) that standardize communication between the Secure World and Normal World leveraging TrustZone technology. This driver uses 64-bit registers as per SMCCCv1.2 spec and comes on top of the SMCCC layer. The driver provides the FF-A ABIs needed for querying the FF-A framework from the secure world. The driver uses SMC32 calling convention which means using the first 32-bit data of the Xn registers. All supported ABIs come with their 32-bit version except FFA_RXTX_MAP which has 64-bit version supported. Both 32-bit and 64-bit direct messaging are supported which allows both 32-bit and 64-bit clients to use the FF-A bus. FF-A is a discoverable bus and similar to architecture features. FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed by the PSCI driver. Clients are able to probe then use the FF-A bus by calling the DM class searching APIs (e.g: uclass_first_device). The Secure World is considered as one entity to communicate with using the FF-A bus. FF-A communication is handled by one device and one instance (the bus). This FF-A driver takes care of all the interactions between Normal world and Secure World. The driver exports its operations to be used by upper layers. Exported operations: - ffa_partition_info_get - ffa_sync_send_receive - ffa_rxtx_unmap Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c). Arm specific methods are implemented in the Arm driver (arm-ffa.c). For more details please refer to the driver documentation [2]. [1]: https://developer.arm.com/documentation/den0077/latest/ [2]: doc/arch/arm64.ffa.rst Signed-off-by:
Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Tom Rini <trini@konsulko.com> Cc: Jens Wiklander <jens.wiklander@linaro.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
-
provide a test case Signed-off-by:
-
- Aug 07, 2023
-
-
Add px30, rv1126 soc, and rockchip soc based boards. Signed-off-by:Kever Yang <kever.yang@rock-chips.com>
-
With this change the DT and binding files are under the at91 tree maintainer, and get_maintainer.pl correctly reports the entry. Signed-off-by:Eugen Hristev <eugen.hristev@collabora.com>
-
Update MAINTAINERS file. Add missing MAINTAINERS file for Spider, Whitehawk and V3HSK boards. Update mail addresses. Add file globs to match on DT and driver files related to these boards. The GRPEACH and R2DPLUS are special in that they are not R-Car and have their own set of specialized drivers. Signed-off-by:Marek Vasut <marek.vasut+renesas@mailbox.org>
-
- Jul 25, 2023
-
-
Angelo Dureghello authoredSigned-off-by:
Angelo Dureghello <angelo@kernel-space.org>
---
Changes for v2:
- none
Changes for v3:
- none -
Tom Rini authored
In a few cases we have MAINTAINERS entries that are missing obvious paths or files. Typically this means a board directory that did not list itself, but in a few cases we have a Kconfig file or similar. Signed-off-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
-
Tom Rini authored
A number of platforms have "common" directories that are in turn not listed by the board MAINTAINERS file. Add these directories in many cases. Signed-off-by:
-
Tom Rini authored
This file is in alphabetical order, move CAAM up to where it should be. Signed-off-by:
-
- Jul 24, 2023
-
-
Tom Rini authored
This reverts commit d927d1a8, reversing changes made to c07ad952. These changes do not pass CI currently. Signed-off-by:
-
Add Sandbox test for the armffa command Signed-off-by:
-
Add functional test cases for the FF-A support These tests rely on the FF-A sandbox emulator and FF-A sandbox driver which help in inspecting the FF-A communication. Signed-off-by:
-
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support Features of the sandbox FF-A support: - Introduce an FF-A emulator - Introduce an FF-A device driver for FF-A comms with emulated Secure World - Provides test methods allowing to read the status of the inspected ABIs The sandbox FF-A emulator supports only 64-bit direct messaging. Signed-off-by:
-
Provide armffa command showcasing the use of the U-Boot FF-A support armffa is a command showcasing how to invoke FF-A operations. This provides a guidance to the client developers on how to call the FF-A bus interfaces. The command also allows to gather secure partitions information and ping these partitions. The command is also helpful in testing the communication with secure partitions. For more details please refer to the command documentation [1]. [1]: doc/usage/cmd/armffa.rst Signed-off-by:
-
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0 The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1] describes interfaces (ABIs) that standardize communication between the Secure World and Normal World leveraging TrustZone technology. This driver uses 64-bit registers as per SMCCCv1.2 spec and comes on top of the SMCCC layer. The driver provides the FF-A ABIs needed for querying the FF-A framework from the secure world. The driver uses SMC32 calling convention which means using the first 32-bit data of the Xn registers. All supported ABIs come with their 32-bit version except FFA_RXTX_MAP which has 64-bit version supported. Both 32-bit and 64-bit direct messaging are supported which allows both 32-bit and 64-bit clients to use the FF-A bus. FF-A is a discoverable bus and similar to architecture features. FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed by the PSCI driver. Clients are able to probe then use the FF-A bus by calling the DM class searching APIs (e.g: uclass_first_device). The Secure World is considered as one entity to communicate with using the FF-A bus. FF-A communication is handled by one device and one instance (the bus). This FF-A driver takes care of all the interactions between Normal world and Secure World. The driver exports its operations to be used by upper layers. Exported operations: - ffa_partition_info_get - ffa_sync_send_receive - ffa_rxtx_unmap Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c). Arm specific methods are implemented in the Arm driver (arm-ffa.c). For more details please refer to the driver documentation [2]. [1]: https://developer.arm.com/documentation/den0077/latest/ [2]: doc/arch/arm64.ffa.rst Signed-off-by:
-
provide a test case Signed-off-by:
-
- Jul 12, 2023
-
-
Bin Meng authored
As the RISC-V ACLINT specification is defined to be backward compatible with the SiFive CLINT specification, we rename SiFive CLINT to RISC-V ALINT in the source tree to be future-proof. Signed-off-by:
Bin Meng <bmeng@tinylab.org> Reviewed-by:
Rick Chen <rick@andestech.com>
-
- Jul 07, 2023
-
-
This was not done when the tree name was changed, fix it now. Signed-off-by:
-
- Jun 12, 2023
-
-
Stefan Roese authored
This patch adds the PCIe controller driver for the Xilinx / AMD ZynqMP NWL PCIe Bridge as root port. The driver source is partly copied from the Linux PCI driver and modified to enable usage in U-Boot (e.g. simplified and interrupt support removed). Signed-off-by:
Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Pali Rohár <pali@kernel.org> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Michal Simek <michal.simek@amd.com> Tested-by:
Michal Simek <michal.simek@amd.com> Acked-by:
Pali Rohár <pali@kernel.org> Link: https://lore.kernel.org/r/20230525094918.111949-1-sr@denx.de Signed-off-by:
-
Venkatesh Yadav Abbarapu authored
The Xilinx ZynqMP SoC has a hardened display pipeline named DisplayPort Subsystem. It includes a buffer manager, blender, an audio mixer and a DisplayPort source controller (transmitter). The DisplayPort controller can source data from memory (non-live input) or the stream (live input). The DisplayPort controller is responsible for managing the link and physical layer functionality. The controller packs audio/video data into transfer units and sends them over the main link. The link rate and lane counts can be selected based on the application bandwidth requirements. The DisplayPort pipeline consists of the DisplayPort direct memory access (DMA) for fetching data from memory. The DisplayPort DMA controller (DPDMA) supports up to six input channels as non-live input. This driver supports the DisplayPort Subsystem and implements 1)640x480 resolution 2)RGBA8888 32bpp format 3)DPDMA channel 3 for Graphics 4)Non-live input 5)Fixed 5.4G link rate 6)Tested on ZCU102 board There will be additional work to configure GT lines based on DT, higher resolutions, support for more compressed video formats, spliting code to more files, add support for EDID, audio support, using clock framework for all clocks and in general code clean up. Codevelop-by:
Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com> Signed-off-by:
-
- May 30, 2023
-
-
K3 devices have runtime type board detection. Make the default defconfig include the secure configuration. Then remove the HS specific config. Non-HS devices will continue to boot due to runtime device type detection. If TI_SECURE_DEV_PKG is not set the build will emit warnings, for non-HS devices these can be ignored. Reviewed-by:
Bryan Brattlof <bb@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com> Acked-by:
Andrew Davis <afd@ti.com> Signed-off-by:
Manorit Chawdhry <m-chawdhry@ti.com>
-
- May 05, 2023
-
-
Known limitations are 1. fastboot reboot doesn't work (answering OK but not rebooting) 2. flashing isn't supported (TCP transport only limitation) The command syntax is fastboot tcp Signed-off-by:
Dmitrii Merkurev <dimorinny@google.com> Cc: Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org> Cc: Simon Glass <sjg@chromium.org> Сс: Joe Hershberger <joe.hershberger@ni.com> Сс: Ramon Fried <rfried.dev@gmail.com> Reviewed-by:
-
- May 04, 2023
-
-
K3 devices have runtime type board detection. Make the default defconfig include the secure configuration. Then remove the HS specific config. Non-HS devices will continue to boot due to runtime device type detection. If TI_SECURE_DEV_PKG is not set the build will emit warnings, for non-HS devices these can be ignored. Reviewed-by:
Kamlesh Gurudasani <kamlesh@ti.com> Signed-off-by:
-
K3 devices have runtime type board detection. Make the default defconfig include the secure configuration. Then remove the HS specific config. Non-HS devices will continue to boot due to runtime device type detection. If TI_SECURE_DEV_PKG is not set the build will emit warnings, for non-HS devices these can be ignored. Reviewed-by:
-
- May 03, 2023
-
-
First supported chip is hi3798mv200 (which is similar to Hi3798cv200 used by poplar). Signed-off-by:Yang Xiwen <forbidden405@outlook.com>
-
- May 02, 2023
-
-
The files include/tpm* are an integral part of the TPM drivers. The tpm* commands are used to access TPM devices. Both should be managed by the TPM DRIVERS maintainer. Signed-off-by:
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by:
-
- Apr 28, 2023
-
-
os.h is only used by the sandbox. Signed-off-by:
-
- Apr 27, 2023
-
-
provide a test for NVM XIP devices The test case allows to make sure of the following: - The NVM XIP QSPI devices are probed - The DT entries are read correctly - the data read from the flash by the NVMXIP block driver is correct Signed-off-by: -
add nvmxip_qspi driver under UCLASS_NVMXIP The device associated with this driver is the parent of the blk#<id> device nvmxip_qspi can be reused by other platforms. If the platform has custom settings to apply before using the flash, then the platform can provide its own parent driver belonging to UCLASS_NVMXIP and reuse nvmxip-blk driver. The custom driver can be implemented like nvmxip_qspi in addition to the platform custom settings. Platforms can use multiple NVM XIP devices at the same time by defining a DT node for each one of them. For more details please refer to doc/develop/driver-model/nvmxip_qspi.rst Signed-off-by: -
add block storage emulation for NVM XIP flash devices Some paltforms such as Corstone-1000 need to see NVM XIP raw flash as a block storage device with read only capability. Here NVM flash devices are devices with addressable memory (e.g: QSPI NOR flash). The implementation is generic and can be used by different platforms. Two drivers are provided as follows. nvmxip-blk : a generic block driver allowing to read from the XIP flash nvmxip Uclass driver : When a device is described in the DT and associated with UCLASS_NVMXIP, the Uclass creates a block device and binds it with the nvmxip-blk. Platforms can use multiple NVM XIP devices at the same time by defining a DT node for each one of them. Signed-off-by:
-
- Apr 16, 2023
-
-
As there are other types of NAND flashes like SPI NAND, let's be more specific. Signed-off-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/all/20230213094626.50957-2-frieder@fris.de/ Signed-off-by:
Dario Binacchi <dario.binacchi@amarulasolutions.com>
-
In [1] Michael agreed on taking patches for SPI NAND through the RAW NAND tree. Add a dedicated entry to the MAINTAINERS file which adds Michael and Dario as maintainers and myself as reviewer. [1] https://lists.denx.de/pipermail/u-boot/2023-February/508571.html Signed-off-by:
-
- Apr 05, 2023
-
-
Explain block maps by going through two common use-cases. Signed-off-by:
Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by:
-
Verify that: - Block maps can be created and destroyed - Mappings aren't allowed to overlap - Multiple mappings can be attached and be read/written from/to Signed-off-by:
-
Add a frontend for the blkmap subsystem. In addition to the common block device operations, this allows users to create and destroy devices, and map in memory and slices of other block devices. With that we support two primary use-cases: - Being able to "distro boot" from a RAM disk. I.e., from an image where the kernel is stored in /boot of some filesystem supported by U-Boot. - Accessing filesystems not located on exact partition boundaries, e.g. when a filesystem image is wrapped in an FIT image and stored in a disk partition. Signed-off-by:
-
blkmaps are loosely modeled on Linux's device mapper subsystem. The basic idea is that you can create virtual block devices whose blocks can be backed by a plethora of sources that are user configurable. This change just adds the basic infrastructure for creating and removing blkmap devices. Subsequent changes will extend this to add support for actual mappings. Signed-off-by:
-
- Mar 30, 2023
-
-
Adds a test for the new pci_mps command to ensure that it can set the Maximum Payload Size (MPS) of all devices to 256 bytes in the sandbox environment. Enables the pci_mps command in the sandbox environment so that this test can be run. Signed-off-by:Stephen Carlson <stcarlso@linux.microsoft.com>
-
- Mar 14, 2023
-
-
Tom Rini authored
This reverts commit c714045c. Signed-off-by:
-
Tom Rini authored
This reverts commit e352e106. Signed-off-by:
-
- Mar 06, 2023
-
-
K3 devices have runtime type board detection. Make the default defconfig include the secure configuration. Then remove the HS specific config. Non-HS devices will continue to boot due to runtime device type detection. If TI_SECURE_DEV_PKG is not set the build will emit warnings, for non-HS devices these can be ignored. Signed-off-by:
-
