Simple module, but won't build

Simple module, but won't build

[Richard Danter]

Hi All,

I am trying to build a simple module which will let me write to a bank
of LED's on my board.

When I #include <asm/io.h> I get this error:

/opt/eldk3.0/ppc_82xx/usr/include/asm/io.h: In function `virt_to_bus':
/opt/eldk3.0/ppc_82xx/usr/include/asm/io.h:235: `CONFIG_KERNEL_START'
undeclared (first use in this function)

the error also occurs in several other functions. I also see errors when
I #include <asm/uaccess.h> as follows:

/opt/eldk3.0/ppc_82xx/usr/include/asm/uaccess.h: In function `verify_area':
/opt/eldk3.0/ppc_82xx/usr/include/asm/uaccess.h:37: `CONFIG_TASK_SIZE'
undeclared (first use in this function)

also in several functions.

I know I have used these with no problems with an older kernel and
compiler. Is there something I need to add to make these work??

I am using ELDK 3.0 with the 2.4.24-pre2 kernel on an 8260 target.

Many thanks,
Rich

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Simple module, but won't build

[Wolfgang Denk]

In message <4097DAEA.5@ntlworld.com> you wrote:
>
> When I #include <asm/io.h> I get this error:
>
> /opt/eldk3.0/ppc_82xx/usr/include/asm/io.h: In function `virt_to_bus':
> /opt/eldk3.0/ppc_82xx/usr/include/asm/io.h:235: `CONFIG_KERNEL_START'
> undeclared (first use in this function)
...
> /opt/eldk3.0/ppc_82xx/usr/include/asm/uaccess.h: In function `verify_area':
> /opt/eldk3.0/ppc_82xx/usr/include/asm/uaccess.h:37: `CONFIG_TASK_SIZE'
> undeclared (first use in this function)
...
> I know I have used these with no problems with an older kernel and
> compiler. Is there something I need to add to make these work??

Seems you are missing to include some necessary header  files  and/or
to provide the necessary compiler options.

It's difficult to guess what  exactly  is  missing  given  so  little
information.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"If you own a machine, you are in turn owned by it,  and  spend  your
time serving it..."    - Marion Zimmer Bradley, _The Forbidden Tower_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Simple module, but won't build

[Joshua Lamorie]

> /opt/eldk3.0/ppc_82xx/usr/include/asm/io.h:235: `CONFIG_KERNEL_START'

> /opt/eldk3.0/ppc_82xx/usr/include/asm/uaccess.h:37: `CONFIG_TASK_SIZE'

These are defined when you are building your kernel.  Before building any
modules,
you need to configure the kernel.

Assuming you use 'make menuconfig'.

    Under 'Code Maturity Level Options' select 'Prompt for advanced kernel
configuration options'.

Then, under General Setup set

    Set Custom Kernel Base Address
    Set Custom user task size

My assumption is that the defaults (0xc0000000 and 0x80000000) are just
dandy.

Joshua

p.s. This type of question is easy to answer by using lxr.linux.no and
searching for freetext or identifier.  No kernel programming should be
performed without this close at hand.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Simple module, but won't build

[Richard Danter]

Hi Wolfgang,

Wolfgang Denk wrote:
>
> Seems you are missing to include some necessary header  files  and/or
> to provide the necessary compiler options.

I am taking a driver I wrote for a 2.4.2 kernel, built with 2.95.x
compiler and trying to port it to 82xx from 8xx and use the new ELDK.

Since it is so simple, it just writes to a mem mapped I/O port to set
some LED's on/off, I assumed it would be pretty simple. But alas, that
was probably a bad assumption on my part.

The main module includes the following:

   linux/module.h
   linux/fs.h
   asm/io.h
   asm/uaccess.h

in that order.

I have grep'ed for CONFIG_KERNEL_START and CONFIG_TASK_SIZE and the only
place I can find them defined is in the kernel source .config (and
default config files for each board). Not in any of the header files.

Maybe I am sposed to #define them myself - I tried that and it worked -
but would like a more automagic solution if there is one!

Command line options are:

   -D__KERNEL__ -DMODULE -Wall -fno-builtins -O -c


