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 |
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>
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!
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! >
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.
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
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 --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
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(-)