summaryrefslogtreecommitdiff
path: root/arch/arm/mach-k3
AgeCommit message (Collapse)Author
2019-10-25armv7R: K3: j721e: Add support for triggering ddr init from SPLLokesh Vutla
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: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-25arm: K3: Clean and invalidate Linux Image before jumping to LinuxLokesh Vutla
U-Boot cleans and invalidate L1 and L2 caches before jumping to Linux by set/way in cleanup_before_linux(). Additionally there is a custom hook provided to clean and invalidate L3 cache. Unfortunately on K3 devices(having a coherent architecture), there is no easy way to quickly clean all the cache lines for L3. The entire address range needs to be cleaned and invalidated by Virtual Address. This can be implemented using the L3 custom hook but it take lot of time to clean the entire address range. In the interest of boot time this might not be a viable solution. The best hit is to make sure the loaded Linux image is flushed so that the entire image is written to DDR from L3. When Linux starts running with caches disabled the full image is available from DDR. Reported-by: Andrew F. Davis <afd@ti.com> Reported-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11arm: k3: Use driver_name to get ti_sci handleLokesh Vutla
Use the driver name to get ti_sci handle rather than relying on just the FIRMWARE uclass. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11arm: k3: Add support for printing CPUINFOLokesh Vutla
Add support for printing CPU info for all K3 devices. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11armv8: K3: j721e: Updated ddr address regions in MMU tableKedar Chitnis
The A72 U-Boot code loads and boots a number of remote processors including the C71x DSP, both the C66_0 and C66_1 DSPs, and the various Main R5FSS Cores. In order to view the code loaded by the U-Boot by remote cores, U-Boot should configure the memory region with right memory attributes. Right now U-Boot carves out a memory region which is not sufficient for all the images to be loaded. So, increase this carve out region by 256MB. Signed-off-by: Kedar Chitnis <kedarc@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11armv8: K3: am65x: Update DDR address regions in MMU tableSuman Anna
The A53 U-Boot code can load and boot the MCU domain R5F cores (either a single core in LockStep mode or 2 cores in Split mode) to achieve various early system functionalities. Change the memory attributes for the DDR regions used by the remote processors so that the cores can see and execute the proper code loaded by U-Boot. These regions are currently limited to 0xa0000000 to 0xa2100000 as per the DDR carveouts assigned for these R5F cores in the overall DDR memory map. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-11arm: K3: sysfw-loader: Allow loading SYSFW via Y-ModemAndreas Dannenberg
In order to allow booting TI K3 family SoCs via Y-Modem add support for loading System Firmware by tapping into the associated SPL core loader function. In this context also make sure a console is available and if not go ahead and activate the early console feature which allows bringing up an alternate full console before the main console is activated. Such an alternate console is typically setup in a way that the associated UART can be fully initialized prior to SYSFW services being available. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2019-10-11arm: K3: common: Allow for early console functionalityAndreas Dannenberg
Implement an early console functionality in SPL that can be used before the main console is being brought up. This helps in situations where the main console is dependent on System Firmware (SYSFW) being up and running, which is usually not the case during the very early stages of boot. Using this early console functionality will allow for an alternate serial port to be used to support things like UART-based boot and early diagnostic messages until the main console is ready to get activated. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2019-10-04board: ti: am654: Disable TRNG node for HS devicesAndrew F. Davis
On HS devices the access to TRNG is restricted on the non-secure ARM side, disable the node in DT to prevent firewall violations. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-10-04arm: K3: Increase default SYSFW image size allocationAndrew F. Davis
The memory allocated to store the FIT image containing SYSFW and board configuration data is statically defined to the largest size expected. This was 269000 bytes but now needs to be grown to 276000 to make room for the signatures attached to the board configuration data on High Security devices. Signed-off-by: Andrew F. Davis <afd@ti.com>
2019-09-13arm: k3: Use get_ti_sci_handle() where ever possibleLokesh Vutla
Instead of calling uclass apis everywhere, use get_ti_sci_handle() when ever ti_sci is needed. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-09-13arm: k3: Fix getting ti_sci handleLokesh Vutla
API get_ti_sci_handle() is relying on the device-tree node name to be "dmsc" for probing the ti_sci device. But with the introduction of debug messages for dmsc, the node name changed to dmsc@44083000. Because of this ti_sci is never probed cause a boot failure. Instead of relying on device-tree node name, use the first available firmware node for probing ti_sci. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-08-12arm: K3: sysfw-loader: Do not require full printf() for version infoAndreas Dannenberg
A previous commit... commit 2a51e16bd57a ("configs: Make USE_TINY_PRINTF depend on SPL||TPL and be default") ...causes the System Firmware version string during SPL boot to no longer getting printed to the console as expected. To fix this issue rework the handling of that string to only use basic printf() syntax rather than for example disabling CONFIG_USE_TINY_PRINTF on affected devices, this way maintaining most of the memory size benefit the initial patch brings when it comes to SPL. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-07-26board: ti: j721e: Add board support for j721e evmLokesh Vutla
Add board specific initialization for j721e evm Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2019-07-26armv8: K3: j721e: Add custom MMU supportSuman Anna
The A72 U-Boot code loads and boots a number of remote processors including the C71x DSP, both the C66_0 and C66_1 DSPs, and the various Main R5FSS Cores. Change the memory attributes for the DDR regions used by the remote processors so that the cores can see and execute the proper code. A separate table based on the current AM65x table is added for J721E SoCs, since the number of remote processors and their DDR usage will be different between the two SoC families. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-26armv7R: K3: j721e: Load SYSFW binary and config from boot mediaAndreas Dannenberg
Use the System Firmware (SYSFW) loader framework to load and start the SYSFW as part of the J721E early initialization sequence. While at it also initialize the MCU_UART0 pinmux as it is used by SYSFW to print diagnostic messages. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-26armv7R: K3: j721e: Shut down R5 core after ATF startup on A72Lokesh Vutla
Populate the release_resources_for_core_shutdown() api with shutting down r5 cores so that it will by called just after jumping to ATF. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-26armv7R: K3: j721e: Store boot index from ROMAndreas Dannenberg
Obtain the boot index as left behind by the device boot ROM and store it in scratch pad SRAM for later use before it may get overwritten. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2019-07-26armv7R: K3: j721e: Unlock all applicable control MMR registersAndreas Dannenberg
To access various control MMR functionality the registers need to be unlocked. Do that for all control MMR regions in the MCU and MAIN domains. We may want to go back later and limit the unlocking that's being done. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2019-07-26armv7R: K3: j721e: Add support for boot device detectionLokesh Vutla
J721E 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: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
2019-07-26arm: K3: j721e: Add basic support for J721E SoC definitionLokesh Vutla
The J721E SoC belongs to the K3 Multicore SoC architecture platform, providing advanced system integration to enable lower system costs of automotive applications such as infotainment, cluster, premium Audio, Gateway, industrial and a range of broad market applications. This SoC is designed around reducing the system cost by eliminating the need of an external system MCU and is targeted towards ASIL-B/C certification/requirements in addition to allowing complex software and system use-cases. Some highlights of this SoC are: * Dual Cortex-A72s in a single cluster, three clusters of lockstep capable dual Cortex-R5F MCUs, Deep-learning Matrix Multiply Accelerator(MMA), C7x floating point Vector DSP, Two C66x floating point DSPs. * 3D GPU PowerVR Rogue 8XE GE8430 * Vision Processing Accelerator (VPAC) with image signal processor and Depth and Motion Processing Accelerator (DMPAC) * Two Gigabit Industrial Communication Subsystems (ICSSG), each with dual PRUs and dual RTUs * Two CSI2.0 4L RX plus one CSI2.0 4L TX, one eDP/DP, One DSI Tx, and up to two DPI interfaces. * Integrated Ethernet switch supporting up to a total of 8 external ports in addition to legacy Ethernet switch of up to 2 ports. * System MMU (SMMU) Version 3.0 and advanced virtualisation capabilities. * Upto 4 PCIe-GEN3 controllers, 2 USB3.0 Dual-role device subsystems, 16 MCANs, 12 McASP, eMMC and SD, UFS, OSPI/HyperBus memory controller, QSPI, I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals. * Two hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL management. * Configurable L3 Cache and IO-coherent architecture with high data throughput capable distributed DMA architecture under NAVSS * Centralized System Controller for Security, Power, and Resource Management (DMSC) See J721E Technical Reference Manual (SPRUIL1, May 2019) for further details: http://www.ti.com/lit/pdf/spruil1 Add base support for J721E SoC Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com>
2019-07-26armv7R: k3: Release all the exclusive devicesLokesh Vutla
Release all the exclusive devices held by SPL. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-26armv7R: K3: am654: Shut down R5 core after ATF startup on A53Andreas Dannenberg
Rather than simply parking the R5 core in WFE after starting up ATF on A53 instead use SYSFW API to properly shut down the R5 CPU cores as well as associated timer resources that were pre-allocated. This allows software further downstream to properly and gracefully bring the R5 cores back online if desired. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-17board: ti: am654: Use EEPROM-based board detectionAndreas Dannenberg
The TI AM654x EVM base board and the associated daughtercards have on- board I2C-based EEPROMs containing board configuration data. Use the board detection infrastructure introduced earlier to do the following: 1) Parse the AM654x EVM base board EEPROM and populate items like board name and MAC addresses into the TI common EEPROM data structure residing in SRAM scratch space 2) Check for presence of daughter card(s) by probing the associated presence signals via an I2C-based GPIO expander. Then, if such a card is found, parse the data such as additional Ethernet MAC addresses from its on-board EEPROM and populate into U-Boot accordingly 3) Dynamically create an U-Boot ENV variable called overlay_files containing a list of daugherboard-specific DTB overlays based on daughercards found. This patch adds support for the AM654x base board ("AM6-COMPROCEVM") as well as for the IDK ("AM6-IDKAPPEVM"), OLDI LCD ("OLDI-LCD1EVM") PCIe/USB3.0 ("SER-PCIEUSBEVM"), 2 Lane PCIe/USB2.0 ("SER-PCIE2LEVM"), and general purpuse ("AM6-GPAPPEVM") daughtercards. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-17arm: K3: am654: Map common EEPROM data into SRAM scratch spaceAndreas Dannenberg
The board detection scheme employed on various TI EVMs makes use of SRAM scratch space to share data read from an on-board EEPROM between the different bootloading stages. Map the associated definition that's used to locate this data into the SRAM scratch space we use on AM654x. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-17armV7R: K3: am654: Load SYSFW binary and config from boot mediaAndreas Dannenberg
Use the System Firmware (SYSFW) loader framework to load and start the SYSFW as part of the AM654 early initialization sequence. While at it also initialize the WKUP_UART0 pinmux as it is used by SYSFW to print diagnostic messages. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2019-07-17arm: K3: Introduce System Firmware loader frameworkAndreas Dannenberg
Introduce a framework that allows loading the System Firmware (SYSFW) binary as well as the associated configuration data from an image tree blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC RAW mode partition or sector. To simplify the handling of and loading from the different boot media we tap into the existing U-Boot SPL framework usually used for loading U-Boot by building on an earlier commit that exposes some of that functionality. Note that this initial implementation only supports FS and RAW-based eMMC/SD card boot. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-05-09arm: k3: config.mk: Use k3_gen_x509_cert.sh to generate boot imagesLokesh Vutla
Instead of overlading makefile, use the k3_gen_x509_cert.sh script to generate boot images. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-04-26arm: mach-k3: Add secure device build supportAndrew F. Davis
K3 HS devices require signed binaries for boot, use the SECDEV tools to sign the boot artifacts during build. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
2019-04-26arm: mach-k3: Add secure device supportAndrew F. Davis
K3 devices have High Security (HS) variants along with the non-HS already supported. Like the previous generation devices (OMAP/Keystone2) K3 supports boot chain-of-trust by authenticating and optionally decrypting images as they are unpacked from FIT images. Add support for this here. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
2019-04-26arm: K3: Avoid use of MCU_PSRAM0 before SYSFW is loadedAndrew F. Davis
On HS devices the 512b region of reset isolated memory called MCU_PSRAM0 is firewalled by default. Until SYSFW is loaded we cannot use this memory. It is only used to store a single value left at the end of SRAM by ROM that will be needed later. Save that value to a global variable stored in the .data section. This section is used as .bss will be cleared between saving this value and using it. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-04-12armv7R: K3: am654: Trigger panic on DDR init failuresAndreas Dannenberg
When initializing DDR from R5 SPL trigger U-Boot's panic facility rather than simply returning from the board init function as there is little point continuing code execution. Further, as panic implies a board reset, so using it might potentially allow to recover from this error in certain cases such as when the init failure was caused by a temporary glitch of some sorts. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-04-12arm: k3: Add support for updating msmc dt nodeLokesh Vutla
Certain parts of msmc sram can be used by DMSC or can be marked as L3 cache. Since the available size can vary, changing DT every time the size varies might be painful. So, query this information using TISCI cmd and fixup the DT for kernel. Fixing up DT does the following: - Create a sram node if not available - update the reg property with available size - update ranges property - loop through available sub nodes and delete it if: - mentioned size is out if available range - subnode represents l3 cache or dmsc usage. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-04-12arm: k3: Add a wrapper to get tisci handleLokesh Vutla
Create a wrapper to get the ti sci handle. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-02-09arm: mach-k3: common: Clean up ATF image startup functionAndreas Dannenberg
Perform some cosmetic cleanup of the ATF image startup function, namely fixing a spelling mistake, capitalization of a few words, spacing, as well aligning how errors are printed and as using panic() for cases that were using a combination of printf() + hang(). Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-02-01spl: Kconfig: Replace CONFIG_SPL_EXT_SUPPORT to CONFIG_SPL_FS_EXT4Tien Fong Chee
Replace CONFIG_SPL_EXT_SUPPORT to CONFIG_SPLY_FS_EXT4 so both obj-$(CONFIG_$(SPL_)FS_EXT4) and CONFIG_IS_ENABLED(FS_EXT4) can be used to control the build in both SPL and U-Boot. Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-02-01spl: Kconfig: Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FATTien Fong Chee
Replace CONFIG_SPL_FAT_SUPPORT with CONFIG_SPL_FS_FAT so obj-$(CONFIG_$(SPL_)FS_FAT) can be used to control the build in both SPL and U-Boot. Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com> Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-01-24arm64: zynqmp: Move SoC sources to mach-zynqmpMichal Simek
Similar changes was done for Zynq in past and this patch just follow this pattern to separate cpu code from SoC code. Move arch/arm/cpu/armv8/zynqmp/* -> arch/arm/mach-zynqmp/* And also fix references to these files. Based on "ARM: zynq: move SoC sources to mach-zynq" (sha1: 0107f2403669f764ab726d0d404e35bb9447bbcc) Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2018-12-26arm: K3: Fix usage of CONFIG_SYS_K3_KEYLokesh Vutla
For signing the tiboot3.bin image, an optional KEY file can be passed using CONFIG_SYS_K3_KEY. Right now, Makefile scripts directly takes the config value and uses it for signing. This is okay if the build directory is a sub-directory of source tree, otherwise it fails. Fix it by using the path relative to the source tree. Reported-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-11-26armv7r: K3: Allow SPL to run only on core 0Lokesh Vutla
Based on the MCU R5 efuse settings, R5F cores in MCU domain either work in split mode or in lock step mode. If efuse settings are in lockstep mode: ROM release R5 cores and SPL continues to run on the R5 core is lockstep mode. If efuse settings are in split mode: ROM releases both the R5 cores simultaneously and allow SPL to run on both the cores. In this case it is bootloader's responsibility to detect core 1 and park it. Else both the core will be running bootloader independently which might result in an unexpected behaviour. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2018-11-16armv7R: K3: am654: Add support for triggering ddr init from SPLLokesh Vutla
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(). Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-11-16armv7R: K3: am654: Add support to start ATF from R5 SPLLokesh Vutla
Considering the boot time requirements, Cortex-A core should be able to start immediately after SPL on R5. Add support for the same. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-11-16armv7R: K3: am654: Add support for generating build targetsLokesh Vutla
Update Makefiles to generate: - tiboot3.bin: Image format that can be processed by ROM. Below is the tiboot3.bin image format that is required by ROM: _______________________ | X509 | | Certificate | | ____________________ | | | | | | | u-boot-spl.bin | | | | | | | |___________________| | |_______________________| Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2018-11-16armv7R: K3: am654: Enable MPU regionsLokesh Vutla
Enable MPU regions for AM654 evm: - Region0: 0x00000000 - 0xFFFFFFFF: Device memory, not executable - Region1: 0x41c00000 - 0x42400000: Normal, executable, WB, Write alloc - Region2: 0x80000000 - 0xFFFFFFFF: Normal, executable, WB, Write alloc - region3-15: Disabled With this dcache can be enabled either in SPL or U-Boot. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-11-16ram: Introduce K3 AM654 DDR Sub System driverLokesh Vutla
K3 based AM654 devices has DDR memory subsystem that comprises Synopys DDR controller, Synopsis DDR phy and wrapper logic to intergrate these blocks into the device. This DDR subsystem provides an interface to external SDRAM devices. Adding support for the initialization of the external SDRAM devices by configuring the DDRSS registers and using the buitin PHY routines. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Schuyler Patton <spatton@ti.com> Signed-off-by: James Doublesin <doublesin@ti.com>
2018-10-10arm: K3: am654: Add support for getting boot modeAndrew F. Davis
Read the boot mode register to find the boot mode. Only use eMMC boot0 mode when the mode is eMMC boot (called BOOT_DEVICE_MMC1 currently due to current conflating of boot mode and boot device), and not iff the boot device is MMC port 0. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-10-10arm: K3: am654: Choose MMC boot device based on boot portAndrew F. Davis
For most devices the boot mode maps directly to the boot device. For MMC this is not the case as we have two MMC boot modes and two MMC boot devices (ports). Check the boot port to determine which MMC device was our boot device. Make this change for both primary and secondary boot modes. Signed-off-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11board: ti: am654: a53: Add initial support for am654Lokesh Vutla
Add initial support for AM654 based EVM running on A53. Enable 4GB of DDR available on the EVM so that kernel DTB file can be updated accordingly. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> [Andreas: Added 4GB ddr support] Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
2018-09-11armv8: K3: am654: Add support for generating build targetsLokesh Vutla
Update Makefile to generate - tispl.bin: First stage bootloader on ARMv8 core - u-boot.img: Second stage bootloader on ARMv8 core. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
2018-09-11armv8: K3: am654: Add custom MMU supportLokesh Vutla
Add MMU mappings for AM654 SoC. Reviewed-by: Tom Rini <trini@konsulko.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>