Thiemo Seufer a écrit :
On Thu, Mar 23, 2006 at 11:34:50AM +0000, Martin Michlmayr wrote:
* Aurelien Jarno <[EMAIL PROTECTED]> [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
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`- people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
