[PATCH 02/19] bootwrapper: Set -msoft-float and assembler target options.

The bootwrapper should be built with the same target options as the
kernel.  In particular, -msoft-float and the assembler target need to be
set.

Without -msoft-float, floating point code can be executed (causing
problems on chips without FP).

Without the assembler target option, the assembler will use the old
dedicated mftb/mftbu instructions, rather than mfspr.  This causes the
boot to hang on e500, which doesn't have the dedicated instructions.

Signed-off-by: Scott Wood <redacted>
---
 arch/powerpc/Makefile      |   10 +++++++---
 arch/powerpc/boot/Makefile |    6 ++++--
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index a00fe72..8e93565 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile

@@ -69,7 +69,7 @@ CFLAGS-$(CONFIG_PPC64)	:= -mminimal-toc -mtraceback=none  -mcall-aixdesc
 CFLAGS-$(CONFIG_PPC32)	:= -Iarch/$(ARCH) -ffixed-r2 -mmultiple
 CPPFLAGS	+= $(CPPFLAGS-y)
 AFLAGS		+= $(AFLAGS-y)
-CFLAGS		+= -msoft-float -pipe $(CFLAGS-y)
+CFLAGS		+= -pipe $(CFLAGS-y)
 CPP		= $(CC) -E $(CFLAGS)
 # Temporary hack until we have migrated to asm-powerpc
 LINUXINCLUDE-$(CONFIG_PPC32)	:= -Iarch/$(ARCH)/include

@@ -116,8 +116,12 @@ cpu-as-$(CONFIG_POWER4)		+= -Wa,-maltivec
 cpu-as-$(CONFIG_E500)		+= -Wa,-me500
 cpu-as-$(CONFIG_E200)		+= -Wa,-me200
 
-AFLAGS += $(cpu-as-y)
-CFLAGS += $(cpu-as-y)
+PLATFORM_AFLAGS += $(cpu-as-y)
+PLATFORM_CFLAGS += $(cpu-as-y) -msoft-float
+export PLATFORM_AFLAGS PLATFORM_CFLAGS
+
+AFLAGS += $(PLATFORM_AFLAGS)
+CFLAGS += $(PLATFORM_CFLAGS)
 
 head-y				:= arch/powerpc/kernel/head_32.o
 head-$(CONFIG_PPC64)		:= arch/powerpc/kernel/head_64.o

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index b1fc029..3c1202c 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile

@@ -24,8 +24,10 @@ all: $(obj)/zImage
 
 HOSTCC		:= gcc
 BOOTCFLAGS	:= $(HOSTCFLAGS) -fno-builtin -nostdinc -isystem \
-		   $(shell $(CROSS32CC) -print-file-name=include) -fPIC
-BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
+		   $(shell $(CROSS32CC) -print-file-name=include) -fPIC \
+		   $(PLATFORM_CFLAGS)
+BOOTAFLAGS	:= -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc \
+		   $(PLATFORM_AFLAGS)
 
 ifeq ($(call cc-option-yn, -fstack-protector),y)
 BOOTCFLAGS	+= -fno-stack-protector

-- 
1.5.0.3

Scott Wood writes:

The bootwrapper should be built with the same target options as the
kernel.  In particular, -msoft-float and the assembler target need to be
set.

I don't like this patch as it stands because I want to keep the
wrapper independent from the kernel config as far as possible.
We need to compile up the wrapper code in a manner that means that it
can run on any processor, so clearly we need -msoft-float.

Without the assembler target option, the assembler will use the old
dedicated mftb/mftbu instructions, rather than mfspr.  This causes the
boot to hang on e500, which doesn't have the dedicated instructions.

I see mftb being used for udelay in util.S, and udelay being used in
serial_edit_cmdline in serial.c.  It's somewhat bogus that we just
hard-code an assumed timebase frequency in util.S, and also bogus that
we get command line editing for serial consoles but not for OF
consoles (why should they be different?).

It looks to me like we should at least make the platform code provide
udelay (or mdelay), possibly with the aid of a helper function.  We
should also consider whether the command-line editing is generally
useful, or not, and whether the function to do it should be made more
generic.

Paul.

On Tue, Mar 13, 2007 at 01:53:09PM +1100, Paul Mackerras wrote:

Many of these are really mine to answer...

Scott Wood writes:

quoted

Without the assembler target option, the assembler will use the old
dedicated mftb/mftbu instructions, rather than mfspr.  This causes the
boot to hang on e500, which doesn't have the dedicated instructions.

I see mftb being used for udelay in util.S, and udelay being used in
serial_edit_cmdline in serial.c.  It's somewhat bogus that we just
hard-code an assumed timebase frequency in util.S, and also bogus that

The timebase stuff was a straight copy from arch/ppc/boot/common/util.S.
I agree that its a bogus and should be fixed.

we get command line editing for serial consoles but not for OF
consoles (why should they be different?).

IIRC, a few of us talked about that on IRC way back.  The consensus
was that you would just change it with OF.  I added editing for non-OF
(should really be any fw that doesn't pass in an updated dtb (i.e.,
anything but OF and the new u-boot)) because, the cmdline would be
coming from the dtb embedded in the zImage (or from builtin_cmdline).
To change it, you have to find the dts, change it, and run 'wrapper'
(or run a pgm to set builtin_cmdline).  Seems like a lot to do for
a quick, temporary cmdline edit.

Its easy enough to add for OF, if you think its worth it.  I lack the OF
knowledge to do so though.

It looks to me like we should at least make the platform code provide
udelay (or mdelay), possibly with the aid of a helper function.

Agreed.

We
should also consider whether the command-line editing is generally
useful, or not, and whether the function to do it should be made more
generic.

IMHO, it is very useful if you have fw that doesn't update the dtb for
you (i.e., OF and u-boot).  Don't know if it makes sense for OF and/or
u-boot.

Mark

On Mon, Mar 12, 2007 at 10:32:59PM -0700, Mark A. Greer wrote:

On Tue, Mar 13, 2007 at 01:53:09PM +1100, Paul Mackerras wrote:

quoted

We
should also consider whether the command-line editing is generally
useful, or not, and whether the function to do it should be made more
generic.

IMHO, it is very useful if you have fw that doesn't update the dtb for
you (i.e., OF and u-boot).  Don't know if it makes sense for OF and/or

           ^^^ add a "not"

u-boot.

On Mon, 2007-03-12 at 22:32 -0700, Mark A. Greer wrote:

On Tue, Mar 13, 2007 at 01:53:09PM +1100, Paul Mackerras wrote:

quoted

We
should also consider whether the command-line editing is generally
useful, or not, and whether the function to do it should be made more
generic.

IMHO, it is very useful if you have fw that doesn't update the dtb for
you (i.e., OF and u-boot).  Don't know if it makes sense for OF and/or
u-boot.

I've found the command-line editing very useful.  Especially during
board bringup.  I'd very much like it if this stayed.

josh

On Tue, Mar 13, 2007 at 01:53:09PM +1100, Paul Mackerras wrote:

It looks to me like we should at least make the platform code provide
udelay (or mdelay), possibly with the aid of a helper function. 

As an interim measure (and/or to make the helper function more
universally usable), what about explicitly using mfspr in util.S instead
of mftb/mftbu?  Are there any chips that this won't work on?

-Scott