summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-03-07board: phytec: am64x: Add PHYTEC phyCORE-AM64x SoMWadim Egorov
Add support for PHYTEC phyCORE-AM64x SoM. Supported features: - 2GB DDR4 RAM - eMMC Flash - external uSD - OSPI NOR Flash - debug UART Product page SoM: https://www.phytec.com/product/phycore-am64x Device trees were taken from Linux v6.8-rc2. Signed-off-by: Wadim Egorov <[email protected]> Reviewed-by: Dhruva Gole <[email protected]>
2024-03-07Check curve_name for null to avoid crashBob Wolff
If mixed rsa and ecdsa keys are specified in dtsi, an rsa key can be sent into the ecdsa verify. Without the ecdsa,curve property, this function will crash due to lack of checking the null pointer return. Signed-off-by: Bob Wolff <[email protected]>
2024-03-06Merge patch series "Move DRAM address of ATF"Tom Rini
Andrew Davis <[email protected]> says: Explanation for this series is mostly in [4/6]. First 3 patches should be safe to take independent of the last 3.
2024-03-06arm: mach-k3: Move DRAM address of ATF for AM62/AM62aAndrew Davis
The current address of TF-A in DRAM is just below the 512MB address line. This means if the DRAM in a system is 512MB then TF-A is right at the end of memory which is often reused, for instance U-Boot relocates itself here. If a system has less than 512MB then that system wouldn't work at all as TF-A would fail to load. To avoid the issues above, move TF-A to the start of DRAM, which doesn't change from system to system. As TF-A is position independent, this has no dependency on TF-A. We also fixup DT as needed when TF-A address is moved, so this change also has no dependency on Linux and is fully forward/backward compatible. Signed-off-by: Andrew Davis <[email protected]> Acked-by: Bryan Brattlof <[email protected]>
2024-03-06arm: mach-k3: am62a: Fixup TF-A/OP-TEE reserved-memory node in FDTAndrew Davis
The address we load TFA and OP-TEE to is configurable by CONFIG_K3_{ATF,OPTEE}_LOAD_ADDR, but the DT nodes reserving this memory are static. Fix that by updating this node when the loaded address does not match the address in DT. Signed-off-by: Andrew Davis <[email protected]> Acked-by: Bryan Brattlof <[email protected]>
2024-03-06arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDTAndrew Davis
The address we load TF-A and OP-TEE to is configurable by Kconfig CONFIG_K3_{ATF,OPTEE}_LOAD_ADDR, but the DT nodes reserving this memory are often statically defined. As these binaries are dynamically loadable, and in the case of OP-TEE may not even be loaded at all, hard-coding these addresses is not a hardware description, but rather a configuration. If the address that U-Boot loaded TF-A or OP-TEE does not match the address in hard-coded in DT, then fix that node address. This also handles the case when no reserved memory for these is provided by DT, which is more correct as explained above. Add this fixup function, and enable it for AM62. Signed-off-by: Andrew Davis <[email protected]> Acked-by: Bryan Brattlof <[email protected]> Reviewed-by: Neha Malcom Francis <[email protected]>
2024-03-06arm: mach-k3: am62: Enable OF_SYSTEM_SETUP for all boardsAndrew Davis
The fixups provided by ft_system_setup() are applicable for all AM62 based boards. Select this at the target selection level for all AM62 boards and remove it from any specific defconfig. Signed-off-by: Andrew Davis <[email protected]>
2024-03-06arm: mach-k3: Add config option for setting OP-TEE addressAndrew Davis
Much like we have for ATF, OP-TEE has a standard address that we load it too and run it from. Add a Kconfig item for this to remove some hard-coding and allow this address to be more easily changed. Signed-off-by: Andrew Davis <[email protected]> Acked-by: Bryan Brattlof <[email protected]> Reviewed-by: Neha Malcom Francis <[email protected]>
2024-03-06arm: mach-k3: Add default ATF location for AM62/AM62aAndrew Davis
There is a default ATF load address that is used for devices that have ATF running in SRAM. For AM62 and AM62a, ATF runs from DRAM. Instead of having to override the address in every defconfig, make add a default for these ATF in DRAM devices. Signed-off-by: Andrew Davis <[email protected]> Acked-by: Bryan Brattlof <[email protected]> Reviewed-by: Neha Malcom Francis <[email protected]>
2024-03-05arm: dts: k3-binman: Make optee optional as requirementMichael Trimarchi
Allow boards that use ti_spl_template to not use optee part in configuration. Vendor can have module with 256 Mb of memory and they try to optimize the available memory just using the essential components. This change allow to remove tee from configuration without binman fail. configurations { default = "conf-0"; conf-0 { description = "k3-am62_ccm_m3"; firmware = "atf"; loadables = "dm", "spl"; fdt = "fdt-0"; }; }; Signed-off-by: Michael Trimarchi <[email protected]>
2024-03-05Merge patch series "Enable OSPI on j721e"Tom Rini
Jonathan Humphreys <[email protected]> says: This series enables OSPI storage and boot.
2024-03-05arm: dts: k3-j721e-sk: Remove OSPI phypattern partitionJonathan Humphreys
The phy calibration pattern partition isn't needed as the Cadence driver isn't calibrating the phys. Signed-off-by: Jonathan Humphreys <[email protected]> Fixes: 58d61fb5a77e ("arm: dts: k3-j721e-sk: Add initial A72 specific dts support")
2024-03-05arm: mach-k3: j721e: Enable OSPI bootJonathan Humphreys
Add boot ROM XSPI bootmode, and set to BOOT_DEVICE_SPI if detected. Signed-off-by: Jonathan Humphreys <[email protected]> Reviewed-by: Udit Kumar <[email protected]>
2024-03-05configs: j721e: Enable OSPI memoryJonathan Humphreys
Set config values to enable OSPI functionality. Signed-off-by: Jonathan Humphreys <[email protected]> Reviewed-by: Udit Kumar <[email protected]>
2024-03-05Merge patch series "enable OSPI support on AM64x"Tom Rini
Jonathan Humphreys <[email protected]> says: This series enables OSPI support for AM64x by setting the proper configs, and DT entries for SPL.
2024-03-05arm: dts: k3-am642-evm/sk: Enable OSPI support in SPLJonathan Humphreys
Add bootph DT tags to enable OSPI in SPL. Set OSPI regs for R5 SPL to address OSPI's boot region. Signed-off-by: Jonathan Humphreys <[email protected]>
2024-03-05configs: am64x_evm_*_defconfig: Enable OSPI supportJonathan Humphreys
Add configs to support OSPI flash. Signed-off-by: Jonathan Humphreys <[email protected]>
2024-03-05arch/arm/mach-omap2/omap5/fdt.c: ft_fixup_clocks: use clock-output-names ↵Romain Naour
property as fallback (kernel 5.19+) Clock names has been updated in kernel 5.19+ with the removal of non-standard node names [1]. Due to this change, ft_opp_clock_fixups() doesn't work anymore since ft_fixup_clocks() is looking to the clock name and ft_opp_clock_fixups() error out with the following message: ft_fixup_clocks failed for DSP voltage domain: <valid offset/length> We can't use the new clock name since several clock are using the same generic name "clock". ft_opp_clock_fixups() is looking at the clocks node in cm_core_aon@0: /sys/firmware/devicetree/base/ocp/interconnect@4a000000/segment@0/target-module@5000/cm_core_aon@0/clocks ... clock@120 clock@160 clock@1a0 clock@1e0 clock@210 clock@234 clock@284 clock@2a8 clock@2d8 When fdt_subnode_offset() fail, we can look at clock-output-names property as fallback since it contain the previous clock name. libfdt doesn't provide any support to replace fdt_subnode_offset() by a new function looking for clock-output-names property instead of the node name. So we have to implement it in arch/arm/mach-omap2/omap5/fdt.c for now. [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e4920169e7a2a839836d3a0d8cda1bae8caa3056 Cc: Suman Anna <[email protected]> Cc: Tom Rini <[email protected]> Cc: Andrew Davis <[email protected]> Signed-off-by: Romain Naour <[email protected]>
2024-03-05virtio: fix get_config / set_config for legacy VirtIO targetsDmitry Baryshkov
The functions virtio_pci_get_config() and virtio_pci_set_config() don't take the offset into account when reading the config space. For example this manifests when U-Boot tries to read the MAC address of the VirtIO networking device. It reads 6 equa bytes instead of the proper addess. Fix those functions by taking the offset in the config space into account. Fixes: 4135e10732a0 ("virtio: Add virtio over pci transport driver") Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-03-05Merge patch series "Fix driver for misc/atsha204a"Tom Rini
Michał Barnaś <[email protected]> says: Fix the driver to behave like the chip datasheet requires. Improve wake up function to send low signal on SDA line for at least 60us as chip requires to wake up. Fix sleep function to move the chip into sleep mode, not into idle mode. Remove unnecessary for loop, which would never run for more than one iteration.
2024-03-05misc: atsha204a: fix wakeup functionMichał Barnaś
The ATSHA204A chip requires SDA line to go low for at least 60us to wake up the chip. Previous implementation did not meet this requirement due to the NAK received on bus and not sending the zeroes. The function to ignore the NAK and send bytes regardless is not supported in the u-boot making it impossible to wake up the chip this way. Instead, the bus speed, if needed, is set to lowest value and the message is sent to the address 0x0. This way, the address of zero makes the SDA line go low for about 80us, meeting the required time to wake up the chip. The zero length packet is not sent by the i2c, so the one byte is sent to the transfer function, but only the address is sent anyway. After sending the zero address, the bus speed is restored to the previous value if it was slowed down to wake up the chip. Signed-off-by: Michał Barnaś <[email protected]>
2024-03-05misc: atsha204a: fix sleep functionMichał Barnaś
Fix the sleep function to issue the sleep command instead of idle one. Signed-off-by: Michał Barnaś <[email protected]>
2024-03-05misc: atsha204a: remove broken for loopMichał Barnaś
Some previous commit changed the continue statement to return, making the for loop used to retry waking up the chip to always return after one iteration. This commit removes the loop, cleaning the code a little. Signed-off-by: Michał Barnaś <[email protected]>
2024-03-05Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-marvellTom Rini
- net: mv88e6xxx: fix missing SMI address initialization (Marek) - mvebu: turris_omnia: Enable networking via ethernet switch (Marek) - mvebu: helios-4: add config fragment for spi booting et al (Josua) - rng: Add Turris Mox rTWM RNG driver (Max)
2024-03-05Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxiTom Rini
One fix makes the reboot more robust on some older board, another one stabilises the initial clock setup on the A10/A20. Two patches make sure our DRAM init does not actually change the content of the DRAM array, which allows to use DRAM for Linux' pstore functionality. We get SPI support for U-Boot proper for one more SoC, that patch was lingering around for a while, and should not affect other SoCs, so I am merging this now. As an added bonus, we get the defconfig file for a new board, the DT was already synced from the kernel tree. The CI looked happy with changes, and I tested them on five different boards with different SoCs.
2024-03-05rng: Add Turris Mox rTWM RNG driverMax Resch
A RNG driver for Armada 3720 boards running the Turris Mox rWTM firmware from CZ.NIC in the secure processor. Signed-off-by: Max Resch <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-03-05board: helios-4: add config fragment for spi bootingJosua Mayer
Add a config fragment with required differences for booting from spi flash instead of sd-card (default). Settings for environment location are based on vendor u-boot: https://github.com/kobol-io/u-boot/blob/helios4/include/configs/helios4.h#L59 The fragment can be applied on top of helios4_defconfig by make: make helios4_defconfig spiboot.config Signed-off-by: Josua Mayer <[email protected]>
2024-03-05arm: mvebu: helios4_defconfig: enable setexpr commandJosua Mayer
Update the helios4 defconfig to enable the 'setexpr' command, which is a default and useful for various complex boot-scripts. Signed-off-by: Josua Mayer <[email protected]>
2024-03-05arm: dts: armada-38x-solidrun-microsom: configure i2c0 busJosua Mayer
SolidRun Armada-388 SoM has an i2c bus supporting on-som eeprom, and peripherals on a carrier. armada-38x.dtsi disables this bus by default, it should be enabled by som or carrier dts. Linux has moved i2c0 from helios-4 board dts to som dtsi, including status, pinctrl and clock speed. Copy these settings from mainline. This fixes accessing i2c bus from u-boot commandline. Signed-off-by: Josua Mayer <[email protected]>
2024-03-05arm: mvebu: turris_omnia: Enable networking via ethernet switchMarek Mojík
The Turris Omnia contains the Marvell 88E6176 ethernet switch. Add config options and device tree to enable the support. Signed-off-by: Marek Mojík <[email protected]> Signed-off-by: Marek Behún <[email protected]>
2024-03-05net: mv88e6xxx: fix missing SMI address initializationMarek Mojík
The mv88e6xxx driver does not currently initialize the smi_addr field, but instead keeps the default zero value. This leads to driver being unusable on devices where the switch is not on address zero of the mdio bus. Fix this problem by reading the SMI address from device tree. Signed-off-by: Marek Mojík <[email protected]> Reviewed-by: Marek Behún <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-03-05sunxi: restore modified memoryAndrey Skvortsov
Current sunxi DRAM initialisation code does several test accesses to the DRAM array to detect aliasing effects and so determine the correct row/column configuration. This changes the DRAM content, which breaks use cases like soft reset and Linux's ramoops mechanism. Fix this problem by saving and restoring the content of the DRAM cells that is used for the test writes. Signed-off-by: Andrey Skvortsov <[email protected]> Reviewed-by: Andre Przywara <[email protected]>
2024-03-05sunxi: reorganize mctl_mem_matches_* functionsAndrey Skvortsov
mctl_mem_matches and mctl_mem_matches_base identical functions. To avoid code duplication move them to dram_helpers and make mctl_mem_matches use generic mctl_mem_matches_base. Signed-off-by: Andrey Skvortsov <[email protected]> Reviewed-by: Andre Przywara <[email protected]>
2024-03-05usb: xhci-dwc3: Fix support for dis_enblslpm_quirkJonas Karlman
No device tree in U-Boot or linux use the wrong spelling used in code. Use correct property name as defined in dwc3 bindings. Fixes: 062790f46131 ("usb: xhci-dwc3: Add USB2 PHY configuration") Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Marek Vasut <[email protected]>
2024-03-04Merge tag 'u-boot-imx-master-20240304' of ↵Tom Rini
https://gitlab.denx.de/u-boot/custodians/u-boot-imx CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/19817 - Fix i.MX93 OP-TEE support. - Use the container image for i.MX93 revision A1. - Fix display regression on opos6uldev.
2024-03-04Merge branch '2024-03-04-assorted-TI-K3-updates' into nextTom Rini
- Merge assorted TI K3 platform / SoC updates
2024-03-04Merge patch series "Introduce initial TI's J784S4 and AM69 support"Tom Rini
Apurva Nandan <[email protected]> says: Hello Everyone! This series will introduce basic support (SD and UART) support for Texas Instruments J784S4 EVM. The J784S4 SoC device tree patches are taken from kernel patch submissions and will be updated as they are accepted and merged to the kernel tree. All other patches are specific to SPL and u-boot and do not have dependency on other trees. Appreciate a review for acceptance to u-boot tree. Here are some of the salient features of the J784S4 automotive grade application processor: The J784S4 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration in automotive, ADAS and industrial applications requiring AI at the network edge. This SoC extends the K3 Jacinto 7 family of SoCs with focus on raising performance and integration while providing interfaces, memory architecture and compute performance for multi-sensor, high concurrency applications. Some highlights of this SoC are: * Up to 8 Cortex-A72s, four clusters of lockstep capable dual Cortex-R5F MCUs, 4 C7x floating point vector DSPs with Matrix Multiply Accelerator(MMA) for deep learning and CNN. * 3D GPU: Automotive grade IMG BXS-4-64 MC1 * Vision Processing Accelerator (VPAC) with image signal processor and Depth and Motion Processing Accelerator (DMPAC) * Three CSI2.0 4L RX plus two CSI2.0 4L TX, two DSI Tx, one eDP/DP and one DPI interface. * Integrated gigabit ethernet switch, up to 8 ports (TDA4VH), two ports support 10Gb USXGMII; Two 4 lane PCIe-GEN3 controllers, USB3.0 Dual-role device subsystems, Up to 20 MCANs, among other peripherals. See J784S4 Technical Reference Manual (SPRUJ52 - JUNE 2022) for further details: http://www.ti.com/lit/zip/spruj52 In addtion, the J784S4 EVM board is designed for TI J784S4 SoC. It supports the following interfaces: * 32 GB DDR4 RAM * x2 Gigabit Ethernet interfaces capable of working in Switch and MAC mode * x1 Input Audio Jack, x1 Output Audio Jack * x1 USB2.0 Hub with two Type A host and x1 USB 3.1 Type-C Port * x2 4L PCIe connector * x1 UHS-1 capable micro-SD card slot * 512 Mbit OSPI flash, 1 Gbit Octal NAND flash, 512 Mbit QSPI flash, UFS flash. * x6 UART through UART-USB bridge * XDS110 for onboard JTAG debug using USB * Temperature sensors, user push buttons and LEDs * 40-pin User Expansion Connector * x2 ENET Expansion Connector, x1 GESI expander, x2 Display connector * x1 15-pin CSI header * x6 MCAN instances Schematics: https://www.ti.com/lit/zip/sprr458 AM69 SD mode bootlog: https://gist.githubusercontent.com/apurvanandan1997/1b2c55d0204ff0f5a47ebbc196a97e99/raw/ J784S4 SD mode bootlog: https://gist.githubusercontent.com/apurvanandan1997/5e2ef85ee4322798d22b57a60dc917db/raw/ eMMC UDA moode bootlog: https://gist.githubusercontent.com/apurvanandan1997/3cffada252d50a8aa0c00a91f1f2f856/raw/
2024-03-04dma: ti: k3-udma: Fix ring_idx to pair k3 nav ringsUdit Kumar
ring_idx was not correctly assigned in case of tflow_id is zero. Which leads to wrong pairing of DMA for drivers like OSPI. Fixes: 4312a1dfca26 ("dma: ti: k3-udma: Use ring_idx to pair k3 nav rings") Reviewed-by: Jai Luthra <[email protected]> Signed-off-by: Udit Kumar <[email protected]>
2024-03-04doc: board: ti: k3: Add J784S4 EVM and AM69 SK documentationApurva Nandan
TI K3 J784S4 and AM69 are new additions to the K3 SoC family. Add documentation about the J784S4 EVM and AM69 SK. Signed-off-by: Dasnavis Sabiya <[email protected]> Signed-off-by: Apurva Nandan <[email protected]> Reviewed-by: Neha Malcom Francis <[email protected]> Tested-by: Marcel Ziswiler <[email protected]> # AM69-SK
2024-03-04board: ti: rm-cfg: Update rm-cfg to reflect new resource reservationVishal Mahaveer
With the latest TIFS firmware, an additional virtual interrupt and event is reserved for TIFS usage on am62x and am62ax devices. Update the rm-cfg to reflect this new reservation. Signed-off-by: Vishal Mahaveer <[email protected]>
2024-03-04configs: am69_sk: Add defconfig for AM69 SK boardDasnavis Sabiya
Add defconfig for AM69 SK A72 and R5 configuration. This inlcudes and modifies the J784S4 EVM defconfigs: j784s4_evm_a72_defconfig -> am69_sk_a72_defconfig j784s4_evm_r5_defconfig -> am69_sk_r5_defconfig Signed-off-by: Dasnavis Sabiya <[email protected]> Signed-off-by: Apurva Nandan <[email protected]> Reviewed-by: Andrew Davis <[email protected]> Tested-by: Marcel Ziswiler <[email protected]> # AM69-SK
2024-03-04dma: ti: k3-udma: Fix error handling for setup_resources() in udma_probe()Siddharth Vadapalli
In udma_probe() the return value of setup_resources() is stored in the u32 "ch_count" member of "struct udma_dev", due to which any negative return value which indicates an error is masked. Fix this by storing the return value of setup_resources() in the already declared integer variable "ret", followed by assigning it to the "ch_count" member of "struct udma_dev" in case of no error. While at it, change the "return ret" at the end of udma_probe() to a "return 0", to explicitly indicate that probe was successful. Fixes: a8837cf43839 ("dma: ti: k3-udma: Query DMA channels allocated from Resource Manager") Signed-off-by: Siddharth Vadapalli <[email protected]> Reviewed-by: Dan Carpenter <[email protected]>
2024-03-04configs: j784s4_evm: Add defconfig for J784S4 EVM boardApurva Nandan
Add defconfigs for building R5 U-Boot SPL and A72 U-Boot. Signed-off-by: Hari Nagalla <[email protected]> Signed-off-by: Apurva Nandan <[email protected]> Tested-by: Marcel Ziswiler <[email protected]> # AM69-SK
2024-03-04configs: am64x_evm_r5_defconfig: enlarge simple malloc poolThomas Weißschuh
With the default size the stack grows into the malloc, pool leading to stack corruption and boot failure. Signed-off-by: Thomas Weißschuh <[email protected]>
2024-03-04arm: mach-k3: am62: Fixup thermal zone critical pointsJoao Paulo Goncalves
Read the max temperature for the SoC temperature grade from the hardware and change the critical trip nodes on each thermal zone of FDT at runtime so they are correct with the hardware value for its grade. Signed-off-by: Joao Paulo Goncalves <[email protected]> Signed-off-by: Francesco Dolcini <[email protected]>
2024-03-04arm: mach-k3: am62: Get soc max temperature by gradeJoao Paulo Goncalves
AM62x SoC is available in multiple temperature grade: - Commercial: 0° to 95° C - Industrial: -40° to 105° C - Automotive: -40° to 125° C Add a new function that returns the am62 max temperature value accordingly to its temperature grade in Celsius. Signed-off-by: Joao Paulo Goncalves <[email protected]> Signed-off-by: Francesco Dolcini <[email protected]>
2024-03-04arm: mach-k3: Move ARM64 specific code into new arm64 directoryAndrew Davis
Like we did with R5, move ARM64 code into a specific directory to make it clear what code is only meant to run on each core type. Signed-off-by: Andrew Davis <[email protected]>
2024-03-04arm: mach-k3: Move firewall removal into R5 directoryAndrew Davis
Firewalls are only ever removed by the R5 core, move this code into the R5 directory. Signed-off-by: Andrew Davis <[email protected]>
2024-03-04arm: mach-k3: am62a7: Disable firewalls only after loading SYSFWAndrew Davis
Currently we do this multiple times, instead just do it once after loading SYSFW in R5 SPL. Signed-off-by: Andrew Davis <[email protected]>
2024-03-04arm: mach-k3: Move tispl.bin loading into R5 directoryAndrew Davis
ATF, OPTEE, DM (tispl.bin) loading is only ever done by the R5 core, move the code into the R5 directory. Signed-off-by: Andrew Davis <[email protected]>