-----BEGIN PGP SIGNATURE-----
iQFQBAABCgA6FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAmU2fxwcHGV1Z2VuLmhy
aXN0ZXZAY29sbGFib3JhLmNvbQAKCRAesx4CDqwvyKr+B/42+WkPiAiwt79R6Kh5
UKo404oN1na28D3V12EvikiCH2QWubi38EV7VfcB3jqEpxj4j+rY0cSLZv+u7d4/
bfQN3FPrcTwYnXYLbYkUKC+MAVzGLiVzFBBhIt5cPrT4iVXctwYY6LJ58aX8uRo6
KU6CwXYc3cnmIUqpXE4EYbbQU4TAp55SV2n8QLFFI9DHcy2kELfdrZduFn+Hm9Ij
9sQHH5JxbrGHv5XpcjJkARW3M4K3K4TPzweFGN61VMJwWqzD3L4YPshwIGDfhRui
LECKCdr/rWkavumXCfw2pD3RYFTqnqnUzaEN/3ueL9FCJ2uFH1EyaoSuXFEn3+Ul
m1LE
=CMMd
-----END PGP SIGNATURE-----
Merge tag 'u-boot-at91-2024.01-b' of https://source.denx.de/u-boot/custodians/u-boot-at91
Second set of u-boot-at91 features for the 2024.01 cycle
This feature set a new board named Conclusive KSTR sama5d27 with some
small prerequisites patches.
This is mostly about support for the Allwinner R528/T113s SoC, which is
reportedly the same die as the Allwinner D1, but with the two
Arm Cortex-A7 cores activated instead of the RISC-V one.
Using sunxi code outside of arch/arm proved to be difficult, so apart
from enabling this Arm SoC, the patches also prepare for more refactoring
to get the D1 nicely supported some day:
- We get rid of some Kconfig (hard-)coded GPIO pins, responsible for
enabling regulators.
- The GPIO code is moved out of arch/arm, into drivers/gpio.
- Some definitions are moved out of header files under asm/arch.
- Some T113s/D1 specific definitions are guarded by a generic Kconfig
symbol (CONFIG_SUNXI_GEN_NCAT2).
- The DRAM controller initialisation code is located under drivers/ram.
- The base SoC .dtsi files are shared (under arch/riscv, as in Linux).
Of course there are also the usual new SoC specific patches, like clock
and pinmux descriptions, alongside a rework of the pinctrl code, since
Allwinner changed the GPIO register layout, for the first time since
sunxi's inception.
On top of this the PSCI code sees some update, to provide SMP services
for R528/T113s boards. Many thanks to Sam for providing this code and
staying strong through the review cycles.
The final patch enables support for one popular board, I hope to see
more DTs and defconfigs contributed in the future!
Many thanks to all the various contributors, testers and reviewers,
that series was a real team effort!
Introduce support for Conclusive KSTR-SAMA5D27 Single Board Computer.
Co-developed-by: Jakub Klama <jakub@conclusive.pl>
Signed-off-by: Jakub Klama <jakub@conclusive.pl>
Co-developed-by: Marcin Jabrzyk <marcin@conclusive.pl>
Signed-off-by: Marcin Jabrzyk <marcin@conclusive.pl>
Signed-off-by: Artur Rojek <artur@conclusive.pl>
The NanoPC-T6 is a Rockchip RK3588 based SBC by FriendlyElec.
There are four variants depending on the DRAM size: 4G/32GB eMMC,
8G/64GB eMMC, 16G/16MB SPI NOR, and 16G/256GB eMMC/16MB SPI NOR
Specifications:
CPU: Rockchip RK3588, 4x Cortex-A76 (up to 2.4GHz)
+ 4x Cortex-A55 (up to 1.8GHz)
GPU: Mali-G610 MP4
VPU: 8K@60fps H.265 and VP9 decoder, 8K@30fps H.264 decoder,
4K@60fps AV1 decoder, 8K@30fps H.264 and H.265 encoder
NPU: 6TOPs, supports INT4/INT8/INT16/FP16
RAM: 64-bit 4GB/8GB/16GB LPDDR4X at 2133MHz
eMMC: 0GB/32GB/64GB/256GB HS400
MicroSD Slot: MicroSD SDR104
PCIe 3.0: M.2 M-Key x1, PCIe 3.0 x4 for NVMe SSDs up to 2,500 MB/s
Ethernet: PCIe 2.5G 2x Ethernet (RTL8125BG)
PCIe 2.1: M.2 E-Key x1, PCIe 2.1 x1 and USB2.0 Host,
supports M.2 WiFi and Bluetooth
4G Module: MiniPCIe x1, MicroSIM Card Slot x1
Audio Out: 3.5mm jack for stereo headphone output
Audio In: 2.0mm PH-2A connector for analog microphone input
Video Input: standard HDMI input port, up to 4Kp60
2x 4-lane MIPI-CSI, compatible with MIPI V1.2
Video Output: 2x standard HDMI output ports compatible with HDMI2.1,
HDMI2.0, and HDMI1.4
2x 4-lane MIPI-DSI, compatible with MIPI DPHY 2.0 or CPHY 1.1
USB-A: USB 3.0, Type A
USB-C: Full function USB Type‑C port, DP display up to 4Kp60, USB 3.0
40-pin 2.54mm header connector: up to 2x SPIs, 6x UARTs, 1x I2Cs,
8x PWMs, 2x I2Ss, 28x GPIOs
Debug UART: 3 Pin 2.54mm header, 3V level, 1500000bps
Onboard IR receiver: 38KHz carrier frequency
RTC Battery: 2 Pin 1.27/1.25mm RTC battery connector for low power
RTC IC HYM8563TS
5V Fan connector
Working Temperature: 0C to 70C
Power: 5.5*2.1mm DC Jack, 12VDC input
Dimensions: 110x80x1.6mm (without case) / 86x114.5x30mm (with case)
Kernel commits:
893c17716d0c ("arm64: dts: rockchip: Add NanoPC T6")
a721e28dfad2 ("arm64: dts: rockchip: Add NanoPC T6 PCIe Ethernet support")
ac76b786cc37 ("arm64: dts: rockchip: Add NanoPC T6 PCIe e-key support")
Signed-off-by: John Clark <inindev@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add support for eMMC (SMHC2) pin pull ups for R528 boards.
The D1 and T113s (and even R329) SoCs do not support 8-bit eMMC anymore,
so it's just four data pins to cover here.
Signed-off-by: Okhunjon Sobirjonov <Okhunjon.Sobirjonov@Mec-electronics.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: adjust commit message]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
U-Boot's generic GPIO_EXTRA_HEADER is a convenience symbol to allow code
to more easily include platform specific GPIO headers. This should not
be needed in a DM world anymore, since the generic GPIO framework
handles that nicely.
For Allwinner boards we still need to deal with non-DM GPIO in the SPL,
but this should become the exception, not the rule.
Make this more obvious by removing the definition of GPIO_EXTRA_HEADER,
and just force every legacy user of platform specific GPIO to include
the new sunxi_gpio.h header explicitly. Everyone doing so should feel
ashamed and should find a way to avoid it from now on.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Samuel Holland <samuel@sholland.org>
The CONFIG_MACPWR Kconfig symbol is used to point to a GPIO that enables
the power for the Ethernet "MAC" (mostly PHY, really).
In the DT this is described with the phy-supply property in the MAC DT
node, pointing to a (GPIO controlled) regulator. Since we need Ethernet
only in U-Boot proper, and use a DM driver there, we should use the DT
instead of hardcoding this.
Add code to the sun8i_emac and sunxi_emac drivers to check the DT for
that regulator and enable it, at probe time. Then drop the current code
from board.c, which was doing that job before.
This allows us to remove the MACPWR Kconfig definition and the respective
values from the defconfigs.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
The CONFIG_SATAPWR Kconfig symbol was used to point to a GPIO that
enables the power for a SATA harddisk.
In the DT this is described with the target-supply property in the AHCI
DT node, pointing to a (GPIO controlled) regulator. Since we need SATA
only in U-Boot proper, and use a DM driver for AHCI there, we should use
the DT instead of hardcoding this.
Add code to the sunxi AHCI driver to check the DT for that regulator and
enable it, at probe time. Then drop the current code from board.c, which
was doing that job before.
This allows us to remove the SATAPWR Kconfig definition and the
respective values from the defconfigs.
We also select the generic fixed regulator driver, which handles those
GPIO controlled regulators.
Please note that the OrangePi Plus is a bit special here, it's a H3
board without native SATA, but with a USB-to-SATA bridge. The DT models
the SATA power via a VBUS supply regulator, which we don't parse yet in
the USB PHY driver. Use the hardcoded CONFIG_USB3_VBUS_PIN for that
board meanwhile.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
Originally, u-boot SPL will place the DTB directly after the kernel,
but the size of the kernel does not include the BSS section, This
means that u-boot SPL places the DTB in the kernel BSS section causing
the DTB to be cleared by the kernel BSS initialisation.
Moving the DTB in front of the kernel can avoid this error.
Signed-off-by: Randolph <randolph@andestech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Introduce two new weak functions, arch_spl_mmc_get_uboot_raw_sector() and
board_spl_mmc_get_uboot_raw_sector(), each of which can be overridden at
a matching level, that is arch/ and board/ , in addition to the existing
weak function spl_mmc_get_uboot_raw_sector().
This way, architecture code can define a default architecture specific
implementation of arch_spl_mmc_get_uboot_raw_sector(), while the board
code can override that using board_spl_mmc_get_uboot_raw_sector() which
takes precedence over the architecture code. In some sort of unlikely
special case where code has to take precedence over board code too, the
spl_mmc_get_uboot_raw_sector() is still left out to be a weak function,
but it should be unlikely that this is ever needed to be overridden.
Signed-off-by: Marek Vasut <marex@denx.de>
The Renesas RZ/G2L SMARC Evaluation Board Kit consists of the RZ/G2L
System-on-Module (SOM) based on the R9A07G044L2 SoC, and a common SMARC
carrier board.
The ARM TrustedFirmware code for the Renesas RZ/G2L SoC family passes a
devicetree blob to the bootloader as an argument in the same was
previous R-Car gen3/gen4 SoCs. This blob contains a compatible string
which can be used to identify the particular SoC we are running on and
this is used to select the appropriate device tree to load.
The configuration renesas_rzg2l_smarc_defconfig is added to support
building for this target. In the future this defconfig will be extended
to support other SoCs and evaluation boards from the RZ/G2L family.
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
The current imx8mp-dhcom-som.dtsi describes production rev.200 SoM,
add DT overlay which reinstates rev.100 SoM description to permit
prototype rev.100 SoMs to be used until they get phased out.
Signed-off-by: Marek Vasut <marex@denx.de>
Add DT overlays to support additional DH i.MX8MP DHCOM SoM 660-100
population options with 1x or 2x RMII PHY mounted on PDK2 or PDK3
carrier boards.
Use SPL DTO support to apply matching SoM specific DTO to cater
for the SoM differences. Remove ad-hoc patching of control DT from
fdtdec_board_setup().
Signed-off-by: Marek Vasut <marex@denx.de>
- Generally we just drop the #ifdef CONFIG_SYS_LONGHELP and endif lines
and use U_BOOT_LONGHELP to declare the same variable name as before
- In a few places, either rename the variable to follow convention or
introduce the variable as it was being done inline before.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
If the data version field of the EEPROM is not supported, provide a hexdump
of the data.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The different implementations of the mac command have board or vendor
specific sub-commands.
Add the command definition specific to the VisionFive 2 board.
Don't call cmd_usage() directly but return CMD_RET_USAGE instead.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The different implementations of the mac command have board or vendor
specific sub-commands.
Add the command definition specific to the SiFive HiFive Unmatched board.
Don't call cmd_usage() directly but return CMD_RET_USAGE instead.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
CONFIG_SYS_LONGHELP=n we want to reduce the size of the U-Boot binary.
The long text should be reduced to and empty string in this case.
There is not need to call cmd_usage() directly. It is sufficient to
return CMD_RET_USAGE.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Board specific implementations of the 'mac' command differ concerning the
supported sub-commands.
Move the Freescale specific mac command definition to the board code.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Handle 2GBit memory size value "2" from tlv eeprom on ddr
initialisation, to support SoMs with 512MB ddr memory.
Signed-off-by: Josua Mayer <josua@solid-run.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Extend the existing tlv vendor extension used for ram size by one byte to
also store the number of ddr channels.
The length of the tlv entry can indicate whether the new information is
present. If not default to single channel.
Signed-off-by: Josua Mayer <josua@solid-run.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Starting with PCB revision 3 we can safely make use of higher RAM
frequency again. Make use of the EEPROM detection to determine the
revision and use the updated RAM timings for new SoMs.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Yannic Moog <y.moog@phytec.de>
Tested-by: Yannic Moog <y.moog@phytec.de>
Add EEPROM detection initialisation for phyCORE-i.MX8MM and
print SoM information during boot when successful.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Yannic Moog <y.moog@phytec.de>
Tested-by: Yannic Moog <y.moog@phytec.de>
Add helper function to read out the PCB revision of a PHYTEC SoM.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Yannic Moog <y.moog@phytec.de>
Tested-by: Yannic Moog <y.moog@phytec.de>
Due to PCB layout constraints in PCB revisions until including 1549.2,
a RAM frequency of 2 GHz can cause rare instabilities. Set the RAM
frequency to 1.5 GHz to achieve a stable system under all conditions.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Yannic Moog <y.moog@phytec.de>
Tested-by: Yannic Moog <y.moog@phytec.de>
Add imx8m specific detection part. Which includes checking the
EEPROM data for article number options.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Yannic Moog <y.moog@phytec.de>
Tested-by: Yannic Moog <y.moog@phytec.de>
Recent shipped PHYTEC SoMs come with an i2c EEPROM containing
information about the hardware such as board revision and variant.
This can be used for RAM detection and loading device tree overlays
during kernel start.
Signed-off-by: Teresa Remmet <t.remmet@phytec.de>
Reviewed-by: Yannic Moog <y.moog@phytec.de>
Tested-by: Yannic Moog <y.moog@phytec.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
ZyXEL NSA325 specifications:
Marvell Kirkwood 88F6282 SoC
1.6 GHz CPU
1x GBE LAN port (Marvell MV88E1318)
512 MB RAM
128 MB Eon NAND, SLC
I2C
1x USB 3.0 (on PCIe bus)
2x USB 2.0
2x SATA (hot swap slots)
Serial console
Signed-off-by: Tony Dinh <mibodhi@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
The 2nd HD is not enabled in U-Boot on the D-Link DNS325. This patch
sets the responsible GPIO to high, enabling the drive.
Suggested-by: Peter Granilla
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Tony Dinh <mibodhi@gmail.com>
When using a list of writeable variables, the initial values come
from the built-in default environment since commit 5ab8105836 ("env:
Complete generic support for writable list").
Remove unnecessary misuse of CONFIG_ENV_IS_NOWHERE as default environment.
Based on the fix done by commit b16fd7f75f ("imx6q: acc: Remove misuse
of env is nowhere driver").
Signed-off-by: Eduard Strehlau <eduard@lionizers.com>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Add detection of eMMC vs NAND devices on the Colibri iMX7
board. A GPIO is configured to detect the presence of an on-board resistor
that is configured differently based on the flash memory used. Depending on
the detection result, the 'variant' environment variable is set to '-emmc'
or cleared, indicating the type of storage device.
This enhancement improves variant detection during system initialization
through USB recovery mode, where U-Boot is loaded directly to RAM. This
allows variant detection for an accurate device tree selection.
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Update lpddr4 configuration and training using updated spreadsheet and
tools from NXP using data from previous spreadsheet and verified
toward datasheet:
- MX8M_Mini_LPDDR4_RPA_v22.xlsx
- mscale_ddr_tool_v3.31_setup.exe
The most relevant update is related to errata ERR050805:
"DRAM: Controller automatic derating logic may not work when
the LPDDR4 memory temperature is above 85 °C at initialization"
Other relevant fixes:
- DRAMTMG7 register: corrected calculation of T_CKPDX parameter
(equal to tCKCKEH for LPDDR4)
- RANKCTL register: corrected calculations for ODTLon and ODTLoff
to follow the JEDEC specification
- ADDRMAP7 register: added support for 17-row devices
As per errata ERR050805:
An issue exists with the automatic derating logic of the DDR
controller that only samples the LPDDR4 MR4 register when the
Temperature Update Flag (TUF) field (MR4[7] ) is 1’b1. If the
LPDDR4 memory is initialized and starts operation above 85 °C
(MR4[2:0] > 3’b011), the MR4 Temperature Update Flag (TUF) will
not be set. The DDR Controller will therefore not automatically
adjust the memory refresh rate or de-rate memory timings based
on the LPDDR4 memory temperature. This may cause the controller
incorrectly setting the refresh period, potentially cause the
LPDDR4 memory losing data contents and lead to possible data
integrity issues above 85 °C.
Errata provides three possible workaround options, while option 2
is the most reasonable:
Disable the automatic derating logic of the DDR controller and
apply fixed x2 refresh rate (0.5x refresh). This option is
suitable for designs that are expected to boot at or above 85 °C
and memory’s MR4[2:0] (Refresh Rate) DOES NOT report the following
conditions:
3b101: 0.25x refresh, no de-rating
3b110: 0.25x refresh, with de-rating
3b111: SDRAM High temperature operating limit exceeded
[1]: https://www.nxp.com/docs/en/errata/IMX8MM_0N87W.pdf
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Update the imx8mp-venice-gw74xx for revB:
- add CAN1
- add TIS-TPM on SPI2
- add FAN controller
- fix PMIC I2C bus (revA PMIC I2C was non-functional so no need for
backward compatible option)
- M2 socket GPIO's moved
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
clk:
- remove additional compatible strings for Versal NET
net:
- zynq_gem: Fix clock calculation for MDC for higher frequencies
pinctrl:
- core: Extend pinmux status buffere size
- zynqmp driver: Show also tristate configuration
test:
- add test case for pxe get
Xilinx:
- describe SelectMAP boot mode
Zynq:
- Fix nand description in DT
ZynqMP:
- DTS sync patches with kernel and also W=1 related fixes
- Add support for KD240, zcu670, e-a2197 with x-prc cards, SC revB/C with i2c
description for other SC based boards
- k24 psu_init cleanup
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQbPNTMvXmYlBPRwx7KSWXLKUoMIQUCZSjvwAAKCRDKSWXLKUoM
IR34AJ92oum3pJXKxKREEZh0dCfDvJlE/wCggyzxI2T5liJfRG5jzlUuDjiLLU0=
=u1bz
-----END PGP SIGNATURE-----
Merge tag 'xilinx-for-v2024.01-rc1-v3' of https://source.denx.de/u-boot/custodians/u-boot-microblaze
Xilinx changes for v2024.01-rc1 v3
clk:
- remove additional compatible strings for Versal NET
net:
- zynq_gem: Fix clock calculation for MDC for higher frequencies
pinctrl:
- core: Extend pinmux status buffere size
- zynqmp driver: Show also tristate configuration
test:
- add test case for pxe get
Xilinx:
- describe SelectMAP boot mode
Zynq:
- Fix nand description in DT
ZynqMP:
- DTS sync patches with kernel and also W=1 related fixes
- Add support for KD240, zcu670, e-a2197 with x-prc cards, SC revB/C with i2c
description for other SC based boards
- k24 psu_init cleanup
Update the MAINTAINERS file and propose a new MAINTAINER for j721s2 due
to the previous MAINTAINER not being associated with TI.
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com>
Switch to using bootstd. Note with this change, we will stop using
distro_bootcmd and instead depend entirely on bootflow method of
starting the system up.
Drop header files that are no longer needed in am64x_evm.h.
k3_dfu.h is available via k3_dfu.env in am64x.env.
Drop unused macro CFG_SYS_SDRAM_BASE1.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
ti_mmc is not a valid boot_target for standard boot flow so
remove it. Prefer mmc1 (sd-card) over mmc0 (emmc).
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Nishanth Menon <nm@ti.com>
This caused the wrong fdtfile to be set and was failing to apply M.2
settings.
Fixes: badaa1f6a7 ("boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Added new xenguest_arm64_virtio_defconfig which
enables support for virtio-blk using various types
of transport like virtio-pci, vrtio-mmio. Currently
supported: up to 2 PCI host bridges and 10 MMIO devices.
Note: DT parsing code was partly taken from pci-uclass.c
Limitation: All memory regions should be
below 4GB address space.
Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi@epam.com>
Current gd->ram_size and gd->ram_top reflect only the
first DRAM bank even if the SynQuacer Developerbox could
have up to three DRAM banks.
With the commit 06d514d77c ("lmb: consider EFI memory map"),
the first DRAM bank indicates <4GB address, so whole >4GB memory
is marked as EFI_BOOT_SERVICES_DATA and it results that
U-Boot can not access >4GB memory.
Since 64-bits DRAM address is fully available on the SynQuacer
Developerbox, let's set the installed DIMM information to
gd->ram_top and gd->ram_size.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Populate the device tree with the MC reserved memory regions.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Populate the device tree with the MC reserved memory regions.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Add support for declaring in device tree the reserved memory ranges
required for MC. Since the MC firmware acts as any DMA master present
in the SoC, the reserved memory ranges need also be identity mapped
in the SMMU, so create the required 'iommu-addresses' property in
the reserved memory nodes.
For now this support is used only on LX2160A SoCs.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
PPA was a secure firmware developed in-house which is no longer
supported and replaced by TF-A quite some years ago. Drop support
for it.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
