[U-Boot] [PATCH v2] defconfig: Add a config for AM335x High Security EVM
Add a new defconfig file for the AM335x High Security EVM. This config is specific for the case of memory device booting. Memory device booting is handled separatly from peripheral booting on HS devices as the load address changes.
This defconfig is the same as for the non-secure part, except for: CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_ISW_ENTRY_ADDR updated for secure images. CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_USE_TINY_PRINTF option set to 'y' to reduce SPL size CONFIG_SPL_SYS_MALLOC_SIMPLE set to 'y' to reduce SPL size
Signed-off-by: Andrew F. Davis afd@ti.com ---
Changes from v1: - Add to MAINTAINERS file
MAINTAINERS | 1 + configs/am335x_hs_evm_defconfig | 62 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+) create mode 100644 configs/am335x_hs_evm_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS index 1ea7ae013a..788e16a391 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -441,6 +441,7 @@ F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S F: arch/arm/mach-omap2/omap5/sec-fxns.c F: arch/arm/mach-omap2/sec-common.c F: arch/arm/mach-omap2/config_secure.mk +F: configs/am335x_hs_evm_defconfig F: configs/am43xx_hs_evm_defconfig F: configs/am57xx_hs_evm_defconfig F: configs/dra7xx_hs_evm_defconfig diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig new file mode 100644 index 0000000000..f8445c3249 --- /dev/null +++ b/configs/am335x_hs_evm_defconfig @@ -0,0 +1,62 @@ +CONFIG_ARM=y +CONFIG_AM33XX=y +CONFIG_TI_SECURE_DEVICE=y +# CONFIG_SPL_EXT_SUPPORT is not set +# CONFIG_SPL_NAND_SUPPORT is not set +CONFIG_TARGET_AM335X_EVM=y +CONFIG_ISW_ENTRY_ADDR=0x40300350 +CONFIG_SPL_STACK_R_ADDR=0x82000000 +# CONFIG_SPL_YMODEM_SUPPORT is not set +CONFIG_DEFAULT_DEVICE_TREE="am335x-evm" +CONFIG_DISTRO_DEFAULTS=y +CONFIG_FIT=y +CONFIG_SYS_EXTRA_OPTIONS="NAND" +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y +CONFIG_FIT_IMAGE_POST_PROCESS=y +CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_VERSION_VARIABLE=y +CONFIG_SPL=y +CONFIG_SPL_SYS_MALLOC_SIMPLE=y +CONFIG_SPL_STACK_R=y +CONFIG_SPL_MTD_SUPPORT=y +# CONFIG_CMD_IMLS is not set +CONFIG_CMD_ASKENV=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y +CONFIG_CMD_DFU=y +CONFIG_CMD_GPIO=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_EXT4_WRITE=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2" +# CONFIG_BLK is not set +CONFIG_DFU_MMC=y +CONFIG_DFU_NAND=y +CONFIG_DFU_RAM=y +CONFIG_DM_I2C=y +CONFIG_DM_MMC=y +# CONFIG_DM_MMC_OPS is not set +CONFIG_MMC_OMAP_HS=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_WINBOND=y +CONFIG_DM_ETH=y +CONFIG_SYS_NS16550=y +CONFIG_TIMER=y +CONFIG_OMAP_TIMER=y +CONFIG_USB=y +CONFIG_USB_MUSB_HOST=y +CONFIG_USB_MUSB_GADGET=y +CONFIG_USB_STORAGE=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_G_DNL_MANUFACTURER="Texas Instruments" +CONFIG_G_DNL_VENDOR_NUM=0x0451 +CONFIG_G_DNL_PRODUCT_NUM=0xd022 +CONFIG_USE_TINY_PRINTF=y +CONFIG_RSA=y +CONFIG_SPL_OF_LIBFDT=y
On Mon, Jan 16, 2017 at 10:44:49AM -0600, Andrew F. Davis wrote:
Add a new defconfig file for the AM335x High Security EVM. This config is specific for the case of memory device booting. Memory device booting is handled separatly from peripheral booting on HS devices as the load address changes.
This defconfig is the same as for the non-secure part, except for: CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_ISW_ENTRY_ADDR updated for secure images. CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_USE_TINY_PRINTF option set to 'y' to reduce SPL size CONFIG_SPL_SYS_MALLOC_SIMPLE set to 'y' to reduce SPL size
Signed-off-by: Andrew F. Davis afd@ti.com
Reviewed-by: Tom Rini trini@konsulko.com
On Monday 16 January 2017 10:14 PM, Andrew F. Davis wrote:
Add a new defconfig file for the AM335x High Security EVM. This config is specific for the case of memory device booting. Memory device booting is handled separatly from peripheral booting on HS devices as the load address changes.
This defconfig is the same as for the non-secure part, except for: CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_ISW_ENTRY_ADDR updated for secure images. CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_USE_TINY_PRINTF option set to 'y' to reduce SPL size CONFIG_SPL_SYS_MALLOC_SIMPLE set to 'y' to reduce SPL size
Signed-off-by: Andrew F. Davis afd@ti.com
Changes from v1:
- Add to MAINTAINERS file
MAINTAINERS | 1 + configs/am335x_hs_evm_defconfig | 62 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+) create mode 100644 configs/am335x_hs_evm_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS index 1ea7ae013a..788e16a391 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -441,6 +441,7 @@ F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S F: arch/arm/mach-omap2/omap5/sec-fxns.c F: arch/arm/mach-omap2/sec-common.c F: arch/arm/mach-omap2/config_secure.mk +F: configs/am335x_hs_evm_defconfig F: configs/am43xx_hs_evm_defconfig F: configs/am57xx_hs_evm_defconfig F: configs/dra7xx_hs_evm_defconfig diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig new file mode 100644 index 0000000000..f8445c3249 --- /dev/null +++ b/configs/am335x_hs_evm_defconfig @@ -0,0 +1,62 @@ +CONFIG_ARM=y +CONFIG_AM33XX=y +CONFIG_TI_SECURE_DEVICE=y +# CONFIG_SPL_EXT_SUPPORT is not set +# CONFIG_SPL_NAND_SUPPORT is not set +CONFIG_TARGET_AM335X_EVM=y +CONFIG_ISW_ENTRY_ADDR=0x40300350 +CONFIG_SPL_STACK_R_ADDR=0x82000000 +# CONFIG_SPL_YMODEM_SUPPORT is not set +CONFIG_DEFAULT_DEVICE_TREE="am335x-evm" +CONFIG_DISTRO_DEFAULTS=y +CONFIG_FIT=y +CONFIG_SYS_EXTRA_OPTIONS="NAND" +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y +CONFIG_FIT_IMAGE_POST_PROCESS=y +CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_VERSION_VARIABLE=y +CONFIG_SPL=y +CONFIG_SPL_SYS_MALLOC_SIMPLE=y +CONFIG_SPL_STACK_R=y +CONFIG_SPL_MTD_SUPPORT=y +# CONFIG_CMD_IMLS is not set +CONFIG_CMD_ASKENV=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y +CONFIG_CMD_DFU=y +CONFIG_CMD_GPIO=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_EXT4_WRITE=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"
Just wondering, do we have HS variants of all these boards? If not we can just keep am335x-evm.
Thanks and regards, Lokesh
On 01/16/2017 09:17 PM, Lokesh Vutla wrote:
On Monday 16 January 2017 10:14 PM, Andrew F. Davis wrote:
Add a new defconfig file for the AM335x High Security EVM. This config is specific for the case of memory device booting. Memory device booting is handled separatly from peripheral booting on HS devices as the load address changes.
This defconfig is the same as for the non-secure part, except for: CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_ISW_ENTRY_ADDR updated for secure images. CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_USE_TINY_PRINTF option set to 'y' to reduce SPL size CONFIG_SPL_SYS_MALLOC_SIMPLE set to 'y' to reduce SPL size
Signed-off-by: Andrew F. Davis afd@ti.com
Changes from v1:
- Add to MAINTAINERS file
MAINTAINERS | 1 + configs/am335x_hs_evm_defconfig | 62 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+) create mode 100644 configs/am335x_hs_evm_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS index 1ea7ae013a..788e16a391 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -441,6 +441,7 @@ F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S F: arch/arm/mach-omap2/omap5/sec-fxns.c F: arch/arm/mach-omap2/sec-common.c F: arch/arm/mach-omap2/config_secure.mk +F: configs/am335x_hs_evm_defconfig F: configs/am43xx_hs_evm_defconfig F: configs/am57xx_hs_evm_defconfig F: configs/dra7xx_hs_evm_defconfig diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig new file mode 100644 index 0000000000..f8445c3249 --- /dev/null +++ b/configs/am335x_hs_evm_defconfig @@ -0,0 +1,62 @@ +CONFIG_ARM=y +CONFIG_AM33XX=y +CONFIG_TI_SECURE_DEVICE=y +# CONFIG_SPL_EXT_SUPPORT is not set +# CONFIG_SPL_NAND_SUPPORT is not set +CONFIG_TARGET_AM335X_EVM=y +CONFIG_ISW_ENTRY_ADDR=0x40300350 +CONFIG_SPL_STACK_R_ADDR=0x82000000 +# CONFIG_SPL_YMODEM_SUPPORT is not set +CONFIG_DEFAULT_DEVICE_TREE="am335x-evm" +CONFIG_DISTRO_DEFAULTS=y +CONFIG_FIT=y +CONFIG_SYS_EXTRA_OPTIONS="NAND" +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y +CONFIG_FIT_IMAGE_POST_PROCESS=y +CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_VERSION_VARIABLE=y +CONFIG_SPL=y +CONFIG_SPL_SYS_MALLOC_SIMPLE=y +CONFIG_SPL_STACK_R=y +CONFIG_SPL_MTD_SUPPORT=y +# CONFIG_CMD_IMLS is not set +CONFIG_CMD_ASKENV=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y +CONFIG_CMD_DFU=y +CONFIG_CMD_GPIO=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_EXT4_WRITE=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"
Just wondering, do we have HS variants of all these boards? If not we can just keep am335x-evm.
We don't "technically" have HS vs non-HS versions of any board, the boards are the same, the non-HS ones simply have the security features locked out. If the silicon they put on any of these boards is not locked out then it becomes an HS board.
But, yes, I only know of unlocked AM335x's currently being placed on the standard EVMs for now.
Andrew
On Tuesday 17 January 2017 08:57 PM, Andrew F. Davis wrote:
On 01/16/2017 09:17 PM, Lokesh Vutla wrote:
On Monday 16 January 2017 10:14 PM, Andrew F. Davis wrote:
Add a new defconfig file for the AM335x High Security EVM. This config is specific for the case of memory device booting. Memory device booting is handled separatly from peripheral booting on HS devices as the load address changes.
This defconfig is the same as for the non-secure part, except for: CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_ISW_ENTRY_ADDR updated for secure images. CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_USE_TINY_PRINTF option set to 'y' to reduce SPL size CONFIG_SPL_SYS_MALLOC_SIMPLE set to 'y' to reduce SPL size
Signed-off-by: Andrew F. Davis afd@ti.com
Changes from v1:
- Add to MAINTAINERS file
MAINTAINERS | 1 + configs/am335x_hs_evm_defconfig | 62 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+) create mode 100644 configs/am335x_hs_evm_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS index 1ea7ae013a..788e16a391 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -441,6 +441,7 @@ F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S F: arch/arm/mach-omap2/omap5/sec-fxns.c F: arch/arm/mach-omap2/sec-common.c F: arch/arm/mach-omap2/config_secure.mk +F: configs/am335x_hs_evm_defconfig F: configs/am43xx_hs_evm_defconfig F: configs/am57xx_hs_evm_defconfig F: configs/dra7xx_hs_evm_defconfig diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig new file mode 100644 index 0000000000..f8445c3249 --- /dev/null +++ b/configs/am335x_hs_evm_defconfig @@ -0,0 +1,62 @@ +CONFIG_ARM=y +CONFIG_AM33XX=y +CONFIG_TI_SECURE_DEVICE=y +# CONFIG_SPL_EXT_SUPPORT is not set +# CONFIG_SPL_NAND_SUPPORT is not set +CONFIG_TARGET_AM335X_EVM=y +CONFIG_ISW_ENTRY_ADDR=0x40300350 +CONFIG_SPL_STACK_R_ADDR=0x82000000 +# CONFIG_SPL_YMODEM_SUPPORT is not set +CONFIG_DEFAULT_DEVICE_TREE="am335x-evm" +CONFIG_DISTRO_DEFAULTS=y +CONFIG_FIT=y +CONFIG_SYS_EXTRA_OPTIONS="NAND" +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y +CONFIG_FIT_IMAGE_POST_PROCESS=y +CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_VERSION_VARIABLE=y +CONFIG_SPL=y +CONFIG_SPL_SYS_MALLOC_SIMPLE=y +CONFIG_SPL_STACK_R=y +CONFIG_SPL_MTD_SUPPORT=y +# CONFIG_CMD_IMLS is not set +CONFIG_CMD_ASKENV=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y +CONFIG_CMD_DFU=y +CONFIG_CMD_GPIO=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_EXT4_WRITE=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"
Just wondering, do we have HS variants of all these boards? If not we can just keep am335x-evm.
We don't "technically" have HS vs non-HS versions of any board, the boards are the same, the non-HS ones simply have the security features locked out. If the silicon they put on any of these boards is not locked out then it becomes an HS board.
Thanks.
But, yes, I only know of unlocked AM335x's currently being placed on the standard EVMs for now.
okay. Then drop all the other dtbs from the list.
Thanks and regards, Lokesh
Andrew
On 01/17/2017 11:31 AM, Lokesh Vutla wrote:
On Tuesday 17 January 2017 08:57 PM, Andrew F. Davis wrote:
On 01/16/2017 09:17 PM, Lokesh Vutla wrote:
On Monday 16 January 2017 10:14 PM, Andrew F. Davis wrote:
Add a new defconfig file for the AM335x High Security EVM. This config is specific for the case of memory device booting. Memory device booting is handled separatly from peripheral booting on HS devices as the load address changes.
This defconfig is the same as for the non-secure part, except for: CONFIG_TI_SECURE_DEVICE option set to 'y' CONFIG_ISW_ENTRY_ADDR updated for secure images. CONFIG_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_SPL_FIT_IMAGE_POST_PROCESS option set to 'y' CONFIG_USE_TINY_PRINTF option set to 'y' to reduce SPL size CONFIG_SPL_SYS_MALLOC_SIMPLE set to 'y' to reduce SPL size
Signed-off-by: Andrew F. Davis afd@ti.com
Changes from v1:
- Add to MAINTAINERS file
MAINTAINERS | 1 + configs/am335x_hs_evm_defconfig | 62 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+) create mode 100644 configs/am335x_hs_evm_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS index 1ea7ae013a..788e16a391 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -441,6 +441,7 @@ F: arch/arm/mach-omap2/omap5/sec_entry_cpu1.S F: arch/arm/mach-omap2/omap5/sec-fxns.c F: arch/arm/mach-omap2/sec-common.c F: arch/arm/mach-omap2/config_secure.mk +F: configs/am335x_hs_evm_defconfig F: configs/am43xx_hs_evm_defconfig F: configs/am57xx_hs_evm_defconfig F: configs/dra7xx_hs_evm_defconfig diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig new file mode 100644 index 0000000000..f8445c3249 --- /dev/null +++ b/configs/am335x_hs_evm_defconfig @@ -0,0 +1,62 @@ +CONFIG_ARM=y +CONFIG_AM33XX=y +CONFIG_TI_SECURE_DEVICE=y +# CONFIG_SPL_EXT_SUPPORT is not set +# CONFIG_SPL_NAND_SUPPORT is not set +CONFIG_TARGET_AM335X_EVM=y +CONFIG_ISW_ENTRY_ADDR=0x40300350 +CONFIG_SPL_STACK_R_ADDR=0x82000000 +# CONFIG_SPL_YMODEM_SUPPORT is not set +CONFIG_DEFAULT_DEVICE_TREE="am335x-evm" +CONFIG_DISTRO_DEFAULTS=y +CONFIG_FIT=y +CONFIG_SYS_EXTRA_OPTIONS="NAND" +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y +CONFIG_FIT_IMAGE_POST_PROCESS=y +CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_VERSION_VARIABLE=y +CONFIG_SPL=y +CONFIG_SPL_SYS_MALLOC_SIMPLE=y +CONFIG_SPL_STACK_R=y +CONFIG_SPL_MTD_SUPPORT=y +# CONFIG_CMD_IMLS is not set +CONFIG_CMD_ASKENV=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_I2C=y +CONFIG_CMD_USB=y +CONFIG_CMD_DFU=y +CONFIG_CMD_GPIO=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_EXT4_WRITE=y +CONFIG_OF_CONTROL=y +CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"
Just wondering, do we have HS variants of all these boards? If not we can just keep am335x-evm.
We don't "technically" have HS vs non-HS versions of any board, the boards are the same, the non-HS ones simply have the security features locked out. If the silicon they put on any of these boards is not locked out then it becomes an HS board.
Thanks.
But, yes, I only know of unlocked AM335x's currently being placed on the standard EVMs for now.
okay. Then drop all the other dtbs from the list.
I'm not sure what that would get us, the differences between non-HS and HS have nothing to do with the devices on the boards. This will only create a support burden if someone gets an unlocked Beaglebone for instance. Why limit the *more* feature-full chip? HS chips needs to be thought of as they are, a superset of the non-HS chips, not as a different kind of chip.
Andrew
Thanks and regards, Lokesh
Andrew
[..snip..]
+CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"
Just wondering, do we have HS variants of all these boards? If not we can just keep am335x-evm.
We don't "technically" have HS vs non-HS versions of any board, the boards are the same, the non-HS ones simply have the security features locked out. If the silicon they put on any of these boards is not locked out then it becomes an HS board.
Thanks.
But, yes, I only know of unlocked AM335x's currently being placed on the standard EVMs for now.
okay. Then drop all the other dtbs from the list.
I'm not sure what that would get us, the differences between non-HS and HS have nothing to do with the devices on the boards. This will only create a support burden if someone gets an unlocked Beaglebone for instance. Why limit the *more* feature-full chip? HS chips needs to be thought of as they are, a superset of the non-HS chips, not as a different kind of chip.
Is this officially supported? Have you tested before posting?
If no then there should not be any argument for adding this support assuming this can possibly be useful or experimental.
Thanks and regards, Lokesh
[..snip..]
+CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"
Just wondering, do we have HS variants of all these boards? If not we can just keep am335x-evm.
We don't "technically" have HS vs non-HS versions of any board, the boards are the same, the non-HS ones simply have the security features locked out. If the silicon they put on any of these boards is not locked out then it becomes an HS board.
Thanks.
But, yes, I only know of unlocked AM335x's currently being placed on the standard EVMs for now.
okay. Then drop all the other dtbs from the list.
I'm not sure what that would get us, the differences between non-HS and HS have nothing to do with the devices on the boards. This will only create a support burden if someone gets an unlocked Beaglebone for instance. Why limit the *more* feature-full chip? HS chips needs to be thought of as they are, a superset of the non-HS chips, not as a different kind of chip.
Is this officially supported? Have you tested before posting? If no then there should not be any argument for adding this support assuming this can possibly be useful or experimental.
Thanks and regards, Lokesh
On 01/17/2017 10:14 PM, Lokesh Vutla wrote:
[..snip..]
+CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"
Just wondering, do we have HS variants of all these boards? If not we can just keep am335x-evm.
We don't "technically" have HS vs non-HS versions of any board, the boards are the same, the non-HS ones simply have the security features locked out. If the silicon they put on any of these boards is not locked out then it becomes an HS board.
Thanks.
But, yes, I only know of unlocked AM335x's currently being placed on the standard EVMs for now.
okay. Then drop all the other dtbs from the list.
I'm not sure what that would get us, the differences between non-HS and HS have nothing to do with the devices on the boards. This will only create a support burden if someone gets an unlocked Beaglebone for instance. Why limit the *more* feature-full chip? HS chips needs to be thought of as they are, a superset of the non-HS chips, not as a different kind of chip.
Is this officially supported? Have you tested before posting? If no then there should not be any argument for adding this support assuming this can possibly be useful or experimental.
I have tested this on the -EVM and will not test this on other boards. The type of board used is unrelated to adding boot authentication. This is not a new chip or board, it is a configuration change defconfig only. (If we could include other defconfigs like we can DTB files then this defconfig would include the regular defconfig and add a few lines. This would be useful for merging all the am335x/am43xx defconfig variations that have started to get rather out of sync with each other).
Think if I added an I2C driver, there would be no need to test it on every board U-Boot supports, just one, and if it didn't work on some board that would be a bug against the board, not against the driver.
I hope to at some point merge the HS and non-HS defconfigs, adding any delta between the two, without a specific reason, only delays this and will create a future support burden.
Andrew
Thanks and regards, Lokesh
On Thursday 19 January 2017 09:29 PM, Andrew F. Davis wrote:
On 01/17/2017 10:14 PM, Lokesh Vutla wrote:
[..snip..]
> +CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2"
Just wondering, do we have HS variants of all these boards? If not we can just keep am335x-evm.
We don't "technically" have HS vs non-HS versions of any board, the boards are the same, the non-HS ones simply have the security features locked out. If the silicon they put on any of these boards is not locked out then it becomes an HS board.
Thanks.
But, yes, I only know of unlocked AM335x's currently being placed on the standard EVMs for now.
okay. Then drop all the other dtbs from the list.
I'm not sure what that would get us, the differences between non-HS and HS have nothing to do with the devices on the boards. This will only create a support burden if someone gets an unlocked Beaglebone for instance. Why limit the *more* feature-full chip? HS chips needs to be thought of as they are, a superset of the non-HS chips, not as a different kind of chip.
Is this officially supported? Have you tested before posting? If no then there should not be any argument for adding this support assuming this can possibly be useful or experimental.
I have tested this on the -EVM and will not test this on other boards. The type of board used is unrelated to adding boot authentication. This is not a new chip or board, it is a configuration change defconfig only. (If we could include other defconfigs like we can DTB files then this defconfig would include the regular defconfig and add a few lines. This would be useful for merging all the am335x/am43xx defconfig variations that have started to get rather out of sync with each other).
Think if I added an I2C driver, there would be no need to test it on every board U-Boot supports, just one, and if it didn't work on some board that would be a bug against the board, not against the driver.
The point here is what is being officially supported. Even the $subject says only *AM335x High security evm* but the patch adds support for all boards with HS silicon. Also look at the size of the image that is getting bloated when you know you are using only 1 evm.
I understand that it is good to have but I am saying that it can be added easily when someone *really* needs it.
Thanks and regards, Lokesh
On 01/19/2017 11:59 AM, Lokesh Vutla wrote:
On Thursday 19 January 2017 09:29 PM, Andrew F. Davis wrote:
On 01/17/2017 10:14 PM, Lokesh Vutla wrote:
[..snip..]
>> +CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2" > > Just wondering, do we have HS variants of all these boards? If not we > can just keep am335x-evm. >
We don't "technically" have HS vs non-HS versions of any board, the boards are the same, the non-HS ones simply have the security features locked out. If the silicon they put on any of these boards is not locked out then it becomes an HS board.
Thanks.
But, yes, I only know of unlocked AM335x's currently being placed on the standard EVMs for now.
okay. Then drop all the other dtbs from the list.
I'm not sure what that would get us, the differences between non-HS and HS have nothing to do with the devices on the boards. This will only create a support burden if someone gets an unlocked Beaglebone for instance. Why limit the *more* feature-full chip? HS chips needs to be thought of as they are, a superset of the non-HS chips, not as a different kind of chip.
Is this officially supported? Have you tested before posting? If no then there should not be any argument for adding this support assuming this can possibly be useful or experimental.
I have tested this on the -EVM and will not test this on other boards. The type of board used is unrelated to adding boot authentication. This is not a new chip or board, it is a configuration change defconfig only. (If we could include other defconfigs like we can DTB files then this defconfig would include the regular defconfig and add a few lines. This would be useful for merging all the am335x/am43xx defconfig variations that have started to get rather out of sync with each other).
Think if I added an I2C driver, there would be no need to test it on every board U-Boot supports, just one, and if it didn't work on some board that would be a bug against the board, not against the driver.
The point here is what is being officially supported. Even the $subject says only *AM335x High security evm* but the patch adds support for all boards with HS silicon. Also look at the size of the image that is getting bloated when you know you are using only 1 evm.
I understand that it is good to have but I am saying that it can be added easily when someone *really* needs it.
Okay, I will deferred to your judgment on this for now, I'll remove them for v2.
Thanks, Andrew
Thanks and regards, Lokesh
participants (3)
-
Andrew F. Davis -
Lokesh Vutla -
Tom Rini