Commits on Source (57)
-
Manorit Chawdhry authored
ti_secure_image_post_process is used for the authentication purposes in the current boot flow. Authentication of remoteproc firmware images require ti_secure_image_post_process to be available outside mach-k3. Signed-off-by:Manorit Chawdhry <m-chawdhry@ti.com>
-
Manorit Chawdhry authored
Remoteproc firmware images aren't authenticated in the current boot flow. Authenticates remoteproc firmware images to complete the root of trust in secure booting. Signed-off-by:
Andrew Davis <afd@ti.com>
-
Manorit Chawdhry authored
Kernel uses the current firmware image names which would break the loading of remoteproc firmware images in Kernel if replaced with signed images. Changes default firmware image names to keep compatibility with kernel remoteproc subsystem. Signed-off-by:
-
Aradhya Bhatia authored
The u-boot ums command models the EVM as a card reader and shows the SD Card latched on the evm as a memory device in the host PC. The Type - C dual role port should be used for this functionality. This helps in automating the linux debugging process. Enable this command in the defconfig. Signed-off-by:Aradhya Bhatia <a-bhatia1@ti.com>
-
Anand Gadiyar authored
The u-boot ums command models the EVM as a card reader and shows the SD Card latched on the evm as a memory device in the host PC. The Type - C dual role port should be used for this functionality. This helps in automating the linux debugging process. Enable this command in the defconfig. Signed-off-by:Anand Gadiyar <gadiyar@ti.com>
-
Bhavya Kapoor authored
Added support for main_uart2 clock in clk-data.c for J7ES. Now , main_uart2 will be turned on while booting the J7ES soc and thus can be used at any instance of time. Signed-off-by:
Bhavya Kapoor <b-kapoor@ti.com> Reviewed-by:
Bryan Brattlof <bb@ti.com>
-
Bhavya Kapoor authored
Added device data for main_uart2 in dev-data.c for J7ES. Now , main_uart2 will be powered on while booting the J7ES soc and thus can be used at any point of time.
-
Matt Ranostay authored
Move device specific data into OF data structure so it is easier to maintain and we can get rid of if statements. Based on: https://lore.kernel.org/linux-phy/20220526064121.27625-1-rogerq@kernel.org/T/#u Cc: Roger Quadros <rogerq@kernel.org> Signed-off-by:
Matt Ranostay <mranostay@ti.com>
-
Matt Ranostay authored
Add support for j784s4-wiz-10g device which has two core reference clocks (e.g core_ref_clk, core_ref1_clk) which requires an additional mux selection option. Signed-off-by: -
Kamlesh Gurudasani authored
This matches what we did for pre-K3 devices. Device type based boot commands. Signed-off-by:Kamlesh Gurudasani <kamlesh@ti.com>
-
Kamlesh Gurudasani authored
Enable FIT_ARGS, which will export default value for variables needed to load fitImage at u-boot prompt. Signed-off-by: -
Kamlesh Gurudasani authored
Common defconfig for HS and non HS devices. Enabled configuration needed for HS devices to boot. Non-HS devices will continue to boot due to runtime device type detection. If TI_SECURE_DEV_PKG is not set the build will emit warnings, for non-HS devices these can be ignored. Signed-off-by: -
Andrew Davis authored
When building for secure devices using non-buildman based image generation the signed tispl.bin file is called tispl.bin_HS. Also build the unsigned tispl.bin file as expected. Signed-off-by: -
Neha Malcom Francis authored
ESM MCU masks must be set to 0h so that PMIC can handle errors that require attention for example SYS_SAFETY_ERRn. The required bits must be cleared: ESM_MCU_RST_MASK, ESM_MCU_FAIL_MASK, ESM_MCU_PIN_MASK. If PMIC expected to handle errors, make sure EVM is configured to connect SOC_SAFETY_ERRz (Main) to the PMIC. Note that even though the User Guide for TPS65941 for J721E mentions that these bits are reset to 0h; it is not reflected once board boots to kernel, possibly due to NVM configurations. Eithercase, it is best to account for this from R5 SPL side as well. Signed-off-by:Neha Malcom Francis <n-francis@ti.com>
-
Ravi Gunasekaran authored
In certain TI SoCs, on the CPSW and ICSS peripherals, there is a possibility that the MDIO interface returns corrupt data on MDIO reads or writes incorrect data on MDIO writes. There is also a possibility for the MDIO interface to become unavailable until the next peripheral reset. The workaround is to configure the MDIO in manual mode and disable the MDIO state machine and emulate the MDIO protocol by reading and writing appropriate fields in MDIO_MANUAL_IF_REG register of the MDIO controller to manipulate the MDIO clock and data pins. More details about the errata i2329 and the workaround is available in: https://www.ti.com/lit/er/sprz487a/sprz487a.pdf Add implementation to disable MDIO state machine, configure MDIO in manual mode and provide software MDIO read and writes via MDIO bitbanging. Allow the MDIO to be initialized based on the need for manual mode. Signed-off-by:
Ravi Gunasekaran <r-gunasekaran@ti.com>
-
Ravi Gunasekaran authored
For the TI SoCs affected by errata i2329, enable MDIO manual mode by default Signed-off-by: -
Ravi Gunasekaran authored
For the TI SoCs affected by errata i2329, enable MDIO manual mode by default Signed-off-by: -
Andrew F. Davis authored
When building tispl.bin for AM62x we depend on the _HS SPL and DTB files now as we build the secure configuration by default. Add this dependency here. Fixes: 30457e61 ("arm: k3: config_secure.mk: Add tispl.bin to secure device builds") Reported-by:
LCPD Autobuilder <lcpd_integration@list.ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
Bhavya Kapoor authored
HS400 is not supported for SDHCI0(eMMC). Kernel dts is not having the mmc-hs400-1_8v property while the U-Boot counterpart is still having that.Updated the speed modes supported to HS200 and their itap delay values for MMCSD subsystems in U-boot. Signed-off-by: -
Ravi Gunasekaran authored
Fix the serdes0 node to support USB3 correctly Signed-off-by:
-
Benoit Parrot authored
Add k3-j721e-common-proc-board-infotainment.dtbo reference for J7X-INFOTAN-EXP. Signed-off-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Nishanth Menon authored
commit a58147c2 upstream. Do 1 byte address checks first prior to doing 2 byte address checks. When performing 2 byte addressing on 1 byte addressing eeprom, the second byte is taken in as a write operation and ends up erasing the eeprom region we want to preserve. While we could have theoretically handled this by ensuring the write protect of the eeproms are properly managed, this is not true in case where board are updated with 1 byte eeproms to handle supply status. Flipping the checks by checking for 1 byte addressing prior to 2 byte addressing check prevents this problem at the minor cost of additional overhead for boards with 2 byte addressing eeproms. Signed-off-by:
Nishanth Menon <nm@ti.com> Reviewed-by:
Tom Rini <trini@konsulko.com>
-
Matwey V. Kornilov authored
commit bf637664 upstream. There are three different kinds of EEPROM possibly present on boards. 1. 1byte address. For those we should avoid 2byte address in order not to rewrite the data. Second byte of the address can potentially be interpreted as the data to write. 2. 2byte address with defined behaviour. When we try to use 1byte address they just return "FF FF FF FF ... FF" 3. 2byte address with undefined behaviour (for instance, 24LC32AI). When we try to use 1byte address, then their internal read pointer is changed to some value. Subsequential reads may be broken. To gracefully handle both case #1 and case #3 we read all required data from EEPROM at once (about 80 bytes). So either all the data is valid or we fallback to 2byte address. Cc: Nishanth Menon <nm@ti.com> Fixes: a58147c2 ("board: ti: common: board_detect: Do 1byte address checks first.") Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/ Signed-off-by:
Matwey V. Kornilov <matwey.kornilov@gmail.com> Acked-by:
-
Nishanth Menon authored
commit d2ab2a2b upstream. The situation is similar to commit bf637664 ("board: ti: common: board_detect: Fix EEPROM read quirk"). This is seen on a variant of eeproms seen on some BeagleBone-AI64 which now has a mix of both 1 byte addressing and 2 byte addressing eeproms. Unlike the am335x (ti_i2c_eeprom_am_get) and dra7 (ti_i2c_eeprom_dra7_get) which use constant data structure which allows us to do a complete read of the data, the am6(ti_i2c_eeprom_am6_get) eeprom parse operation is dynamic. This removes the option of being able to read the complete eeprom data in one single shot. Fortunately, on the I2C bus, we do see the following behavior: In 1 byte mode, if we attempt to read the first header data yet again, the misbehaving 2 byte addressing device acts in constant addressing mode which results in the header not matching up and follow on attempt at 2 byte addressing scheme grabs the correct data. This costs us an extra ~3 milliseconds, which is a minor penalty compared to the consistent image support we need to have. Reported-by:
Jason Kridner <jkridner@beagleboard.org> Fixes: a58147c2 ("board: ti: common: board_detect: Do 1byte address checks first.") Signed-off-by:
-
Vaishnav Achath authored
Enable OSPI1 instance for J784S4 EVM in R5 SPL and A72 SPL,U-Boot. OSPI1 instance has mt25qu512a QSPI flash connected on J784S4 EVM. This commit enables the instance and adds the necessary DT entries and pre-relocation properties to enable the OSP1 controller and instantiate mt25qu512a flash. Signed-off-by:Vaishnav Achath <vaishnav.a@ti.com>
-
Vaishnav Achath authored
Implement overrides for spl_spi_boot_bus() lookup function according to bootmode selection, so as to support both QSPI and OSPI boot using the same build. Signed-off-by: -
Vaishnav Achath authored
When devm_ti_sci_get_of_resource() call fails to return a valid pointer for ringacc->rm_gp_range, the error was being ignored and returned success.Fix the return and also add an error print for the same. Signed-off-by: -
Vaishnav Achath authored
Current entries in the ti_sci_static_data for J784S4 is incorrect due to update in rm-cfg and this caused DMA failures in SPL while trying OSPI boot with DMA for J784S4, fix the incorrect entries. Fixes: 0b6d1af1 ("drivers: dma: Add support for J784S4") Signed-off-by:
-
Hari Nagalla authored
On J784S4 SoC, GTC and CPTS clock parents can be selected from either main pll0 HS divisor6 or main pll3 HS divisor1. The GTC clock needs to be at 200 MHz and this decides the HS divisor and VCO clock frequency to be used. Since the main pll0 and pll3 also source clocks for other peripherals and may need specific frequency the VCO of the plls need to be preset to a default value. On J784S4 the default VCO freqeuncy to satisy GTC and othe peripherals on pll0 is 2000 MHz. Signed-off-by:
Hari Nagalla <hnagalla@ti.com> Acked-by:
Apurva Nandan <a-nandan@ti.com>
-
Hari Nagalla authored
Change GTC and CPTS clock parents on J784S4 to main pll0, hsdiv6 from pll3, hsdiv1. This is because pll3, hsdiv0 sources cpsw rgmii and this needs to be at 250MHz. And on the other hand GTC clock needs to be at 200 MHz. Since it is not possible to program the hs dividers for 250 200 MHz from same VCO frequency, move GTC and CPTS clock parents to main pll0, hsdiv6. Signed-off-by:
-
Andrew Davis authored
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:
-
Manorit Chawdhry authored
Add J784S4 High Security EVM defconfig. These configs are same as for the non-secure part, except for: CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_BOOTCOMMAND option is changed to use fitImage Non-HS devices will continue to boot due to runtime device type detection. If TI_SECURE_DEV_PKG is not set the build will emit warnings, for non-HS devices these can be ignored. Signed-off-by: -
Manorit Chawdhry authored
Some firewalls enabled by ROM are still left on. So some address space is inaccessible to the bootloader. For example, in OSPI boot mode we get an exception and the system hangs. Therefore, disable all the firewalls left on by the ROM. Signed-off-by:
-
Bhavya Kapoor authored
Added support for main_uart5 clock in clk-data.c for J721S2. Now, main_uart5 will be turned on in SPL while booting the J721S2 soc and thus can be used at any instance of of time. Signed-off-by:
-
Bhavya Kapoor authored
Added device data for main_uart5 in dev-data.c for J721S2. Now, main_uart5 will be powered on in SPL while booting the J721S2 soc and thus can be used at any point of time. Signed-off-by: -
Bhavya Kapoor authored
Added support for main_uart5 clock in clk-data.c for J784S4. Now, main_uart5 will be turned on in SPL while booting the J784S4 soc and thus can be used at any instance of of time. Signed-off-by: -
Bhavya Kapoor authored
Added device data for main_uart5 in dev-data.c for J784S4. Now, main_uart5 will be powered on in SPL while booting the J784S4 soc and thus can be used at any point of time. Signed-off-by: -
Kamlesh Gurudasani authored
Move BSS section just after the 8kb space reserved for ROM info to keep map compact and save space. Move stack, global data and heap section from OCSRAM to HSMSRAM. OCSRAM is being firewalled by ROM, unless TIFS opens up concerned firewall, r5 can't access it. r5 was trying to access the OCSRAM before tifs was opening it, hence a firewall exception was occurring. Delaying the access to OCSRAM was solving the issue, but was increasing boot up time, so moving stack and heap to HSMSRAM In GP devices, we never faced this issue because nothing is firewalled. Reduce size of BSS section to fit the stack and heap section in HSM SRAM Signed-off-by: -
Kamlesh Gurudasani authored
Move start of eeprom address from on chip SRAM to HSMRAM This Macro is being used to verify that we can write/read to EEPROM OCSRAM is firewalled by ROM, so before TIFS opens up that firewall, we can't access it. Because of this, we were getting firewall exception in r5 core Signed-off-by: -
Kamlesh Gurudasani authored
OCSRAM is firewalled by ROM, so before TIFS opens up that firewall, we can't access it. Because of this, we were getting firewall exception in r5 core. Moving STACK/HEAP to HSM SRAM as it is not firewalled. Due to space constraint on HSMRAM, reduced malloc to 28672 bytes. Max actual usage noticed was 26340 bytes Max stack size 13568, SPL initial stack usage: 13424 bytes Enabled option to subtract size of HEAP, GD and stack section from SPL_SIZE_LIMIT. Updated SPL_SIZE_LIMIT will consist of text, heap, stack, gd. Text section is 193160 bytes, allocated max size is 196607. Removing CONFIG_SPL_LOAD_FIT_APPLY_OVERLAY=y as it is increasing size of text section by 10k and we don't need it as of now. from am62x_evm_r5_usbdfu_defconfig, removed CONFIG_MMC_SDHCI_AM654=y as it wasn't fitting and adding 10k more. This breaks mmc boot using usbdfu_defconfig old map: HSM SRAM (256KB) PSRAM (64KB) 0x43c00000┌───────────────┐ ┌──────────────┐0x70000000 │ │ │ ▲ │ │ │ │ Stack │ │ │ SPL IMAGE │ │ │ │ MAX 204KB │ ├──────────────┤0x70006f1f │(excluding BSS)│ │Global Data │ │ │ ├──────────────┤0x70006fff │ │ │ Heap (36KB) │ 0x43c33000├───────────────┤ └──────────────┘0x7000ffff │ EMPTY (18KB) │ 0x43c37800├───────────────┤ │ │ │ BSS (20KB max)│ 0x43c3c800├───────────────┤ │ │ │ DM data(1.5KB)│ 0x43c3cd82├───────────────┤ │ │ │ EMPTY (9KB) │ 0x43c3f290├───────────────┤ │ ROM extended │ │ boot info │ │ (3.5KB) │ 0x43c3ffff└───────────────┘ New map: HSM SRAM (256KB) 0x43c00000┌───────────────┐ │ │ │ │ │ SPL IMAGE │ │ MAX 204KB │ │(excluding BSS)│ │ 196607 B max │ │ │ 0x43c32fff├───────────────┤ │STACK 13568Bmax│ ├───────────────┤ │GD (428B max) │ ├───────────────┤ │ │ │HEAP (28KB max)│ 0x43c3a7f0├───────────────┤ │ 16B empty │ 0x43c3a800├───────────────┤ │ DM data(2KB) )│ 0x43c3b000├───────────────┤ │ │ │ BSS (12KB) )│ 0x43c3e000├───────────────┤ │ EMPTY (4.5KB) │ │Reserve for ROM│ 0x43c3f1e0├───────────────┤ │ ROM extended │ │ boot info │ │ (3.5KB) │ 0x43c3ffff└───────────────┘ Signed-off-by: -
Bryan Brattlof authored
The data TI's firmware teams use to develop their releases, and the source for these files, are constantly in motion. This churn eventually causes the ordering of the clock tree in the WKUP SPL to change without having any functional change to the driver. So, to enable later patches wishing to make updates to this stripped down clock trees, reorder the clocks to match the v08.05.01 release. There are no functional changes. Signed-off-by: -
Bryan Brattlof authored
Moving forwared, DM firmware will no longer mess with the MAIN_PLL3. This means we (uboot) will need to manually set this PLL to 2GHz in order order for the CPSW HSDIV to have the correct 250MHz output. CC: Jonathan Bergsagel <jbergsagel@ti.com> Signed-off-by: -
Bryan Brattlof authored
In order for the Cortex-A72s to operate at different frequencies other than the default 2GHz, add in a new 'virtual' mux (a mux that does not physically exist in the clock tree) that can be selected. CC: Apurva Nandan <a-nandan@ti.com> CC: Vishal Mahaveer <vishalm@ti.com> Signed-off-by: -
Vignesh Raghavendra authored
Starting with v08.05.01 TIFS, HSM SRAM access is restricted to DM R5 and SMS Cores only, A53 SPL/U-Boot won't be able to access those SRAMs. There are three data structures in the HSM SRAM that A53 SPL/U-Boot make use of which needs relocation: 1. Boot index info from ROM indicating whether ROM booted from primary vs secondary media. This is now relocated to On Chip RAM by R5 SPL 2. EXTEND BOOT INFO which indicates images loaded by ROM, this info is not needed by A53 SPL and thus is limited to R5 SPL usage 3. Board EEPROM data scratch pad, which is now moved to On Chip RAM Co-developed-by:
Judith Mendez <jm@ti.com>
-
Nitin Yadav authored
U-Boot is fail to boot class U1 UHS SD cards (such as microcenter) due to incorrect OTAP and ITAP delay select values. Update OTAP and ITAP delay select values based on recommeded RIOT values to fix boot issue. Signed-off-by:Nitin Yadav <n-yadav@ti.com>
-
Nitin Yadav authored
UHS Class U1 sd-card are failing to boot due to incorrect OTAP/ITAP delay select values. Update OTAP and ITAP delay select values for various speed modes. For sdhci0 update OTAP delay values for ddr52 & HS200 and add ITAP delay for legacy & mmc-hs in dt nodes. For sdhci1 & sdhci2, update OTAP & ITAP delay select recommended as in RIOT for various speed modes. Signed-off-by: -
Nitin Yadav authored
Class U1 UHS SD cards are failing to boot at u-boot. Renable UHS related DT nodes given that driver and OTAP and ITAP values are now updated. Enable UHS modes and voltage switching by default for by enabling the respective nodes in the device tree, remove sdhci-caps-mask in sdhci1 node and add sdhci2 node in device tree. Signed-off-by: -
Nitin Yadav authored
This essentially reverts ("Revert "configs: am62x_evm_a53_defconfig: Enable configs required to add support for UHS modes"") Class U1 UHS cards are failing at U-Boot. Given that now OTAP and ITAP delay values are updated, Revert above commit to renable UHS mode support at U-Boot. Signed-off-by: -
Vignesh Raghavendra authored
With SPI_LOAD disabled, below warning is seen arch/arm/mach-k3/sysfw-loader.c:378:8: warning: unused variable âsysfw_spi_baseâ [-Wunused-variable] 378 | void *sysfw_spi_base; | ^~~~~~~~~~~~~~ Fix the same. Signed-off-by: -
Vignesh Raghavendra authored
AM62x LP SK board has SPI NAND flash and no SPI NOR flash, therefore drop SPI NOR support in order to reduce R5 SPL memory footprint. This is pre requisite to add AM62x HS Support Signed-off-by: -
Vignesh Raghavendra authored
Similar to commit 525f95f8 ("configs: am62x: Move stack and heap from OC SRAM to HSMRAM") move stack/heap to HSM SRAM and resize according to available space Signed-off-by:
-
Vignesh Raghavendra authored
Enable CONFIG_TI_SECURE_DEVICE to support AM62x LP SK with HS devices. Signed-off-by: -
This adds persist partition to partition table. Signed-off-by:Safae Ouajih <souajih@baylibre.com>
-
Guillaume LA ROQUE authored
- Add support of device tree overlay for Android to support CSI camera, LVDS screen. - Support for multiple dtbo indices. This assumes that the `dtbo_index` env variable is a space-separated list of indices. Example: => env set dtbo_index "0 2" Signed-off-by:Guillaume La Roque <glaroque@baylibre.com>
-
Guillaume LA ROQUE authored
Actually am625-sk and am62x-lp-sk board use same board_name. We need to know for android support exact name of board to know which device tree we need to load. Signed-off-by: -
Guillaume LA ROQUE authored
Check board_name value to select device tree in dtb.img for AM62-LP-SK board. Signed-off-by: -
Guillaume LA ROQUE authored
After commit to enable HS mode android boot was broken. So remove bootcmd from defconfig to use distrocmd from config file Fixes: 767a83a9 ("configs: am62x: Enable config option for am62x HS EVM") Signed-off-by:
Showing
- arch/arm/dts/k3-am62-main.dtsi 24 additions, 22 deletionsarch/arm/dts/k3-am62-main.dtsi
- arch/arm/dts/k3-am625-sk-u-boot.dtsi 40 additions, 0 deletionsarch/arm/dts/k3-am625-sk-u-boot.dtsi
- arch/arm/dts/k3-am62x-sk-common-u-boot.dtsi 0 additions, 1 deletionarch/arm/dts/k3-am62x-sk-common-u-boot.dtsi
- arch/arm/dts/k3-j721e-main.dtsi 13 additions, 1 deletionarch/arm/dts/k3-j721e-main.dtsi
- arch/arm/dts/k3-j784s4-evm-u-boot.dtsi 13 additions, 0 deletionsarch/arm/dts/k3-j784s4-evm-u-boot.dtsi
- arch/arm/dts/k3-j784s4-evm.dts 10 additions, 6 deletionsarch/arm/dts/k3-j784s4-evm.dts
- arch/arm/dts/k3-j784s4-main.dtsi 4 additions, 0 deletionsarch/arm/dts/k3-j784s4-main.dtsi
- arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi 2 additions, 0 deletionsarch/arm/dts/k3-j784s4-mcu-wakeup.dtsi
- arch/arm/dts/k3-j784s4-r5-evm.dts 36 additions, 1 deletionarch/arm/dts/k3-j784s4-r5-evm.dts
- arch/arm/mach-k3/Kconfig 2 additions, 1 deletionarch/arm/mach-k3/Kconfig
- arch/arm/mach-k3/am625_init.c 12 additions, 2 deletionsarch/arm/mach-k3/am625_init.c
- arch/arm/mach-k3/am6_init.c 0 additions, 4 deletionsarch/arm/mach-k3/am6_init.c
- arch/arm/mach-k3/common.h 2 additions, 2 deletionsarch/arm/mach-k3/common.h
- arch/arm/mach-k3/config.mk 2 additions, 0 deletionsarch/arm/mach-k3/config.mk
- arch/arm/mach-k3/include/mach/am62_hardware.h 4 additions, 2 deletionsarch/arm/mach-k3/include/mach/am62_hardware.h
- arch/arm/mach-k3/include/mach/security.h 11 additions, 0 deletionsarch/arm/mach-k3/include/mach/security.h
- arch/arm/mach-k3/j7200/clk-data.c 27 additions, 19 deletionsarch/arm/mach-k3/j7200/clk-data.c
- arch/arm/mach-k3/j7200/dev-data.c 2 additions, 3 deletionsarch/arm/mach-k3/j7200/dev-data.c
- arch/arm/mach-k3/j721e/clk-data.c 30 additions, 19 deletionsarch/arm/mach-k3/j721e/clk-data.c
- arch/arm/mach-k3/j721e/dev-data.c 4 additions, 4 deletionsarch/arm/mach-k3/j721e/dev-data.c
arch/arm/mach-k3/include/mach/security.h
0 → 100644