>
> It's difficult to guess what  exactly  is  missing  given  so  little
> information.

Sorry, yes.

Rich


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Simple module, but won't build

[Wolfgang Denk]

In message <4097F32F.6090504@ntlworld.com> you wrote:
> Hi Wolfgang,
>
> Wolfgang Denk wrote:
> >
> > Seems you are missing to include some necessary header  files  and/or
> > to provide the necessary compiler options.
>
> I am taking a driver I wrote for a 2.4.2 kernel, built with 2.95.x
> compiler and trying to port it to 82xx from 8xx and use the new ELDK.
>
> Since it is so simple, it just writes to a mem mapped I/O port to set
> some LED's on/off, I assumed it would be pretty simple. But alas, that
> was probably a bad assumption on my part.
>
> The main module includes the following:
>
Insert:

	#include <linux/kernel.h>
	#include <linux/init.h>

>    linux/module.h
>    linux/fs.h

Probably needed:

	#include <asm/types.h>

>    asm/io.h
>    asm/uaccess.h
>
> in that order.
>
> I have grep'ed for CONFIG_KERNEL_START and CONFIG_TASK_SIZE and the only
> place I can find them defined is in the kernel source .config (and
> default config files for each board). Not in any of the header files.

Grep after configuring the kernel, and you should find them in

	include/linux/autoconf.h:#define CONFIG_KERNEL_START 0xc0000000
	include/config/kernel/start.h:#define CONFIG_KERNEL_START 0xc0000000
resp.
	include/linux/autoconf.h:#define CONFIG_TASK_SIZE 0x80000000
	include/config/task/size.h:#define CONFIG_TASK_SIZE 0x80000000

> Maybe I am sposed to #define them myself - I tried that and it worked -
> but would like a more automagic solution if there is one!

There is no magic involved ;-)

> Command line options are:
>
>    -D__KERNEL__ -DMODULE -Wall -fno-builtins -O -c

This is not good either. You may try running a "make modules" in  you
kernel  source  directory and see what CFLAGS are needed; for me this
looks for example like this:

CFLAGS="-D__KERNEL__ -I/work/TQM860L/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -I/work/TQM860L/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -DMODULE"

Some of the options (like -msoft-float) are not optional at all ;-)

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If A equals success, then the formula is A = X + Y + Z. X is work.  Y
is play. Z is keep your mouth shut.                 - Albert Einstein

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Simple module, but won't build

[Sam Ravnborg]

On Tue, May 04, 2004 at 08:46:55PM +0100, Richard Danter wrote:
>
> Command line options are:
>
>   -D__KERNEL__ -DMODULE -Wall -fno-builtins -O -c
>
>

A better approach is to create a small Makefile:
obj-m := rich.o
obj-y :=

Then use:
make -C $KERNELSRCDIR SUBDIRS=$PWD modules

This should give you the correct gcc options.

[Speaking of vanilla kernel, not knowing ELDK in this respect].

	Sam

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Simple module, but won't build

[Wolfgang Denk]

In message <20040504211508.GA2510@mars.ravnborg.org> you wrote:
>
> make -C $KERNELSRCDIR SUBDIRS=$PWD modules
>
> This should give you the correct gcc options.
>
> [Speaking of vanilla kernel, not knowing ELDK in this respect].

Same for ELDK. We use a standard Linux kernel,  too  [just  some  bug
fixes and extensions included].

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"It's when they say 2 + 2 = 5 that I begin to argue."    - Eric Pepke

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Next steps

[Brian Hawley]

We've finally gotten the 2.5 kernel to boot using u-boot [ 2.6.3 doesn't,
nor did 2.4 variants ] on a PPC440GP
on the Ebony board.

At this point, it is trying to talk to a dhcp/bootp server and get a NFS
root filesystem.

Eventually, we'll be porting this to a custom board with some other chip
set support on it.

Our application will essentially be data acquisition and
transmission.  We'll be talking to the chipset to
suck data off [ and push data ] and on the other side push/pull data from
the PCI bus.

Linux is probably overkill for this, but we wanted a development platform
we could extend in the future
more readily.

