diff mbox series

[U-Boot,v2,4/7] ARM: mach-omap2: Kconfig: Allow OMAP5 devices to set entry point

Message ID 20181205175136.27119-5-afd@ti.com
State Superseded
Delegated to: Tom Rini
Headers show
Series Add USB boot to HS DRA7xx/AM57xx | expand

Commit Message

Andrew Davis Dec. 5, 2018, 5:51 p.m. UTC
Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to
have an non-standard boot address in memory. This may be due
to the device being a high security variant, which place the
Initial SoftWare (ISW) after certificates and secure software.

Allow these devices to set this from Kconfig.

Signed-off-by: Andrew F. Davis <afd@ti.com>
---
 arch/arm/mach-omap2/Kconfig        | 13 +++++++++++++
 arch/arm/mach-omap2/am33xx/Kconfig | 15 ---------------
 include/configs/ti_omap5_common.h  |  2 +-
 3 files changed, 14 insertions(+), 16 deletions(-)

Comments

Tom Rini Dec. 6, 2018, 9:41 p.m. UTC | #1
On Wed, Dec 05, 2018 at 11:51:33AM -0600, Andrew F. Davis wrote:

> Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to
> have an non-standard boot address in memory. This may be due
> to the device being a high security variant, which place the
> Initial SoftWare (ISW) after certificates and secure software.
> 
> Allow these devices to set this from Kconfig.
> 
> Signed-off-by: Andrew F. Davis <afd@ti.com>

Reviewed-by: Tom Rini <trini@konsulko.com>
Tom Rini Jan. 16, 2019, 9:14 p.m. UTC | #2
On Wed, Dec 05, 2018 at 11:51:33AM -0600, Andrew F. Davis wrote:

> Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to
> have an non-standard boot address in memory. This may be due
> to the device being a high security variant, which place the
> Initial SoftWare (ISW) after certificates and secure software.
> 
> Allow these devices to set this from Kconfig.
> 
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> Reviewed-by: Tom Rini <trini@konsulko.com>
> ---
>  arch/arm/mach-omap2/Kconfig        | 13 +++++++++++++
>  arch/arm/mach-omap2/am33xx/Kconfig | 15 ---------------
>  include/configs/ti_omap5_common.h  |  2 +-
>  3 files changed, 14 insertions(+), 16 deletions(-)

Turns out this breaks OMAP3 among others as the question is asked there
now and we have no default value (nor I suspect a reasonable one).
Thanks!
Andrew Davis Jan. 17, 2019, 2:13 p.m. UTC | #3
On 1/16/19 3:14 PM, Tom Rini wrote:
> On Wed, Dec 05, 2018 at 11:51:33AM -0600, Andrew F. Davis wrote:
> 
>> Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to
>> have an non-standard boot address in memory. This may be due
>> to the device being a high security variant, which place the
>> Initial SoftWare (ISW) after certificates and secure software.
>>
>> Allow these devices to set this from Kconfig.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> Reviewed-by: Tom Rini <trini@konsulko.com>
>> ---
>>  arch/arm/mach-omap2/Kconfig        | 13 +++++++++++++
>>  arch/arm/mach-omap2/am33xx/Kconfig | 15 ---------------
>>  include/configs/ti_omap5_common.h  |  2 +-
>>  3 files changed, 14 insertions(+), 16 deletions(-)
> 
> Turns out this breaks OMAP3 among others as the question is asked there
> now and we have no default value (nor I suspect a reasonable one).

The only thing changed is ti_omap5_common.h, the default provided in
that file is 0x40301350, would it be okay to just make that the default
for ISW_ENTRY_ADDR for all platforms that included that file?

Andrew

> Thanks!
>
Tom Rini Jan. 17, 2019, 2:15 p.m. UTC | #4
On Thu, Jan 17, 2019 at 08:13:21AM -0600, Andrew F. Davis wrote:
> On 1/16/19 3:14 PM, Tom Rini wrote:
> > On Wed, Dec 05, 2018 at 11:51:33AM -0600, Andrew F. Davis wrote:
> > 
> >> Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to
> >> have an non-standard boot address in memory. This may be due
> >> to the device being a high security variant, which place the
> >> Initial SoftWare (ISW) after certificates and secure software.
> >>
> >> Allow these devices to set this from Kconfig.
> >>
> >> Signed-off-by: Andrew F. Davis <afd@ti.com>
> >> Reviewed-by: Tom Rini <trini@konsulko.com>
> >> ---
> >>  arch/arm/mach-omap2/Kconfig        | 13 +++++++++++++
> >>  arch/arm/mach-omap2/am33xx/Kconfig | 15 ---------------
> >>  include/configs/ti_omap5_common.h  |  2 +-
> >>  3 files changed, 14 insertions(+), 16 deletions(-)
> > 
> > Turns out this breaks OMAP3 among others as the question is asked there
> > now and we have no default value (nor I suspect a reasonable one).
> 
> The only thing changed is ti_omap5_common.h, the default provided in
> that file is 0x40301350, would it be okay to just make that the default
> for ISW_ENTRY_ADDR for all platforms that included that file?

