Re: [PATCH 1/2] arm: mach-k3: am625: copy bootindex to OCRAM for main domain SPL
Hi,
On 3/6/2024 7:14 PM, Wadim Egorov wrote:
> Hi Vignesh,
>
> Am 04.03.24 um 06:06 schrieb Vignesh Raghavendra:
>> Hi Wadim,
>>
>> On 26/02/24 19:00, Wadim Egorov wrote:
>>> Texas Instruments has begun enabling security settings on the SoCs it
>>> produces to instruct ROM and TIFS to begin protecting the Security
>>> Management Subsystem (SMS) from other binaries we load into the chip by
>>> default.
>>>
>>> One way ROM and TIFS do this is by enabling firewalls to protect the
>>> OCSRAM and HSM RAM regions they're using during bootup.
>>>
>>> The HSM RAM the wakeup SPL is in is firewalled by TIFS to protect
>>> itself from the main domain applications. This means the 'bootindex'
>>> value in HSM RAM, left by ROM to indicate if we're using the primary
>>> or secondary boot-method, must be moved to OCSRAM (that TIFS has open
>>> for us) before we make the jump to the main domain so the main domain's
>>> bootloaders can keep access to this information.
>>>
>>> Based on commit
>>> b672e8581070 ("arm: mach-k3: copy bootindex to OCRAM for main
>>> domain SPL")
>>>
>> FYI, this is mostly a problem in non SPL flow (TI prosperity SBL for
>> example) where HSM RAM would be used by HSM firmware. This should be a
>> issue in R5 SPL flow. Do you see any issues today? If so, whats the
>> TIFS firmware being used?
>
> I remember I was losing the bootindex using ti/downstream u-boot.
> But can't figure out the exact version anymore.
> Just did a bit of testing and I can not see the Issue with the current
> u-boot.
> Boot index in 0x43c3f290 stays intact.
>
> Would it be okay to drop this patch and keep only the 2nd patch that
> factors out into get_boot_device()?
>
yeah... 2/2 is still relevant irrespective of this patch.
[...]
Re: [PATCH 1/2] arm: mach-k3: am625: copy bootindex to OCRAM for main domain SPL
On 3/5/2024 11:04 PM, Bryan Brattlof wrote:
> On March 5, 2024 thus sayeth Vignesh Raghavendra:
>>
>> On 05/03/24 01:57, Bryan Brattlof wrote:
>>> Hey Vignesh!
>>>
>>> On March 4, 2024 thus sayeth Vignesh Raghavendra:
Hi Wadim,
On 26/02/24 19:00, Wadim Egorov wrote:
> Texas Instruments has begun enabling security settings on the SoCs it
> produces to instruct ROM and TIFS to begin protecting the Security
> Management Subsystem (SMS) from other binaries we load into the chip by
> default.
>
> One way ROM and TIFS do this is by enabling firewalls to protect the
> OCSRAM and HSM RAM regions they're using during bootup.
>
> The HSM RAM the wakeup SPL is in is firewalled by TIFS to protect
> itself from the main domain applications. This means the 'bootindex'
> value in HSM RAM, left by ROM to indicate if we're using the primary
> or secondary boot-method, must be moved to OCSRAM (that TIFS has open
> for us) before we make the jump to the main domain so the main domain's
> bootloaders can keep access to this information.
>
> Based on commit
> b672e8581070 ("arm: mach-k3: copy bootindex to OCRAM for main domain
> SPL")
>
FYI, this is mostly a problem in non SPL flow (TI prosperity SBL for
example) where HSM RAM would be used by HSM firmware. This should be a
issue in R5 SPL flow. Do you see any issues today? If so, whats the
TIFS firmware being used?
> Signed-off-by: Wadim Egorov
> ---
> arch/arm/mach-k3/Kconfig | 3 ++-
> arch/arm/mach-k3/am625_init.c | 15 +--
> arch/arm/mach-k3/include/mach/am62_hardware.h | 15 +++
> 3 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> index 03898424c9..f5d06593f7 100644
> --- a/arch/arm/mach-k3/Kconfig
> +++ b/arch/arm/mach-k3/Kconfig
> @@ -75,7 +75,8 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX
> default 0x41cffbfc if SOC_K3_J721E
> default 0x41cfdbfc if SOC_K3_J721S2
> default 0x701bebfc if SOC_K3_AM642
> - default 0x43c3f290 if SOC_K3_AM625
> + default 0x43c3f290 if SOC_K3_AM625 && CPU_V7R
> + default 0x7000f290 if SOC_K3_AM625 && ARM64
> default 0x43c3f290 if SOC_K3_AM62A7 && CPU_V7R
> default 0x7000f290 if SOC_K3_AM62A7 && ARM64
> help
> diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
> index 6c96e88114..67cf63b103 100644
> --- a/arch/arm/mach-k3/am625_init.c
> +++ b/arch/arm/mach-k3/am625_init.c
> @@ -35,8 +35,10 @@ static struct rom_extended_boot_data bootdata
> __section(".data");
> static void store_boot_info_from_rom(void)
> {
> bootindex = *(u32 *)(CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX);
> - memcpy(, (uintptr_t *)ROM_EXTENDED_BOOT_DATA_INFO,
> -sizeof(struct rom_extended_boot_data));
> + if (IS_ENABLED(CONFIG_CPU_V7R)) {
> + memcpy(, (uintptr_t *)ROM_EXTENDED_BOOT_DATA_INFO,
> +sizeof(struct rom_extended_boot_data));
> + }
> }
>
> static void ctrl_mmr_unlock(void)
> @@ -175,6 +177,15 @@ void board_init_f(ulong dummy)
> k3_sysfw_loader(true, NULL, NULL);
> }
>
> +#if defined(CONFIG_CPU_V7R)
> + /*
> + * Relocate boot information to OCRAM (after TIFS has opend this
> + * region for us) so the next bootloader stages can keep access to
> + * primary vs backup bootmodes.
> + */
> + writel(bootindex, K3_BOOT_PARAM_TABLE_INDEX_OCRAM);
> +#endif
> +
> /*
>* Force probe of clk_k3 driver here to ensure basic default clock
>* configuration is always done.
> diff --git a/arch/arm/mach-k3/include/mach/am62_hardware.h
> b/arch/arm/mach-k3/include/mach/am62_hardware.h
> index 54380f36e1..9f504f4642 100644
> --- a/arch/arm/mach-k3/include/mach/am62_hardware.h
> +++ b/arch/arm/mach-k3/include/mach/am62_hardware.h
> @@ -76,8 +76,23 @@
> #define CTRLMMR_MCU_RST_CTRL (MCU_CTRL_MMR0_BASE +
> 0x18170)
>
> #define ROM_EXTENDED_BOOT_DATA_INFO 0x43c3f1e0
> +#define K3_BOOT_PARAM_TABLE_INDEX_OCRAM 0x7000F290
>
> +/*
> + * During the boot process ROM will kill anything that writes to OCSRAM.
R5 ROM is long gone when R5 SPL starts, how would it kill anything?
>>> Looks like this was based on my patch long ago for the AM62Ax family.
>>> From what little I remember about this was ROM is leaving behind a
>>> firewall that we need TIFS's help to bring down for us. So I just
>>> blamed ROM
>> Thats true. ROM does bare minimum and so wont open up firewall around
>> main SRAM. but TIFS does, so you should be able to access this region
>> post k3_sysfw_loader().
>>
>>> IDK if this is an issue for the AM62x family
Re: [PATCH 2/3] arm: mach-k3: Remove non-cached memory map areas
On 11/23/2023 10:52 PM, Andrew Davis wrote:
> @@ -219,16 +177,9 @@ struct mm_region am62_mem_map[] = {
> }, {
> .virt = 0x8000UL,
> .phys = 0x8000UL,
> - .size = 0x1E78UL,
> - .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
> - PTE_BLOCK_INNER_SHARE
> - }, {
> - .virt = 0xA000UL,
> - .phys = 0xA000UL,
> - .size = 0x6000UL,
> + .size = 0x8000UL,
> .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>PTE_BLOCK_INNER_SHARE
> -
> }, {
> .virt = 0x88000UL,
> .phys = 0x88000UL,
This causes issues when TF-A region @0x9e78 is firewalled off from
non-secure world. A53 does speculative accesses to this region from EL1
leading to FW exceptions being reported on TIFS log (although A53 itself
doesn't seem to abort)
Re: [PATCH 2/3] board: ti: am62x: am62x: Update args_all env variable
On 4/28/2023 1:23 PM, Nikhil M Jain wrote:
> Remove the earlycon settings from args_all.
>
Could you explain why is it okay to drop earlycon?
Note, earlycon helps us to debug kernel crashes "before" kernel
initializes UART driver ... Its very useful to have it on by default
Regards
Vignesh
> Signed-off-by: Nikhil M Jain
> ---
> board/ti/am62x/am62x.env | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
> index e4e64fa637..cdd30b08ed 100644
> --- a/board/ti/am62x/am62x.env
> +++ b/board/ti/am62x/am62x.env
> @@ -7,8 +7,7 @@ findfdt=
> setenv fdtfile ${name_fdt}
> name_kern=Image
> console=ttyS2,115200n8
> -args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
> - ${mtdparts}
> +args_all=setenv optargs ${optargs} ${mtdparts}
> run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
>
> boot=mmc
Re: [PATCH v2 04/18] sf: Rename spi-nor-tiny functions
On 4/18/2023 9:00 PM, Simon Glass wrote: > The 'tiny' SPI nor functions have the same name as their big brothers, > which can be confusing. Use different names so it is clear which > version is in the image. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > drivers/mtd/spi/spi-nor-tiny.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) Acked-by: Vignesh Raghavendra
Re: [U-Boot] [U-Boot,1/2] spi: ti_qspi: Drop non DM code
On Mon, Feb 11, 2019 at 02:35:35PM +0530, Vignesh R wrote: > Now that all boards using TI QSPI have moved to DM and DT, drop non DM > code completely. > > Signed-off-by: Vignesh R > Reviewed-by: Tom Rini > --- > drivers/spi/Kconfig | 12 +- > drivers/spi/Makefile | 2 +- > drivers/spi/ti_qspi.c | 231 ++--- > include/configs/am43xx_evm.h | 2 - > include/configs/am57xx_evm.h | 2 - > include/configs/cl-som-am57x.h | 1 - > include/configs/cm_t43.h | 1 - > include/configs/dra7xx_evm.h | 2 - > scripts/config_whitelist.txt | 2 - > 9 files changed, 45 insertions(+), 210 deletions(-) The problem is that cl-som-am57x isn't converted to enabling CONFIG_DM at all. Uri, is this something that's on your current TODO list? Thanks! Uri indicated that there is no plan to convert cl-som-am57x to CONFIG_DM at all. So should we drop the support or is there a way to mark it broken? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