I'm curious as to the direction people think we should take at this
point.  Should we be trying to set up
a root NFS filesystem [ presumably because it is easier to change -- and
then moving it to an initrd ? ]?

What do we need on the NFS filesystem...

What resources can you point me to to help us make the transition to the
next level.

Any help is appreciated,

Thanks.

-- Brian

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Next steps

[Bob White]

> I'm curious as to the direction people think we should take at this
> point.  Should we be trying to set up
> a root NFS filesystem [ presumably because it is easier to change -- and
> then moving it to an initrd ? ]?
>
> What do we need on the NFS filesystem...
>

Are you using the ELDK?  Have you seen:

http://www.denx.de/twiki/bin/view/DULG/ELDKMountingTargetComponentsViaNF
S

Bob
--
Robert B. White        Perigee, A Division of Sensis Corp
Software Design Engr   316 Commerce Blvd.
TEL: 315.453.7842x29   Liverpool, NY  13088
FAX: 315.453.7917      www.Perigee.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Next steps

[Mark Chambers]

Bob,

I would definitely recommend NFS.  As Bob White pointed out, you can get a
directory structure all set up from eldk.  The thing about NFS is you have a
PC with visual tools and all to mess with the same files that your embedded
system is accessing.  Plus of course you have much more file space.  And if
you're new to Linux it's a whole lot easier to get up to speed on the PC.

dhcp & bootp are really different things from NFS, although I think you have
to enable them in the [embedded] kernel for nfsboot to work.  But you
probably want to set your board up with a fixed IP and compressed kernel (or
tftp it in) from u-boot, just feeding a command line to the kernel that
tells it the root is nfs something.  No sense adding more complexity than
you need!

When it comes to stand-alone booting of an embedded system you can also
consider jffs2 or cramfs instead of initrd.  (I can tell you more if you're
interested).

Mark Chambers
WV Computronics


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Next steps

[chris]

Hey gang,

I'm trying to work on issue 305, suspend/resume for cs46xx.

I'm running CentOS 5, so I'd like to work on what's current for that 
distribution first, and patch to latest if needed after that.

I think I have the correct source package, but the only mention of cs46xx 
I could find in the source is a configuration file. Running make doesn't 
make the cs46xx module, AFAICT.

Which source (package)(s) should I have?

How do I track down the source file(s) I need to examine?

Thanks,
Chris

Re: Next steps

[Takashi Iwai]

At Tue, 29 May 2007 09:55:22 -0500 (CDT),
chris@idlelion.net wrote:
> 
> Hey gang,
> 
> I'm trying to work on issue 305, suspend/resume for cs46xx.
> 
> I'm running CentOS 5, so I'd like to work on what's current for that 
> distribution first, and patch to latest if needed after that.
> 
> I think I have the correct source package, but the only mention of cs46xx 
> I could find in the source is a configuration file. Running make doesn't 
> make the cs46xx module, AFAICT.
> 
> Which source (package)(s) should I have?

The driver codes are usually included in the kernel source tree.  What
you've seen are the alsa-lib and alsa-utils packages, I guess.

Anyway, if you want to debug the driver, build the alsa driver
externally from the latest ALSA HG tree.  So, there is no
corresponding "distro packages" at all.


Takashi

Re: Next steps

[chris]

On Tue, 29 May 2007, Takashi Iwai wrote:

> At Tue, 29 May 2007 09:55:22 -0500 (CDT),
> chris@idlelion.net wrote:
>> Which source (package)(s) should I have?
>
> The driver codes are usually included in the kernel source tree.  What
> you've seen are the alsa-lib and alsa-utils packages, I guess.
>
> Anyway, if you want to debug the driver, build the alsa driver
> externally from the latest ALSA HG tree.  So, there is no
> corresponding "distro packages" at all.

> Takashi

Thanks!

As it happens, I'm going to a talk on Mercurial tonight.

There are a bunch of repositories. Would I want Driver or Kernel?

Chris

Re: Next steps

[Takashi Iwai]

