Home
last modified time | relevance | path

Searched hist:"1 d73ce6f" (Results 1 – 3 of 3) sorted by relevance

/openbmc/u-boot/arch/arm/mach-keystone/include/mach/
H A Dmon.h1d73ce6f Mon Jul 17 12:59:15 CDT 2017 Madan Srinivas <madans@ti.com> arm: mach-keystone: Updates mon_install for K2G HS

On early K2 devices (eg. K2HK) the secure ROM code does not support
loading secure code to firewall protected memory, before decrypting,
authenticating and executing it.

To load the boot monitor on these devices, it is necessary to first
authenticate and run a copy loop from non-secure memory that copies
the boot monitor behind firewall protected memory, before decrypting
and executing it.

On K2G, the secure ROM does not allow secure code executing from
unprotected memory. Further, ROM first copies the signed and encrypted
image into firewall protected memory, then decrypts, authenticates
and executes it.

As a result of this, we cannot use the copy loop for K2G. The
mon_install has to be modified to pass the address the signed and
encrypted secure boot monitor image to the authentication API.

For backward compatibility with other K2 devices and K2G GP,
the mon_install API still supports a single argument. In this case
the second argument is set to 0 by u-boot and is ignored by ROM

Signed-off-by: Thanh Tran <thanh-tran@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
/openbmc/u-boot/arch/arm/mach-keystone/
H A Dcmd_mon.c1d73ce6f Mon Jul 17 12:59:15 CDT 2017 Madan Srinivas <madans@ti.com> arm: mach-keystone: Updates mon_install for K2G HS

On early K2 devices (eg. K2HK) the secure ROM code does not support
loading secure code to firewall protected memory, before decrypting,
authenticating and executing it.

To load the boot monitor on these devices, it is necessary to first
authenticate and run a copy loop from non-secure memory that copies
the boot monitor behind firewall protected memory, before decrypting
and executing it.

On K2G, the secure ROM does not allow secure code executing from
unprotected memory. Further, ROM first copies the signed and encrypted
image into firewall protected memory, then decrypts, authenticates
and executes it.

As a result of this, we cannot use the copy loop for K2G. The
mon_install has to be modified to pass the address the signed and
encrypted secure boot monitor image to the authentication API.

For backward compatibility with other K2 devices and K2G GP,
the mon_install API still supports a single argument. In this case
the second argument is set to 0 by u-boot and is ignored by ROM

Signed-off-by: Thanh Tran <thanh-tran@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
H A Dmon.c1d73ce6f Mon Jul 17 12:59:15 CDT 2017 Madan Srinivas <madans@ti.com> arm: mach-keystone: Updates mon_install for K2G HS

On early K2 devices (eg. K2HK) the secure ROM code does not support
loading secure code to firewall protected memory, before decrypting,
authenticating and executing it.

To load the boot monitor on these devices, it is necessary to first
authenticate and run a copy loop from non-secure memory that copies
the boot monitor behind firewall protected memory, before decrypting
and executing it.

On K2G, the secure ROM does not allow secure code executing from
unprotected memory. Further, ROM first copies the signed and encrypted
image into firewall protected memory, then decrypts, authenticates
and executes it.

As a result of this, we cannot use the copy loop for K2G. The
mon_install has to be modified to pass the address the signed and
encrypted secure boot monitor image to the authentication API.

For backward compatibility with other K2 devices and K2G GP,
the mon_install API still supports a single argument. In this case
the second argument is set to 0 by u-boot and is ignored by ROM

Signed-off-by: Thanh Tran <thanh-tran@ti.com>
Signed-off-by: Madan Srinivas <madans@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>