[U-Boot] [PATCH V4 05/11] ARM: OMAP: Change set_pl310_ctrl_reg to be generic

[Matt Porter <mporter@konsulko.com>]

On Thu, Mar 05, 2015 at 11:49:05AM -0600, Nishanth Menon wrote:
> On 03/05/2015 08:00 AM, Matt Porter wrote:
> > On Tue, Mar 03, 2015 at 04:26:22PM -0600, Nishanth Menon wrote:
> >> set_pl310_ctrl_reg does use the Secure Monitor Call (SMC) to setup
> >> PL310 control register, however, that is something that is generic
> >> enough to be used for OMAP5 generation of processors as well. The only
> >> difference being the service being invoked for the function.
> >>
> >> So, convert the service to a macro and use a generic name (same as
> >> that used in Linux for some consistency). While at that, also add a
> >> data barrier which is necessary as per recommendation.
> >>
> >> While at this, switch over to smc #0 instead of handcoded assembly.
> >> To ensure gcc compatibility, steal the strategy used by Linux kernel
> >> for sec extension builds (NOTE: we no longer use '-march=armv5' as the
> >> legacy comment claims).
> > 
> > Hi Nishanth,
> > 
> > I applied this series with fuzz and fixed a minor conflict on master. I
> > ran into a build issue for omap3 beagle with the sec extension scheme on
> > the gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-2ubuntu1) toolchain:
> > 
> >  arm-linux-gnueabi-gcc
> > -Wp,-MD,arch/arm/cpu/armv7/omap3/.lowlevel_init.o.d  -nostdinc -isystem
> > /usr/lib/gcc-cross/arm-linux-gnueabi/4.7/include -Iinclude  -I../include
> > -I../arch/arm/include -include ../include/linux/kconfig.h -D__KERNEL__
> > -D__UBOOT__ -DCONFIG_SYS_TEXT_BASE=0x80100000 -D__ASSEMBLY__ -g
> > -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux
> > -mword-relocations -march=armv7-a -mno-unaligned-access
> > -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float
> > -pipe   -c -o arch/arm/cpu/armv7/omap3/lowlevel_init.o
> > ../arch/arm/cpu/armv7/omap3/lowlevel_init.S
> > 
> > ../arch/arm/cpu/armv7/omap-common/lowlevel_init.S: Assembler messages:
> > ../arch/arm/cpu/armv7/omap-common/lowlevel_init.S:34: Error: selected
> > processor does not support ARM mode `smc #0'
> > 
> > I've worked around this for the moment by placing an explicit
> > .arch_extension sec in lowlevel_init.S but hopefully you have some
> > thoughts on why those flags don't seem to be picked up. I'll continue
> > to take a look at it in the meantime.
> > 
> 
> 
> Uggh.. this is weird. I had considered ".arch_extension sec in
> lowlevel_init.S"

Yeah, no worries, I'm not suggesting that. Just a temporary workaround.

> > +plus_sec := $(call as-instr,.arch_extension sec,+sec)
> > +AFLAGS_lowlevel_init.o       :=-Wa,-march=armv7-a$(plus_sec)
> 
> seems to be what we have in kernel and seems to do the job for me on

right

> $ arm-linux-gnueabi-gcc --version
> arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
> 
> $ git clean -fdx; make omap3_beagle_defconfig;
> make V=1 arch/arm/cpu/armv7/omap-common/lowlevel_init.o
> 
> with gcc 4.6:
> arm-linux-gnueabi-gcc
> -Wp,-MD,arch/arm/cpu/armv7/omap-common/.lowlevel_init.o.d  -nostdinc
> -isystem /usr/lib/gcc/arm-linux-gnueabi/4.6/include -Iinclude
> -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__
> -D__UBOOT__ -DCONFIG_SYS_TEXT_BASE=0x80100000  -D__ASSEMBLY__ -g
> -D__ARM__ -marm -mno-thumb-interwork  -mabi=aapcs-linux
> -mword-relocations  -march=armv7-a  -mno-unaligned-access
> -ffunction-sections -fdata-sections -fno-common -ffixed-r9
> -msoft-float  -pipe   -Wa,-march=armv7-a+sec   -c -o
> arch/arm/cpu/armv7/omap-common/lowlevel_init.o
> arch/arm/cpu/armv7/omap-common/lowlevel_init.S

I also succeed here..and on a gcc 4.8.2 toolchain
> 
> with gcc 4.7:
> arm-linux-gnueabi-gcc
> -Wp,-MD,arch/arm/cpu/armv7/omap-common/.lowlevel_init.o.d  -nostdinc
> -isystem /usr/lib/gcc-cross/arm-linux-gnueabi/4.7/include -Iinclude
> -I./arch/arm/include -include ./include/linux/kconfig.h -D__KERNEL__
> -D__UBOOT__ -DCONFIG_SYS_TEXT_BASE=0x80100000  -D__ASSEMBLY__ -g
> -D__ARM__ -marm -mno-thumb-interwork  -mabi=aapcs-linux
> -mword-relocations  -march=armv7-a  -mno-unaligned-access
> -ffunction-sections -fdata-sections -fno-common -ffixed-r9
> -msoft-float  -pipe  -Wa,-march=armv7-a   -c -o
> arch/arm/cpu/armv7/omap-common/lowlevel_init.o
> arch/arm/cpu/armv7/omap-common/lowlevel_init.S
> arch/arm/cpu/armv7/omap-common/lowlevel_init.S: Assembler messages:
> arch/arm/cpu/armv7/omap-common/lowlevel_init.S:34: Error: selected
> processor does not support ARM mode `smc #0'
> make[1]: *** [arch/arm/cpu/armv7/omap-common/lowlevel_init.o] Error 1
> make: *** [arch/arm/cpu/armv7/omap-common/lowlevel_init.o] Error 2
> 
> I thought I stole the exact code from kernel, but as you can probably
> see -march=armv7-a+sec was generated for gcc 4.6 but -march=armv7-a
> without +sec for gcc 4.7!

Yeah, so I played a bit with the low-level checks and noted the
following results.

gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-2ubuntu1):

$ printf "%b\n" ".arch_extension sec" | arm-linux-gnueabi-gcc -c -x
assembler -; echo $?
{standard input}: Assembler messages:
{standard input}:1: Error: architectural extension `sec' is not allowed
for the current base architecture
1

gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4)

$ printf "%b\n" ".arch_extension sec" | arm-linux-gnueabihf-gcc -c -x
assembler -; echo $?
0

My 4.7.4 toolchain's gas does support -march=armv7-a+sec however I need to
pass that architecture in specifically to make it pass:

$ printf "%b\n" ".arch_extension sec" | arm-linux-gnueabi-gcc
-Wa,-march=armv7-a+sec -c -x assembler -; echo $?
0

> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/Makefile#n44
> 
> It will be nice to have a solution that works on gcc 4.4 and above..
> if we want to ignore gcc 4.4, then we can embed ".arch_extension sec
> in lowlevel_init.S"
> 
> https://gcc.gnu.org/ml/gcc-help/2012-07/msg00181.html
> 
> 
> any suggestions?

Not sure of the best approach here. It seems if the actual check engages
the -march option for gas (on an omap build) we should build for any of
them. That's a bit hacky though. But it's just as easy to just add the
.arch_extension sec as you suggest and we have to quit supporting gcc 4.4
in either case AFAICT.

-Matt