a problem of kernel-module version mismatch.

a problem of kernel-module version mismatch.

[Ming Liu]

Hello everyone,
Now I am trying to cross-compile the driver for a customed FIFO peripheral 
in my design. My embedded platform is Xilinx ML403 development board 
(Virtex4) and the host linux is suse 64-bit. I use the cross-compiler to 
compile the driver source files provided by Xilinx EDK. But the problem 
happens:

# insmod FIFO.o
insmod: kernel-module version mismatch
        FIFO.o was compiled for kernel version
        while this kernel is version 2.4.26

If I use "-f" option, it shows:

insmod: kernel-module version mismatch
        FIFO.o was compiled for kernel version
        while this kernel is version 2.4.26
insmod: unresolved symbol XIo_In32
insmod: unresolved symbol XIO_Out32

My embedded linux kernel version is 2.4.26. My compiler is 
"powerpc-405-linux-gnu-gcc 3.4.1". I don't know how the version mismatch 
happened. Shall I change another cross-compiler version? I will appreciate 
a lot if someone could tell me how to solve it. Thanks a lot.

Regards
Ming

_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger:  http://messenger.msn.com/cn  

Re: a problem of kernel-module version mismatch.

[Arnd Bergmann]

On Thursday 08 June 2006 15:27, Ming Liu wrote:
> My embedded linux kernel version is 2.4.26. My compiler is 
> "powerpc-405-linux-gnu-gcc 3.4.1". I don't know how the version mismatch 
> happened. Shall I change another cross-compiler version? I will appreciate 
> a lot if someone could tell me how to solve it. Thanks a lot.

The easiest way is usually to put the driver in your source tree
and compile everything together. That also makes it easier to
distribute the complete source tree to your users.

> insmod: unresolved symbol XIo_In32
> insmod: unresolved symbol XIO_Out32

that looks like part of your module is missing. Try to find where thses
functions are defined in there and why that isn't compiled.

	Arnd <><

Re: a problem of kernel-module version mismatch.

[Ming Liu]

Thanks for your telling first.

>The easiest way is usually to put the driver in your source tree
>and compile everything together. That also makes it easier to
>distribute the complete source tree to your users.

Sorry that I am a novice in Linux. I don't know how can I put the driver in 
my source tree and compile everything together. It looks like that there is 
no option in the menuconfig to choose a specially customed peripheral. So I 
think I only can include the customed peripheral as a module. Could you 
please say in a detail on how to do that? 


> > insmod: unresolved symbol XIo_In32
> > insmod: unresolved symbol XIO_Out32
>
>that looks like part of your module is missing. Try to find where thses
>functions are defined in there and why that isn't compiled.

It's very strange because I have checked the source. In the header file of 
xio.h, there are the following sentences,

/************************** Function Prototypes 
******************************/

/* The following functions allow the software to be transportable across
 * processors which may use memory mapped I/O or I/O which is mapped into a
 * seperate address space such as X86.  The functions are better suited for
 * debugging and are therefore the default implementation. Macros can 
instead
 * be used if USE_IO_MACROS is defined.
 */
#ifndef USE_IO_MACROS

/* Functions */
Xuint8 XIo_In8(XIo_Address InAddress);
Xuint16 XIo_In16(XIo_Address InAddress);
Xuint32 XIo_In32(XIo_Address InAddress);

void XIo_Out8(XIo_Address OutAddress, Xuint8 Value);
void XIo_Out16(XIo_Address OutAddress, Xuint16 Value);
void XIo_Out32(XIo_Address OutAddress, Xuint32 Value);

#else

/* The following macros allow optimized I/O operations for memory mapped 
I/O
 * Note that the SYNCHRONIZE_IO may be moved by the compiler during
 * optimization.
 */

#define XIo_In8(InputPtr)  (*(volatile Xuint8  *)(InputPtr)); 
SYNCHRONIZE_IO;
#define XIo_In16(InputPtr) (*(volatile Xuint16 *)(InputPtr)); 
SYNCHRONIZE_IO;
#define XIo_In32(InputPtr) (*(volatile Xuint32 *)(InputPtr)); 
SYNCHRONIZE_IO;

