| Message ID | 1425939129-308-8-git-send-email-nm@ti.com |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
On Mon, Mar 09, 2015 at 05:12:05PM -0500, Nishanth Menon wrote: > omap_smc1 is now generic enough to remove duplicate > omap3_gp_romcode_call logic that omap3 introduced. > > As part of this change, move to using the generic lowlevel_init.S for > omap3 as well. > > Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com> But I've always wondered, does OMAP3 not actually pass in the same info in the same location / manner as OMAP4 and later?
On Wed, Mar 11, 2015 at 10:48 AM, Tom Rini <trini@konsulko.com> wrote: > On Mon, Mar 09, 2015 at 05:12:05PM -0500, Nishanth Menon wrote: > >> omap_smc1 is now generic enough to remove duplicate >> omap3_gp_romcode_call logic that omap3 introduced. >> >> As part of this change, move to using the generic lowlevel_init.S for >> omap3 as well. >> >> Signed-off-by: Nishanth Menon <nm@ti.com> > > Reviewed-by: Tom Rini <trini@konsulko.com> > > But I've always wondered, does OMAP3 not actually pass in the same info > in the same location / manner as OMAP4 and later? For smc call, the calls are similar, but the parameters change
On Wed, Mar 11, 2015 at 10:53:41AM -0500, Nishanth Menon wrote: > On Wed, Mar 11, 2015 at 10:48 AM, Tom Rini <trini@konsulko.com> wrote: > > On Mon, Mar 09, 2015 at 05:12:05PM -0500, Nishanth Menon wrote: > > > >> omap_smc1 is now generic enough to remove duplicate > >> omap3_gp_romcode_call logic that omap3 introduced. > >> > >> As part of this change, move to using the generic lowlevel_init.S for > >> omap3 as well. > >> > >> Signed-off-by: Nishanth Menon <nm@ti.com> > > > > Reviewed-by: Tom Rini <trini@konsulko.com> > > > > But I've always wondered, does OMAP3 not actually pass in the same info > > in the same location / manner as OMAP4 and later? > > For smc call, the calls are similar, but the parameters change Right, sorry but I mean for boot params as that's what's still being omap3-specific in lowlevel_init.S
On Wed, Mar 11, 2015 at 11:00 AM, Tom Rini <trini@konsulko.com> wrote: > On Wed, Mar 11, 2015 at 10:53:41AM -0500, Nishanth Menon wrote: >> On Wed, Mar 11, 2015 at 10:48 AM, Tom Rini <trini@konsulko.com> wrote: >> > On Mon, Mar 09, 2015 at 05:12:05PM -0500, Nishanth Menon wrote: >> > >> >> omap_smc1 is now generic enough to remove duplicate >> >> omap3_gp_romcode_call logic that omap3 introduced. >> >> >> >> As part of this change, move to using the generic lowlevel_init.S for >> >> omap3 as well. >> >> >> >> Signed-off-by: Nishanth Menon <nm@ti.com> >> > >> > Reviewed-by: Tom Rini <trini@konsulko.com> >> > >> > But I've always wondered, does OMAP3 not actually pass in the same info >> > in the same location / manner as OMAP4 and later? >> >> For smc call, the calls are similar, but the parameters change > > Right, sorry but I mean for boot params as that's what's still being > omap3-specific in lowlevel_init.S There seemed to be differences w.r.t bootdevice detection logic which seems to be extensive in omap3 :( had'nt dug too much there :(
Le mercredi 11 mars 2015 à 11:04 -0500, Nishanth Menon a écrit : > On Wed, Mar 11, 2015 at 11:00 AM, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Mar 11, 2015 at 10:53:41AM -0500, Nishanth Menon wrote: > >> On Wed, Mar 11, 2015 at 10:48 AM, Tom Rini <trini@konsulko.com> wrote: > >> > On Mon, Mar 09, 2015 at 05:12:05PM -0500, Nishanth Menon wrote: > >> > > >> >> omap_smc1 is now generic enough to remove duplicate > >> >> omap3_gp_romcode_call logic that omap3 introduced. > >> >> > >> >> As part of this change, move to using the generic lowlevel_init.S for > >> >> omap3 as well. > >> >> > >> >> Signed-off-by: Nishanth Menon <nm@ti.com> > >> > > >> > Reviewed-by: Tom Rini <trini@konsulko.com> > >> > > >> > But I've always wondered, does OMAP3 not actually pass in the same info > >> > in the same location / manner as OMAP4 and later? > >> > >> For smc call, the calls are similar, but the parameters change > > > > Right, sorry but I mean for boot params as that's what's still being > > omap3-specific in lowlevel_init.S > > There seemed to be differences w.r.t bootdevice detection logic which > seems to be extensive in omap3 :( > had'nt dug too much there :( As far as I can see, the main difference is that omap4/5 are using SRAM to store various bits such as the boot device (OMAP_SRAM_SCRATCH_BOOT_PARAMS). On omap3, that logic is not used and a global variable (omap3_boot_device) is there instead. We could easily make that logic fit omap3 as well and get rid of the global variable. I also see a few functions from omap-common's hwinit-common.c that could be reused on omap3. I could start looking into that, even though again, I don't have many OMAP devices to test with.
On Wed, Mar 11, 2015 at 09:26:43PM +0100, Paul Kocialkowski wrote: > Le mercredi 11 mars 2015 à 11:04 -0500, Nishanth Menon a écrit : > > On Wed, Mar 11, 2015 at 11:00 AM, Tom Rini <trini@konsulko.com> wrote: > > > On Wed, Mar 11, 2015 at 10:53:41AM -0500, Nishanth Menon wrote: > > >> On Wed, Mar 11, 2015 at 10:48 AM, Tom Rini <trini@konsulko.com> wrote: > > >> > On Mon, Mar 09, 2015 at 05:12:05PM -0500, Nishanth Menon wrote: > > >> > > > >> >> omap_smc1 is now generic enough to remove duplicate > > >> >> omap3_gp_romcode_call logic that omap3 introduced. > > >> >> > > >> >> As part of this change, move to using the generic lowlevel_init.S for > > >> >> omap3 as well. > > >> >> > > >> >> Signed-off-by: Nishanth Menon <nm@ti.com> > > >> > > > >> > Reviewed-by: Tom Rini <trini@konsulko.com> > > >> > > > >> > But I've always wondered, does OMAP3 not actually pass in the same info > > >> > in the same location / manner as OMAP4 and later? > > >> > > >> For smc call, the calls are similar, but the parameters change > > > > > > Right, sorry but I mean for boot params as that's what's still being > > > omap3-specific in lowlevel_init.S > > > > There seemed to be differences w.r.t bootdevice detection logic which > > seems to be extensive in omap3 :( > > had'nt dug too much there :( > > As far as I can see, the main difference is that omap4/5 are using SRAM > to store various bits such as the boot device > (OMAP_SRAM_SCRATCH_BOOT_PARAMS). On omap3, that logic is not used and a > global variable (omap3_boot_device) is there instead. > > We could easily make that logic fit omap3 as well and get rid of the > global variable. I also see a few functions from omap-common's > hwinit-common.c that could be reused on omap3. > > I could start looking into that, even though again, I don't have many > OMAP devices to test with. Right, but is the data format the same or did it change, in what we're reading?
Le mercredi 11 mars 2015 à 17:16 -0400, Tom Rini a écrit : > On Wed, Mar 11, 2015 at 09:26:43PM +0100, Paul Kocialkowski wrote: > > Le mercredi 11 mars 2015 à 11:04 -0500, Nishanth Menon a écrit : > > > On Wed, Mar 11, 2015 at 11:00 AM, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Mar 11, 2015 at 10:53:41AM -0500, Nishanth Menon wrote: > > > >> On Wed, Mar 11, 2015 at 10:48 AM, Tom Rini <trini@konsulko.com> wrote: > > > >> > On Mon, Mar 09, 2015 at 05:12:05PM -0500, Nishanth Menon wrote: > > > >> > > > > >> >> omap_smc1 is now generic enough to remove duplicate > > > >> >> omap3_gp_romcode_call logic that omap3 introduced. > > > >> >> > > > >> >> As part of this change, move to using the generic lowlevel_init.S for > > > >> >> omap3 as well. > > > >> >> > > > >> >> Signed-off-by: Nishanth Menon <nm@ti.com> > > > >> > > > > >> > Reviewed-by: Tom Rini <trini@konsulko.com> > > > >> > > > > >> > But I've always wondered, does OMAP3 not actually pass in the same info > > > >> > in the same location / manner as OMAP4 and later? > > > >> > > > >> For smc call, the calls are similar, but the parameters change > > > > > > > > Right, sorry but I mean for boot params as that's what's still being > > > > omap3-specific in lowlevel_init.S > > > > > > There seemed to be differences w.r.t bootdevice detection logic which > > > seems to be extensive in omap3 :( > > > had'nt dug too much there :( > > > > As far as I can see, the main difference is that omap4/5 are using SRAM > > to store various bits such as the boot device > > (OMAP_SRAM_SCRATCH_BOOT_PARAMS). On omap3, that logic is not used and a > > global variable (omap3_boot_device) is there instead. > > > > We could easily make that logic fit omap3 as well and get rid of the > > global variable. I also see a few functions from omap-common's > > hwinit-common.c that could be reused on omap3. > > > > I could start looking into that, even though again, I don't have many > > OMAP devices to test with. > > Right, but is the data format the same or did it change, in what we're > reading? The boot structure is very similar (at least between omap3 and omap4). This is chapter 27.4.8.4 Image Execution of the OMAP4430 TRM and chapter 26.4.8.4 Image Execution of the OMAP36xx TRM. There is some padding difference between omap3 and omap4, but nothing we can't deal with in omap-common.c's save_omap_boot_params: some offsets are already defined at omap_boot.h, we probably just need to adjust those for omap3.
On Mon, Mar 09, 2015 at 05:12:05PM -0500, Nishanth Menon wrote: > omap_smc1 is now generic enough to remove duplicate > omap3_gp_romcode_call logic that omap3 introduced. > > As part of this change, move to using the generic lowlevel_init.S for > omap3 as well. > > Signed-off-by: Nishanth Menon <nm@ti.com> > Reviewed-by: Tom Rini <trini@konsulko.com> Applied to u-boot/master, thanks!
diff --git a/arch/arm/cpu/armv7/omap-common/Makefile b/arch/arm/cpu/armv7/omap-common/Makefile index 7695e16d36f5..f3725b267c99 100644 --- a/arch/arm/cpu/armv7/omap-common/Makefile +++ b/arch/arm/cpu/armv7/omap-common/Makefile @@ -28,7 +28,7 @@ endif ifeq ($(CONFIG_OMAP34XX),) obj-y += boot-common.o -obj-y += lowlevel_init.o endif +obj-y += lowlevel_init.o obj-y += mem-common.o diff --git a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S index 80619b04df5d..746df922c27d 100644 --- a/arch/arm/cpu/armv7/omap-common/lowlevel_init.S +++ b/arch/arm/cpu/armv7/omap-common/lowlevel_init.S @@ -16,11 +16,13 @@ #include <asm/arch/spl.h> #include <linux/linkage.h> +#ifndef CONFIG_OMAP34XX ENTRY(save_boot_params) ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS str r0, [r1] b save_boot_params_ret ENDPROC(save_boot_params) +#endif ENTRY(omap_smc1) PUSH {r4-r12, lr} @ save registers - ROM code may pollute diff --git a/arch/arm/cpu/armv7/omap3/board.c b/arch/arm/cpu/armv7/omap3/board.c index dd53b207f850..6e6a95762b8d 100644 --- a/arch/arm/cpu/armv7/omap3/board.c +++ b/arch/arm/cpu/armv7/omap3/board.c @@ -429,8 +429,7 @@ static void omap3_update_aux_cr_secure(u32 set_bits, u32 clear_bits) acr |= set_bits; if (get_device_type() == GP_DEVICE) { - omap3_gp_romcode_call(OMAP3_GP_ROMCODE_API_WRITE_ACR, - acr); + omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_ACR, acr); } else { struct emu_hal_params emu_romcode_params; emu_romcode_params.num_params = 1; @@ -470,8 +469,7 @@ static void omap3_update_aux_cr(u32 set_bits, u32 clear_bits) static void omap3_invalidate_l2_cache_secure(void) { if (get_device_type() == GP_DEVICE) { - omap3_gp_romcode_call(OMAP3_GP_ROMCODE_API_L2_INVAL, - 0); + omap_smc1(OMAP3_GP_ROMCODE_API_L2_INVAL, 0); } else { struct emu_hal_params emu_romcode_params; emu_romcode_params.num_params = 1; diff --git a/arch/arm/cpu/armv7/omap3/lowlevel_init.S b/arch/arm/cpu/armv7/omap3/lowlevel_init.S index 80cb2639f60c..7a691519bb6b 100644 --- a/arch/arm/cpu/armv7/omap3/lowlevel_init.S +++ b/arch/arm/cpu/armv7/omap3/lowlevel_init.S @@ -27,17 +27,6 @@ ENTRY(save_boot_params) ENDPROC(save_boot_params) #endif -ENTRY(omap3_gp_romcode_call) - PUSH {r4-r12, lr} @ Save all registers from ROM code! - MOV r12, r0 @ Copy the Service ID in R12 - MOV r0, r1 @ Copy parameter to R0 - mcr p15, 0, r0, c7, c10, 4 @ DSB - mcr p15, 0, r0, c7, c10, 5 @ DMB - .word 0xe1600070 @ SMC #0 to enter monitor - hand assembled - @ because we use -march=armv5 - POP {r4-r12, pc} -ENDPROC(omap3_gp_romcode_call) - /* * Funtion for making PPA HAL API calls in secure devices * Input: diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h b/arch/arm/include/asm/arch-omap3/sys_proto.h index bcf92fbe658b..0c77a22ccfff 100644 --- a/arch/arm/include/asm/arch-omap3/sys_proto.h +++ b/arch/arm/include/asm/arch-omap3/sys_proto.h @@ -73,6 +73,5 @@ void power_init_r(void); void dieid_num_r(void); void get_dieid(u32 *id); void do_omap3_emu_romcode_call(u32 service_id, u32 parameters); -void omap3_gp_romcode_call(u32 service_id, u32 parameter); u32 warm_reset(void); #endif
omap_smc1 is now generic enough to remove duplicate omap3_gp_romcode_call logic that omap3 introduced. As part of this change, move to using the generic lowlevel_init.S for omap3 as well. Signed-off-by: Nishanth Menon <nm@ti.com> --- arch/arm/cpu/armv7/omap-common/Makefile | 2 +- arch/arm/cpu/armv7/omap-common/lowlevel_init.S | 2 ++ arch/arm/cpu/armv7/omap3/board.c | 6 ++---- arch/arm/cpu/armv7/omap3/lowlevel_init.S | 11 ----------- arch/arm/include/asm/arch-omap3/sys_proto.h | 1 - 5 files changed, 5 insertions(+), 17 deletions(-)