At Tue, 29 May 2007 11:52:55 -0500 (CDT),
chris@idlelion.net wrote:
> 
> On Tue, 29 May 2007, Takashi Iwai wrote:
> 
> > At Tue, 29 May 2007 09:55:22 -0500 (CDT),
> > chris@idlelion.net wrote:
> >> Which source (package)(s) should I have?
> >
> > The driver codes are usually included in the kernel source tree.  What
> > you've seen are the alsa-lib and alsa-utils packages, I guess.
> >
> > Anyway, if you want to debug the driver, build the alsa driver
> > externally from the latest ALSA HG tree.  So, there is no
> > corresponding "distro packages" at all.
> 
> > Takashi
> 
> Thanks!
> 
> As it happens, I'm going to a talk on Mercurial tonight.
> 
> There are a bunch of repositories. Would I want Driver or Kernel?

Both alsa-driver and alsa-kernel are repos for ALSA drivers, so you
need both.  The latter contains the source codes to be merged to linux
kernel tree while the former contains the stuff for building the
modules.

It's not always necessary to use HG version of alsa-lib, utils and
others.  But, at least, it's safe and recommended to use the latest
version of alsa-lib and utils together with alsa-driver.


Takashi

Re: Next steps

[Chris Schumann]

Takashi Iwai wrote:
> At Tue, 29 May 2007 11:52:55 -0500 (CDT),
> chris@idlelion.net asked about alsa development
 > ...
> Both alsa-driver and alsa-kernel are repos for ALSA drivers, so you
> need both.  The latter contains the source codes to be merged to linux
> kernel tree while the former contains the stuff for building the
> modules.
> 
> It's not always necessary to use HG version of alsa-lib, utils and
> others.  But, at least, it's safe and recommended to use the latest
> version of alsa-lib and utils together with alsa-driver.
> 
> 
> Takashi

I'm running CentOS 5 and would like to keep the machine working for its 
owner while I try to fix the sound driver.

I cloned alsa-driver and alsa-kernel from the hg repository. In 
alsa-driver is a file called INSTALL.

Step 1 says I need full configured source for the kernel. "yum install 
kernel-devel" seemed to do that.

Step 2 says turn on sound support. No idea what that means.

Step 3 says run ./configure. That file doesn't exist. There is a 
configure.in that says it should be run through autoconf. If there's an 
automated script to do that, its location isn't obvious.

There are over 4000 lines in the cs46xx module, so any tips on what's 
important (other than the actual suspend and resume functions that I've 
found) and where to start a search would be helpful too.

Thanks,
Chris

Re: Next steps

[Tobin Davis]

Try running "./hgcompile".  It will rebuild the ./configure script and
build the drivers for you.

On Sat, 2007-06-02 at 22:47 -0500, Chris Schumann wrote:

> Takashi Iwai wrote:
> > At Tue, 29 May 2007 11:52:55 -0500 (CDT),
> > chris@idlelion.net asked about alsa development
>  > ...
> > Both alsa-driver and alsa-kernel are repos for ALSA drivers, so you
> > need both.  The latter contains the source codes to be merged to linux
> > kernel tree while the former contains the stuff for building the
> > modules.
> > 
> > It's not always necessary to use HG version of alsa-lib, utils and
> > others.  But, at least, it's safe and recommended to use the latest
> > version of alsa-lib and utils together with alsa-driver.
> > 
> > 
> > Takashi
> 
> I'm running CentOS 5 and would like to keep the machine working for its 
> owner while I try to fix the sound driver.
> 
> I cloned alsa-driver and alsa-kernel from the hg repository. In 
> alsa-driver is a file called INSTALL.
> 
> Step 1 says I need full configured source for the kernel. "yum install 
> kernel-devel" seemed to do that.
> 
> Step 2 says turn on sound support. No idea what that means.
> 
> Step 3 says run ./configure. That file doesn't exist. There is a 
> configure.in that says it should be run through autoconf. If there's an 
> automated script to do that, its location isn't obvious.
> 
> There are over 4000 lines in the cs46xx module, so any tips on what's 
> important (other than the actual suspend and resume functions that I've 
> found) and where to start a search would be helpful too.
> 
> Thanks,
> Chris
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-- 
Tobin Davis <tdavis@dsl-only.net>