The issue described in https://github.com/psf/requests/pull/6655 has
been assigned as a security issue. While unlikely to be exploited in our
usage, update to the current release to fix it. Furthermore, upstream
has now moved on to v2.23.2 as the release to use which has all of the
issues resolved.
Reported-by: GitHub dependabot
Signed-off-by: Tom Rini <trini@konsulko.com>
Comment is not kernel-doc format that's why don't label it like that and
also fix indentation to have proper multiline comment.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Fix a trivial typo in the bootmeth documentation.
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
According to UEFI v2.10 spec section 8.2.6, if a caller invokes the
SetVariables() service, it will produce a digest from hash(VariableName,
VendorGuid, Attributes, TimeStamp, DataNew_variable_content), then the
firmware that implements the SetVariable() service will compare the
digest with the result of applying the signer’s public key to the
signature. For EFI variable append write, efitools sign-efi-sig-list has
an option "-a" to add EFI_VARIABLE_APPEND_WRITE attr, and u-boot will
drop this attribute in efi_set_variable_int(). So if a caller uses
"sign-efi-sig-list -a" to create the authenticated variable, this append
write will fail in the u-boot due to "hash check failed".
This patch resumes writing the EFI_VARIABLE_APPEND_WRITE attr to ensure
that the hash check is correct. And also update the "test_efi_secboot"
test case to compliance with the change.
Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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>
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>
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>
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.
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>
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>
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>
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>
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>
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>
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.
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>
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>
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>
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>
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>
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>
Neha Malcom Francis <n-francis@ti.com> says:
This series was plucked out from the larger series [1] that did some
templating reformatting and also enabled OF_UPSTREAM for J721E. The
former has been kept aside till all the platforms affected have moved to
using OF_UPSTREAM to have less conflicts while merging.
Patches split J721E EVM and J721E SK to using separate builds, as well
as enable OF_UPSTREAM for both the platforms.
Boot logs:
https://gist.github.com/nehamalcom/8f326376b6c6b1196084721405159bb9
[1] https://lore.kernel.org/all/20240322131011.1029620-1-n-francis@ti.com/
Move to using OF_UPSTREAM config and thus using the devicetree-rebasing
subtree.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Add defconfig for J721E SK R5 and A72 configuration.
This includes and modifies the J721E EVM defconfigs:
j721e_evm_r5_defconfig -> j721e_sk_r5_defconfig
j721e_evm_a72_defconfig -> j721e_sk_a72_defconfig
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Introduce k3-j721e-r5.dtsi to be used by board R5 DTS files. This
helps sync SoC changes across boards.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Manorit Chawdhry <m-chawdhry@ti.com>
Emanuele Ghidoli <emanuele.ghidoli@toradex.com> says:
Manually, since SysConfig tool do not have the relevant option,
set PHY_LP4_WDQS_OE_EXTEND to 1.
Since WDQS control mode is required on our modules LPDDR4,
this enables WDQS control mode 1.
Manually, since SysConfig tool do not have the relevant option,
set PHY_LP4_WDQS_OE_EXTEND to 1.
Since WDQS control mode is required on our modules LPDDR4,
this enables WDQS control mode 1.
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
