armv8: usec2ticks function defined
Subsystems (3)
PATCH v2 1/5 armv8: usec2ticks function defined
usec2ticks() function has been defined for ARMv8 which will be used by SEC Driver.
---
Changes in v2:
New Patch Set created with an additional patch.
arch/arm/cpu/armv8/generic_timer.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
arch/arm/cpu/armv8/generic_timer.c +11 -0
@@ -40,3 +40,14 @@ unsigned long timer_read_counter(void)#endif return cntpct; } + +unsigned long usec2ticks (unsigned long usec) +{ +ulong ticks; +if (usec <1000 ) + ticks = ((usec * (get_tbclk ()/1000 )) +500 ) /1000 ; +else + ticks = ((usec /10 ) * (get_tbclk () /100000 )); + +return ticks; +}
Signature · 1 line
1.8.1.4
PATCH v2 2/5 armv8: Make SEC read/write as snoopable for LS1043
For LS1043, SEC read/writes are made snoopable by setting the corresponding bits in SCFG to avoid coherency issues.
---
Changes in v2:
New Patch Set created with an additional patch
Commit Subject modified
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm/cpu/armv8/fsl-layerscape/soc.c +5 -0
@@ -81,11 +81,16 @@ void fsl_lsch3_early_init_f(void)void fsl_lsch2_early_init_f (void ) {struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR ; +struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR ;#ifdef CONFIG_FSL_IFC init_early_memctl_regs ();/* tighten IFC timing */ #endif +/* Make SEC reads and writes snoopable */ +setbits_be32 (&scfg->snpcnfgcr,SCFG_SNPCNFGCR_SECRDSNP | +SCFG_SNPCNFGCR_SECWRSNP ); +/* * Enable snoop requests and DVM message requests for * Slave insterface S4 (A53 core cluster)
Signature · 1 line
1.8.1.4
PATCH 3/5 Data type defined for pointer addresses
In reply to Aneesh BansalA new data type uintptr_t has been defined for creating pointers (32 or 64 bit depending on Core) from 32 bit variables storing the address.
If a 32 bit variable (u32) is typecasted to a pointer (void *), compiler gives a warning in case size of pointer on the core is 64 bit.
--- arch/arm/include/asm/types.h | 2 ++ arch/powerpc/include/asm/types.h | 1 + 2 files changed, 3 insertions(+)
arch/arm/include/asm/types.h +2 -0
@@ -56,6 +56,8 @@ typedef unsigned long phys_addr_t;typedef unsigned long phys_size_t ;#endif +typedef unsigned long uintptr_t ; +#endif /* __KERNEL__ */ typedef unsigned long resource_size_t ;
arch/powerpc/include/asm/types.h +1 -0
@@ -56,6 +56,7 @@ typedef unsigned long phys_addr_t;typedef unsigned long phys_size_t ;#endif +typedef unsigned long uintptr_t ;#endif /* __KERNEL__ */ #endif /* __ASSEMBLY__ */
Signature · 1 line
1.8.1.4
PATCH 3/5 Data type defined for pointer addresses
Guys,
Please comment on this new typedef. I am not comfortable to accept it.
Quoted 17 lines · Aneesh Bansal
A new data type
uintptr_thas been defined for creating pointers (32 or 64 bit depending on Core) from 32 bit variables storing the address.
If a 32 bit variable (u32) is typecasted to a pointer (void *), compiler gives a warning in case size of pointer on the core is 64 bit.Signed-off-by Aneesh Bansal <[email protected]>--- arch/arm/include/asm/types.h | 2 ++ arch/powerpc/include/asm/types.h | 1 + 2 files changed, 3 insertions(+)arch/arm/include/asm/types.h +0
-0
arch/arm/include/asm/types.h typedef unsigned long phys_addr_t; · line 59
Quoted 4 lines
arch/arm/include/asm/types.h +1
-0@@ -56,6 +56,8 @@ typedef unsigned long phys_addr_t;typedef unsigned long phys_size_t ;#endif +typedef unsigned long uintptr_t ;
It is used in next patch of this series
http://patchwork.ozlabs.org/patch/552669/, in two-step casting such as
(u8 *)(uintptr_t)csf_hdr_addr
As OP indicated, the variable is u32. Casting to a pointer causes compiling warning. Is this the right approach?
York
PATCH 3/5 Data type defined for pointer addresses
It is required because the variable is 32 bit in length and it must be typecasted to a pointer before passing to some functions.
The pointer length is 64 bit on 64 bit cores and 32 bit on 32 bit cores.
So if I have (u8*)csf_hdr_addr, a warning is given on 64 bit cores like ARMv8 on LS1043. Thus the variable must be typecasted to 'unsigned long' which is 64 or 32 bit depending on the core before typecasting to a pointer. Currently there is no typedef for 'unsigned long' in uboot. That is the reason I thought of adding it.
Is there any other way of achieving this?
Regards,
Aneesh Bansal
Sent from Samsung Mobile.
-------- Original message --------
From: York Sun
Date:07/12/2015 10:20 PM (GMT+05:30)
To: Bansal Aneesh-B39320 , u-boot at lists.denx.de, Tom Rini , Wolfgang Denk , Wood Scott-B07421 , Simon Glass
Cc: Gupta Ruchika-R66431 , Kushwaha Prabhakar-B32579
Subject: Re: [PATCH 3/5] Data type defined for pointer addresses
Guys,
Please comment on this new typedef. I am not comfortable to accept it.
Quoted 17 lines · Aneesh Bansal
A new data type
uintptr_thas been defined for creating pointers (32 or 64 bit depending on Core) from 32 bit variables storing the address.
If a 32 bit variable (u32) is typecasted to a pointer (void *), compiler gives a warning in case size of pointer on the core is 64 bit.Signed-off-by Aneesh Bansal <[email protected]>--- arch/arm/include/asm/types.h | 2 ++ arch/powerpc/include/asm/types.h | 1 + 2 files changed, 3 insertions(+)arch/arm/include/asm/types.h +0
-0
arch/arm/include/asm/types.h typedef unsigned long phys_addr_t; · line 59
Quoted 4 lines
arch/arm/include/asm/types.h +1
-0@@ -56,6 +56,8 @@ typedef unsigned long phys_addr_t;typedef unsigned long phys_size_t ;#endif +typedef unsigned long uintptr_t ;
It is used in next patch of this series
http://patchwork.ozlabs.org/patch/552669/, in two-step casting such as
(u8 *)(uintptr_t)csf_hdr_addr
As OP indicated, the variable is u32. Casting to a pointer causes compiling warning. Is this the right approach?
York
PATCH 3/5 Data type defined for pointer addresses
In reply to York SunQuoted 30 lines · York Sun
Guys,
Please comment on this new typedef. I am not comfortable to accept it.
Quoted 17 lines · Aneesh Bansal
A new data type
uintptr_thas been defined for creating pointers (32 or 64 bit depending on Core) from 32 bit variables storing the address.
If a 32 bit variable (u32) is typecasted to a pointer (void *), compiler gives a warning in case size of pointer on the core is 64 bit.Signed-off-by Aneesh Bansal <[email protected]>--- arch/arm/include/asm/types.h | 2 ++ arch/powerpc/include/asm/types.h | 1 + 2 files changed, 3 insertions(+)arch/arm/include/asm/types.h +0
-0arch/arm/include/asm/types.h typedef unsigned long phys_addr_t; · line 59
Quoted 4 lines
arch/arm/include/asm/types.h +1
-0@@ -56,6 +56,8 @@ typedef unsigned long phys_addr_t;typedef unsigned long phys_size_t ;#endif +typedef unsigned long uintptr_t ;It is used in next patch of this series
http://patchwork.ozlabs.org/patch/552669/, in two-step casting such as
Quoted 4 lines
(u8 *)(uintptr_t)csf_hdr_addr
As OP indicated, the variable is u32. Casting to a pointer causes compiling warning. Is this the right approach?
Approach is OK. But please do it as a "backport" of 142956af from the linux kernel which adds 142956af to <linux/types.h> so everyone has it.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151207/845b8008/attachment.sig>
PATCH 3/5 Data type defined for pointer addresses
Quoted 31 lines · Tom Rini
Quoted 30 lines · York Sun
Guys,
Please comment on this new typedef. I am not comfortable to accept it.
Quoted 17 lines · Aneesh Bansal
A new data type
uintptr_thas been defined for creating pointers (32 or 64 bit depending on Core) from 32 bit variables storing the address.
If a 32 bit variable (u32) is typecasted to a pointer (void *), compiler gives a warning in case size of pointer on the core is 64 bit.Signed-off-by Aneesh Bansal <[email protected]>--- arch/arm/include/asm/types.h | 2 ++ arch/powerpc/include/asm/types.h | 1 + 2 files changed, 3 insertions(+)arch/arm/include/asm/types.h +0
-0arch/arm/include/asm/types.h typedef unsigned long phys_addr_t; · line 59
Quoted 4 lines
arch/arm/include/asm/types.h +1
-0@@ -56,6 +56,8 @@ typedef unsigned long phys_addr_t;typedef unsigned long phys_size_t ;#endif +typedef unsigned long uintptr_t ;It is used in next patch of this series
http://patchwork.ozlabs.org/patch/552669/, in two-step casting such as
Quoted 8 lines
Quoted 5 lines
(u8 *)(uintptr_t)csf_hdr_addr
As OP indicated, the variable is u32. Casting to a pointer causes compiling
warning. Is this the right approach?Approach is OK. But please do it as a "backport" of
142956affrom the linux kernel which adds142956afto <linux/types.h> so everyone has it.
There's also an existing uintptr_t typedef in include/compiler.h...
-Scott
PATCH 3/5 Data type defined for pointer addresses
Quoted 34 lines · Scott Wood
Quoted 33 lines · Tom Rini
Quoted 32 lines · York Sun
Guys,
Please comment on this new typedef. I am not comfortable to accept it.
Quoted 17 lines · Aneesh Bansal
A new data type
uintptr_thas been defined for creating pointers (32 or 64 bit depending on Core) from 32 bit variables storing the address.
If a 32 bit variable (u32) is typecasted to a pointer (void *), compiler gives a warning in case size of pointer on the core is 64 bit.Signed-off-by Aneesh Bansal <[email protected]>--- arch/arm/include/asm/types.h | 2 ++ arch/powerpc/include/asm/types.h | 1 + 2 files changed, 3 insertions(+)arch/arm/include/asm/types.h +0
-0arch/arm/include/asm/types.h typedef unsigned long phys_addr_t; · line 59
Quoted 4 lines
arch/arm/include/asm/types.h +1
-0@@ -56,6 +56,8 @@ typedef unsigned long phys_addr_t;typedef unsigned long phys_size_t ;#endif +typedef unsigned long uintptr_t ;It is used in next patch of this series
http://patchwork.ozlabs.org/patch/552669/, in two-step casting such as(u8 *)(uintptr_t)csf_hdr_addr
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
As OP indicated, the variable is u32. Casting to a pointer causes compiling
warning. Is this the right approach?Approach is OK. But please do it as a "backport" of
142956affrom the linux kernel which adds142956afto <linux/types.h> so everyone has it.There's also an existing
uintptr_ttypedef ininclude/compiler.h...
Tom,
We seem not having the abuse of ptrdiff_t. So the equivalent of Linux commit 142956af would be moving this typedef from include/compiler.h to include/linux/types.h.
York
PATCH 3/5 Data type defined for pointer addresses
Quoted 44 lines · York Sun
Quoted 41 lines · Scott Wood
Quoted 39 lines · Tom Rini
Quoted 30 lines · York Sun
Guys,
Please comment on this new typedef. I am not comfortable to accept it.
Quoted 17 lines · Aneesh Bansal
A new data type
uintptr_thas been defined for creating pointers (32 or 64 bit depending on Core) from 32 bit variables storing the address.
If a 32 bit variable (u32) is typecasted to a pointer (void *), compiler gives a warning in case size of pointer on the core is 64 bit.Signed-off-by Aneesh Bansal <[email protected]>--- arch/arm/include/asm/types.h | 2 ++ arch/powerpc/include/asm/types.h | 1 + 2 files changed, 3 insertions(+)arch/arm/include/asm/types.h +0
-0arch/arm/include/asm/types.h typedef unsigned long phys_addr_t; · line 59
Quoted 4 lines
arch/arm/include/asm/types.h +1
-0@@ -56,6 +56,8 @@ typedef unsigned long phys_addr_t;typedef unsigned long phys_size_t ;#endif +typedef unsigned long uintptr_t ;It is used in next patch of this series
http://patchwork.ozlabs.org/patch/552669/, in two-step casting such asQuoted 5 lines
(u8 *)(uintptr_t)csf_hdr_addr
As OP indicated, the variable is u32. Casting to a pointer causes compiling
warning. Is this the right approach?Approach is OK. But please do it as a "backport" of
142956affrom the linux kernel which adds142956afto <linux/types.h> so everyone has it.
Quoted 8 lines
Quoted 2 lines
There's also an existing
uintptr_ttypedef ininclude/compiler.h...Tom,
We seem not having the abuse of
ptrdiff_t. So the equivalent of Linux commit142956afwould be moving this typedef frominclude/compiler.htoinclude/linux/types.h.
Ah good, thanks. I didn't follow the trail too far.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151207/c720fd5e/attachment.sig>
PATCH 3/5 Data type defined for pointer addresses
Quoted 48 lines · Tom Rini
Quoted 47 lines · York Sun
Quoted 43 lines · Scott Wood
Quoted 31 lines · Tom Rini
Quoted 30 lines · York Sun
Guys,
Please comment on this new typedef. I am not comfortable to accept it.
Quoted 17 lines · Aneesh Bansal
A new data type
uintptr_thas been defined for creating pointers (32 or 64 bit depending on Core) from 32 bit variables storing the address.
If a 32 bit variable (u32) is typecasted to a pointer (void *), compiler gives a warning in case size of pointer on the core is 64 bit.Signed-off-by Aneesh Bansal <[email protected]>--- arch/arm/include/asm/types.h | 2 ++ arch/powerpc/include/asm/types.h | 1 + 2 files changed, 3 insertions(+)arch/arm/include/asm/types.h +0
-0arch/arm/include/asm/types.h typedef unsigned long phys_addr_t; · line 59
Quoted 4 lines
arch/arm/include/asm/types.h +1
-0@@ -56,6 +56,8 @@ typedef unsigned long phys_addr_t;typedef unsigned long phys_size_t ;#endif +typedef unsigned long uintptr_t ;It is used in next patch of this series
http://patchwork.ozlabs.org/patch/552669/, in two-step casting such asQuoted 8 lines
Quoted 5 lines
(u8 *)(uintptr_t)csf_hdr_addr
As OP indicated, the variable is u32. Casting to a pointer causes compiling
warning. Is this the right approach?Approach is OK. But please do it as a "backport" of
142956affrom the linux kernel which adds142956afto <linux/types.h> so everyone has it.There's also an existing
uintptr_ttypedef ininclude/compiler.h...
Quoted 8 lines
Quoted 5 lines
Tom,
We seem not having the abuse of
ptrdiff_t. So the equivalent of Linux commit142956afwould be moving this typedef frominclude/compiler.htoinclude/linux/types.h.Ah good, thanks. I didn't follow the trail too far.
Aneesh,
Please revise your patch according to the feedback. Thanks.
York
PATCH v2 4/5 armv8/ls1043ardb: SECURE BOOT target added for NOR
In reply to Aneesh BansalLS1043ARDB Secure Boot Target from NOR has been added.
- Configs defined to enable esbc_validate.
- ESBC Address in header is made 64 bit.
- SMMU is re-configured in Bypass mode.
---
Changes in v2:
New Patch Set created with an additional patch. Pointers typecasted to uintptr_t to remove compiler warnings
arch/arm/include/asm/arch-fsl-layerscape/config.h | 16 ++++++++-- .../include/asm/arch-fsl-layerscape/immap_lsch2.h | 2 +- board/freescale/common/fsl_validate.c | 35 +++++++++++++--------- board/freescale/ls1043ardb/MAINTAINERS | 5 ++++ board/freescale/ls1043ardb/ls1043ardb.c | 18 ++++++++++- common/cmd_blob.c | 6 ++-- configs/ls1043ardb_SECURE_BOOT_defconfig | 4 +++ include/configs/ls1043ardb.h | 12 ++++++++ include/fsl_validate.h | 9 +++++- 9 files changed, 85 insertions(+), 22 deletions(-) create mode 100644 configs/ls1043ardb_SECURE_BOOT_defconfig
arch/arm/include/asm/arch-fsl-layerscape/config.h +14 -2
@@ -122,9 +122,21 @@#define CONFIG_SYS_FSL_SRDS_1 #define CONFIG_SYS_FSL_PCIE_COMPAT "fsl,qoriq-pcie-v2.4" +#ifdef CONFIG_SECURE_BOOT +#define CONFIG_CMD_ESBC_VALIDATE +#define CONFIG_FSL_SEC_MON +#define CONFIG_SHA_PROG_HW_ACCEL +#define CONFIG_DM +#define CONFIG_RSA +#define CONFIG_RSA_FREESCALE_EXP +#ifndef CONFIG_FSL_CAAM +#define CONFIG_FSL_CAAM +#endif +#endif +#define CONFIG_SYS_FSL_SFP_VER_3_2 -#define CONFIG_SYS_FSL_SNVS_LE -#define CONFIG_SYS_FSL_SEC_LE +#define CONFIG_SYS_FSL_SEC_MON_BE +#define CONFIG_SYS_FSL_SEC_BE #define CONFIG_SYS_FSL_SFP_BE #define CONFIG_SYS_FSL_SRK_LE #define CONFIG_KEY_REVOCATION
arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h +1 -1
@@ -38,7 +38,7 @@#define CONFIG_SYS_PCIE3_ADDR (CONFIG_SYS_IMMR + 0x2600000)#define CONFIG_SYS_FSL_SEC_ADDR (CONFIG_SYS_IMMR + 0x700000)#define CONFIG_SYS_FSL_JR0_ADDR (CONFIG_SYS_IMMR + 0x710000) -#define CONFIG_SYS_SNVS_ADDR (CONFIG_SYS_IMMR + 0xe90000) +#define CONFIG_SYS_SEC_MON_ADDR (CONFIG_SYS_IMMR + 0xe90000)#define CONFIG_SYS_SFP_ADDR (CONFIG_SYS_IMMR + 0xe80200)#define CONFIG_SYS_FSL_TIMER_ADDR 0x02b00000
board/freescale/common/fsl_validate.c +21 -14
@@ -15,9 +15,6 @@#include <u-boot/rsa-mod-exp.h> #include <hash.h> #include <fsl_secboot_err.h> -#ifndef CONFIG_MPC85xx -#include <asm/arch/immap_ls102xa.h> -#endif #define SHA256_BITS 256#define SHA256_BYTES (256/8)
@@ -99,7 +96,8 @@ int get_csf_base_addr(u32 *csf_addr, u32 *flash_base_addr)struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR );u32 csf_hdr_addr =in_be32 (&gur->scratchrw[0 ]); -if (memcmp ((u8 *)csf_hdr_addr, barker_code,ESBC_BARKER_LEN )) +if (memcmp ((u8 *)(uintptr_t )csf_hdr_addr, + barker_code,ESBC_BARKER_LEN ))return -1 ; *csf_addr = csf_hdr_addr;
@@ -117,7 +115,7 @@ static int get_ie_info_addr(u32 *ie_addr)if (get_csf_base_addr (&csf_addr, &flash_base_addr))return -1 ; - hdr = (struct fsl_secboot_img_hdr *)csf_addr; + hdr = (struct fsl_secboot_img_hdr *)(uintptr_t )csf_addr;/* For SoC's with Trust Architecture v1 with corenet bus * the sg table field in CSF header has absolute address
@@ -130,7 +128,7 @@ static int get_ie_info_addr(u32 *ie_addr) (((u32 )hdr->psgtable & ~(CONFIG_SYS_PBI_FLASH_BASE )) + flash_base_addr);#else - sg_tbl = (struct fsl_secboot_sg_table *)(csf_addr + + sg_tbl = (struct fsl_secboot_sg_table *)(uintptr_t )(csf_addr + (u32 )hdr->psgtable);#endif
@@ -379,8 +377,8 @@ static int calc_img_key_hash(struct fsl_secboot_img_priv *img)#ifdef CONFIG_KEY_REVOCATION if (check_srk (img)) { ret = algo->hash_update (algo, ctx, - (u8 *)(img->ehdrloc + img->hdr.srk_tbl_off), - img->hdr.len_kr.num_srk *sizeof (struct srk_table ),1 ); + (u8 *)(uintptr_t )(img->ehdrloc + img->hdr.srk_tbl_off), + img->hdr.len_kr.num_srk *sizeof (struct srk_table ),1 ); srk =1 ; }#endif
@@ -438,8 +436,8 @@ static int calc_esbchdr_esbc_hash(struct fsl_secboot_img_priv *img)#ifdef CONFIG_KEY_REVOCATION if (check_srk (img)) { ret = algo->hash_update (algo, ctx, - (u8 *)(img->ehdrloc + img->hdr.srk_tbl_off), - img->hdr.len_kr.num_srk *sizeof (struct srk_table ),0 ); + (u8 *)(uintptr_t )(img->ehdrloc + img->hdr.srk_tbl_off), + img->hdr.len_kr.num_srk *sizeof (struct srk_table ),0 ); key_hash =1 ; }#endif
@@ -454,8 +452,13 @@ static int calc_esbchdr_esbc_hash(struct fsl_secboot_img_priv *img)return ret;/* Update hash for actual Image */ +#ifdef CONFIG_ESBC_ADDR_64BIT + ret = algo->hash_update (algo, ctx, + (u8 *)(uintptr_t )img->hdr.pimg64, img->hdr.img_size,1 ); +#else ret = algo->hash_update (algo, ctx, - (u8 *)img->hdr.pimg, img->hdr.img_size,1 ); + (u8 *)(uintptr_t )img->hdr.pimg, img->hdr.img_size,1 ); +#endif if (ret)return ret;
@@ -533,7 +536,7 @@ static int read_validate_esbc_client_header(struct fsl_secboot_img_priv *img) {char buf[20 ];struct fsl_secboot_img_hdr *hdr = &img->hdr; -void *esbc = (u8 *)img->ehdrloc; +void *esbc = (u8 *)(uintptr_t )img->ehdrloc;u8 *k, *s;#ifdef CONFIG_KEY_REVOCATION u32 ret;
@@ -549,7 +552,11 @@ static int read_validate_esbc_client_header(struct fsl_secboot_img_priv *img)if (memcmp (hdr->barker, barker_code,ESBC_BARKER_LEN ))return ERROR_ESBC_CLIENT_HEADER_BARKER ; +#ifdef CONFIG_ESBC_ADDR_64BIT +sprintf (buf,"%llx" , hdr->pimg64); +#else sprintf (buf,"%x" , hdr->pimg); +#endif setenv ("img_addr" , buf);if (!hdr->img_size)
@@ -594,7 +601,7 @@ static int read_validate_esbc_client_header(struct fsl_secboot_img_priv *img)if (!key_found &&check_ie (img)) {if (get_ie_info_addr (&img->ie_addr))return ERROR_IE_TABLE_NOT_FOUND ; - ie_info = (struct ie_key_info *)img->ie_addr; + ie_info = (struct ie_key_info *)(uintptr_t )img->ie_addr;if (ie_info->num_keys ==0 || ie_info->num_keys >32 )return ERROR_ESBC_CLIENT_HEADER_INVALID_IE_NUM_ENTRY ;
@@ -748,7 +755,7 @@ int fsl_secboot_validate(cmd_tbl_t *cmdtp, int flag, int argc, hdr = &img->hdr; img->ehdrloc = addr; - esbc = (u8 *)img->ehdrloc; + esbc = (u8 *)(uintptr_t )img->ehdrloc;memcpy (hdr, esbc,sizeof (struct fsl_secboot_img_hdr ));
board/freescale/ls1043ardb/MAINTAINERS +5 -0
@@ -7,3 +7,8 @@ F: include/configs/ls1043ardb.h F: configs/ls1043ardb_defconfig F: configs/ls1043ardb_nand_defconfig F: configs/ls1043ardb_sdcard_defconfig + +LS1043A_SECURE_BOOT BOARD +M: Aneesh Bansal <[email protected]> +S: Maintained +F: configs/ls1043ardb_SECURE_BOOT_defconfig
board/freescale/ls1043ardb/ls1043ardb.c +17 -1
@@ -18,6 +18,8 @@#include <fsl_csu.h> #include <fsl_esdhc.h> #include <fsl_ifc.h> +#include <environment.h> +#include <fsl_sec.h> #include "cpld.h" DECLARE_GLOBAL_DATA_PTR ;
@@ -107,7 +109,21 @@ int config_board_mux(void)int misc_init_r (void ) {config_board_mux (); - +#ifdef CONFIG_SECURE_BOOT +#ifdef CONFIG_LS1043A +/* In case of Secure Boot, the IBR configures the SMMU +* to allow only Secure transactions. +* SMMU must be reset in bypass mode. +* Set the ClientPD bit and Clear the USFCFG Bit +*/ +u32 val; + val = (in_le32 (SMMU_SCR0 ) |SCR0_CLIENTPD_MASK ) & ~(SCR0_USFCFG_MASK ); +out_le32 (SMMU_SCR0 , val); + val = (in_le32 (SMMU_NSCR0 ) |SCR0_CLIENTPD_MASK ) & ~(SCR0_USFCFG_MASK ); +out_le32 (SMMU_NSCR0 , val); +#endif +return sec_init (); +#endif return 0 ; }#endif
common/cmd_blob.c +3 -3
@@ -73,9 +73,9 @@ static int do_blob(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[]) len =simple_strtoul (argv[4 ],NULL ,16 ); key_addr =simple_strtoul (argv[5 ],NULL ,16 ); - km_ptr = (uint8_t *)key_addr; - src_ptr = (uint8_t *)src_addr; - dst_ptr = (uint8_t *)dst_addr; + km_ptr = (uint8_t *)(uintptr_t )key_addr; + src_ptr = (uint8_t *)(uintptr_t )src_addr; + dst_ptr = (uint8_t *)(uintptr_t )dst_addr;if (enc) ret =blob_encap (km_ptr, src_ptr, dst_ptr, len);
configs/ls1043ardb_SECURE_BOOT_defconfig new file +4 -0
@@ -0,0 +1,4 @@ +CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4, SECURE_BOOT" +CONFIG_ARM=y +CONFIG_TARGET_LS1043ARDB=y +CONFIG_FSL_LAYERSCAPE=y
include/configs/ls1043ardb.h +12 -0
@@ -268,4 +268,16 @@#define CONFIG_ETHPRIME "FM1 at DTSEC3"#endif +#ifdef CONFIG_SECURE_BOOT +/* Hash command with SHA acceleration supported in hardware */ +#define CONFIG_CMD_HASH +#define CONFIG_SHA_HW_ACCEL +#define CONFIG_CMD_BLOB + +/* For LS1043 (ARMv8), ESBC image Address in Header is 64 bit */ +#define CONFIG_ESBC_ADDR_64BIT + +#include <asm/fsl_secure_boot.h> +#endif +#endif /* __LS1043ARDB_H__ */
include/fsl_validate.h +8 -1
@@ -83,7 +83,9 @@ struct fsl_secboot_img_hdr {u32 sign_len;/* length of the signature in bytes */ union {u32 psgtable;/* ptr to SG table */ +#ifndef CONFIG_ESBC_ADDR_64BIT u32 pimg;/* ptr to ESBC client image */ +#endif };union {u32 sg_entries;/* no of entries in SG table */
@@ -97,7 +99,12 @@ struct fsl_secboot_img_hdr {u32 reserved1[2 ];u32 fsl_uid_1;u32 oem_uid_1; -u32 reserved2[2 ]; +union { +u32 reserved2[2 ]; +#ifdef CONFIG_ESBC_ADDR_64BIT +u64 pimg64;/* 64 bit pointer to ESBC Image */ +#endif + };u32 ie_flag;u32 ie_key_sel; };
Signature · 1 line
1.8.1.4
PATCH v2 4/5 armv8/ls1043ardb: SECURE BOOT target added for NOR
Add folks familiar with DSPI.
Quoted 11 lines · Aneesh Bansal
LS1043ARDB Secure Boot Target from NOR has been added.
- Configs defined to enableesbc_validate.
- ESBC Address in header is made 64 bit.
- SMMU is re-configured in Bypass mode.Signed-off-by Aneesh Bansal <[email protected]>---
Changes in v2:
New Patch Set created with an additional patch. Pointers typecasted touintptr_tto remove compiler warnings
Quoted 11 lines
arch/arm/include/asm/arch-fsl-layerscape/config.h | 16 ++++++++-- .../include/asm/arch-fsl-layerscape/immap_lsch2.h | 2 +- board/freescale/common/fsl_validate.c | 35 +++++++++++++--------- board/freescale/ls1043ardb/MAINTAINERS | 5 ++++ board/freescale/ls1043ardb/ls1043ardb.c | 18 ++++++++++- common/cmd_blob.c | 6 ++-- configs/ls1043ardb_SECURE_BOOT_defconfig | 4 +++ include/configs/ls1043ardb.h | 12 ++++++++ include/fsl_validate.h | 9 +++++- 9 files changed, 85 insertions(+), 22 deletions(-) create mode 100644 configs/ls1043ardb_SECURE_BOOT_defconfig
I know a recent change requires CONFIG_SYS_NS16550=y. I am not sure if DSPI can/should be enabled. Let's wait for Alison/Prabhakar's comment on DSPI.
Alison/Prabhakar, DSPI support is enabled using DM for QDS and RDB for NOR boot. Do we want to enable DSPI for nand boot, and secure boot?
<snip>
Quoted 9 lines
include/configs/ls1043ardb.h +1
-0@@ -268,4 +268,16 @@#define CONFIG_ETHPRIME "FM1 at DTSEC3"#endif +#ifdef CONFIG_SECURE_BOOT
include/configs/ls1043ardb.h line 281
Quoted 10 lines
include/configs/ls1043ardb.h +10
-0+/* Hash command with SHA acceleration supported in hardware */ +#define CONFIG_CMD_HASH +#define CONFIG_SHA_HW_ACCEL +#define CONFIG_CMD_BLOB + +/* For LS1043 (ARMv8), ESBC image Address in Header is 64 bit */ +#define CONFIG_ESBC_ADDR_64BIT + +#include <asm/fsl_secure_boot.h> +#endif
Do you want to put this include inside ifdef? You have both ways in different header files.
York
PATCH v2 5/5 drivers/crypto/fsl: fix endianness issue in RNG
In reply to Aneesh BansalFor Setting and clearing the bits in SEC Block registers sec_clrbits32() and sec_setbits32() are used which work as per endianness of CAAM block.
So these must be used with SEC register address as argument. If the value is read in a local variable, then the functions will not behave correctly where endianness of CAAM and core is different.
---
Changes in v2:
New Patch Set created with an additional patch.
drivers/crypto/fsl/jr.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-)
drivers/crypto/fsl/jr.c +2 -6
@@ -470,17 +470,13 @@ static void kick_trng(int ent_delay)sec_out32 (&rng->rtfreqmin, ent_delay >>2 );/* disable maximum frequency count */ sec_out32 (&rng->rtfreqmax,RTFRQMAX_DISABLE ); -/* read the control register */ - val =sec_in32 (&rng->rtmctl);/* * select raw sampling in both entropy shifter * and statistical checker */ -sec_setbits32 (&val,RTMCTL_SAMP_MODE_RAW_ES_SC ); +sec_setbits32 (&rng->rtmctl,RTMCTL_SAMP_MODE_RAW_ES_SC );/* put RNG4 into run mode */ -sec_clrbits32 (&val,RTMCTL_PRGM ); -/* write back the control register */ -sec_out32 (&rng->rtmctl, val); +sec_clrbits32 (&rng->rtmctl,RTMCTL_PRGM ); }static int rng_init (void )
Signature · 1 line
1.8.1.4
PATCH v2 1/5 armv8: usec2ticks function defined
In reply to Aneesh BansalQuoted 21 lines · Aneesh Bansal
usec2ticks()function has been defined for ARMv8 which will be used by SEC Driver.Signed-off-by Aneesh Bansal <[email protected]>---
Changes in v2:
New Patch Set created with an additional patch.arch/arm/cpu/armv8/generic_timer.c | 11 +++++++++++ 1 file changed, 11 insertions(+)arch/arm/cpu/armv8/generic_timer.c +1
-0@@ -40,3 +40,14 @@ unsigned long timer_read_counter(void)#endif return cntpct; } +
arch/arm/cpu/armv8/generic_timer.c unsigned long timer_read_counter(void) · line 53
Quoted 10 lines
arch/arm/cpu/armv8/generic_timer.c +10
-0+unsigned long usec2ticks (unsigned long usec) +{ +ulong ticks; +if (usec <1000 ) + ticks = ((usec * (get_tbclk ()/1000 )) +500 ) /1000 ; +else + ticks = ((usec /10 ) * (get_tbclk () /100000 )); + +return ticks; +}
Is existing usec_to_tick() in lib/time.c good for you?
York
PATCH v2 1/5 armv8: usec2ticks function defined
Quoted 42 lines
-----Original Message-----
From: York Sun [mailto:yorksun at freescale.com]
Sent: Thursday, November 19, 2015 10:26 PM
To: Bansal Aneesh-B39320 <[email protected]>; u-boot at lists.denx.de
Cc: Gupta Ruchika-R66431 <[email protected]>; Kushwaha Prabhakar- B32579 <[email protected]>
Subject: Re: [PATCH 1/5][v2] armv8: usec2ticks function definedQuoted 20 lines · Aneesh Bansal
usec2ticks()function has been defined for ARMv8 which will be used by SEC Driver.Signed-off-by Aneesh Bansal <[email protected]>---
Changes in v2:
New Patch Set created with an additional patch.arch/arm/cpu/armv8/generic_timer.c | 11 +++++++++++ 1 file changed, 11 insertions(+)arch/arm/cpu/armv8/generic_timer.c +1
-0@@ -40,3 +40,14 @@ unsigned long timer_read_counter(void) #endifreturn cntpct; } +arch/arm/cpu/armv8/generic_timer.c unsigned long timer_read_counter(void) #endif · line 52
Quoted 10 lines
arch/arm/cpu/armv8/generic_timer.c +9
-0+unsigned long usec2ticks (unsigned long usec) { +ulong ticks; +if (usec <1000 ) + ticks = ((usec * (get_tbclk ()/1000 )) +500 ) /1000 ; +else + ticks = ((usec /10 ) * (get_tbclk () /100000 )); + +return ticks; +}Is existing
usec_to_tick()inlib/time.cgood for you?
Quoted 1 line
York
The CAAM driver in U-Boot uses the function usec2ticks(). This is already defined for previous SoC's LS1020 (ARM v7) and PPC.
Aneesh