Bug#358559: madwidi-source: Fails to build kernel module on mipsel

[Thiemo Seufer]

On Thu, Mar 23, 2006 at 11:34:50AM +0000, Martin Michlmayr wrote:
> * Aurelien Jarno <aurel32 at debian.org> [2006-03-23 09:05]:
> > I was unable to build the kernel module on mipsel. The problem is that
> > 1) The mipsisa32-be-elf version of hal.o is used on mipsel, which is
> >    little endian
> > 2) Depending on the CPU, the kernel could have multiple formats, MIPS-I,
> >    MIPS-II or MIPS-III.

As well as MIPS32, MIPS32R2, MIPS64 and theoretically MIPS64R2.

> > In the case of the madwifi driver, it is
> >    hardcoded to mipsisa32 aka MIPS-III.

mipsisa32 (in the convention used by gcc) is _not_ MIPS-III by default
but MIPS32 (thus the name).

> > 3) The gcc flags passed by madwifi to select the processor conflict
> >    with the kernel ones.

Generally, kernel modules for mips will only work correctly when they
were compiled with exactly the same flags as the kernel, at least as
long as they are using kernel headers.

IOW, the kernel makefile's logic has to be mimiced.

> > Please find attached a patch to fix that. It try to detect R1 or R2
> > processor, and select the hal.o file accordingly. It goes by default to
> 
> Hmm, you select the hal.o file accordingly?  Won't mips1-le-elf work
> on both R1 and R2?  Checking for R1/R2 doesn't seem ideal to me if it
> can be avoided.
>
> Thiemo, any comment?

At least for 32bit kernels this looks like a viable option, if the hal
layer is sufficiently simple (i.e. no dependency to kernel headers).

Same for 64bit kernels and MIPS-III.

> > mipsisa32-{be,le}-elf. It also removes the gcc flags passed by madwifi,
> > actually as on other platforms.
> 
> 
> > diff -u madwifi-0.svn20060207/debian/patches/00list madwifi-0.svn20060207/debian/patches/00list
> > --- madwifi-0.svn20060207/debian/patches/00list
> > +++ madwifi-0.svn20060207/debian/patches/00list
> > @@ -2,0 +3 @@
> > +03_mips.dpatch
> > diff -u madwifi-0.svn20060207/debian/rules.modules madwifi-0.svn20060207/debian/rules.modules
> > --- madwifi-0.svn20060207/debian/rules.modules
> > +++ madwifi-0.svn20060207/debian/rules.modules
> > @@ -16,10 +16,23 @@
> >  
> >  ifeq ($(DEB_HOST_ARCH),mips)
> >  	ARCH_TARGET := mipsisa32-be-elf
> > +ifneq ($(shell grep '^CONFIG_CPU_MIPS32_R1.*=.*y' $(KSRC)/.config),)
> > +	ARCH_TARGET := mips1-be-elf
> > +endif
> > +ifneq ($(shell grep '^CONFIG_CPU_MIPS32_R2.*=.*y' $(KSRC)/.config),)
> > +	ARCH_TARGET := mips-be-elf
> > +endif
> > +
> >  endif
> >  
> >  ifeq ($(DEB_HOST_ARCH),mipsel)
> > -	ARCH_TARGET := mipsisa32-be-elf
> > +	ARCH_TARGET := mipsisa32-le-elf
> > +ifneq ($(shell grep '^CONFIG_CPU_MIPS32_R1.*=.*y' $(KSRC)/.config),)
> > +	ARCH_TARGET := mips1-le-elf
> > +endif
> > +ifneq ($(shell grep '^CONFIG_CPU_MIPS32_R2.*=.*y' $(KSRC)/.config),)
> > +	ARCH_TARGET := mips-le-elf
> > +endif
> >  endif

This (that is, the original) approach looks wrong. If the naming isn't
randomly choosen, then it should be something like mips1-le-linux. An
ELF-configured compiler usually fails on kernel headers, in worst case
by silently generating broken code.

[snip]
> > +--- madwifi.orig/hal/public/mipsisa32-le-elf.inc
> > ++++ madwifi/hal/public/mipsisa32-le-elf.inc
> > +@@ -65,5 +65,5 @@
> > + 
> > + LDOPTS=	-EL
> > + COPTS+=	-DAH_BYTE_ORDER=AH_LITTLE_ENDIAN
> > +-COPTS+=	-G 0 -EL -mno-abicalls -fno-pic -march=r4600 -Wa,--trap \
> > ++COPTS+=	-G 0 -EL -mno-abicalls -fno-pic -Wa,--trap \
> > + 	-fno-strict-aliasing -fno-common -fomit-frame-pointer -mlong-calls

Creates an MIPS-III object, but uses only MIPS-II instructions for the
32bit case. MIPS32 should use -march=mips32 (or -march=mips1 for generic
code).

[snip]
> > + LDOPTS=	-EL
> > + COPTS+=	-DAH_BYTE_ORDER=AH_LITTLE_ENDIAN
> > +-COPTS+=	-G 0 -EL -mno-abicalls -fno-pic -mips1 -Wa,--trap \
> > ++COPTS+=	-G 0 -EL -mno-abicalls -fno-pic -Wa,--trap \
> > + 	-fno-strict-aliasing -fno-common -fomit-frame-pointer -mlong-calls

-Wa,--trap isn't supported for MIPS-I.


Thiemo