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

[Aurelien Jarno]

Thiemo Seufer a écrit :
> 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.

Well there is no hal.o for MIPS64 :( Ah closed source software...

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

Ok, didn't know that. I just assumed that looking at the output of 'file 
hal.o'.

>>>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.

Well actually madwifi uses the kernel scripts to build the modules, so 
the flags that are passed are the right ones. It's just that it *adds* 
some new flags, that sometimes conflicts with the kernel one.

>>>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.

So in short we could use mipsisa32-{be,le}-elf on all machines but the 
one that have CONFIG_CPU_MIPS32_R1 or CONFIG_CPU_MIPS32_R2 set to one. 
Am I right?

[snip]


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

Well -march=mips32 is already passed by the kernel scripts.

> [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.

Ok, so I will remove it.

Thanks for your help.
Aurelien

-- 
   .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
  : :' :  Debian developer           | Electrical Engineer
  `. `'   aurel32 at debian.org         | aurelien at aurel32.net
    `-    people.debian.org/~aurel32 | www.aurel32.net