mpc / linux kernel - user space

mpc / linux kernel - user space

[Juergen Oberhofer]

Hi,

I have a module and an application program in user space:

The Module performs the following task: at init it initializes the cpm
timer register of the mpc823,
such that an interrupt is generated every x microseconds. Thus, I
installed an interrupt handling function f that handles the timer
interrupts.

My problem is that the module / the interrupt handling function should
execute a procedure defined in the application program. How can I pass a
pointer (which points to that function) from the appl.program to the
module, such that the handler can execute this function every x
milliseconds? I thought to create a procedure in the module that accepts
a function pointer as argument. But how can I achieve, that this module
procedure is visible to the application program? Does somebody have a
suggestion or know another way to do it?

Regards,
Juergen


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

Re: mpc / linux kernel - user space

[Jaap-Jan Boor]

Hi Juergen,

That's normally not something you do and I don't know if it's possible.
Application code normally communicates with your driver code using
system
calls (read/write). So either your appl procedure must be part
of your module, or you must signal e.g. a user thread the timer
interrupt happened, so the thread can execute that code.
Hope this helps,

Jaap-Jan


On 27-nov-03, at 17:07, Juergen Oberhofer wrote:

>
> Hi,
>
> I have a module and an application program in user space:
>
> The Module performs the following task: at init it initializes the cpm
> timer register of the mpc823,
> such that an interrupt is generated every x microseconds. Thus, I
> installed an interrupt handling function f that handles the timer
> interrupts.
>
> My problem is that the module / the interrupt handling function should
> execute a procedure defined in the application program. How can I pass
> a
> pointer (which points to that function) from the appl.program to the
> module, such that the handler can execute this function every x
> milliseconds? I thought to create a procedure in the module that
> accepts
> a function pointer as argument. But how can I achieve, that this module
> procedure is visible to the application program? Does somebody have a
> suggestion or know another way to do it?
>
> Regards,
> Juergen
>
>


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

Re: mpc / linux kernel - user space

[Juergen Oberhofer]

Thank you! You mean that the application should install a signal handler
and
the module sends on every interrupt a signal to the application process.
Do you know, Which function does exist to send a signal? I guess, the
module has to know the pid of the application process? How can the module
be informed about it?
Regards,
Juergen

On Thu, 27 Nov 2003, Jaap-Jan Boor wrote:

> Hi Juergen,
>
> That's normally not something you do and I don't know if it's possible.
> Application code normally communicates with your driver code using
> system
> calls (read/write). So either your appl procedure must be part
> of your module, or you must signal e.g. a user thread the timer
> interrupt happened, so the thread can execute that code.
> Hope this helps,
>
> Jaap-Jan
>
>
> On 27-nov-03, at 17:07, Juergen Oberhofer wrote:
>
> >
> > Hi,
> >
> > I have a module and an application program in user space:
> >
> > The Module performs the following task: at init it initializes the cpm
> > timer register of the mpc823,
> > such that an interrupt is generated every x microseconds. Thus, I
> > installed an interrupt handling function f that handles the timer
> > interrupts.
> >
> > My problem is that the module / the interrupt handling function should
> > execute a procedure defined in the application program. How can I pass
> > a
> > pointer (which points to that function) from the appl.program to the
> > module, such that the handler can execute this function every x
> > milliseconds? I thought to create a procedure in the module that
> > accepts
> > a function pointer as argument. But how can I achieve, that this module
> > procedure is visible to the application program? Does somebody have a
> > suggestion or know another way to do it?
> >
> > Regards,
> > Juergen
> >
> >
>

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

Re: mpc / linux kernel - user space

[Dan Kegel]

Juergen Oberhofer wrote:
>>>My problem is that the module / the interrupt handling function should
>>>execute a procedure defined in the application program. How can I pass
>>>a pointer (which points to that function) from the appl.program to the
>>>module, such that the handler can execute this function every x
>>>milliseconds? I thought to create a procedure in the module that
>>>accepts
>>>a function pointer as argument. But how can I achieve, that this module
>>>procedure is visible to the application program?
 >>> ...