Well, ISW_ENTRY_ADDR doesn't make sense for OMAP3, right?  I suspect the
problem is that in moving it from mach-omap2/am33xx/Kconfig to
mach-omap2/Kconfig you need to update the depends on guards so that it
doesn't show up where it's not used.
Andrew Davis Jan. 17, 2019, 3:11 p.m. UTC | #5
On 1/17/19 8:15 AM, Tom Rini wrote:
> On Thu, Jan 17, 2019 at 08:13:21AM -0600, Andrew F. Davis wrote:
>> On 1/16/19 3:14 PM, Tom Rini wrote:
>>> On Wed, Dec 05, 2018 at 11:51:33AM -0600, Andrew F. Davis wrote:
>>>
>>>> Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to
>>>> have an non-standard boot address in memory. This may be due
>>>> to the device being a high security variant, which place the
>>>> Initial SoftWare (ISW) after certificates and secure software.
>>>>
>>>> Allow these devices to set this from Kconfig.
>>>>
>>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>>>> Reviewed-by: Tom Rini <trini@konsulko.com>
>>>> ---
>>>>  arch/arm/mach-omap2/Kconfig        | 13 +++++++++++++
>>>>  arch/arm/mach-omap2/am33xx/Kconfig | 15 ---------------
>>>>  include/configs/ti_omap5_common.h  |  2 +-
>>>>  3 files changed, 14 insertions(+), 16 deletions(-)
>>>
>>> Turns out this breaks OMAP3 among others as the question is asked there
>>> now and we have no default value (nor I suspect a reasonable one).
>>
>> The only thing changed is ti_omap5_common.h, the default provided in
>> that file is 0x40301350, would it be okay to just make that the default
>> for ISW_ENTRY_ADDR for all platforms that included that file?
> 
> Well, ISW_ENTRY_ADDR doesn't make sense for OMAP3, right?  I suspect the
> problem is that in moving it from mach-omap2/am33xx/Kconfig to
> mach-omap2/Kconfig you need to update the depends on guards so that it
> doesn't show up where it's not used.
> 

CONFIG_SPL_TEXT_BASE should be converted to Kconfig, but cannot be right
now due to some other platforms using strange methods for setting it in
header files. So we have ISW_ENTRY_ADDR in Kconfig that is used to set
CONFIG_SPL_TEXT_BASE. ISW_ENTRY_ADDR can be defined for any platform, I
just may not be used depending on what headers it includes and whether
they use it to set CONFIG_SPL_TEXT_BASE.

The change here is using it in ti_omap5_common.h, which a lot more
platforms use is seems than I noticed. So all these platforms now need
ISW_ENTRY_ADDR set to what the header to set them as (0x40301350).

Again, all this goes away when CONFIG_SPL_TEXT_BASE gets converted to
Kconfig.

Andrew
Andrew Davis Jan. 17, 2019, 7:58 p.m. UTC | #6
On 1/17/19 9:11 AM, Andrew F. Davis wrote:
> On 1/17/19 8:15 AM, Tom Rini wrote:
>> On Thu, Jan 17, 2019 at 08:13:21AM -0600, Andrew F. Davis wrote:
>>> On 1/16/19 3:14 PM, Tom Rini wrote:
>>>> On Wed, Dec 05, 2018 at 11:51:33AM -0600, Andrew F. Davis wrote:
>>>>
>>>>> Like AM33xx and AM43xx, DRA7xx and AM57xx devices may need to
>>>>> have an non-standard boot address in memory. This may be due
>>>>> to the device being a high security variant, which place the
>>>>> Initial SoftWare (ISW) after certificates and secure software.
>>>>>
>>>>> Allow these devices to set this from Kconfig.
>>>>>
>>>>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>>>>> Reviewed-by: Tom Rini <trini@konsulko.com>
>>>>> ---
>>>>>  arch/arm/mach-omap2/Kconfig        | 13 +++++++++++++
>>>>>  arch/arm/mach-omap2/am33xx/Kconfig | 15 ---------------
>>>>>  include/configs/ti_omap5_common.h  |  2 +-
>>>>>  3 files changed, 14 insertions(+), 16 deletions(-)
>>>>
>>>> Turns out this breaks OMAP3 among others as the question is asked there
>>>> now and we have no default value (nor I suspect a reasonable one).
>>>
>>> The only thing changed is ti_omap5_common.h, the default provided in
>>> that file is 0x40301350, would it be okay to just make that the default
>>> for ISW_ENTRY_ADDR for all platforms that included that file?
>>
>> Well, ISW_ENTRY_ADDR doesn't make sense for OMAP3, right?  I suspect the
>> problem is that in moving it from mach-omap2/am33xx/Kconfig to
>> mach-omap2/Kconfig you need to update the depends on guards so that it
>> doesn't show up where it's not used.
>>
> 
> CONFIG_SPL_TEXT_BASE should be converted to Kconfig, but cannot be right
> now due to some other platforms using strange methods for setting it in
> header files. So we have ISW_ENTRY_ADDR in Kconfig that is used to set
> CONFIG_SPL_TEXT_BASE. ISW_ENTRY_ADDR can be defined for any platform, I
> just may not be used depending on what headers it includes and whether
> they use it to set CONFIG_SPL_TEXT_BASE.
> 
> The change here is using it in ti_omap5_common.h, which a lot more
> platforms use is seems than I noticed. So all these platforms now need
> ISW_ENTRY_ADDR set to what the header to set them as (0x40301350).
> 
> Again, all this goes away when CONFIG_SPL_TEXT_BASE gets converted to
> Kconfig.