#define XIo_Out8(OutputPtr, Value)  \
    { (*(volatile Xuint8  *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
#define XIo_Out16(OutputPtr, Value) \
    { (*(volatile Xuint16 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
#define XIo_Out32(OutputPtr, Value) \
    { (*(volatile Xuint32 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }

#endif

I think these are the defination of XIo_In32 and XIo_Out32. Also, during 
the compilation, there is no error to complain that "XIo_In32 or XIo_Out32 
undeclared". 

More suggestions are appreciated. Thanks.

BR
Ming

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn/  

Re: a problem of kernel-module version mismatch.

[Arnd Bergmann]

On Thursday 08 June 2006 15:52, Ming Liu wrote:
> >The easiest way is usually to put the driver in your source tree
> >and compile everything together. That also makes it easier to
> >distribute the complete source tree to your users.
>=20
> Sorry that I am a novice in Linux. I don't know how can I put the driver =
in=20
> my source tree and compile everything together. It looks like that there =
is=20
> no option in the menuconfig to choose a specially customed peripheral. So=
 I=20
> think I only can include the customed peripheral as a module. Could you=20
> please say in a detail on how to do that?=20

The most simple way would be to put it into linux/drivers/misc and add it
to the Makefile in there.

> > > insmod: unresolved symbol XIo_In32
> > > insmod: unresolved symbol XIO_Out32
> >
> >that looks like part of your module is missing. Try to find where thses
> >functions are defined in there and why that isn't compiled.
>=20
> It's very strange because I have checked the source. In the header file o=
f=20
> xio.h, there are the following sentences,
>=20
> /************************** Function Prototypes=20
> ******************************/
>=20
> /* The following functions allow the software to be transportable across
> =A0* processors which may use memory mapped I/O or I/O which is mapped in=
to a
> =A0* seperate address space such as X86. =A0The functions are better suit=
ed for
> =A0* debugging and are therefore the default implementation. Macros can=20
> instead
> =A0* be used if USE_IO_MACROS is defined.
> =A0*/
> #ifndef USE_IO_MACROS

The comment tells you that you either need to implement these functions
youself or #define USE_IO_MACROS in the code before this.

> /* Functions */
> Xuint8 XIo_In8(XIo_Address InAddress);
> Xuint16 XIo_In16(XIo_Address InAddress);
> Xuint32 XIo_In32(XIo_Address InAddress);
>=20
> void XIo_Out8(XIo_Address OutAddress, Xuint8 Value);
> void XIo_Out16(XIo_Address OutAddress, Xuint16 Value);
> void XIo_Out32(XIo_Address OutAddress, Xuint32 Value);
>=20
> #else
>=20
> /* The following macros allow optimized I/O operations for memory mapped=
=20
> I/O
> =A0* Note that the SYNCHRONIZE_IO may be moved by the compiler during
> =A0* optimization.
> =A0*/
>=20
> #define XIo_In8(InputPtr) =A0(*(volatile Xuint8 =A0*)(InputPtr));=20
> SYNCHRONIZE_IO;
> #define XIo_In16(InputPtr) (*(volatile Xuint16 *)(InputPtr));=20
> SYNCHRONIZE_IO;
> #define XIo_In32(InputPtr) (*(volatile Xuint32 *)(InputPtr));=20
> SYNCHRONIZE_IO;
>=20
> #define XIo_Out8(OutputPtr, Value) =A0\
> =A0 =A0 { (*(volatile Xuint8 =A0*)(OutputPtr) =3D Value); SYNCHRONIZE_IO;=
 }
> #define XIo_Out16(OutputPtr, Value) \
> =A0 =A0 { (*(volatile Xuint16 *)(OutputPtr) =3D Value); SYNCHRONIZE_IO; }
> #define XIo_Out32(OutputPtr, Value) \
> =A0 =A0 { (*(volatile Xuint32 *)(OutputPtr) =3D Value); SYNCHRONIZE_IO; }
>=20
> #endif

These macros are probably broken on powerpc.

>=20
> I think these are the defination of XIo_In32 and XIo_Out32. Also, during=
=20
> the compilation, there is no error to complain that "XIo_In32 or XIo_Out3=
2=20
> undeclared".=20
>=20

I would suggest you remove that part of the header file completely, and
replace it with:

#define XIo_In32(p) in_le32(x)
#define XIO_Out32(p,v) out_le32(p, v)

	Arnd <><

Re: a problem of kernel-module version mismatch.

[Ming Liu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 4010 bytes --]

Dear Arnd,
Thanks a lot for your help. Now I have solved the problem of version 
mismatch. The reason is I haven't include the sentence of "#define MODULE". 


However the problem of unresolved symbol XIo_In32 and XIo_Out32 still 
exists. I will try to solve it following your suggestion. If any question, 
I will ask you again. Thanks a lot for your help.

Regards
Ming


>From: Arnd Bergmann <arnd.bergmann@de.ibm.com>
>To: "Ming Liu" <eemingliu@hotmail.com>
>CC: linuxppc-embedded@ozlabs.org
>Subject: Re: a problem of kernel-module version mismatch.
>Date: Thu, 8 Jun 2006 17:25:37 +0200
>
>On Thursday 08 June 2006 15:52, Ming Liu wrote:
> > >The easiest way is usually to put the driver in your source tree
> > >and compile everything together. That also makes it easier to
> > >distribute the complete source tree to your users.
> >
> > Sorry that I am a novice in Linux. I don't know how can I put the 
driver in
> > my source tree and compile everything together. It looks like that 
there is
> > no option in the menuconfig to choose a specially customed peripheral. 
So I
> > think I only can include the customed peripheral as a module. Could you
> > please say in a detail on how to do that?
>
>The most simple way would be to put it into linux/drivers/misc and add it
>to the Makefile in there.
>
> > > > insmod: unresolved symbol XIo_In32
> > > > insmod: unresolved symbol XIO_Out32
> > >
> > >that looks like part of your module is missing. Try to find where 
thses
> > >functions are defined in there and why that isn't compiled.
> >
> > It's very strange because I have checked the source. In the header file 
of
> > xio.h, there are the following sentences,
> >
> > /************************** Function Prototypes
> > ******************************/
> >
> > /* The following functions allow the software to be transportable 
across
> > ? processors which may use memory mapped I/O or I/O which is mapped 
into a
> > ? seperate address space such as X86.  The functions are better suited 
for
> > ? debugging and are therefore the default implementation. Macros can
> > instead
> > ? be used if USE_IO_MACROS is defined.
> > ?/
> > #ifndef USE_IO_MACROS
>
>The comment tells you that you either need to implement these functions
>youself or #define USE_IO_MACROS in the code before this.
>
> > /* Functions */
> > Xuint8 XIo_In8(XIo_Address InAddress);
> > Xuint16 XIo_In16(XIo_Address InAddress);
> > Xuint32 XIo_In32(XIo_Address InAddress);
> >
> > void XIo_Out8(XIo_Address OutAddress, Xuint8 Value);
> > void XIo_Out16(XIo_Address OutAddress, Xuint16 Value);
> > void XIo_Out32(XIo_Address OutAddress, Xuint32 Value);
> >
> > #else
> >
> > /* The following macros allow optimized I/O operations for memory 
mapped
> > I/O
> > ? Note that the SYNCHRONIZE_IO may be moved by the compiler during
> > ? optimization.
> > ?/
> >
> > #define XIo_In8(InputPtr) ?*(volatile Xuint8 ?)(InputPtr));
> > SYNCHRONIZE_IO;
> > #define XIo_In16(InputPtr) (*(volatile Xuint16 *)(InputPtr));
> > SYNCHRONIZE_IO;
> > #define XIo_In32(InputPtr) (*(volatile Xuint32 *)(InputPtr));
> > SYNCHRONIZE_IO;
> >
> > #define XIo_Out8(OutputPtr, Value)  \
> > ??{ (*(volatile Xuint8 ?)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> > #define XIo_Out16(OutputPtr, Value) \
> > ??{ (*(volatile Xuint16 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> > #define XIo_Out32(OutputPtr, Value) \
> > ??{ (*(volatile Xuint32 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> >
> > #endif
>
>These macros are probably broken on powerpc.
>
> >
> > I think these are the defination of XIo_In32 and XIo_Out32. Also, 
during
> > the compilation, there is no error to complain that "XIo_In32 or 
XIo_Out32
> > undeclared".
> >
>
>I would suggest you remove that part of the header file completely, and
>replace it with:
>
>#define XIo_In32(p) in_le32(x)
>#define XIO_Out32(p,v) out_le32(p, v)
>
>	Arnd <><

_________________________________________________________________
ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger:  http://messenger.msn.com/cn  

Re: a problem of kernel-module version mismatch.

[Ming Liu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 4664 bytes --]

Hello Arnd,
I found a problem on unsolved symbol XIo_In32 and XIo_Out32: in the linux 
kernel directory of <kernel>/arch/ppc/platforms/xilinx_ocp, the original 
xio.h file lying there is provided by MontaVista. But when I use xilinx EDK 
to generate the driver for my perapheral, it generates such a file which is 
provided by Xilinx. There are some differneces between these two files. One 
is in the MVista version, the XIo_In32 or XIo_Out32 are defined as 'u32' 
type while in the Xilinx version as 'xuint32'. When I compiled the driver 
module, if I refered the header file to MVista xio.h, an error will appear 
which is 'xuint32' undeclared. If I refered to the Xilinx xio.h, the 
compilation succeeded. Do you think is that the reason why these two 
symbols cannot be resolved by Linux? Shall I use the MVista version xio.h 
and define XIo_In32 and XIo_out32 as 'u32' type and then the linux could 
recognize these two symbols? Waiting for your help. Thanks a lot.

Any information about this problem is also appreciated.

Regards
Ming


>From: Arnd Bergmann <arnd.bergmann@de.ibm.com>
>To: "Ming Liu" <eemingliu@hotmail.com>
>CC: linuxppc-embedded@ozlabs.org
>Subject: Re: a problem of kernel-module version mismatch.
>Date: Thu, 8 Jun 2006 17:25:37 +0200
>
>On Thursday 08 June 2006 15:52, Ming Liu wrote:
> > >The easiest way is usually to put the driver in your source tree
> > >and compile everything together. That also makes it easier to
> > >distribute the complete source tree to your users.
> >
> > Sorry that I am a novice in Linux. I don't know how can I put the 
driver in
> > my source tree and compile everything together. It looks like that 
there is
> > no option in the menuconfig to choose a specially customed peripheral. 
So I
> > think I only can include the customed peripheral as a module. Could you
> > please say in a detail on how to do that?
>
>The most simple way would be to put it into linux/drivers/misc and add it
>to the Makefile in there.
>
> > > > insmod: unresolved symbol XIo_In32
> > > > insmod: unresolved symbol XIO_Out32
> > >
> > >that looks like part of your module is missing. Try to find where 
thses
> > >functions are defined in there and why that isn't compiled.
> >
> > It's very strange because I have checked the source. In the header file 
of
> > xio.h, there are the following sentences,
> >
> > /************************** Function Prototypes
> > ******************************/
> >
> > /* The following functions allow the software to be transportable 
across
> > ? processors which may use memory mapped I/O or I/O which is mapped 
into a
> > ? seperate address space such as X86.  The functions are better suited 
for
> > ? debugging and are therefore the default implementation. Macros can
> > instead
> > ? be used if USE_IO_MACROS is defined.
> > ?/
> > #ifndef USE_IO_MACROS
>
>The comment tells you that you either need to implement these functions
>youself or #define USE_IO_MACROS in the code before this.
>
> > /* Functions */
> > Xuint8 XIo_In8(XIo_Address InAddress);
> > Xuint16 XIo_In16(XIo_Address InAddress);
> > Xuint32 XIo_In32(XIo_Address InAddress);
> >
> > void XIo_Out8(XIo_Address OutAddress, Xuint8 Value);
> > void XIo_Out16(XIo_Address OutAddress, Xuint16 Value);
> > void XIo_Out32(XIo_Address OutAddress, Xuint32 Value);
> >
> > #else
> >
> > /* The following macros allow optimized I/O operations for memory 
mapped
> > I/O
> > ? Note that the SYNCHRONIZE_IO may be moved by the compiler during
> > ? optimization.
> > ?/
> >
> > #define XIo_In8(InputPtr) ?*(volatile Xuint8 ?)(InputPtr));
> > SYNCHRONIZE_IO;
> > #define XIo_In16(InputPtr) (*(volatile Xuint16 *)(InputPtr));
> > SYNCHRONIZE_IO;
> > #define XIo_In32(InputPtr) (*(volatile Xuint32 *)(InputPtr));
> > SYNCHRONIZE_IO;
> >
> > #define XIo_Out8(OutputPtr, Value)  \
> > ??{ (*(volatile Xuint8 ?)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> > #define XIo_Out16(OutputPtr, Value) \
> > ??{ (*(volatile Xuint16 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> > #define XIo_Out32(OutputPtr, Value) \
> > ??{ (*(volatile Xuint32 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> >
> > #endif
>
>These macros are probably broken on powerpc.
>
> >
> > I think these are the defination of XIo_In32 and XIo_Out32. Also, 
during
> > the compilation, there is no error to complain that "XIo_In32 or 
XIo_Out32
> > undeclared".
> >
>
>I would suggest you remove that part of the header file completely, and
>replace it with:
>
>#define XIo_In32(p) in_le32(x)
>#define XIO_Out32(p,v) out_le32(p, v)
>
>	Arnd <><

_________________________________________________________________
Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn/  

Re: a problem of kernel-module version mismatch.

[Ming Liu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 4006 bytes --]

Dear Arnd, 
Thanks a lot for your help. Now I have solved the problem of version 
mismatch. The reason is I haven't include the sentence of "#define MODULE". 



However the problem of unresolved symbol XIo_In32 and XIo_Out32 still 
exists. I will try to solve it following your suggestion. If any question, 
I will ask you again. Thanks a lot for your help. 

Regards 
Ming 


From: Arnd Bergmann <arnd.bergmann@de.ibm.com> 
To: "Ming Liu" <eemingliu@hotmail.com> 
CC: linuxppc-embedded@ozlabs.org 
Subject: Re: a problem of kernel-module version mismatch. 
Date: Thu, 8 Jun 2006 17:25:37 +0200 

On Thursday 08 June 2006 15:52, Ming Liu wrote: 
> >The easiest way is usually to put the driver in your source tree 
> >and compile everything together. That also makes it easier to 
> >distribute the complete source tree to your users. 
> 
> Sorry that I am a novice in Linux. I don't know how can I put the 
 
driver in 
    > my source tree and compile everything together. It looks like that 
 
there is 
    > no option in the menuconfig to choose a specially customed 
peripheral. 
 
So I 
    > think I only can include the customed peripheral as a module. Could 
you 
> please say in a detail on how to do that? 

The most simple way would be to put it into linux/drivers/misc and add it 
to the Makefile in there. 

> > > insmod: unresolved symbol XIo_In32 
> > > insmod: unresolved symbol XIO_Out32 
> > 
> >that looks like part of your module is missing. Try to find where 
 
thses 
    > >functions are defined in there and why that isn't compiled. 
> 
> It's very strange because I have checked the source. In the header file 
 
of 
    > xio.h, there are the following sentences, 
> 
> /************************** Function Prototypes 
> ******************************/ 
> 
> /* The following functions allow the software to be transportable 
 
across 
    > ? processors which may use memory mapped I/O or I/O which is mapped 
 
into a 
    > ? seperate address space such as X86.  The functions are better 
suited 
 
for 
    > ? debugging and are therefore the default implementation. Macros can 
> instead 
> ? be used if USE_IO_MACROS is defined. 
> ?/ 
> #ifndef USE_IO_MACROS 

The comment tells you that you either need to implement these functions 
youself or #define USE_IO_MACROS in the code before this. 

> /* Functions */ 
> Xuint8 XIo_In8(XIo_Address InAddress); 
> Xuint16 XIo_In16(XIo_Address InAddress); 
> Xuint32 XIo_In32(XIo_Address InAddress); 
> 
> void XIo_Out8(XIo_Address OutAddress, Xuint8 Value); 
> void XIo_Out16(XIo_Address OutAddress, Xuint16 Value); 
> void XIo_Out32(XIo_Address OutAddress, Xuint32 Value); 
> 
> #else 
> 
> /* The following macros allow optimized I/O operations for memory 
 
mapped 
    > I/O 
> ? Note that the SYNCHRONIZE_IO may be moved by the compiler during 
> ? optimization. 
> ?/ 
> 
> #define XIo_In8(InputPtr) ?*(volatile Xuint8 ?)(InputPtr)); 
> SYNCHRONIZE_IO; 
> #define XIo_In16(InputPtr) (*(volatile Xuint16 *)(InputPtr)); 
> SYNCHRONIZE_IO; 
> #define XIo_In32(InputPtr) (*(volatile Xuint32 *)(InputPtr)); 
> SYNCHRONIZE_IO; 
> 
> #define XIo_Out8(OutputPtr, Value)  \ 
> ??{ (*(volatile Xuint8 ?)(OutputPtr) = Value); SYNCHRONIZE_IO; } 
> #define XIo_Out16(OutputPtr, Value) \ 
> ??{ (*(volatile Xuint16 *)(OutputPtr) = Value); SYNCHRONIZE_IO; } 
> #define XIo_Out32(OutputPtr, Value) \ 
> ??{ (*(volatile Xuint32 *)(OutputPtr) = Value); SYNCHRONIZE_IO; } 
> 
> #endif 

These macros are probably broken on powerpc. 

> 
> I think these are the defination of XIo_In32 and XIo_Out32. Also, 
 
during 
    > the compilation, there is no error to complain that "XIo_In32 or 
 
XIo_Out32 
    > undeclared". 
> 

I would suggest you remove that part of the header file completely, and 
replace it with: 

#define XIo_In32(p) in_le32(x) 
#define XIO_Out32(p,v) out_le32(p, v) 

Arnd <><

_________________________________________________________________
ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger:  http://messenger.msn.com/cn  

Re: a problem of kernel-module version mismatch.

[Ming Liu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 4608 bytes --]

Dear Arnd,
I have tried to replace the original definations for XIn_In32 and XIn_Out32 
by what you suggested: 
           #define XIo_In32(p) in_le32(x)         (Should that be 
in_le32(p) instead of x?)
           #define XIO_Out32(p,v) out_le32(p, v)

The following warnings are generated: 
passing arg 1 of 'in_le32' (and 'out_le32') makes pointer from integer 
without a cast

Also, when I try to insmod FIFO.o, the following errors appeared:
insmod: unresolved symbol out_le32
insmod: unresolved symbol in_le32

Are in_le32 and out_le32 two functions defined by the kernel to input and 
output 32-bit data? When we define XIo_In32 and XIo_Out32 as them, which is 
we use out_le32 and in_le32 to input and output data, they are still not 
resolvable. Any other suggestions? Thanks a lot.

Regards
Ming


>From: Arnd Bergmann <arnd.bergmann@de.ibm.com>
>To: "Ming Liu" <eemingliu@hotmail.com>
>CC: linuxppc-embedded@ozlabs.org
>Subject: Re: a problem of kernel-module version mismatch.
>Date: Thu, 8 Jun 2006 17:25:37 +0200
>
>On Thursday 08 June 2006 15:52, Ming Liu wrote:
> > >The easiest way is usually to put the driver in your source tree
> > >and compile everything together. That also makes it easier to
> > >distribute the complete source tree to your users.
> >
> > Sorry that I am a novice in Linux. I don't know how can I put the 
driver in
> > my source tree and compile everything together. It looks like that 
there is
> > no option in the menuconfig to choose a specially customed peripheral. 
So I
> > think I only can include the customed peripheral as a module. Could you
> > please say in a detail on how to do that?
>
>The most simple way would be to put it into linux/drivers/misc and add it
>to the Makefile in there.
>
> > > > insmod: unresolved symbol XIo_In32
> > > > insmod: unresolved symbol XIO_Out32
> > >
> > >that looks like part of your module is missing. Try to find where 
thses
> > >functions are defined in there and why that isn't compiled.
> >
> > It's very strange because I have checked the source. In the header file 
of
> > xio.h, there are the following sentences,
> >
> > /************************** Function Prototypes
> > ******************************/
> >
> > /* The following functions allow the software to be transportable 
across
> > ? processors which may use memory mapped I/O or I/O which is mapped 
into a
> > ? seperate address space such as X86.  The functions are better suited 
for
> > ? debugging and are therefore the default implementation. Macros can
> > instead
> > ? be used if USE_IO_MACROS is defined.
> > ?/
> > #ifndef USE_IO_MACROS
>
>The comment tells you that you either need to implement these functions
>youself or #define USE_IO_MACROS in the code before this.
>
> > /* Functions */
> > Xuint8 XIo_In8(XIo_Address InAddress);
> > Xuint16 XIo_In16(XIo_Address InAddress);
> > Xuint32 XIo_In32(XIo_Address InAddress);
> >
> > void XIo_Out8(XIo_Address OutAddress, Xuint8 Value);
> > void XIo_Out16(XIo_Address OutAddress, Xuint16 Value);
> > void XIo_Out32(XIo_Address OutAddress, Xuint32 Value);
> >
> > #else
> >
> > /* The following macros allow optimized I/O operations for memory 
mapped
> > I/O
> > ? Note that the SYNCHRONIZE_IO may be moved by the compiler during
> > ? optimization.
> > ?/
> >
> > #define XIo_In8(InputPtr) ?*(volatile Xuint8 ?)(InputPtr));
> > SYNCHRONIZE_IO;
> > #define XIo_In16(InputPtr) (*(volatile Xuint16 *)(InputPtr));
> > SYNCHRONIZE_IO;
> > #define XIo_In32(InputPtr) (*(volatile Xuint32 *)(InputPtr));
> > SYNCHRONIZE_IO;
> >
> > #define XIo_Out8(OutputPtr, Value)  \
> > ??{ (*(volatile Xuint8 ?)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> > #define XIo_Out16(OutputPtr, Value) \
> > ??{ (*(volatile Xuint16 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> > #define XIo_Out32(OutputPtr, Value) \
> > ??{ (*(volatile Xuint32 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> >
> > #endif
>
>These macros are probably broken on powerpc.
>
> >
> > I think these are the defination of XIo_In32 and XIo_Out32. Also, 
during
> > the compilation, there is no error to complain that "XIo_In32 or 
XIo_Out32
> > undeclared".
> >
>
>I would suggest you remove that part of the header file completely, and
>replace it with:
>
>#define XIo_In32(p) in_le32(x)
>#define XIO_Out32(p,v) out_le32(p, v)
>
>	Arnd <><
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded

_________________________________________________________________
ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£  http://www.hotmail.com  

Re: a problem of kernel-module version mismatch.

[Arnd Bergmann]

On Friday 09 June 2006 16:07, Ming Liu wrote:
> Are in_le32 and out_le32 two functions defined by the kernel to input and 
> output 32-bit data? When we define XIo_In32 and XIo_Out32 as them, which is 
> we use out_le32 and in_le32 to input and output data, they are still not 
> resolvable. Any other suggestions? Thanks a lot.

They should be defined in include/asm-powerpc/io.h, include <asm/io.h>
to get the definition.
If your kernel is too old, they may not be there however, so you need
to use readl/writel or inl/outl, also defined in that file.

	Arnd <><