Problem in compiling a kernel module

Problem in compiling a kernel module

[Matthias Fechner]

Hi,

I'm not sure if this is the right list, so please correct me.

If have written a kernel module to read a I2C chip (it's very basic
now and I try to understand some thinks first so please forgive some
stupid questions).

I copied it to drivers/i2c/chips and added it into the Makefile with
the following line:
obj-m += max6633.o

If I try now to compile to kernel I got the following error message:
WARNING: drivers/i2c/chips/max6633.o - Section mismatch: reference to
.init.data: from .text after 'cleanup_module' (at offset 0x196)
WARNING: drivers/i2c/chips/max6633.o - Section mismatch: reference to
.init.data: from .text after 'cleanup_module' (at offset 0x1a6)
WARNING: drivers/i2c/chips/max6633.o - Section mismatch: reference to
.init.data: from .text after 'cleanup_module' (at offset 0x1da)
WARNING: drivers/i2c/chips/max6633.o - Section mismatch: reference to
.init.data: from .text after 'cleanup_module' (at offset 0x1e2)

What does that mean or how can debug or solve the problem?

Best regards,
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

Re: Problem in compiling a kernel module

[Grant Likely]

On 3/12/07, Matthias Fechner <idefix@fechner.net> wrote:
> If I try now to compile to kernel I got the following error message:
> WARNING: drivers/i2c/chips/max6633.o - Section mismatch: reference to
> .init.data: from .text after 'cleanup_module' (at offset 0x196)
> WARNING: drivers/i2c/chips/max6633.o - Section mismatch: reference to
> .init.data: from .text after 'cleanup_module' (at offset 0x1a6)
> WARNING: drivers/i2c/chips/max6633.o - Section mismatch: reference to
> .init.data: from .text after 'cleanup_module' (at offset 0x1da)
> WARNING: drivers/i2c/chips/max6633.o - Section mismatch: reference to
> .init.data: from .text after 'cleanup_module' (at offset 0x1e2)
>
> What does that mean or how can debug or solve the problem?
>

Looks like you're trying to access inital data (which is freed after
module load) from regular code (which is not)

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Problem in compiling a kernel module

[Matthias Fechner]

Hello Grant,

* Grant Likely <grant.likely@secretlab.ca> [12-03-07 12:36]:
> Looks like you're trying to access inital data (which is freed after
> module load) from regular code (which is not)

is it possible to find the line of code with the address is these
warnings?

Best regards,
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

Re: Problem in compiling a kernel module

[Grant Likely]

On 3/12/07, Matthias Fechner <idefix@fechner.net> wrote:
> Hello Grant,
>
> * Grant Likely <grant.likely@secretlab.ca> [12-03-07 12:36]:
> > Looks like you're trying to access inital data (which is freed after
> > module load) from regular code (which is not)
>
> is it possible to find the line of code with the address is these
> warnings?

somewhere in the 'cleanup_module' function.  I don't know how to
resolve function+offset to line number in .o files, but it can
probably be done with readelf.

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Problem in compiling a kernel module

[Ben Warren]

Matthias,

--- Matthias Fechner <idefix@fechner.net> wrote:

> Hello Grant,
> 
> * Grant Likely <grant.likely@secretlab.ca> [12-03-07
> 12:36]:
> > Looks like you're trying to access inital data
> (which is freed after
> > module load) from regular code (which is not)
> 
> is it possible to find the line of code with the
> address is these
> warnings?

Is there any chance that you qualify private data as
__init within the driver?  Can you post the cleanup()
function and any private (static) functions that it
calls?

regards,
Ben

Re: Problem in compiling a kernel module

[Matthias Fechner]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

Hello Ben,

* Ben Warren <bwarren@qstreams.com> [13-03-07 05:55]:
> Is there any chance that you qualify private data as
> __init within the driver?  Can you post the cleanup()
> function and any private (static) functions that it
> calls?

no problem, I attached the file. It is bery basic from now and it is
not written very well, but it should have all necessary parts in it.

PS: It's not necessary to CC me I'm on the list :)

Best regards,
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

