aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-k3
Commit message (Collapse)AuthorAgeFilesLines
* misc: fs_loader: Add function to get the chosen loaderSean Anderson2023-01-121-1/+1
| | | | | | | | | | | | | | The fs_loader device is used to pull in settings via the chosen node. However, there was no library function for this, so arria10 was doing it explicitly. This function subsumes that, and uses ofnode_get_chosen_node instead of navigating the device tree directly. Because fs_loader pulls its config from the environment by default, it's fine to create a device with nothing backing it at all. Doing this allows enabling CONFIG_FS_LOADER without needing to modify the device tree. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
* arm: mach-k3: copy bootindex to OCRAM for main domain SPLBryan Brattlof2023-01-103-4/+33
| | | | | | | | | | | | | | | | | | | Texas Instruments has begun enabling security settings on the SoCs it produces to instruct ROM and TIFS to begin protecting the Security Management Subsystem (SMS) from other binaries we load into the chip by default. One way ROM and TIFS do this is by enabling firewalls to protect the OCSRAM and HSM RAM regions they're using during bootup. The HSM RAM the wakeup SPL is in is firewalled by TIFS to protect itself from the main domain applications. This means the 'bootindex' value in HSM RAM, left by ROM to indicate if we're using the primary or secondary boot-method, must be moved to OCSRAM (that TIFS has open for us) before we make the jump to the main domain so the main domain's bootloaders can keep access to this information. Signed-off-by: Bryan Brattlof <bb@ti.com>
* arm64:mach-k3 am625_init: Correct boot mode detectionMartyn Welch2023-01-101-10/+9
| | | | | | | | | | | | | | | | | | | | The boot mode detection assumes that BOOT_DEVICE_MMC2 should always result in MMCSD_MODE_FS, but MMCSD_MODE_RAW is also a valid option for this port. The current logic also avoids looking at the bootmode pin strapping, which should be the primary means of determining whether a device is being booted in MMCSD_MODE_EMMCBOOT mode. Switch around the logic to check the boot mode to determine whether the eMMC boot mode is expected or MMC/SD boot mode. From there we can look at the boot mode config if in MMC/SD boot mode to determine whether to attempt RAW or FS based booting. This change allows U-Boot to also be successfully booted from RAW offsets in addition to from a filesystem. Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
* arm: mach-k3: am62a: introduce auto-generated SoC dataBryan Brattlof2022-12-093-0/+396
| | | | | | | Introduce the auto-generated clock tree and power domain data needed to attach the am62a into the power-domain and clock frameworks of uboot Signed-off-by: Bryan Brattlof <bb@ti.com>
* arm: mach-k3: introduce basic files to support the am62aBryan Brattlof2022-12-098-7/+396
| | | | | | | Introduce the mach-k3 files needed to properly boot TI's am62a SoC family of devices Signed-off-by: Bryan Brattlof <bb@ti.com>
* global: Move remaining CONFIG_SYS_* to CFG_SYS_*Tom Rini2022-12-051-1/+1
| | | | | | | | | | The rest of the unmigrated CONFIG symbols in the CONFIG_SYS namespace do not easily transition to Kconfig. In many cases they likely should come from the device tree instead. Move these out of CONFIG namespace and in to CFG namespace. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* global: Move remaining CONFIG_SYS_SDRAM_* to CFG_SYS_SDRAM_*Tom Rini2022-12-052-2/+2
| | | | | | | | | | The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM namespace do not easily transition to Kconfig. In many cases they likely should come from the device tree instead. Move these out of CONFIG namespace and in to CFG namespace. Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* arm: mach-k3: fix spelling mistake "entended" -> "extended"Bryan Brattlof2022-11-248-8/+8
| | | | | | the macro for the boot data location from rom is misspelled. fix it Signed-off-by: Bryan Brattlof <bb@ti.com>
* Rename CONFIG_SYS_TEXT_BASE to CONFIG_TEXT_BASESimon Glass2022-10-312-2/+2
| | | | | | | | | The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE and this makes it imposible to use CONFIG_VAL(). Rename it to resolve this problem. Signed-off-by: Simon Glass <sjg@chromium.org>
* arm: mach-k3: Move hardware handling to common filesAndrew Davis2022-10-187-106/+32
| | | | | | | | | These hardware register definitions are common for all K3, remove duplicate data them by moving them to hardware.h. While here do some minor whitespace cleanup + grouping. Signed-off-by: Andrew Davis <afd@ti.com>
* arm: mach-k3: security: Use dma-mapping for cache opsAndrew Davis2022-10-181-8/+6
| | | | | | | This matches how this would be done in Linux and these functions do the alignment for us which makes the code look cleaner. Signed-off-by: Andrew Davis <afd@ti.com>
* arm: mach-k3: common: Set boot_fit on non-GP devicesAndrew Davis2022-10-181-0/+4
| | | | | | | This matches what we did for pre-K3 devices. This allows us to build boot commands that can check for our device type at runtime. Signed-off-by: Andrew Davis <afd@ti.com>
* dm: treewide: Use uclass_next_device_err when accessing second deviceMichal Suchanek2022-10-171-1/+1
| | | | | | | | | | | | There are a couple users of uclass_next_device return value that get the first device by other means and use uclass_next_device assuming the following device in the uclass is related to the first one. Use uclass_next_device_err because the return value from uclass_next_device will be removed in a later patch. Signed-off-by: Michal Suchanek <msuchanek@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org>
* treewide: Drop image_header_t typedefSimon Glass2022-09-291-3/+3
| | | | | | | This is not needed and we should avoid typedefs. Use the struct instead and rename it to indicate that it really is a legacy struct. Signed-off-by: Simon Glass <sjg@chromium.org>
* treewide: Drop bootm_headers_t typedefSimon Glass2022-09-291-1/+1
| | | | | | This is not needed and we should avoid typedefs. Use the struct instead. Signed-off-by: Simon Glass <sjg@chromium.org>
* arm: mach-k3: security: Remove certificate if detected on GP deviceAndrew Davis2022-08-041-1/+29
| | | | | | | | | | | | | | | | If the device is a GP and we detect a signing certificate then remove it. It would fail to authenticate otherwise as the device is GP and has no secure authentication services in SYSFW. This shouldn't happen often as trying to boot signed images on GP devices doesn't make much sense, but if we run into a signed image we should at least try to ignore the certificate and boot the image anyway. This could help with users of GP devices who only have HS images available. If this does happen, print a nice big warning. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* arm: mach-k3: security: Bypass image signing at runtime for GP devicesAndrew Davis2022-08-043-4/+4
| | | | | | | | | We can skip the image authentication check at runtime if the device is GP. This reduces the delta between GP and HS U-Boot builds. End goal is to re-unify the two build types into one build that can run on all device types. Signed-off-by: Andrew Davis <afd@ti.com>
* arm: mach-k3: security: Allow signing bypass if type is HS-FSAndrew Davis2022-08-041-1/+21
| | | | | | | | | On HS-FS devices signing boot images is optional. To ease use we check if we are HS-FS and if no certificate is attached to the image we skip the authentication step with a warning that this will fail when the device is set to security enforcing. Signed-off-by: Andrew Davis <afd@ti.com>
* arm: mach-k3: Add support for device type detectionAndrew Davis2022-08-043-1/+70
| | | | | | | | | | | K3 SoCs are available in a number of device types such as GP, HS-FS, EMU, etc. Like OMAP SoCs we can detect this at runtime and should print this out as part of the SoC information line. We add this as part of the common.c file as it will be used to also modify our security state early in the device boot. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* arm: k3: config.mk: Read software revision information from file on HSAndrew Davis2022-07-251-0/+8
| | | | | | | | | Read the swrv.txt file from the TI Security Development Tools when TI_SECURE_DEVICE is enabled. This allows us to set our software revision in one place and have it used by all the tools that create TI x509 boot certificates. Signed-off-by: Andrew Davis <afd@ti.com>
* k3_gen_x509_cert: Make SWRV configurable for anti-rollback protectionYogesh Siraswar2022-07-252-1/+10
| | | | | | | | | | | The x509 certificate SWRV is currently hard-coded to 0. This need to be updated to 1 for j721e 1.1, j7200 and am64x. It is don't care for other k3 devices. Added new config K3_X509_SWRV to k3. Default is set to 1. Signed-off-by: Yogesh Siraswar <yogeshs@ti.com> Reviewed-by: Dave Gerlach <d-gerlach@ti.com>
* arm: mach-k3: Remove ROM firewalls on GP devicesAndrew Davis2022-07-252-8/+0
| | | | | | | | | This isn't strictly needed as these firewalls should all be disabled on GP, but it also doesn't hurt, so do this unconditionally to remove this use of CONFIG_TI_SECURE_DEVICE. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* arm: mach-k3: Rename SOC_K3_AM6 to SOC_K3_AM654Andrew Davis2022-07-256-12/+12
| | | | | | | | | | | The first AM6x device was the AM654x, but being the first we named it just AM6, since more devices have come out with this same prefix we should switch it to the normal convention of using the full name of the first compatibility device the series. This makes what device we are talking about more clear and matches all the K3 devices added since. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* arm: mach-k3: Only build init files for SPLAndrew Davis2022-07-256-18/+8
| | | | | | | | | The content of these files are only used in SPL builds. The contents are already ifdef for the same, remove that and only include the whole file in the build when building for SPL. Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* armv8: mach-k3: correct define checking for AM625/AM642 memory mapsMatt Ranostay2022-07-251-1/+1
| | | | | | | | | | | | | | | | | Using CONFIG_IS_ENABLED breaks accessing memory map structure when doing a A53 SPL build for AM625 and AM642 platforms. This is due to 'abc if CONFIG_SPL_BUILD is defined and CONFIG_SPL_FOO is set to 'y'' in which there is no CONFIG_SPL_SOC_K3_AM625/CONFIG_SPL_SOC_K3_AM642 defined in the configuration. For the A53 SPL builds on these platform to access the memory mapping which it will need for enabling the mmu/cache it must use #if defined(X) checks and not CONFIG_IS_ENABLED. Cc: Suman Anna <s-anna@ti.com> Cc: Neha Francis <n-francis@ti.com> Signed-off-by: Matt Ranostay <mranostay@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* arm64: mach-k3: am625_init: Probe ESM nodesJulien Panis2022-07-252-0/+26
| | | | | | | | | | | On AM62x devices, main ESM error event outputs can be routed to MCU ESM as inputs. So, two ESM device nodes are expected in the device tree : one for main ESM and another one for MCU ESM. MCU ESM error output can trigger the reset logic to reset the device when CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RESET_EN_Z is set to '0'. Signed-off-by: Julien Panis <jpanis@baylibre.com>
* arm: mach-k3: common: Use ddr_init in spl_enable_dcacheGeorgi Vlaev2022-07-061-1/+1
| | | | | | | | | | | The spl_enable_dcache() function calls dram_init_banksize() to get the total memory size. Normally the dram_init_banksize() setups the memory banks, while the total size is reported by ddr_init(). This worked so far for K3 since we set the gd->ram_size in dram_init_banksize() as well. Signed-off-by: Georgi Vlaev <g-vlaev@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* arm: k3: j721e: add dynamic sf bus override support for j721eVaishnav Achath2022-07-062-2/+13
| | | | | | | | | implement overrides for spl_spi_boot_bus() and spl_spi_boot_cs() lookup functions according to bootmode selection, so as to support both QSPI and OSPI boot using the same build. Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
* Merge branch 'master' into nextTom Rini2022-06-201-0/+3
|\ | | | | | | Merge in v2022.07-rc5.
| * arch: arm: mach-k3: am642_init: bring back MCU_PADCFG_MMR1 unlockChristian Gmeiner2022-06-161-0/+3
| | | | | | | | | | | | | | | | | | Without this register unlock it is not possible to configure the pinmux used for mcu spi0. Fixes: 92e46092f2 ("arch: arm: mach-k3: am642_init: Probe ESM nodes") Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Nishanth Menon <nm@ti.com>
* | board: ti: Introduce the basic files to support AM62 SK boardSuman Anna2022-06-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add basic support for AM62 SK. This has 2GB DDR. Note that stack for R5 SPL is in OCRAM @ 0x7000ffff so that is away from BSS and does not step on BSS section Add only the bare minimum required to support UART and SD. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* | arm: mach-k3: am62: Introduce autogenerated SoC dataSuman Anna2022-06-103-0/+450
| | | | | | | | | | | | | | | | | | Introduce autogenerated SoC data support clk and device data for the AM62. Hook it upto to power-domain and clk frameworks of U-Boot. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
* | arm: mach-k3: Introduce the basic files to support AM62Suman Anna2022-06-108-3/+414
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The AM62 SoC family is the follow on AM335x built on K3 Multicore SoC architecture platform, providing ultra-low-power modes, dual display, multi-sensor edge compute, security and other BOM-saving integration. The AM62 SoC targets broad market to enable applications such as Industrial HMI, PLC/CNC/Robot control, Medical Equipment, Building Automation, Appliances and more. Some highlights of this SoC are: * Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster. Pin-to-pin compatible options for single and quad core are available. * Cortex-M4F for general-purpose or safety usage. * Dual display support, providing 24-bit RBG parallel interface and OLDI/LVDS-4 Lane x2, up to 200MHz pixel clock support for 2K display resolution. * Selectable GPUsupport, up to 8GFLOPS, providing better user experience in 3D graphic display case and Android. * PRU(Programmable Realtime Unit) support for customized programmable interfaces/IOs. * Integrated Giga-bit Ethernet switch supporting up to a total of two external ports (TSN capable). * 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio, 1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals. * Dedicated Centralized System Controller for Security, Power, and Resource Management. * Multiple low power modes support, ex: Deep sleep,Standby, MCU-only, enabling battery powered system design. AM625 is the first device of the family. Add DT bindings for the same. More details can be found in the Technical Reference Manual: https://www.ti.com/lit/pdf/spruiv7 Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Gowtham Tammana <g-tammana@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* | arm: mach-k3: am6_init: Fix the path and value's length in the fixup ↵Aswath Govindraju2022-06-101-2/+2
| | | | | | | | | | | | | | | | | | | | performed for usb boot The node name of the bus in the device tree has changed. Also, the length argument to be passed should be the length of new value. Therefore, fix the path to usb device tree node as well as the length argument passed. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
* | arm: k3: sysfw-loader: add hyperflash supportVaishnav Achath2022-06-101-0/+28
|/ | | | | | add support for loading system firmware from hyperflash. Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
* Merge branch '2022-04-04-platform-updates'Tom Rini2022-04-051-4/+36
|\ | | | | | | - Updates for exynos78x0 and TI K3 platforms
| * arch: arm: mach-k3: am642_init: Probe ESM nodesHari Nagalla2022-04-041-4/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On AM64x devices, it is possible to route Main ESM0 error events to MCU ESM. MCU ESM high error output can trigger the reset logic to reset the device. So, for these devices we expect two ESM device nodes in the device tree, one for Main ESM and the another MCU ESM in the device tree. When these ESM device nodes are properly configired it is possible to route the Main RTI0 WWDT output to the MCU ESM high output through Main ESM and trigger a device reset when CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RESET_EN_Z is set to '0'. On K3 AM64x devices, the R5 SPL u-boot handles the ESM device node configurations. Signed-off-by: Hari Nagalla <hnagalla@ti.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
* | spl: mmc: extend spl_mmc_boot_mode() to take mmc argumentAndre Przywara2022-04-044-4/+4
|/ | | | | | | | | | | | | | | | | | | Platforms can overwrite the weak definition of spl_mmc_boot_mode() to determine where to load U-Boot proper from. For most of them this is a trivial decision based on Kconfig variables, but it might be desirable the probe the actual device to answer this question. Pass the pointer to the mmc struct to that function, so implementations can make use of that. Compile-tested for all users changed. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Stefano Babic <sbabic@denx.de> Reviewed-by: Ley Foon Tan <ley.foon.tan@inte.com> (for SoCFPGA) Acked-by: Lokesh Vutla <lokeshvutla@ti.com> (for OMAP and K3) Reviewed-by: Simon Glass <sjg@chromium.org>
* arm: mach-k3: am6_init: Use CONFIG_TI_I2C_BOARD_DETECTChristian Gmeiner2022-03-041-1/+2
| | | | | | | | | | 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>
* arm: j721e: Add support for selecting DT based on board nameSinthu Raja2022-02-161-0/+59
| | | | | | | | 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>
* drivers: misc: Makefile: Enable fs_loader compilation at SPL LevelKeerthy2022-02-081-7/+3
| | | | | | | | 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>
* arm: K3: Add basic support for J721S2 SoC definitionDavid Huang2022-02-0811-5/+971
| | | | | | | | | | 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>
* mach-k3: am64_spl: Alias Ethernet RGMII boot to CPGMACVignesh Raghavendra2022-01-151-0/+1
| | | | | | This is required to enables spl_net boot on AM64x Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
* mach-k3: am642_init: Probe AM65 CPSW NUSS for R5/A53 SPLVignesh Raghavendra2022-01-151-0/+7
| | | | | | In order to support Ethernet boot on AM64x, probe AM65 CPSW NUSS. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
* mach-k3: common: Instantiate AM65 CPSW NUSS wrapperVignesh Raghavendra2022-01-151-0/+16
| | | | | | | | | 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>
* ARM: mach-k3: sysfw-loader: Copy sysfw.itb to OCRAM in OSPI/SPI bootmodeVignesh Raghavendra2022-01-151-2/+16
| | | | | | | | | | | | | | | | | | 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>
* arm: mach-k3: am642_init: Unlock MCU PADCFG regsMichael Liebert2022-01-152-0/+5
| | | | | | | | | 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>
* board: siemens: Add support for SIMATIC IOT2050 devicesJan Kiszka2021-10-031-0/+1
| | | | | | | | | | | | | | | | | 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>
* Merge tag 'v2021.10-rc5' into nextTom Rini2021-09-277-113/+163
|\ | | | | | | Prepare v2021.10-rc5
| * arm: mach-k3: common: Make sure firmware sections are loaded prior to armv8 ↵WIP/2021-09-17-TI-platform-updatesNishanth Menon2021-09-171-12/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit (git 2.34.1) at 2025-03-01 09:40:06 +0000