[U-Boot] [PATCH v2] defconfig: Add a config for AM335x High Security EVM

[Andrew F. Davis]

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 at 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
>>