>> That's normally not something you do and I don't know if it's possible.
>> Application code normally communicates with your driver code using
>> system
>> calls (read/write). So either your appl procedure must be part
>> of your module, or you must signal e.g. a user thread the timer
>> interrupt happened, so the thread can execute that code.
>
> Thank you! You mean that the application should install a signal handler
> and the module sends on every interrupt a signal to the application process.

Although you could do it that way, it might be better to use
a unix domain or a netlink socket, and have the kernel module
send a message which the user program reads via the 'read' system call.

For what it's worth, netlink sockets turn out to be pretty
easy to use.  See http://www.cs.auc.dk/~fleury/netkeeper/
for one example.  Most of the complexity in programs that use
netlink are because they're trying to communicate routing
information.  If you just want to send your own messages,
create the netlink socket with type NETLINK_USERSOCK and
don't worry about the fancy stuff.
- Dan

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

How to change /proc to the writable directory

[John Zhou]

Hi,

I have a based mpc82xx board running embedded linux. But, I met a problem now:

when I boot kernel and mount file system( cramfs and JFFS), for default, the dir /proc is not writable that located in cramfs. Now, I want to change it to be writable. which places/functions should I modify?

In cramfs I have these dirs:
/bin
/root
/boot
/sbin
/usr
/mnt
/dev/ --> /mnt/rwfs/dev
/proc --> /mnt/rwfs/proc
/etc  --> /mnt/rwfs/etc
/tmp  --> /mnt/rwfs/tmp
/var  --> /mnt/rwfs/var
...

In R/W JFFS I have these dirs:

dev
proc
etc
tmp
var

Thanks in advance!
John

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

Re: How to change /proc to the writable directory

[Wolfgang Denk]

In message <000001c3b568$639e70a0$b702a8c0@newrock2> you wrote:
>
> when I boot kernel and mount file system( cramfs and JFFS), for default, the dir /proc is not writable that located in cramfs. Now, I want to change it to be writable. which places/functions should I modify?

/proc it it's own pseudo-filesystem. You don;t include this  in  your
filesystem image, but rather mount it.

> In cramfs I have these dirs:
> /bin
> /root
> /boot
> /sbin
> /usr
> /mnt
> /dev/ --> /mnt/rwfs/dev
> /proc --> /mnt/rwfs/proc

Make /proc a plain directroy,  and  as  part  of  your  init  scripts
execute something like "/bin/mount -t proc proc /proc"


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
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.

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

Re: mpc / linux kernel - user space

[Jaap-Jan Boor]

Hi Juergen,

What I more ment with 'signal your application process' is you have
a user thread block waiting in the read() system call of your driver
and your driver will wake up that blocking read, so the application
thread returns from read.

If you want to send a signal to user code, you can use kill_proc()
I think.

Jaap-Jan

On Thu, 2003-11-27 at 19:08, Juergen Oberhofer wrote:
> Thank you! You mean that the application should install a signal handler
> and
> the module sends on every interrupt a signal to the application process.
> Do you know, Which function does exist to send a signal? I guess, the
> module has to know the pid of the application process? How can the module
> be informed about it?
> Regards,
> Juergen
>
> On Thu, 27 Nov 2003, Jaap-Jan Boor wrote:
>
> > Hi Juergen,
> >
> > That's normally not something you do and I don't know if it's possible.
> > Application code normally communicates with your driver code using
> > system
> > calls (read/write). So either your appl procedure must be part
> > of your module, or you must signal e.g. a user thread the timer
> > interrupt happened, so the thread can execute that code.
> > Hope this helps,
> >
> > Jaap-Jan
> >
> >
> > On 27-nov-03, at 17:07, Juergen Oberhofer wrote:
> >
> > >
> > > Hi,
> > >
> > > I have a module and an application program in user space:
> > >
> > > The Module performs the following task: at init it initializes the cpm
> > > timer register of the mpc823,
> > > such that an interrupt is generated every x microseconds. Thus, I
> > > installed an interrupt handling function f that handles the timer
> > > interrupts.
> > >
> > > My problem is that the module / the interrupt handling function should
> > > execute a procedure defined in the application program. How can I pass
> > > a
> > > pointer (which points to that function) from the appl.program to the
> > > module, such that the handler can execute this function every x
> > > milliseconds? I thought to create a procedure in the module that
> > > accepts
> > > a function pointer as argument. But how can I achieve, that this module
> > > procedure is visible to the application program? Does somebody have a
> > > suggestion or know another way to do it?
> > >
> > > Regards,
> > > Juergen
> > >
> > >
> >
>


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