[-- Attachment #2: max6633.c --]
[-- Type: text/x-csrc, Size: 5720 bytes --]

/*
  driver to support MAX6633
*/

#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/i2c.h>
#include <linux/mutex.h>

#define MAX6633_VERSION 0.1
#define MAX6633_DATE 20070301

//#define MAX633_SYSCTL_FUNC1 0x1000
//#define MAX6633_REG_GENERIX 0x0

int max6633_attach_adapter(struct i2c_adapter *adapter);
int max6633_detach_client(struct i2c_client *client);
int max6633_detect_client(struct i2c_adapter *adapter, int address, int kind);
void max6633_cleanup(void);

static struct i2c_driver max6633_driver = {
   .driver = {
      .name = "max6633",
   },
   .attach_adapter = max6633_attach_adapter,
   .detach_client = max6633_detach_client,
//   .command = &max6633_command /* may be NULL */
};

struct max6633_data 
{
      struct i2c_client client;
      struct mutex update_lock;
      int sysctl_id; /* To keep the /proc directory entry */
      
      char valid;
      u16 temp;
      
      unsigned long last_updated;
};

/// TODO: create the function func1 or rename it here
/*
static ctl_table max6633_dir_table_template[]= {
   { MAX633_SYSCTL_FUNC1, "func1", NULL, 0, 0644, NULL, &i2c_proc_real,
     &i2c_sysctl_real, NULL, &max6633_temp },
   { 0 }
};
*/

void max6633_temp(struct i2c_client *client, int operation, int ctl_name,
		  int *nrels_mag, long *results)
{
   return;
}

int max6633_read_value(struct i2c_client *client, u8 reg)
{
   return i2c_smbus_read_word_data(client,reg);
}

int max6633_write_value(struct i2c_client *client, u8 reg, u16 value)
{
   return i2c_smbus_write_word_data(client,reg,value);
}

/// TODO: check all possible addresses
/* scan 0x40, 0x41 and 0x42 */
static unsigned short normal_i2c[] = {
   0x40, 0x41, 0x42, I2C_CLIENT_END
};

/* Magic definition of all other variables and things */
I2C_CLIENT_INSMOD;

int max6633_attach_adapter(struct i2c_adapter *adapter)
{
   return i2c_probe(adapter, &addr_data,max6633_detect_client);
}

int max6633_detect_client(struct i2c_adapter *adapter, int address, int kind)
{
   int err=0;
   //int i;
   struct i2c_client *new_client;
   struct max6633_data *data;

   /* Let's see wheter this adapter can support what we need */
   if(!i2c_check_functionality(adapter,I2C_FUNC_SMBUS_WORD_DATA |
			       I2C_FUNC_SMBUS_BYTE_DATA))
   {
      printk("max6633: Adapter doesn't support functionality.\n");
      goto ERROR0;
   }
   
//   const char *type_name="";
   
   /* OK. For now, we presume we have a valid client. We no create the
      client structure, even though we cannot fill it completely yet.
      But it allows us to access several i2c functions safely */
   if(!(data=kzalloc(sizeof(struct max6633_data), GFP_KERNEL)))
   {
      err=-ENOMEM;
      goto ERROR0;
   }
   
   new_client=&data->client;
   i2c_set_clientdata(new_client, data);
   
   new_client->addr=address;
   new_client->adapter=adapter;
   new_client->driver=&max6633_driver;
   new_client->flags=0;
   
   /* Now, we do the remaining detection. If no `force' parameter is used. */

   /* First, the generic detection (if any), that is skipped if any force
      parameter was used. */
   if(kind <0)
   {
      /* The bellow is of course bogus */
      /*
      if(max6633_read_value(new_client, MAX633_REG_GENERIC) != MAX633_GENERIC_VALUE)
	 goto ERROR1;
      */
   }
   
   /* Fill in the remaining client fields. */
   strcpy(new_client->name,"max6633");
   data->valid=0;
   //init_MUTEX(&data->update_lock); /* only if you use this field */

   /* Any other initialisation in data must be done here too. */

   /* Tell the i2c layer a new client has arrived */
   if((err=i2c_attach_client(new_client)))
      goto ERROR3;
   
//   type_name="chip1"; /* for /proc entry */
   
   /* Register a new directory entry with module sensors. See above for
      the template structure. */
/*   if((i=i2c_register_entry(new_client, type_name,
			    max6633_dir_table_template, THIS_MODULE)) < 0)
   {
      err=i;
      goto ERROR4;
   }
*/
   //data->sysctl_id=i;
   
   /* This function can write default values to the client registers, if
      needed. */
   //max6633_init_client(new_client);

   printk(KERN_INFO "Found max6633 I2C temperature sensor.\n");
   return 0;
   
   /* OK, this is not exactly good programming practice, usually. But it is
      ver code-efficient in this case. */

//  ERROR4:
//   i2c_detach_client(new_client);
  ERROR3:
//  ERROR2:
//  ERROR1:
   kfree(data);
  ERROR0:
   return err;
}

int max6633_detach_client(struct i2c_client *client)
{
   int err;
   
   /* Try to detach the client from i2c space */
   if((err=i2c_detach_client(client)))
      return err;
   
   kfree(i2c_get_clientdata(client));
   return 0;
}

/* Keep track of how far we got in the initialisation process. If several
   things have to initialized and we fail halfway, only those things
   have to be cleared up! */
static int __initdata max6633_initialized = 0;

static int __init max6633_init(void)
{
   int res;
   printk("max6633 version %f (%d)\n", MAX6633_VERSION, MAX6633_DATE);
   
   if((res=i2c_add_driver(&max6633_driver)))
   {
      printk("max6633: Driver registration failed, module not inserted.\n");
      max6633_cleanup();
      return res;
   }
   max6633_initialized ++;
   return 0;
}

void max6633_cleanup(void)
{
   int res;
   if(max6633_initialized==1)
   {
      if((res=i2c_del_driver(&max6633_driver)))
      {
	 printk("max6633: Driver registration failed, module not removed.\n");
	 return;
      }
      max6633_initialized --;
   }
}

MODULE_AUTHOR("Matthias Fechner <idefix@fechner.net>");
MODULE_DESCRIPTION("Driver for MAX6633 temperature I2C device.");

module_init(max6633_init);
module_exit(max6633_cleanup);


   

Re: Problem in compiling a kernel module

[Domen Puncer]

On 14/03/07 05:33 +0100, Matthias Fechner wrote:
> Hello Ben,
> 
> * Ben Warren <bwarren@qstreams.com> [13-03-07 05:55]:
> > Is there any chance that you qualify private data as
> > __init within the driver?  Can you post the cleanup()
> > function and any private (static) functions that it
> > calls?
> 
> no problem, I attached the file. It is bery basic from now and it is
> not written very well, but it should have all necessary parts in it.
> 
> PS: It's not necessary to CC me I'm on the list :)
> 