Scratch that, it's not SPL_TEXT_BASE converted to Kconfig (that's done
for some platforms) it looks to be us overwriting it still in many places.

Anyway posted v3 with fix for above.

Andrew

> 
> Andrew
>
diff mbox series

Patch

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 58e545a45b..ebe3c0f39a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -167,6 +167,19 @@  config TI_SECURE_EMIF_PROTECTED_REGION_SIZE
 	  using hardware memory firewalls. This value must be smaller than the
 	  TI_SECURE_EMIF_TOTAL_REGION_SIZE value.
 
+config ISW_ENTRY_ADDR
+	hex "Address in memory or XIP address of bootloader entry point"
+	default 0x402F4000 if AM43XX
+	default 0x402F0400 if AM33XX
+	default 0x40301350 if OMAP54XX
+	help
+	  After any reset, the boot ROM searches the boot media for a valid
+	  boot image. For non-XIP devices, the ROM then copies the image into
+	  internal memory. For all boot modes, after the ROM processes the
+	  boot image it eventually computes the entry point address depending
+	  on the device type (secure/non-secure), boot media (xip/non-xip) and
+	  image headers.
+
 source "arch/arm/mach-omap2/omap3/Kconfig"
 
 source "arch/arm/mach-omap2/omap4/Kconfig"
diff --git a/arch/arm/mach-omap2/am33xx/Kconfig b/arch/arm/mach-omap2/am33xx/Kconfig
index 3529607479..5f2ee83c27 100644
--- a/arch/arm/mach-omap2/am33xx/Kconfig
+++ b/arch/arm/mach-omap2/am33xx/Kconfig
@@ -274,21 +274,6 @@  config SPL_RTC_DDR_SUPPORT
 endif
 
 if AM43XX || AM33XX
-config ISW_ENTRY_ADDR
-	hex "Address in memory or XIP flash of bootloader entry point"
-	default 0x402F4000 if AM43XX
-	default 0x402F0400 if AM33XX
-	help
-	  After any reset, the boot ROM on the AM43XX SOC
-	  searches the boot media for a valid boot image.
-	  For non-XIP devices, the ROM then copies the
-	  image into internal memory.
-	  For all boot modes, after the ROM processes the
-	  boot image it eventually computes the entry
-	  point address depending on the device type
-	  (secure/non-secure), boot media (xip/non-xip) and
-	  image headers.
-
 config PUB_ROM_DATA_SIZE
 	hex "Size in bytes of the L3 SRAM reserved by ROM to store data"
 	default 0x8400
diff --git a/include/configs/ti_omap5_common.h b/include/configs/ti_omap5_common.h
index 8bf4a6b7e9..ba57c40182 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -81,7 +81,7 @@ 
  * RAM from address 0x40301350 (0x40300000+0x1000(reserved)+0x350(cert)).
  */
 #define TI_OMAP5_SECURE_BOOT_RESV_SRAM_SZ	0x1000
-#define CONFIG_SPL_TEXT_BASE	0x40301350
+#define CONFIG_SPL_TEXT_BASE	CONFIG_ISW_ENTRY_ADDR
 /* If no specific start address is specified then the secure EMIF
  * region will be placed at the end of the DDR space. In order to prevent
  * the main u-boot relocation from clobbering that memory and causing a