summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-06-19arch: mach-k3: Introduce basic files to support J722S SoC familyJayesh Choudhary
Introduce the basic functions and definitions needed to properly initialize TI J722S family of SoCs. Co-developed-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
2024-06-19ram: k3-ddrss: Enable the am62ax's DDR controller for J722SJayesh Choudhary
The J722S family of SoCs uses the same DDR controller as found on the AM62A family. Enable this option when building for the J722S family. Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
2024-06-19arm: mach-k3: j722s: introduce clock and device files for wkup splJayesh Choudhary
Include the clock and lpsc tree files needed for the wkup spl to initialize the proper PLLs and power domains to boot the SoC. Reviewed-by: Bryan Brattlof <bb@ti.com> Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
2024-06-19arm: mach-k3: r5: Makefile: Fix the order for entriesJayesh Choudhary
Add the entries in alphabetical order. Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
2024-06-19power: domain: ti: Fix the order for platform data entriesJayesh Choudhary
Add the power domain platform data entries in alphabetical order. Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
2024-06-19clk: ti: clk-k3: use IS_ENABLED macro and fix the clock-data orderJayesh Choudhary
Use IS_ENABLED macro for the platform clock-data list and add them in alphabetical order. Reviewed-by: Bryan Brattlof <bb@ti.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
2024-06-19soc: add info to identify the J722S SoC familyJayesh Choudhary
Include the part number for TI's j722s family of SoC to identify it during boot. Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
2024-06-19soc: ti: k3-socinfo: Fix SOC JTAG entry orderJayesh Choudhary
Add JTAG_ID_PARTNO_* in alphabetical order. Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
2024-06-19arm: mach-k3: Sort CONFIG_SOC* and K3_SOC_ID entriesJayesh Choudhary
Sort CONFIG_SOC* and K3_SOC_ID alphabetically. Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
2024-06-11Merge tag 'efi-next-20240611' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-efi into next Pull request efi-next-20240611 UEFI: * Allow specifying a device-tree in an EFI load option using the efidebug or eficonfig command. * Let the EFI boot manager fall back to an OS provided device-tree if no device-tree is specified.
2024-06-10efi_loader: rename struct efi_initrd_dp to efi_lo_dp_prefixHeinrich Schuchardt
As we now also store device-tree device-paths in load options rename struct efi_initrd_dp to efi_lo_dp_prefix. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2024-06-10efi_loader: load distro dtb in bootmgrHeinrich Schuchardt
If no device-tree is specified, try to load a device-tree from the boot device use the $fdtfile concatenated to either of the paths '/dtb/', '/', '/dtb/current/'. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-06-10efi_loader: export efi_load_image_from_pathHeinrich Schuchardt
We can reuse this function to load the device-tree. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-06-10efi_loader: return binary from efi_dp_from_lo()Heinrich Schuchardt
For finding distro supplied device-trees we need to know from which device we are booting. This can be identified via the device-path of the binary. Up to now efi_dp_from_lo() only could return the initrd or fdt device-path. Allow returning the binary device-path, too. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-06-10efi_loader: move distro_efi_get_fdt_name()Heinrich Schuchardt
Move distro_efi_get_fdt_name() to a separate C module and rename it to efi_get_distro_fdt_name(). Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-06-10efi_loader: load device-tree specified in boot optionHeinrich Schuchardt
We allow to specify the triple of binary, initrd, and device-tree in boot options. Add the code to actually load the specified device-tree. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-06-10cmd: efidebug: add support for setting fdtHeinrich Schuchardt
We already support creating a load option where the device-path field contains the concatenation of the binary device-path and optionally the device path of the initrd which we expose via the EFI_LOAD_FILE2_PROTOCOL. Allow to append another device-path pointing to the device-tree identified by the device-tree GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-06-10cmd: eficonfig: add support for setting fdtHeinrich Schuchardt
We already support creating a load option where the device-path field contains the concatenation of the binary device-path and optionally the device path of the initrd which we expose via the EFI_LOAD_FILE2_PROTOCOL. Allow to append another device-path pointing to the device-tree identified by the device-tree GUID. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-06-10efi_loader: allow concatenation with contained end nodeHeinrich Schuchardt
Allow appending a device-path to a device-path that contains an end node as separator. We need this feature for creating boot options specifying kernel, initrd, and dtb. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-06-07Added arm64 assembly for examples/api crt0Brunham, Kalen
I've encountered a problem when compiling the 'examples/api' directory for ARM64 in U-boot. The problem lies in the assembly code in 'examples/api/crt0.S' where the current CONFIG_ARM code is only 32-bit. When targeting ARM64, a 64-bit version is necessary. I have proposed a fix by including a 'CONFIG_ARM64' section in the assembly code as shown below. These changes have been check via https://github.com/u-boot/u-boot/pull/538. Feedback is welcome. Signed-off-by: Kalen Brunham <kalen.brunham@intel.com>
2024-06-07abootimg: Add init_boot image supportRoman Stratiienko
Quote from [1]: "For devices launching with Android 13, the generic ramdisk is removed from the boot image and placed in a separate init_boot image. This change leaves the boot image with only the GKI kernel." While at it, update wrong error handling message when vendor_boot cannot be loaded. [1]: https://source.android.com/docs/core/architecture/partitions/generic-boot Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2024-06-07android: Fix ramdisk loading for bootimage v3+Roman Stratiienko
The boot_ramdisk and vendor_ramdisk must be both concatenated together. Without this change, Android root is missing some of the necessary tools to complete virtual AB OTA. Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2024-06-07arm: move _end to linker symbolsIlias Apalodimas
commit 6e2228fb052b ("Merge patch series "Clean up arm linker scripts") was cleaning up linker scripts for armv7 and v8 but was leaving _end and __secure_stack_start/end. commit d0b5d9da5de2 ("arm: make _end compiler-generated") was moving _end to be compiler generated. _end is defined as c variable in its own section to force the compiler emit relative a reference. However, defining those in the linker script will do the same thing since [0]. So let's remove the special sections from the linker scripts, the variable definitions from sections.c and define them as a symbols. It's worth noting that _image_binary_end symbol is now redundant and can be removed in the future. - SPL The .end section has been removed from the new binary [ 5] .end PROGBITS 00000000fffdf488 000000000002f488 0 0000000000000000 0000000000000000 0 1 [0000000000000003]: WRITE, ALLOC $~ bloat-o-meter kria_old/spl/u-boot-spl krina_new/spl/u-boot-spl add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) Function old new delta Total: Before=115980, After=115980, chg +0.00% $~ readelf -sW kria_old/u-boot kria_new/u-boot | grep -w _end 12047: 000000000813a0f0 0 OBJECT GLOBAL DEFAULT 11 _end 12047: 000000000813a118 0 NOTYPE GLOBAL DEFAULT 11 _end $~ readelf -sW kria_old/spl/u-boot-spl kria_new/spl/u-boot-spl | grep -w _end 1605: 00000000fffdf488 0 OBJECT GLOBAL DEFAULT 5 _end 1603: 00000000fffdf498 0 NOTYPE GLOBAL DEFAULT 4 _end $~ readelf -sW old/u-boot new/u-boot | grep -w _end 8847: 0000000000103710 0 OBJECT GLOBAL DEFAULT 11 _end 8847: 0000000000103738 0 NOTYPE GLOBAL DEFAULT 11 _end $~ readelf -sW old_v7/u-boot new_v7/u-boot | grep -w _end 10638: 000da824 0 OBJECT GLOBAL DEFAULT 10 _end 10637: 000da84c 0 NOTYPE GLOBAL DEFAULT 10 _end - For both QEMU instances $~ bloat-o-meter old/u-boot new/u-boot add/remove: 0/0 grow/shrink: 1/0 up/down: 20/0 (20) Function old new delta version_string 50 70 +20 Total: Before=656915, After=656935, chg +0.00% [0] binutils commit 6b3b0ab89663 ("Make linker assigned symbol dynamic only for shared object") Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2024-06-07image: Set load_end on partial loadsMattijs Korpershoek
When decompressing, it's possible that the algorithm only performs a partial decompression. This usually happens when CONFIG_SYS_BOOTM_LEN is too small for the uncompressed image. When that happens, image_decomp() returns an error and *load_end == load. The error is then handled by handle_decomp_error(). handle_decomp_error() expects the number of uncompressed bytes in uncomp_size but receives *load_end - load == load - load == 0. Because of this, handle_decomp_error does not report the expected "Image too large: increase CONFIG_SYS_BOOTM_LEN" error message. Modify the image_decomp() logic to always report the decompressed size, even when a partial decompression happened. Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
2024-06-07fs: relax ext4_write_file() dependencyBaruch Siach
ext4_write_file() depends on CONFIG_EXT4_WRITE. Allow build without CONFIG_CMD_EXT4_WRITE. Signed-off-by: Baruch Siach <baruch@tkos.co.il>
2024-06-07dm: use newly added linux/compat alloc functionsMaxim Moskalets
Signed-off-by: Maxim Moskalets <maximmosk4@gmail.com>
2024-06-07memory: ti-gpmc: use printf to dump settings/timingsRoger Quadros
pr_info() depends on CONFIG_LOGLEVEL > 6. If user has enabled CONFIG_TI_GPMC_DEBUG then we should print the GPMC settings/timings regardless of CONFIG_LOGLEVEL. So use printf() instead of pr_info(). Signed-off-by: Roger Quadros <rogerq@kernel.org>
2024-06-07arm: dts: k3-j7200: Move to OF_UPSTREAMAniket Limaye
Move to using OF_UPSTREAM config and thus using the devicetree-rebasing subtree. Signed-off-by: Aniket Limaye <a-limaye@ti.com> Acked-by: Sumit Garg <sumit.garg@linaro.org>
2024-06-07include: extension_board: Increase overlay file name sizeDaniel Schultz
Upstream overlays like the ARM64 TI k3-am625-beagleplay-csi2-tevi-ov5640.dtso can easily have more then 32 characters. Increase the overlay length to 64 characters to apply overlays with longer names. Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Acked-by: Kory Maincent <kory.maincent@bootlin.com>
2024-06-07Merge patch series "*** phyCORE-AM62x: DDR detection / Inject DDR timing ↵Tom Rini
deltas ***" Wadim Egorov <w.egorov@phytec.de> says: Changes in v2: - Reabse to current next - Add Tested-by: John Ma <jma@phytec.com> - Add Kconfig option to select RAM size statically - Make board/phytec/common/k3 always compile for CONFIG_ARCH_K3 v1: https://lists.denx.de/pipermail/u-boot/2024-May/553057.html
2024-06-07board: phytec: am62x: Add support for 1 & 4 GB RAM variantsWadim Egorov
Use content of EEPROM to detect the actual RAM size and adjust DDR timings, size and banks accordingly. Also enable the SoM detection per default in the defconfigs. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Tested-by: John Ma <jma@phytec.com>
2024-06-07board: phytec: common: Introduce a method to inject DDR timings deltasWadim Egorov
Introduce fdt_apply_ddrss_timings_patch() to allow board code to override DDR settings in the device tree prior to DDRSS driver probing. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Tested-by: John Ma <jma@phytec.com>
2024-06-07arm: mach-k3: am625: Call do_board_detect() before DDR probingWadim Egorov
Call do_board_detect() hook before the K3 DDRSS driver gets probed. It will allow boards to adjust DDR timings in do_board_detect(). Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Tested-by: John Ma <jma@phytec.com>
2024-06-07board: phytec: Fix function definitions in AM6x SOM detectionWadim Egorov
Functions are declared as phytec_am6* and not phytec_am62*. Update the definitions to match the declarations. Fixes: 9d152c23279c ("board: phytec: Add SOM detection for AM6x") Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Tested-by: John Ma <jma@phytec.com> Reviewed-by: Dhruva Gole <d-gole@ti.com>
2024-06-07board: phytec: Make AM6 SoM detection depend on I2CWadim Egorov
SoM detection is using I2C driver model functions. Let's depend on I2C. Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Tested-by: John Ma <jma@phytec.com> Reviewed-by: Dhruva Gole <d-gole@ti.com>
2024-06-07Merge patch series "PHYTEC SOM Detection API v3"Tom Rini
Daniel Schultz <d.schultz@phytec.de> says: This patch series adds support for the EEPROM v3 API. V3 is backwards compatible to V2 and therefore, the V2 image still exists at the beginning. Only the API version changed from 2 to 3. V3 is a block-based memory layout organized as singled-linked list with different types of blocks. This is a more flexible approach and allows us to extend it by more block types in the future. The V3 data starts with a 8-byte large header which defines the block count (u8), V3 subversion (u8) and data payload length (u16). Additionally the header contains a CRC8 checksum a 3 reserved bytes. Each block starts with a 4-byte large header which defined the block type (u8), the absolute address of the next block (u16) and a CRC8 checksum. The content itself is defined via the block type and we currently have 2 different types: 1) MAC: Contains the Ethernet interface number (u8), MAC address (6 x u8) and a CRC8 checksum.
2024-06-07configs: phycore_am62x_a53_defconfig: Enable CONFIG_ENV_OVERWRITEDaniel Schultz
Enable CONFIG_ENV_OVERWRITE to overwrite ethaddr in the environment. This is required because our environment is not located in the boot partition. Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Tested-by: Wadim Egorov <w.egorov@phytec.de>
2024-06-07board: phytec: common: k3: Set MACDaniel Schultz
Read the EEPROM API v3 content and set all available MAC-Addresses to the environment. Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de> Tested-by: Wadim Egorov <w.egorov@phytec.de>
2024-06-07board: phytec: common: Add API v3Daniel Schultz
This API is based on a block structure with a 8 Byte large API v3 header and various of different blocks following. It extends our current API v2, which is always 32 Byte large, and is located directly after v2. Add the MAC block as first block type. It contains the physical Ehternet interface number, a MAC address and a CRC checksum over the MAC payload. Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Tested-by: Wadim Egorov <w.egorov@phytec.de>
2024-06-07board: phytec: common: Move API v2 init to new functionDaniel Schultz
Move the entire initialization code for API v2 into a dedicated function. This rework will allow to easily integrate the API v3 as next step during init. Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Tested-by: Wadim Egorov <w.egorov@phytec.de>
2024-06-07board: phytec: common: Define PHYTEC_API2_DATA_LENDaniel Schultz
The EEPROM image length for API v2 is fixed to 32 bytes. No need to use sizeof while this value won't change. This value is also be required for API v3 to know where the API v3 header starts. Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Tested-by: Wadim Egorov <w.egorov@phytec.de>
2024-06-07board: phytec: common: Move eeprom read to new functionDaniel Schultz
We need to read multiple times from different offsets in API v3. Move the EEPROM read logic into a dedicated function to make it usable multiple times. Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Tested-by: Wadim Egorov <w.egorov@phytec.de>
2024-06-07Merge patch series "Add remoteproc support for J784S4 SoCs"Tom Rini
Beleswar Padhi <b-padhi@ti.com> says: Hello All, This series adds remoteproc support for TI's J784S4 SoCs. The K3 J784S4 SoCs have four dual-core R5F subsystems and four C71x DSP subsystems. Enable the remoteproc drivers in defconfig and set the rproc firmware names to add remoteproc support. Note: No driver changes are required as J784S4 SoCs have the same data as J721S2 SoCs. Thus, utilize the existing compatible string for driver probe.
2024-06-07board: ti: j784s4: j784s4.env: Set remoteproc firmware namesBeleswar Padhi
Include k3_rproc.env to access rproc boot commands and specify rproc firmware names for adding remoteproc support in J784S4 SoCs. Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
2024-06-07configs: j784s4_evm_a72_defconfig: Enable remoteproc driversBeleswar Padhi
The K3 J784S4 SoC has four dual-core R5F subsystems and four C71x DSP subsystems. Set config values to enable the remoteproc functionality with these R5F and DSP subsystems. Signed-off-by: Beleswar Padhi <b-padhi@ti.com>
2024-06-07Merge patch series "Adding support to load secure firmware for HS devices"Tom Rini
Udit Kumar <u-kumar1@ti.com> says: Some use case needs rproc firmware to be loaded at u-boot stage, using following commands at u-boot shell, firmware could be loaded => setenv dorprocboot 1 => run boot_rprocs For Secure devices, secure version of rproc firmware should be loaded, which is appended by sec keyword[0]. but currently non-secure firmware is loaded even for secure devices. So adding support for loading secure firmware on Secured devices. [0]: https://gist.github.com/uditkumarti/cd8bf6a448079b59145d17a0e8bf13b7 Bootlogs: GP : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-gp_device line 65 onwards HS : https://gist.github.com/uditkumarti/23a00c313e1c28b62537aab733a585df#file-hs-device line 60 onwards
2024-06-07mach-k3: common.c: add a flag for booting authenticated rproc binariesManorit Chawdhry
The flag will be used for booting authenticated remote procs from hs-se devices which can optionally be used in hs-fs devices also. Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Udit Kumar <u-kumar1@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2024-06-07include: env: ti: Add support for secure firmwaresUdit Kumar
Secure firmwares must be loaded if SOC is secure, currently rproc framework chooses non-secure firmware always. So adding support to load secure firmware, when SOC is secure Signed-off-by: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Udit Kumar <u-kumar1@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2024-06-07drivers: remoteproc: ti_k3 : enable secure booting with firmware imagesManorit Chawdhry
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: Manorit Chawdhry <m-chawdhry@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2024-06-07include: mach-k3: move k3 security functions to security.hManorit Chawdhry
ti_secure_image_post_process and ti_secure_image_check_binary 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> Signed-off-by: Udit Kumar <u-kumar1@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> # Intel Edison Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
generated by cgit v1.2.3 (git 2.0.4) at 2025-08-07 06:35:00 +0000