...
> static int __initdata max6633_initialized = 0;

__initdata

> 
> void max6633_cleanup(void)
> {
>    int res;
>    if(max6633_initialized==1)

But you access it from non-init code.


	Domen

Re: Problem in compiling a kernel module

[Matthias Fechner]

Hello Domen,

* Domen Puncer <domen.puncer@telargo.com> [14-03-07 07:54]:
> __initdata
> 
> > 
> > void max6633_cleanup(void)
> > {
> >    int res;
> >    if(max6633_initialized==1)
> 
> But you access it from non-init code.

ah ok, I rechecked the docu in the kernel now again and found a small
line that mentioned that. I have easily written the code from the docu.
But now it will be linked fine.

Thx a lot, now a lot of thinks got clearer and I understood some steps.

Best regards,
Matthias

-- 

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning." --
Rich Cook

Fedora 7 on a non FPU system

[Michael Brian Willis]

Hello, 

I'm trying to install a Fedora 7 Root File System on an MPC8540 based
embedded system with a Denx 2.6.21 kernel. I have read the Denx
Application note located at: 
http://www.denx.de/wiki/DULG/AN2007_03_InstallFC7OnSequoia. 

However this App. Note says that the instructions apply only to
processors that have a full Floating Point Unit (FPU). My processor does
not have an FPU and I believe that this is causing some system hangs. 

Has anybody every successfully installed Fedora(or another major distro)
on a non-FPU system? Or, does anybody know what is needed to get it
working properly on a non FPU system? 

Any help is greatly appreciated. 

Regards,

Michael Willis
Applied Research Labs-University of Texas
willis@arlut.utexas.edu

Re: Fedora 7 on a non FPU system

[Roland Dreier]

 > Has anybody every successfully installed Fedora(or another major distro)
 > on a non-FPU system? Or, does anybody know what is needed to get it
 > working properly on a non FPU system? 

The simplest thing to do is to use a kernel that has FPU emulation
enabled.  Pretty much every ppc binary will use the FPU for spare
registers if nothing else, so your only other alternative would be to
rebuild the whole distribution.

 - R.

Re: Fedora 7 on a non FPU system

[Josh Boyer]

On Tue, 07 Aug 2007 12:42:41 -0500
Michael Brian Willis <willis@arlut.utexas.edu> wrote:

> Hello, 
> 
> I'm trying to install a Fedora 7 Root File System on an MPC8540 based
> embedded system with a Denx 2.6.21 kernel. I have read the Denx
> Application note located at: 
> http://www.denx.de/wiki/DULG/AN2007_03_InstallFC7OnSequoia. 
> 
> However this App. Note says that the instructions apply only to
> processors that have a full Floating Point Unit (FPU). My processor does
> not have an FPU and I believe that this is causing some system hangs. 
> 
> Has anybody every successfully installed Fedora(or another major distro)
> on a non-FPU system? Or, does anybody know what is needed to get it
> working properly on a non FPU system? 

CONFIG_MATH_EMULATION in the kernel will emulate floating point
instructions. Try that.

josh

Re: Fedora 7 on a non FPU system

[Clemens Koller]

Hi, Michael!

Michael Brian Willis schrieb:
> I'm trying to install a Fedora 7 Root File System on an MPC8540 based
> embedded system with a Denx 2.6.21 kernel. I have read the Denx
> Application note located at: 
> http://www.denx.de/wiki/DULG/AN2007_03_InstallFC7OnSequoia. 
> 
> However this App. Note says that the instructions apply only to
> processors that have a full Floating Point Unit (FPU). My processor does
> not have an FPU and I believe that this is causing some system hangs. 

Yes, that won't work.
You can either use FPU emulation or do the floating point stuff on the e500
core's SPE (Signal Processing Engine) which is AFAIK not supported by any
major distribution.

> Has anybody every successfully installed Fedora(or another major distro)
> on a non-FPU system?

CRUX - not a "major distro", because it's targeted at "experienced Linux users".
I am running my selfmade version of "embedded CRUX" on my MPC8540 Boards
based on http://cruxppc.sunsite.dk/wp/index.php which now fully supports
the e500 core features.

> Or, does anybody know what is needed to get it
> working properly on a non FPU system?

... mentioned above.
I bootstrapped the toolchain (binutils, (e)glibc, gcc and friends)
from scratch. See:
http://www.anagramm-technology.com/05_Services/FoxFactSheet.pdf
Current versions: kernel 2.6.23-rc2, gcc-4.2.1, (e)glibc 2.5.1/2.6.1.

Regards,
-- 
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm-technology.com
Phone: +49-89-741518-50
Fax: +49-89-741518-19

Re: Fedora 7 on a non FPU system

[Michael Brian Willis]

On Tue, 2007-08-07 at 23:43 +0200, Clemens Koller wrote:

> You can either use FPU emulation or do the floating point stuff on the e500
> core's SPE (Signal Processing Engine) which is AFAIK not supported by any
> major distribution.

I do have FPU emulation enabled in the kernel. I was able to get a
Yellow Dog 4.1 root filesystem to work. However when I move up to
YellowDog 5.0 or to Fedora 7, I have system lags. (For example, shortly
after boot-up, date and top do not behave properly. For example top
displays "nan" values. However a few minutes after boot up everything
seems fine.)

I suspect that the newest distribution versions rely more heavily on
full FPU functionality while the older distributions don't. Which might
be why older distributions seem to work a little better. 



> CRUX - not a "major distro", because it's targeted at "experienced Linux users".
> I am running my selfmade version of "embedded CRUX" on my MPC8540 Boards
> based on http://cruxppc.sunsite.dk/wp/index.php which now fully supports
> the e500 core features.

Thanks, I will start looking into using CRUX. 



> I bootstrapped the toolchain (binutils, (e)glibc, gcc and friends) from scratch

Did you find any documentation that was helpful when you did this? 
I'm not really sure how to start this process. Do you basically just
download binutils, glibc etc... and compile them using the gcc that
comes with CRUX? 



Thanks again for all your help!

Regards, 

Michael Willis
Applied Research Labs-University of Texas
willis@arlut.utexas.edu