Re: mpc / linux kernel - user space

[Dan Malek]

Jaap-Jan Boor wrote:

> If you want to send a signal to user code, you can use kill_proc()
> I think.

IMHO, trying to use signals to propagate a hardware interrupt to a
user application is complicated and has design flaws (what happens
if the application "misses" an interrupt or gets blocked for some
reason).

A couple of other methods that I find simple and use extensively
are multi-threading the application and then using a different
minor ID device to wait on a read() or ioctl() to simply return.
The driver just uses the standard sleep/wakeup mechanisms to
synchronize with the application.

Another, and I think most useful, method is to implement a select/poll
entry point in the driver.  It provides the most flexibility when
waiting for various events, plus provides a timeout should something
fail to function properly.


	-- Dan


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

Re: mpc / linux kernel - user space

[Jaap-Jan Boor]

On Fri, 2003-11-28 at 16:42, Dan Malek wrote:
> Jaap-Jan Boor wrote:
>
> > If you want to send a signal to user code, you can use kill_proc()
> > I think.
>
> IMHO, trying to use signals to propagate a hardware interrupt to a
> user application is complicated and has design flaws (what happens
> if the application "misses" an interrupt or gets blocked for some
> reason).

Fortunately I never used it (that's the 'I think')

>
> A couple of other methods that I find simple and use extensively
> are multi-threading the application and then using a different
> minor ID device to wait on a read() or ioctl() to simply return.
> The driver just uses the standard sleep/wakeup mechanisms to
> synchronize with the application.
>
> Another, and I think most useful, method is to implement a select/poll
> entry point in the driver.  It provides the most flexibility when
> waiting for various events, plus provides a timeout should something
> fail to function properly.

Yes, especially the timeout is nice as 'this should never happen'
failures never happens except with the customer

Jaap-Jan

>
>
> 	-- Dan
>
>


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

Peripherals Memory Mapping

[Kevin A. Sapp]

Hello,

Maybe this is a simple question, but I have searched the code
and played around with no luck.  This is for an 8260 FADS
board, later to be used on custom H/W.

How and where do I add peripherals memory to the memory
map?   I have tried adding it in the ads_map_io function but
when I try to access the 82xx internal memory space there to
add the memory to the base and option registers it dies.
io_block_mapping is called successfully for the internal
space, but appears to be inaccessable at this time.

Is there a function that adds memory ranges to both the Linux
map and the processor map (Base and Option registers) ?

Thank you
Kevin


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

Re: Peripherals Memory Mapping

[Paul Miller]

On Monday 01 December 2003 6:51 am, Kevin A. Sapp wrote:
> Hello,
>
> Maybe this is a simple question, but I have searched the code
> and played around with no luck.  This is for an 8260 FADS
> board, later to be used on custom H/W.
>
> How and where do I add peripherals memory to the memory
> map?   I have tried adding it in the ads_map_io function but
> when I try to access the 82xx internal memory space there to
> add the memory to the base and option registers it dies.
> io_block_mapping is called successfully for the internal
> space, but appears to be inaccessable at this time.
>
> Is there a function that adds memory ranges to both the Linux
> map and the processor map (Base and Option registers) ?

I recently jumped into the embedded linux world and I've been playing
around with a 405EP from Intrinsyc.  In order to get I/O access to
the peripheral bus, you need to ioremap_nocache() the peripheral
memory in a kernel module, then mmap() it in user space.  For the DCR
registers (e.g., the embedded memory controller (EBC) registers),
you'll need to modify these in kernel space by calling mtdcr() and
mfdcr().

I've been able to communicate with external hardware via peripheral I/
O.  I noticed that memory addresses should lie on a 16 or 32-bit
boundary, otherwise the write pulse occurs too late for single
writes.

Hope this helps,
-Paul

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

Re: mpc / linux kernel - user space

[Juergen Oberhofer]

Hello,
I tried to make use of wake_up_interruptible(wq) in my module as
following (I just wanted to test if I'm using it correctly):
If I'm doing insmod, the module blocks in the wake_up_interruptible call.
Does somebody know why? Maybe because there is no process sleeping? How do
I check this?

DECLARE_WAIT_QUEUE_HEAD(wq);

int sleepy_init(void) {
  test_file = create_proc_entry("test", 0666, NULL);
  if(test_file == NULL) {
    return -ENOMEM;
  }

  wake_up_interruptible(&wq);

  return 0;
}

void sleepy_cleanup(void) {
remove_proc_entry("test", NULL);
}

module_init(test_init);
module_exit(test_cleanup);


Best regards,
Juergen

On Fri, 2003-11-28 at 10:21, Aain_Devarenne%ZODIAC@zodiac.com wrote:
> Hi everybody
>
> I 'm pending on the same problem as Juergen,
> - How can a User Space Thread Wait for a signaling event set by KERNEL ?

e.g. issue a read on some device driver (/dev/<your driver>
which will block until an interrupt has occured.
something like this:

DECLARE_WAIT_QUEUE_HEAD(mydriver_queue);

ssize_t mydriver_read(
struct file *filp,
char *buf,
size_t count,
loff_t *f_pos)
{
/* wait on interrupt */
while (1) {
interruptible_sleep_on(&mydriver_queue);
if (signal_pending (current)) /* a signal arrived */
return -ERESTARTSYS; /* tell the fs layer to handle it */
else break;
}
return 0;
}

void mydriver_irqhandler(unsigned long arg)
{
wake_up_interruptible(&mydriver_queue);
}

Jaap-Jan


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

Re: mpc / linux kernel - user space

[Sampath Kumar]

Hi,

Write an ioctl method in your module. And provide provision in ioctl to take
a function pointer & store it.
Whenever there is an timer interrupt, check for this pointer, if not NULL ,
then you can call the function. When your application comes up, makesure u
pass the command to ioctl of your module with the function pointer as arg.

Hope this help !

Regards
Sampath
----- Original Message -----
From: Juergen Oberhofer <e9826367@student.tuwien.ac.at>
To: <linuxppc-embedded@lists.linuxppc.org>
Sent: Thursday, November 27, 2003 9:37 PM
Subject: mpc / linux kernel - user space


>
> Hi,
>
> I have a module and an application program in user space:
>
> The Module performs the following task: at init it initializes the cpm
> timer register of the mpc823,
> such that an interrupt is generated every x microseconds. Thus, I
> installed an interrupt handling function f that handles the timer
> interrupts.
>
> My problem is that the module / the interrupt handling function should
> execute a procedure defined in the application program. How can I pass a
> pointer (which points to that function) from the appl.program to the
> module, such that the handler can execute this function every x
> milliseconds? I thought to create a procedure in the module that accepts
> a function pointer as argument. But how can I achieve, that this module
> procedure is visible to the application program? Does somebody have a
> suggestion or know another way to do it?
>
> Regards,
> Juergen
>
>
>


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

Re: mpc / linux kernel - user space

[Wolfgang Denk]

In message <006801c3b571$408bc6e0$c314a8c0@cm> you wrote:
>
> Write an ioctl method in your module. And provide provision in ioctl to take
> a function pointer & store it.

What a bogus advice.

You CANNOT call user space code from kernel  context.  [And  actually
you don't want to.]

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
Human beings were created by water to transport it uphill.

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