summaryrefslogtreecommitdiff
path: root/arch/arm/mach-k3
AgeCommit message (Collapse)Author
2022-03-04arm: mach-k3: am6_init: Use CONFIG_TI_I2C_BOARD_DETECTChristian Gmeiner
We only want to call do_board_detect() if CONFIG_TI_I2C_BOARD_DETECT is set. Same as done for am64. This makes it possible to add a custom am65 based board design to U-Boot that does not use this board detection mechanism. Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2022-02-16arm: j721e: Add support for selecting DT based on board nameSinthu Raja
Enable support for selecting DTB from FIT within SPL based on the board name read from EEPROM. This will help to use single defconfig for both EVM and SK. Signed-off-by: Sinthu Raja <sinthu.raja@ti.com>
2022-02-08drivers: misc: Makefile: Enable fs_loader compilation at SPL LevelKeerthy
Enable fs_loader compilation at SPL Level. Signed-off-by: Keerthy <j-keerthy@ti.com> [Amjad: fix compilation failures for J721e platform] Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
2022-02-08arm: K3: Add basic support for J721S2 SoC definitionDavid Huang
Add basic support for J721S2 SoC definition Signed-off-by: David Huang <d-huang@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Hari Nagalla <hnagalla@ti.com>
2022-01-15mach-k3: am64_spl: Alias Ethernet RGMII boot to CPGMACVignesh Raghavendra
This is required to enables spl_net boot on AM64x Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2022-01-15mach-k3: am642_init: Probe AM65 CPSW NUSS for R5/A53 SPLVignesh Raghavendra
In order to support Ethernet boot on AM64x, probe AM65 CPSW NUSS. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2022-01-15mach-k3: common: Instantiate AM65 CPSW NUSS wrapperVignesh Raghavendra
Probe toplevel AM65 CPSW NUSS driver from misc_init_r() when driver is enabled. Since driver is modeled as UCLASS_MISC, we need to explicitly probe the driver. Use common misc_init_r() that entire K3 family of SoCs. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
2022-01-15ARM: mach-k3: sysfw-loader: Copy sysfw.itb to OCRAM in OSPI/SPI bootmodeVignesh Raghavendra
In case of xSPI bootmode OSPI flash is in DDR mode and needs to be accessed in multiple of 16bit accesses Hence we cannot parse sysfw.itb FIT image directly on OSPI flash via MMIO window. So, copy the image to internal on-chip RAM before parsing the image. Moreover, board cfg data maybe modified by ROM/TIFS in case of HS platform and thus cannot reside in OSPI/xSPI and needs to be copied over to internal OCRAM. This unblocks OSPI/xSPI boot on HS platforms Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Dave Gerlach <d-gerlach@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Acked-by: Pratyush Yadav <p.yadav@ti.com>
2022-01-15arm: mach-k3: am642_init: Unlock MCU PADCFG regsMichael Liebert
Currently only the PADCFG registers of the main domain are unlocked. Also unlock PADCFG registers of MCU domain, so MCU pin muxing can be configured by u-boot or Linux. Signed-off-by: Michael Liebert <liebert@ibv-augsburg.de> Tested-by: Christian Gmeiner <christian.gmeiner@gmail.com> Acked-by: Nishanth Menon <nm@ti.com>
2021-10-03board: siemens: Add support for SIMATIC IOT2050 devicesJan Kiszka
This adds support for the IOT2050 Basic and Advanced devices. The Basic used the dual-core AM6528 GP processor, the Advanced one the AM6548 HS quad-core version. Both variants are booted via a Siemens-provided FSBL that runs on the R5 cores. Consequently, U-Boot support is targeting the A53 cores. U-Boot SPL, ATF and TEE have to reside in SPI flash. Full integration into a bootable image can be found on https://github.com/siemens/meta-iot2050 Based on original board support by Le Jin, Gao Nian and Chao Zeng. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
2021-09-27Merge tag 'v2021.10-rc5' into nextTom Rini
Prepare v2021.10-rc5
2021-09-17arm: mach-k3: common: Make sure firmware sections are loaded prior to armv8 ↵Nishanth Menon
startup With Device Manager firmware in an elf file form, we cannot load the FIT image to the exact same address as any of the executable sections of the elf file itself is located. However, the device tree descriptions for the ARMV8 bootloader/OS includes DDR regions only the final sections in DDR where the Device Manager firmware is actually executing out of. As the R5 uC is usually operating at a slower rate than an ARMv8 MPU, by starting the Armv8 ahead of parsing the elf and copying the correct sections to the required memories creates a race condition where the ARMv8 could overwrite the elf image loaded from the FIT image prior to the R5 completing parsing and putting the correct sections of elf in the required memory locations. OR create rather obscure debug conditions where data in the section is being modified by ARMV8 OS while the elf copy is in progress. To prevent all these conditions, lets make sure that the elf parse and copy operations are completed ahead of ARMv8 being released to execute. We will pay a penalty of elf copy time, but that is a valid tradeoff in comparison to debug of alternate scenarios. Signed-off-by: Nishanth Menon <nm@ti.com>
2021-09-17arm: mach-k3: am6_init: Prioritize MSMC traffic over DDR in NAVSS NorthbridgeRoger Quadros
NB0 is bridge to SRAM and NB1 is bridge to DDR. To ensure that SRAM transfers are not stalled due to delays during DDR refreshes, SRAM traffic should be higher priority (threadmap=2) than DDR traffic (threadmap=0). This fixup is critical to provide deterministic access latency to MSMC from ICSSG, it applies to all AM65 silicon revisions and is due to incorrect reset values (has no erratum id) and statically setting things up should be done independent of usecases and board. This specific style of Northbridge configuration is specific only to AM65x devices, follow-on K3 devices have different data prioritization schemes (ASEL and the like) and hence the fixup applies purely to AM65x. Without this fix, ICSSG TX lock-ups due to delays in MSMC transfers in case of SR1 devices, on SR2 devices, lockups were not observed so far but high retry rates of ICSSG Ethernet (icssg-eth) and, thus, lower throughput. Signed-off-by: Roger Quadros <rogerq@ti.com> Acked-by: Andrew F. Davis <afd@ti.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Benoit Parrot <bparrot@ti.com> [Jan: rebased, dropped used define, extended commit log] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> [Nishanth: Provide relevant context in the commit message] Signed-off-by: Nishanth Menon<nm@ti.com>
2021-09-17clk: ti: k3: Update driver to account for divider flagsSuman Anna
The K3 SoCs have some PLL output clocks (POSTDIV clocks) which in turn serve as inputs to other HSDIV output clocks. These clocks use the actual value to compute the divider clock rate, and need to be registered with the CLK_DIVIDER_ONE_BASED flags. The current k3-clk driver and data lacks the infrastructure to pass in divider flags. Update the driver and data to account for these divider flags. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-09-17arm: mach-k3: Add note to auto-generated filesDave Gerlach
Add a note to the automatically generated clk-data and dev-data files for j721e and j7200 to indicate that they are in fact auto-generated and should not be hand edited. Also adjust TI URL to use https instead of http and also add an empty line before first header inclusion. Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-09-17arm: mach-k3: j7200: Fix clk-data parenting for postdiv PLL clocksSuman Anna
The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2 divisors to generate the final FOUTPOSTDIV clock. These are in sequence with POSTDIV2 following the POSTDIV1 clock. The current J7200 clock data has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is opposite of the actual implementation. Fix the data by simply adjusting the register bit-shifts. The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0 register values, fix these as well. Fixes: 277729eaf373 ("arm: mach-k3: Add platform data for j721e and j7200") Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-09-17arm: mach-k3: j721e: Fix clk-data parenting for postdiv PLL clocksSuman Anna
The TI K3 Fractional PLLs use two programmable POSTDIV1 and POSTDIV2 divisors to generate the final FOUTPOSTDIV clock. These are in sequence with POSTDIV2 following the POSTDIV1 clock. The current J721E clock data has the POSTDIV2 clock as the parent for the POSTDIV1 clock, which is opposite of the actual implementation. Fix the data by simply adjusting the register bit-shifts. The Main PLL1 POSTDIV clocks were also defined incorrectly using Main PLL0 register values, fix these as well. Fixes: 277729eaf373 ("arm: mach-k3: Add platform data for j721e and j7200") Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-09-17arm: mach-k3: common: Add a release_resources_for_core_shutdown() stubSuman Anna
Add a weak release_resources_for_core_shutdown() stub implementation that can be overridden by actual implementation if a SoC supports that function. Signed-off-by: Suman Anna <s-anna@ti.com> Reviewed-by: Nishanth Menon <nm@ti.com>
2021-09-04mmc: Rename MMC_SUPPORT to MMCSimon Glass
Rename these options so that CONFIG_IS_ENABLED can be used with them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> [trini: Fixup some incorrect renames] Signed-off-by: Tom Rini <trini@konsulko.com>
2021-07-27arm: mach-k3: Cleanup common start_non_linux_remote_cores()Suman Anna
The mach-k3 common code defined a weak start_non_linux_remote_cores() function so that the proper implementation can be plugged in the SoC-specific source files. This won't be needed anymore, so remove the the common code. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726211311.5977-4-s-anna@ti.com
2021-07-27arm: mach-k3: j721e: Cleanup MAIN R5 boot code from R5 SPLSuman Anna
The common J7 specific start_non_linux_remote_cores() override function implements the logic to load and boot the Main R5FSS Core0 from R5 SPL. This won't be supported any more for either J721E or J7200 after the R5 SPL rearchitecture for the System Firmware split into TI Foundation Security (TIFS) and Device Management (DM) firmwares. So, cleanup the corresponding code and the related SPL env variables. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726211311.5977-3-s-anna@ti.com
2021-07-27arm: mach-k3: j721e: Move booting of Main R5FSS Core0 to A72 U-BootSuman Anna
The Main R5FSS Core0 on J721E SoCs is originally booted from R5 SPL itself to achieve certain product-level early-boot metrics. This is no longer supported after the R5 SPL re-architecture (support merged for v2021.10-rc1). Move the booting of this core altogether from R5 SPL to A72 U-Boot. The env variables are left as is for now, and will be cleaned up in a subsequent patch. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726211311.5977-2-s-anna@ti.com
2021-07-27arch: arm: mach-k3: am642_init: Correct the function name spl_boot_mode() to ↵Aswath Govindraju
spl_mmc_boot_mode() Function spl_boot_mode() is called in common/spl/spl_mmc.c, to find the boot mode for a given boot device. This function was renamed to spl_mmc_boot_mode() by commit e97590654aea4c964f49bd915543a417d0c76996. Therefore, rename spl_boot_mode to spl_mmc_boot_mode. Fixes: 57dba04afbb7 ("arm: mach-k3: am642: Add support for boot device detection") Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726152807.22991-2-a-govindraju@ti.com
2021-07-15arm: mach-k3: am642_init: Add missing ddr guardGowtham Tammana
The `struct udevice *` reference is needed for either of the K3_LOAD_SYSFW, K3_AM64_DDRSS config guards. Adding the missing K3_AM64_DDRSS guard. Signed-off-by: Gowtham Tammana <g-tammana@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210624171614.14244-1-g-tammana@ti.com
2021-06-11arm: mach-k3: j721e_init: Force early probe of clk-k3 driverDave Gerlach
Force the clk-k3 driver to probe early during R5 SPL boot to ensure the default system clock configuration is completed. Many other drivers assume a default state of the clock tree and it is currently possible for them to probe before clk-k3 depending on the exact system configuration. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Reported-by: Keerthy <j-keerthy@ti.com> Tested-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11arm: mach-k3: sysfw-loader: pass boardcfg to sciserverTero Kristo
Copy the contents of the board config loaded from sysfw.itb into an EXTBOOT shared memory buffer that gets passed to sciserver. This only needs to be done if EXTBOOT area has not been populated by ROM code yet. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11arm: mach-k3: common: Drop main r5 startDave Gerlach
Only start-up the non-linux remote cores if we are running in legacy boot mode. HSM rearch is not yet supporting this. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11arm: mach-k3: do board config for PM only if supportedTero Kristo
If the raw PM support is built in, we are operating in the split firmware approach mode where PM support is not available. In this case, skip the board config for this. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11arm: mach-k3: add support for detecting firmware images from FITTero Kristo
Add callback routines for parsing the firmware info from FIT image, and use the data to boot up ATF and the MCU R5 firmware. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11arm: mach-k3: Add platform data for j721e and j7200Dave Gerlach
Add platform clock and powerdomain data for J721e and J7200. This data is used by the corresponding drivers to register all the required device clocks and powerdomains. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11tools: k3_fit_atf: add DM binary to the FIT imageTero Kristo
Add DM (device manager) firmware image to the fit image that is loaded by R5 SPL. This is needed with the HSM rearch where the firmware allocation has been changed slightly. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11common: fit: Update board_fit_image_post_process() to pass fit and node_offsetLokesh Vutla
board_fit_image_post_process() passes only start and size of the image, but type of the image is not passed. So pass fit and node_offset, to derive information about image to be processed. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-11arm: mach-k3: introduce new config option for sysfw splitTero Kristo
On J7 family of SoCs (J721E and J7200), sysfw is being split to be run under two cores, TIFS portion on DMSC core, and DM firmware under MCU R5. As MCU R5 is also used to run one phase of the bootloader, we must prevent access from here towards sysfw services. To support this, add new config option which can be used to detect presence of RM/PM sysfw services. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tero Kristo <kristo@kernel.org>
2021-06-09configs: am64x_evm_*_defconfig: Rearrange the components in SRAM to satisfy ↵Aswath Govindraju
the limitations for USB DFU boot mode For USB DFU boot mode there is a limitation on the load address of boot images that they have to be less than 0x70001000. Therefore, move the SPL_TEXT_BASE address to 0x70000000. Currently ATF is being loaded at 0x70000000, if the SPL is being loaded at 0x70000000 then ATF would overwrite SPL image when loaded. Therefore, move the location of ATF to a latter location in SRAM, past the SPL image. Also rearrange the EEPROM and BSS data on top of ATF. Given below is the placement of various data sections in SRAM ┌──────────────────────────────────────┐0x70000000 │ │ │ │ │ │ │ SPL IMAGE (Max size 1.5 MB) │ │ │ │ │ │ │ ├──────────────────────────────────────┤0x7017FFFF │ │ │ SPL STACK │ │ │ ├──────────────────────────────────────┤0x70192727 │ GLOBAL DATA(216 B) │ ├──────────────────────────────────────┤0x701927FF │ │ │ INITIAL HEAP (32 KB) │ │ │ ├──────────────────────────────────────┤0x7019A7FF │ │ │ BSS (20 KB) │ ├──────────────────────────────────────┤0x7019F7FF │ EEPROM DATA (2 KB) │ ├──────────────────────────────────────┤0x7019FFFF │ │ │ │ │ ATF (123 KB) │ │ │ │ │ ├──────────────────────────────────────┤0x701BEBFB │ BOOT PARAMETER INDEX TABLE (5124 B)│ ├──────────────────────────────────────┤0x701BFFFF │ │ │SYSFW FIREWALLED DUE TO A BUG (128 KB)│ │ │ ├──────────────────────────────────────┤0x701DFFFF │ │ │ DMSC CODE AREA (128 KB) │ │ │ └──────────────────────────────────────┘0x701FFFFF Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210604163043.12811-9-a-govindraju@ti.com
2021-06-09arm: mach-k3: am642_init: Do USB fixups to facilitate host and device boot modesAswath Govindraju
U-Boot either supports USB host or device mode for a node at a time in the device tree nodes. To support both host and dfu bootmodes, dr_mode is set to "peripheral" by default and then fixed based on the mode selected by the boot mode config dip switches on the board. This needs to happen before the cdns3 generic layer binds the usb device to a host or a device driver. Therefore, use fdtdec_setup_board() implementation to fixup the device tree property. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210604163043.12811-4-a-govindraju@ti.com
2021-06-09arm: mach-k3: am642_init: Add support for USB boot modeAswath Govindraju
Add support for identifying USB host and device boot modes Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210604163043.12811-3-a-govindraju@ti.com
2021-06-09tools: k3_fit_atf: Add support for providing ATF load address using a ↵Aswath Govindraju
Kconfig symbol Add support for providing ATF load address with a Kconfig symbol. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20210604163043.12811-2-a-govindraju@ti.com
2021-05-24treewide: Convert macro and uses of __section(foo) to __section("foo")Marek Behún
This commit does the same thing as Linux commit 33def8498fdd. Use a more generic form for __section that requires quotes to avoid complications with clang and gcc differences. Remove the quote operator # from compiler_attributes.h __section macro. Convert all unquoted __section(foo) uses to quoted __section("foo"). Also convert __attribute__((section("foo"))) uses to __section("foo") even if the __attribute__ has multiple list entry forms. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2021-05-12arm: am64x: Add support for selecting DT based on EEPROMLokesh Vutla
Enable support for selecting DTB within SPL based on EEPROM. This will help to use single defconfig for both EVM and SK Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2021-05-12board: ti: am64x: Add support for reading eeprom dataLokesh Vutla
I2C EEPROM data contains the board name and its revision. Add support for: - Reading EEPROM data and store a copy at end of SRAM - Updating env variable with relevant board info - Printing board info during boot. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2021-05-12arm: mach-k3: am642: Add support for triggering ddr init from SPLDave Gerlach
In SPL, DDR should be made available by the end of board_init_f() so that apis in board_init_r() can use ddr. Adding support for triggering DDR initialization from board_init_f(). Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-05-12board: ti: am64x: Add board support for am64x evmDave Gerlach
Add board specific initialization for am64x based boards. Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-05-12armv8: mach-k3: am642: Add custom MMU supportKeerthy
Change the memory attributes for the DDR regions used by the remote processors on AM65x so that the cores can see and execute the proper code. A separate table based on the previous K3 SoCs is introduced since the number of remote processors and their DDR usage is different between the SoC families. Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-05-12arm: mach-k3: am642: Shut down R5 core after ATF startup on A53Suman Anna
The AM642 SoCs use the Main R5FSS0 as a boot processor, and runs the R5 SPL that performs the initialization of the System Controller processor and starting the Arm Trusted Firmware (ATF) on the Arm Cortex A53 cluster. The Core0 serves as this boot processor and is parked in WFE after all the initialization. Core1 does not directly participate in the boot flow, and is simply parked in a WFI. Power down these R5 cores (and the associated RTI timer resources that were indirectly powered up) after starting up ATF on A53 by using the appropriate SYSFW API in release_resources_for_core_shutdown(). This allows these Main R5F cores to be further controlled from the A53 to run regular applications. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-05-12arm: mach-k3: am642: Use mmc start and stop callbacksDave Gerlach
To avoid any glitches on MMC clock line, make use of pm per and post callbacks when loading sysfw. Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-05-12arm: mach-k3: am642: Load SYSFW binary and config from boot mediaDave Gerlach
Use the System Firmware (SYSFW) loader framework to load and start the SYSFW as part of the AM642 early initialization sequence. Also make use of existing logic to detect if ROM has already loaded sysfw and avoided attempting to reload and instead just prepare to use already running firmware. While at it also initialize the MAIN_UART1 pinmux as it is used by SYSFW to print diagnostic messages. Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-05-12arm: mach-k3: am642: Store boot info from ROMDave Gerlach
For AM642, ROM supports loading system firmware directly from boot image. ROM passes information about the number of images that are loaded to bootloader at a specific address that is temporary. Add support for storing this information somewhere permanent before it gets corrupted. Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-05-12arm: mach-k3: am642: Unlock all applicable control MMR registersDave Gerlach
To access various control MMR functionality the registers need to be unlocked. Do that for all control MMR regions in the MAIN domain. Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-05-12arm: mach-k3: am642: Add support for boot device detectionKeerthy
AM642 allows for booting from primary or backup boot media. Both media can be chosen individually based on switch settings. ROM looks for a valid image in primary boot media, if not found then looks in backup boot media. In order to pass this boot media information to boot loader, ROM stores a value at a particular address. Add support for reading this information and determining the boot media correctly. Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
2021-05-12arm: mach-k3: Add basic support for AM642 SoC definitionDave Gerlach
The AM642 SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration to enable applications such as Motor Drives, PLC, Remote IO and IoT Gateways. Some highlights of this SoC are: * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F MCUs, and a single Cortex-M4F. * Two Gigabit Industrial Communication Subsystems (ICSSG). * Integrated Ethernet switch supporting up to a total of two external ports. * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other peripherals. * Centralized System Controller for Security, Power, and Resource Management (DMSC). See AM64X Technical Reference Manual (SPRUIM2, Nov 2020) for further details: https://www.ti.com/lit/pdf/spruim2 Signed-off-by: Dave Gerlach <d-gerlach@ti.com>