Mirrors/u-boot
1
0
Fork 0
mirror of https://source.denx.de/u-boot/u-boot.git synced 2026-06-13 15:03:58 +03:00
Code Issues Packages Projects Releases Wiki Activity

doc: ti: k3: Correct spelling mistakes and improve clarity

Browse Source 
Few cosmetic fixes for clarity and spelling mistakes.

Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
This commit is contained in:
Jonathan Humphreys
2024-06-14 11:35:29 -05:00
committed by Tom Rini
parent cedad0670e
commit bf240862a8
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
doc/board/ti/k3.rst
View File

@@ -51,14 +51,14 @@ For all K3 SoCs the first core started will be inside the Security
Management Subsystem (SMS) which will secure the device and start a core
in the wakeup domain to run the ROM code. ROM will then initialize the
boot media needed to load the binaries packaged inside `tiboot3.bin`,
including a 32bit U-Boot SPL, (called the wakup SPL) that ROM will jump
including a 32bit U-Boot SPL, (called the wakeup SPL) that ROM will jump
to after it has finished loading everything into internal SRAM.
.. image:: img/boot_flow_01.svg
:alt: Boot flow up to wakeup domain SPL
The wakeup SPL, running on a wakeup domain core, will initialize DDR and
any peripherals needed load the larger binaries inside the `tispl.bin`
any peripherals needed to load the larger binaries inside the `tispl.bin`
into DDR. Once loaded the wakeup SPL will start one of the 'big'
application cores inside the main domain to initialize the main domain,
starting with Trusted Firmware-A (TF-A), before moving on to start
@@ -94,7 +94,7 @@ essentially 4 unique but very similar flows:
* Combined binary with a split firmware: (eg: AM62)
For devices that utilize the split binary approach, ROM is not capable
of loading the firmware into the SoC requiring the wakeup domain's
of loading the firmware into the SoC, requiring the wakeup domain's
U-Boot SPL to load the firmware.
Devices with a split firmware will have two firmwares loaded into the
@@ -114,8 +114,8 @@ K3 HS-SE (High Security - Security Enforced) devices enforce an
authenticated boot flow for secure boot. HS-FS (High Security - Field
Securable) is the state of a K3 device before it has been eFused with
customer security keys. In the HS-FS state the authentication still can
function as in HS-SE but as there are no customer keys to verify the
signatures against the authentication will pass for certificates signed
function as in HS-SE, but as there are no customer keys to verify the
signatures against, the authentication will pass for certificates signed
with any key.
Chain of trust