On 9/5/23 3:21 AM, Manorit Chawdhry wrote:
The following commits adds the configuration of firewalls required to
protect ATF and OP-TEE memory region from non-secure reads and
writes using master and slave firewalls present in our K3 SOCs.
Signed-off-by: Manorit Chawdhry
---
On 9/5/23 1:09 PM, Andrew Davis wrote:
If the source .env file changes to one that is also older than
the generated env.txt file then it is not regenerated. This means
when switching board configs we do not regenerate the env. This
can be tested easily with:
$ make j721e_evm_a72_defconfig
force it for now.
Signed-off-by: Andrew Davis
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 9be24c4ec61..d195590d4b0 100644
--- a/Makefile
+++ b/Makefile
@@ -1830,7 +1830,7 @@ quiet_cmd_envc = ENVC$@
touch
On 9/6/23 12:18 AM, Manorit Chawdhry wrote:
Hi Andrew,
On 10:22-20230905, Andrew Davis wrote:
On 9/5/23 3:21 AM, Manorit Chawdhry wrote:
The following commits adds the configuration of firewalls required to
protect ATF and OP-TEE memory region from non-secure reads and
writes using master
On 9/10/23 5:36 PM, Simon Glass wrote:
Hi Andrew,
On Tue, 5 Sept 2023 at 12:15, Andrew Davis wrote:
On 9/5/23 1:09 PM, Andrew Davis wrote:
If the source .env file changes to one that is also older than
the generated env.txt file then it is not regenerated. This means
when switching board
but that is okay for this test
$ make am64x_evm_a53_defconfig
$ make
$ vim include/generated/env.txt
Note this is still the J721e env not the AM64 config as expected.
As ENV_FILE is set based on configuration, regenerate anytime
autoconf.h changes.
Signed-off-by: Andrew Davis
---
Changes for v2
On 8/30/23 7:31 AM, Nishanth Menon wrote:
On 17:14-20230829, Andrew Davis wrote:
Add am62x_beagleplay_r5_defconfig for R5 SPL and
am62x_beagleplay_a53_defconfig for A53 SPL and U-Boot support.
These defconfigs are composite defconfigs built from the config fragment
board/ti/am62x/beagleplay_
On 8/30/23 9:59 AM, Nishanth Menon wrote:
On 09:31-20230830, Andrew Davis wrote:
On 8/30/23 7:31 AM, Nishanth Menon wrote:
On 17:14-20230829, Andrew Davis wrote:
Add am62x_beagleplay_r5_defconfig for R5 SPL and
am62x_beagleplay_a53_defconfig for A53 SPL and U-Boot support.
These defconfigs
On 9/8/23 9:42 AM, Nishanth Menon wrote:
On 16:35-20230908, Apurva Nandan wrote:
From: Dasnavis Sabiya
The board name is programmed in the EEPROM. Add support for board
detection and choose the right dtb based on the board name read
from EEPROM.
The J784S4/AM69 has two platforms naming
On 9/8/23 6:43 AM, Manorit Chawdhry wrote:
Hi Andrew,
On 08:54-20230906, Andrew Davis wrote:
On 9/6/23 12:18 AM, Manorit Chawdhry wrote:
Hi Andrew,
On 10:22-20230905, Andrew Davis wrote:
On 9/5/23 3:21 AM, Manorit Chawdhry wrote:
The following commits adds the configuration of firewalls
On 9/8/23 12:03 PM, Nishanth Menon wrote:
On 10:59-20230908, Andrew Davis wrote:
On 9/8/23 9:42 AM, Nishanth Menon wrote:
On 16:35-20230908, Apurva Nandan wrote:
From: Dasnavis Sabiya
The board name is programmed in the EEPROM. Add support for board
detection and choose the right dtb based
On 8/29/23 11:47 AM, Simon Glass wrote:
Hi Andrew,
On Wed, 23 Aug 2023 at 10:44, Andrew Davis wrote:
On 8/23/23 10:30 AM, Simon Glass wrote:
Hi,
Up until 2023.04 it has been possible to build all the defconfigs but
with 2023.07 that changed. Tom mentioned this to me recently.
Up until
Hello all,
For context see thread ending here[0].
Thanks,
Andrew
[0] https://marc.info/?l=u-boot=169333616210919=2
Andrew Davis (2):
Makefile: Run defconfig files through the C preprocessor
configs: Add am62x_beagleplay_* defconfigs
configs/am62x_beagleplay_a53_defconfig | 3 +++
configs
Add am62x_beagleplay_r5_defconfig for R5 SPL and
am62x_beagleplay_a53_defconfig for A53 SPL and U-Boot support.
These defconfigs are composite defconfigs built from the config fragment
board/ti/am62x/beagleplay_*.config applied onto the base
am62x_evm_*_defconfig.
Signed-off-by: Andrew Davis
This allows us to use some of the normal preprocessor directives inside
defconfig files. Such as #define and #include.
Signed-off-by: Andrew Davis
---
scripts/kconfig/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig
Add am62x_beagleplay_r5_defconfig for R5 SPL and
am62x_beagleplay_a53_defconfig for A53 SPL and U-Boot support.
These defconfigs are composite defconfigs built from the config fragment
board/ti/am62x/beagleplay_*.config applied onto the base
am62x_evm_*_defconfig.
Signed-off-by: Andrew Davis
Hello all,
For context see thread ending here[0].
Thanks,
Andrew
Changes from RFC[1]:
- Added Reviewed-by
[0] https://marc.info/?l=u-boot=169333616210919=2
[1] https://lists.denx.de/pipermail/u-boot/2023-August/529084.html
Andrew Davis (2):
Makefile: Run defconfig files through the C
This allows us to use some of the normal preprocessor directives inside
defconfig files. Such as #define and #include.
Signed-off-by: Andrew Davis
Reviewed-by: Simon Glass
---
scripts/kconfig/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/kconfig
This file is common for all K3, move it out of board/ directory and
into mach-k3. As we need to change the path in k3-binman.dtsi let's
take this opportunity to switch to absolute paths which makes adding
non-TI boards (like Toradex Verdin) not need to override these paths.
Signed-off-by: Andrew
build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/Kconfig | 2 +-
arch/arm/mach-k3/j721e/Kconfig | 56 ++
board/ti/j721e
build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/Kconfig | 2 +-
{board/ti => arch/arm/mach-k3}/am64x/Kconfig |
build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/Kconfig| 2 +-
arch/arm/mach-k3/j721s2/Kconfig | 36 +
board/ti/j721s2
build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/Kconfig | 4 +--
arch/arm/mach-k3/am62x/Kconfig| 49 +++
board/ti
build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/Kconfig | 3 +-
{board/ti => arch/arm/mach-k3}/am65x/Kconfig |
build.
To fix this we need to move the target board choice to a common location
for each parent SoC selection. Do this in arch/arm/mach-k3.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/Kconfig | 2 +-
{board/ti => arch/arm/mach-k3}/am62ax/Kconfig |
Currently the K3 selection for TARGET boards does not depend on the SoC
for which it is based. This leds to the odd ability to select for instance
both SOC_K3_AM625 and TARGET_J721E_A72_EVM.
To fix this the target choice should depend on the matching SOC config.
Signed-off-by: Andrew Davis
On 11/2/23 3:55 AM, Francesco Dolcini wrote:
Hello Andrew,
On Wed, Nov 01, 2023 at 03:35:28PM -0500, Andrew Davis wrote:
Currently each set of board targets from a vendor is selected inside
the board directory for that vendor. This has the problem of multiple
targets, one from each vendor
On 11/3/23 2:06 PM, Nishanth Menon wrote:
On 13:51-20231103, Andrew Davis wrote:
On 11/2/23 7:38 PM, Nishanth Menon wrote:
Add defconfig fragments for J721E based BeagleBone AI-64 and
corresponding customized environment.
Signed-off-by: Nishanth Menon
---
board/ti/j721e/beagleboneai64.env
On 11/2/23 7:38 PM, Nishanth Menon wrote:
Add defconfig fragments for J721E based BeagleBone AI-64 and
corresponding customized environment.
Signed-off-by: Nishanth Menon
---
board/ti/j721e/beagleboneai64.env| 19
board/ti/j721e/beagleboneai64_a72.config | 55
Cc: Vignesh Raghavendra
Cc: Francesco Dolcini
Cc: Andrew Davis
Similar to the patch
https://lore.kernel.org/all/20231101183329.65091-1-...@ti.com/
arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi | 2 +-
arch/arm/dts/k3-binman.dtsi | 2 +-
{board/ti
:
On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:
On 10/4/23 8:54 AM, Nishanth Menon wrote:
On 08:48-20231004, Andrew Davis wrote:
On 10/4/23 8:23 AM, Roger Quadros wrote:
ti_mmc is not a valid boot_target for standard boot flow so
Is there some way to make it into a valid
On 11/4/23 2:21 AM, Nishanth Menon wrote:
J7200 shares quite a few characteristics with J721E. However a few sets
are different. Introduce a Kconfig to differentiate the two to allow for
new boards to be introduced in a seamless manner.
Signed-off-by: Nishanth Menon
---
Menon
---
Reviewed-by: Andrew Davis
Changes from V1:
* Dropped the override from verdin dtsi
V1: https://lore.kernel.org/all/20231103224453.3264313-1...@ti.com/
arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4
arch/arm/dts/k3-binman.dtsi
NR_MMU_REGIONS is a copy/paste from another platform that extends
this list later. We do not do that, so let the list be the size
of the initializer list.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/arm64-mmu.c | 34 ++
1 file changed, 6 insertions(+), 28
On 11/4/23 2:21 AM, Nishanth Menon wrote:
Refactor J721E J7200 definition to make this independent of board
macros.
Signed-off-by: Nishanth Menon
---
arch/arm/mach-k3/arm64-mmu.c | 50 ++--
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git
On 11/4/23 3:11 AM, Nishanth Menon wrote:
Add base support for BeagleBone AI-64 board support.
Further information at https://beagleboard.org/ai-64
Signed-off-by: Nishanth Menon
---
arch/arm/mach-k3/Kconfig |1 +
board/beagle/beagleboneai64/Kconfig |
On 11/3/23 9:45 PM, Nishanth Menon wrote:
This file is used to emulate customer keys on TI development board
ecosystems, move it out of board/ directory and into mach-k3. And
change the relative paths to absolute paths in the binman paths.
While at it, drop the reference in verdin-binman file
On 11/6/23 11:47 AM, Simon Glass wrote:
Hi Andrew,
On Mon, 6 Nov 2023 at 10:27, Andrew Davis wrote:
On 11/6/23 9:31 AM, Tom Rini wrote:
On Mon, Nov 06, 2023 at 11:23:51AM +0530, Manorit Chawdhry wrote:
Hi Simon,
On 11:22-20231005, Simon Glass wrote:
Hi Nishanth,
On Thu, 5 Oct 2023 at 11
On 9/22/23 1:29 PM, Simon Glass wrote:
Hi Andrew,
On Fri, 22 Sept 2023 at 12:14, Andrew Davis wrote:
On 9/22/23 11:40 AM, Simon Glass wrote:
Hi Andrew,
On Fri, 22 Sept 2023 at 10:35, Andrew Davis wrote:
On 9/22/23 10:01 AM, Simon Glass wrote:
Hi Masahiro,
On Thu, 21 Sept 2023 at 09:36
On 9/22/23 11:40 AM, Simon Glass wrote:
Hi Andrew,
On Fri, 22 Sept 2023 at 10:35, Andrew Davis wrote:
On 9/22/23 10:01 AM, Simon Glass wrote:
Hi Masahiro,
On Thu, 21 Sept 2023 at 09:36, Masahiro Yamada wrote:
Hi.
Since the TI platform migrated to binman,
u-boot.img is built twice
On 9/22/23 10:01 AM, Simon Glass wrote:
Hi Masahiro,
On Thu, 21 Sept 2023 at 09:36, Masahiro Yamada wrote:
Hi.
Since the TI platform migrated to binman,
u-boot.img is built twice.
It is created by "mkimage -E",
then overwritten by binman.
So, the data are embedded in the FIT structure
On 9/21/23 5:49 AM, Manorit Chawdhry wrote:
After the refactor with conf- nodes in fitImage, overlaystring wasn't
didn't handle the new conf- nodes in FIT Booting. Fix get_overlaystring
to handle conf- nodes.
Fixes: 837833a724b7 ("environment: ti: Add get_fit_config command to get FIT config
onfig
string")
Reported-by: Aniket Limaye
Signed-off-by: Manorit Chawdhry
---
Reviewed-by: Andrew Davis
Test Logs:
=> setenv name_overlays ti/k3-dt.dtbo ti/k3-dt1.dtbo
=> run get_overlaystring
=> printenv overlaystring
overlaystring=#conf-ti_k3-dt.dtbo#conf-ti_k3-dt1.dtb
On 9/26/23 2:58 AM, Manorit Chawdhry wrote:
K3 devices have firewalls that are used to prevent illegal accesses to
memory regions that are deemed secure. The series prevents the illegal
accesses to ATF and OP-TEE regions that are present in different K3
devices.
AM62AX and AM64X are currently
On 10/4/23 8:23 AM, Roger Quadros wrote:
ti_mmc is not a valid boot_target for standard boot flow so
Is there some way to make it into a valid boot_target? Otherwise
how do we use uEnv.txt files, or boot from FIT images with overlays?
Andrew
remove it. Prefer mmc1 (sd-card) over mmc0
On 10/4/23 8:54 AM, Nishanth Menon wrote:
On 08:48-20231004, Andrew Davis wrote:
On 10/4/23 8:23 AM, Roger Quadros wrote:
ti_mmc is not a valid boot_target for standard boot flow so
Is there some way to make it into a valid boot_target? Otherwise
how do we use uEnv.txt files, or boot from
This is now done using binman but this file was leftover and is now
unused, remove it.
Signed-off-by: Andrew Davis
---
MAINTAINERS | 1 -
arch/arm/mach-k3/config_secure.mk | 44 ---
2 files changed, 45 deletions(-)
delete mode 100644 arch/arm
On 10/5/23 12:16 PM, Nishanth Menon wrote:
On 12:10-20231005, Nishanth Menon wrote:
On 12:36-20231005, Tom Rini wrote:
On Thu, Oct 05, 2023 at 09:19:48AM -0500, Andrew Davis wrote:
On 10/4/23 8:54 AM, Nishanth Menon wrote:
On 08:48-20231004, Andrew Davis wrote:
On 10/4/23 8:23 AM, Roger
On 8/20/23 12:59 PM, Tom Rini wrote:
On Sun, Aug 20, 2023 at 11:49:21AM -0600, Simon Glass wrote:
Hi,
The deadline has passed for the non-driver model SCSI code. The boards
below still have this enabled:
$ ./tools/moveconfig.py -f SCSI ~DM_SCSI
controlcenterdc am57xx_hs_evm_usb
This should have already been enabled but was missed when converting the
base platform defconfig, fix this here.
Fixes: 3c5aa6caccab ("configs: Enable CONFIG_BLK in am57xx_evm and
am57xx_hs_evm")
Signed-off-by: Andrew Davis
---
configs/am57xx_hs_evm_usb_defconfig | 4 ++--
1 file
On 8/23/23 10:30 AM, Simon Glass wrote:
Hi,
Up until 2023.04 it has been possible to build all the defconfigs but
with 2023.07 that changed. Tom mentioned this to me recently.
Up until 2023.04 we can enumerate all the board configs that can be
built. We can build any of them using a single
On 11/7/23 10:18 AM, Thomas Richard wrote:
During the boot a copy of DM-Firmware is done in a reserved memory
area before it starts.
When resuming, R5 SPL uses this copy of DM-Firmware instead of the fit
image.
TF-A which saved itself in this same memory area, is restored in
SRAM by R5 SPL.
On 11/9/23 11:37 AM, Nishanth Menon wrote:
On 11:09-20231109, Joao Paulo Goncalves wrote:
Enable the am625 instruction cache on SPL and U-boot earlier for the A53
to execute code a bit faster. For normal boot flow, it was possible to
gain about 2 seconds on boot time.
Signed-off-by: Joao Paulo
On 5/25/22 3:30 AM, Roger Quadros wrote:
Hi Andrew,
On 25/05/2022 01:03, Andrew Davis wrote:
On 5/9/22 2:29 AM, Roger Quadros wrote:
Introduce k3-am642-evm-binman.dtsi to provide binman configuration.
R5 build is still not converted to use binman so restrict binman.dtsi
to A53 builds only
On 5/31/22 12:06 AM, Roger Quadros wrote:
Hi,
On 27/05/2022 20:50, Alper Nebi Yasak wrote:
On 26/05/2022 17:15, Tom Rini wrote:
On Thu, May 26, 2022 at 10:28:45AM +0300, Roger Quadros wrote:
Any thoughts on how to get the new ti-secure etype work with atf-bl31 and
tee-os etypes so that it
On 6/1/22 5:55 AM, Roger Quadros wrote:
On 01/06/2022 13:42, Neha Malcom Francis wrote:
Hi Roger,
On 01/06/22 14:53, Roger Quadros wrote:
Hi,
On 01/06/2022 09:08, Neha Malcom Francis wrote:
Hi Roger,
On 31/05/22 16:32, Roger Quadros wrote:
On 06/05/2022 07:37, Neha Malcom Francis
On 5/9/22 2:29 AM, Roger Quadros wrote:
Introduce k3-am642-evm-binman.dtsi to provide binman configuration.
R5 build is still not converted to use binman so restrict binman.dtsi
to A53 builds only.
This patch also take care of building Secure (HS) images using
binman instead of
On 6/15/22 1:47 AM, Neha Malcom Francis wrote:
For K3 devices that require a sysfw image, add entry for SYSFW. It can
contain system firmware image that can be packaged into sysfw.itb by
binman.
HS devices do this very differently, even an RFC without HS support
doesn't make much sense, this
ned-off-by: Corentin LABBE
---
If no one was using this data I wonder if the compiler could have removed
it with LTO enabled.. Something to think on.
Acked-by: Andrew Davis
board/ti/am335x/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/ti/am335x/board
On 6/13/22 9:20 AM, Tom Rini wrote:
On Mon, Jun 13, 2022 at 02:51:03PM +0200, LABBE Corentin wrote:
Le Fri, Jun 10, 2022 at 11:48:34AM -0400, Tom Rini a écrit :
On Fri, Jun 10, 2022 at 05:45:04PM +0200, LABBE Corentin wrote:
Le Fri, Jun 10, 2022 at 11:01:47AM -0400, Tom Rini a écrit :
On
On 7/16/22 7:00 AM, Simon Glass wrote:
Hi Andrew,
On Fri, 15 Jul 2022 at 09:35, Andrew Davis wrote:
From: "Andrew F. Davis"
Print statements in SPL depend on lib/common support, due to this many
such print statements are ifdef'd. Instead of checking at each call site
move
We can check if the message was acknowledged in the common
ti_sci_do_xfer() which lets us remove it from after each call to this
function. This simplifies the code and reduces binary size.
Signed-off-by: Andrew Davis
---
drivers/firmware/ti_sci.c | 165 ++
1
We don't need to print the same message in every location, just
print it in the function that fails and remove all the extra
message printouts.
Signed-off-by: Andrew Davis
---
drivers/firmware/ti_sci.c | 40 ---
1 file changed, 4 insertions(+), 36 deletions
This ti_sci_do_xfer() function already prints out the reason for the
failure, and the caller of each of these functions should also notify
the user of the failed task. Remove this extra level of error message.
Signed-off-by: Andrew Davis
---
drivers/firmware/ti_sci.c | 132
-16090.4
Andrew
Andrew Davis (4):
firmware: ti_sci: Reduce output on ti_sci_do_xfer error
firmware: ti_sci: Factor out message alloc failed message
firmware: ti_sci: Remove inline keyword from functions
firmware: ti_sci: Move ACK checking to ti_sci_do_xfer() function
drivers/firmware
benefit to this due to the larger function size reducing
cache locality, but there is a huge size penalty. Remove inline keyword.
Signed-off-by: Andrew Davis
---
drivers/firmware/ti_sci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers
On 7/25/22 11:57 AM, Tom Rini wrote:
On Fri, Jul 15, 2022 at 11:34:32AM -0500, Andrew Davis wrote:
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 is no longer needed as the SA2UL can now be shared with Linux.
Leave the SA2UL DT node enabled.
Signed-off-by: Andrew Davis
---
board/ti/am65x/evm.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index 7182a8cad1..8a0a506a3e
clear and matches all the K3 devices added since.
Signed-off-by: Andrew Davis
---
arch/arm/dts/Makefile | 2 +-
arch/arm/mach-k3/Kconfig | 14 +++---
arch/arm/mach-k3/Makefile | 2 +-
arch/arm/mach-k3/{am6_init.c
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
---
arch/arm/mach-k3/Makefile | 13 -
arch/arm/mach-k3/am625_init.c
From: "Andrew F. Davis"
Print statements in SPL depend on lib/common support, due to this many
such print statements are ifdef'd. Instead of checking at each call site
move the check to the common.h header and remove these inline checks.
Signed-off-by: Andrew F. Davis
Reviewed-by: Simon Glass
The ISW_ENTRY_ADDR symbol was used for OMAP devices in place of
SPL_TEXT_BASE. Keystone2 HS devices were not using it right either.
Remove ISW_ENTRY_ADDR and use SPL_TEXT_BASE directly.
Signed-off-by: Andrew Davis
---
arch/arm/Kconfig | 15 ---
arch/arm/mach
On AM43xx HS devices, QSPI boot is XIP and we use a single stage
bootloader. Add a defconfig for this.
Signed-off-by: Andrew Davis
---
MAINTAINERS | 1 +
configs/am43xx_hs_evm_qspi_defconfig | 74
2 files changed, 75 insertions(+)
create
Additions have been made to the non-HS defconfig without the same
being made to the HS defconfig, sync them.
Signed-off-by: Andrew Davis
---
configs/j721e_hs_evm_a72_defconfig | 42 ++
configs/j721e_hs_evm_r5_defconfig | 56 +-
2 files changed
Additions have been made to the non-HS defconfig without the same
being made to the HS defconfig, sync them.
Signed-off-by: Andrew Davis
---
configs/am65x_hs_evm_a53_defconfig | 23 ++-
configs/am65x_hs_evm_r5_defconfig | 8
2 files changed, 30 insertions(+), 1
Sync new additions to non-HS defconfig with HS defconfig.
Signed-off-by: Andrew Davis
---
configs/am57xx_hs_evm_defconfig | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index aa0b466d95
in the device boot.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/common.c| 51 +++-
arch/arm/mach-k3/common.h| 10 +
arch/arm/mach-k3/include/mach/hardware.h | 10 +
3 files changed, 70 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach
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
---
arch/arm/mach-k3/security.c | 30
From: Yogesh Siraswar
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
Reviewed-by: Dave Gerlach
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
---
arch/arm/mach-k3/config.mk | 8
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
---
arch/arm/mach-k3/am6_init.c | 4
arch/arm/mach-k3/j721e_init.c | 4
2 files
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
---
arch/arm/mach-k3
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
---
arch/arm/mach-k3/Makefile | 3
On 4/15/22 9:09 AM, Vignesh Raghavendra wrote:
Add info of boot flow and build steps for AM62x SK.
Signed-off-by: Vignesh Raghavendra
---
doc/board/ti/am62x_sk.rst | 231 ++
This isn't specific to the SK, more the AM62x in general, suggest name
This matches what this support is called in the non-SPL case. The postfix
_SUPPORT is redundant as enabling Kconfig options implies support.
With this we can use CONFIG_IS_ENABLED() as needed.
Signed-off-by: Andrew Davis
---
common/spl/Kconfig | 6 +++---
common/spl
Non-FIT image loading support should be disabled for TI secure
devices as the image handlers for those image types do not follow
our secure boot checks.
Signed-off-by: Andrew Davis
---
boot/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/boot/Kconfig b/boot/Kconfig
TI secure devices chain-of-trust depends on FIT image processing,
enable it by default on these devices. This also reduces the delta
between the secure and non-secure defconfig files.
Signed-off-by: Andrew Davis
---
boot/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/boot/Kconfig
Booting of non-FIT images bypass our chain-of-trust boot flow,
these options should not be allowed when high security is set.
Signed-off-by: Andrew Davis
---
common/spl/Kconfig | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
The functions board_fit_image_post_process() and board_tee_image_process()
are not actually board specific (despite their names). Any board using the
OMAP2 family can use these functions. Move them to boot-common.c.
Signed-off-by: Andrew Davis
---
arch/arm/mach-omap2/boot-common.c | 16
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
---
arch/arm/mach-k3/security.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-k3/security.c
Before this was named just evm, which doesn't match the naming
of the other TI board file directory and makes it look like a
common directory for evms. Name this omap3.
Signed-off-by: Andrew Davis
---
arch/arm/mach-omap2/omap3/Kconfig | 2 +-
board/ti/{evm => omap3}/Kconfig | 2 +-
bo
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
---
arch/arm/mach-k3/common.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3
We should clean the caches before any DMA operation and clean+invalidate
after. This matches what the DMA framework does for us already but adds
it to the two functions here in this driver that don't yet go through the
new DMA framework.
Signed-off-by: Andrew Davis
---
drivers/dma/ti-edma3.c
The DMA'd memory area needs cleaned and invalidated after the DMA
write so that any stale cache lines do not mask new data.
Signed-off-by: Andrew Davis
---
drivers/dma/dma-uclass.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/dma-uclass.c b
DMA operations should function on DMA addresses, not virtual addresses.
Although these are usually the same in U-Boot, it is more correct
to be explicit with our types here.
Signed-off-by: Andrew Davis
---
drivers/dma/dma-uclass.c | 2 +-
drivers/dma/sandbox-dma-test.c | 4 ++--
drivers
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
---
arch/arm/mach-k3/am642_init.c | 1 -
arch/arm/mach-k3/include/mach
J721e needs DM firmware when using updated SYSFW. Add steps to fetch,
build, and deploy the same.
Signed-off-by: Andrew Davis
---
doc/board/ti/j721e_evm.rst | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/doc/board/ti/j721e_evm.rst b/doc/board/ti
This matches the others here.
Signed-off-by: Andrew Davis
---
tools/k3_gen_x509_cert.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/k3_gen_x509_cert.sh b/tools/k3_gen_x509_cert.sh
index 029247c105..d9cde07417 100755
--- a/tools/k3_gen_x509_cert.sh
+++ b/tools
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
---
common/bouncebuf.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/common/bouncebuf.c b/common
On 10/7/22 10:21 PM, Derald Woods wrote:
On Fri, Oct 07, 2022 at 12:33:14PM -0500, Andrew Davis wrote:
Before this was named just evm, which doesn't match the naming
of the other TI board file directory and makes it look like a
common directory for evms. Name this omap3.
Signed-off-by: Andrew
1 - 100 of 335 matches
Mail list logo
