[Xenomai-core] User space drivers on PPC440

[Xenomai-core] User space drivers on PPC440

[Steven A. Falco]

The rt_misc_get_io_region() has the "start" argument as an unsigned 
long.  On the PPC440, we have a 36-bit address space, where the I/O 
registers are generally above the 4GB area.  For example, the UART is at 
address 0x1ef600300.

The Linux request_region call has "start" typed as a resource_size_t, 
which is a u64 on the PPC440 (i.e. CONFIG_RESOURCES_64BIT is set even 
though this is a 23-bit processor).

Is this something that should be handled by xeno-config?  It could 
append a CFLAG indicating the size of a resource.

    Steve

Re: [Xenomai-core] User space drivers on PPC440

[Steven A. Falco]

>  (i.e. CONFIG_RESOURCES_64BIT is set even though this is a 23-bit 
> processor).
Make that a 32-bit processor. :-[

Re: [Xenomai-core] User space drivers on PPC440

[Philippe Gerum]

Steven A. Falco wrote:
> The rt_misc_get_io_region() has the "start" argument as an unsigned 
> long.  On the PPC440, we have a 36-bit address space, where the I/O 
> registers are generally above the 4GB area.  For example, the UART is at 
> address 0x1ef600300.
> 
> The Linux request_region call has "start" typed as a resource_size_t, 
> which is a u64 on the PPC440 (i.e. CONFIG_RESOURCES_64BIT is set even 
> though this is a 23-bit processor).
> 
> Is this something that should be handled by xeno-config?  It could 
> append a CFLAG indicating the size of a resource.

Or use a 64bit long unconditionally, to keep the same kernel-based
implementation, since there is no performance issue for this call. In
any case, we need to fix the API before 2.4 final is out -- which will
also affect the ABI, but it already changed during the 2.4 development
phase anyway.

> 
>     Steve
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 
Philippe.

Re: [Xenomai-core] User space drivers on PPC440

[Philippe Gerum]

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

Philippe Gerum wrote:
> Steven A. Falco wrote:
>> The rt_misc_get_io_region() has the "start" argument as an unsigned 
>> long.  On the PPC440, we have a 36-bit address space, where the I/O 
>> registers are generally above the 4GB area.  For example, the UART is at 
>> address 0x1ef600300.
>>
>> The Linux request_region call has "start" typed as a resource_size_t, 
>> which is a u64 on the PPC440 (i.e. CONFIG_RESOURCES_64BIT is set even 
>> though this is a 23-bit processor).
>>
>> Is this something that should be handled by xeno-config?  It could 
>> append a CFLAG indicating the size of a resource.
> 
> Or use a 64bit long unconditionally, to keep the same kernel-based
> implementation, since there is no performance issue for this call. In
> any case, we need to fix the API before 2.4 final is out -- which will
> also affect the ABI, but it already changed during the 2.4 development
> phase anyway.
> 

Does this patch work for you?

-- 
Philippe.

[-- Attachment #2: io-region-64bit-start-address.patch --]
[-- Type: text/x-patch, Size: 3220 bytes --]

Index: include/native/misc.h
===================================================================
--- include/native/misc.h	(revision 3162)
+++ include/native/misc.h	(working copy)
@@ -32,11 +32,11 @@
 
 /* Public interface. */
 
-int rt_misc_get_io_region(unsigned long start,
+int rt_misc_get_io_region(uint64_t start,
 			  unsigned long len,
 			  const char *label);
 
-int rt_misc_put_io_region(unsigned long start,
+int rt_misc_put_io_region(uint64_t start,
 			  unsigned long len);
 
 #ifdef __cplusplus
Index: src/skins/native/misc.c
===================================================================
--- src/skins/native/misc.c	(revision 3162)
+++ src/skins/native/misc.c	(working copy)
@@ -22,16 +22,16 @@
 
 extern int __native_muxid;
 
-int rt_misc_get_io_region(unsigned long start,
+int rt_misc_get_io_region(uint64_t start,
 			  unsigned long len, const char *label)
 {
 	return XENOMAI_SKINCALL3(__native_muxid,
-				 __native_misc_get_io_region, start, len,
+				 __native_misc_get_io_region, &start, len,
 				 label);
 }
 
-int rt_misc_put_io_region(unsigned long start, unsigned long len)
+int rt_misc_put_io_region(uint64_t start, unsigned long len)
 {
 	return XENOMAI_SKINCALL2(__native_muxid,
-				 __native_misc_put_io_region, start, len);
+				 __native_misc_put_io_region, &start, len);
 }
Index: ksrc/skins/native/syscall.c
===================================================================
--- ksrc/skins/native/syscall.c	(revision 3163)
+++ ksrc/skins/native/syscall.c	(working copy)
@@ -3656,7 +3656,7 @@
 #endif /* CONFIG_XENO_OPT_NATIVE_PIPE */
 
 /*
- * int __rt_misc_get_io_region(unsigned long start,
+ * int __rt_misc_get_io_region(uint64_t *start,
  *                             unsigned long len,
  *                             const char *label)
  */
@@ -3664,35 +3664,49 @@
 static int __rt_misc_get_io_region(struct task_struct *curr,
 				   struct pt_regs *regs)
 {
-	unsigned long start, len;
+	unsigned long len;
+	uint64_t start;
 	char label[64];
 
 	if (!__xn_access_ok
+	    (curr, VERIFY_READ, __xn_reg_arg1(regs), sizeof(start)))
+		return -EFAULT;
+
+	if (!__xn_access_ok
 	    (curr, VERIFY_READ, __xn_reg_arg3(regs), sizeof(label)))
 		return -EFAULT;
 
+	__xn_copy_from_user(curr, &start, (void __user *)__xn_reg_arg1(regs),
+			    sizeof(start));
+
 	__xn_strncpy_from_user(curr, label,
 			       (const char __user *)__xn_reg_arg3(regs),
 			       sizeof(label) - 1);
 	label[sizeof(label) - 1] = '\0';
 
-	start = __xn_reg_arg1(regs);
 	len = __xn_reg_arg2(regs);
 
 	return request_region(start, len, label) ? 0 : -EBUSY;
 }
 
 /*
- * int __rt_misc_put_io_region(unsigned long start,
+ * int __rt_misc_put_io_region(uint64_t *start,
  *                             unsigned long len)
  */
 
 static int __rt_misc_put_io_region(struct task_struct *curr,
 				   struct pt_regs *regs)
 {
-	unsigned long start, len;
+	unsigned long len;
+	uint64_t start;
 
-	start = __xn_reg_arg1(regs);
+	if (!__xn_access_ok
+	    (curr, VERIFY_READ, __xn_reg_arg1(regs), sizeof(start)))
+		return -EFAULT;
+
+	__xn_copy_from_user(curr, &start, (void __user *)__xn_reg_arg1(regs),
+			    sizeof(start));
+
 	len = __xn_reg_arg2(regs);
 	release_region(start, len);
 

Re: [Xenomai-core] User space drivers on PPC440

[Steven A. Falco]

[-- Attachment #1.1: Type: text/plain, Size: 2793 bytes --]

Your patch makes sense.

I have some results, but I'm not sure I understand what they mean.  I've 
attached the test program that I am using.  Here is what it outputs:

bash-3.00# ./o2
Trying to free nonexistent resource <0000000000000000-00000000c0000001>
get leds: -16 Device or resource busy
put leds: 0 Success

Trying to free nonexistent resource <0000000000000000-ffffffffffffffff>
get low_mem: -16 Device or resource busy
put low_mem: 0 Success

I am a little unclear on request_resource() - the return code is 
backwards of what I would have expected.  Looking at examples in the 
kernel, it appears that request_resource() returns EBUSY when things go 
well, and it returns 0 when things go badly.  Like I said, that seems 
backwards, but I guess it makes sense - EBUSY apparently means that the 
resource is _now_ busy?

Anyway, following the kernel examples, my program considers a non-zero 
return as success.  At that point I release the region.  If instead, I 
get a zero return, then I treat that as a failure, and don't release the 
region.

The part I don't understand is why I get the "Trying to free nonexistent 
resource" messages.  Since I am getting an EBUSY, I thought that meant I 
owned the resource, and that I should release it...

Also, the addresses printed above are a bit strange.  For example, I 
would have thought that instead of 
"<0000000000000000-00000000c0000001>", it would print 
"<00000001c0000000-00000001c0000013>".  Perhaps that is a clue - maybe 
the start and length are not being passed correctly.

One more question.  It appears that if my program crashes, that the 
region will never be released.  So, the normal behavior of an exiting 
process freeing all its resources doesn't seem to be guaranteed.

    Steve


Philippe Gerum wrote:
> Philippe Gerum wrote:
>   
>> Steven A. Falco wrote:
>>     
>>> The rt_misc_get_io_region() has the "start" argument as an unsigned 
>>> long.  On the PPC440, we have a 36-bit address space, where the I/O 
>>> registers are generally above the 4GB area.  For example, the UART is at 
>>> address 0x1ef600300.
>>>
>>> The Linux request_region call has "start" typed as a resource_size_t, 
>>> which is a u64 on the PPC440 (i.e. CONFIG_RESOURCES_64BIT is set even 
>>> though this is a 23-bit processor).
>>>
>>> Is this something that should be handled by xeno-config?  It could 
>>> append a CFLAG indicating the size of a resource.
>>>       
>> Or use a 64bit long unconditionally, to keep the same kernel-based
>> implementation, since there is no performance issue for this call. In
>> any case, we need to fix the API before 2.4 final is out -- which will
>> also affect the ABI, but it already changed during the 2.4 development
>> phase anyway.
>>
>>     
>
> Does this patch work for you?
>
>   

[-- Attachment #1.2: Type: text/html, Size: 3477 bytes --]

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

#include <fcntl.h>
#include <posix/pthread.h>
#include <posix/time.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

#include <native/task.h>
#include <native/timer.h>

#define LED 0x1c0000002ULL
#define LEN 13
#define BS 128

test_it(unsigned long long addr, unsigned long len, char *name)
{
        int rv_get;
        int rv_put;
        char *bp;
        char buf[BS];

        rv_get = rt_misc_get_io_region(addr, len, name);
        if(rv_get) {
                rv_put = rt_misc_put_io_region(addr, len);
        }

        bp = strerror_r(-rv_get, buf, BS);
        fprintf(stderr, "get %s: %d %s\n", name, rv_get, bp);

        bp = strerror_r(-rv_put, buf, BS);
        fprintf(stderr, "put %s: %d %s\n", name, rv_put, bp);
}

main()
{
        test_it(LED, LEN, "leds");
        test_it(0, LEN, "low_mem");
}

Re: [Xenomai-core] User space drivers on PPC440

[Steven A. Falco]

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

Many apologies.  I forgot to build the user library.  Now the addresses 
look better:

bash-3.00# ./o2
req: start = 00000001c0000002   len = 0000000d
rel: start = 00000001c0000002   len = 0000000d
Trying to free nonexistent resource <00000001c0000002-00000001c000000e>
get leds: -16 Device or resource busy
put leds: 0 Success

However, I still get the printk that I've tried to free a non-existent 
resource.  Next, I'll try page aligning the addresses to see if that helps.

    Steve


Steven A. Falco wrote:
> Your patch makes sense.
>
> I have some results, but I'm not sure I understand what they mean.  
> I've attached the test program that I am using.  Here is what it outputs:
>
> bash-3.00# ./o2
> Trying to free nonexistent resource <0000000000000000-00000000c0000001>
> get leds: -16 Device or resource busy
> put leds: 0 Success
>
> Trying to free nonexistent resource <0000000000000000-ffffffffffffffff>
> get low_mem: -16 Device or resource busy
> put low_mem: 0 Success
>
> I am a little unclear on request_resource() - the return code is 
> backwards of what I would have expected.  Looking at examples in the 
> kernel, it appears that request_resource() returns EBUSY when things 
> go well, and it returns 0 when things go badly.  Like I said, that 
> seems backwards, but I guess it makes sense - EBUSY apparently means 
> that the resource is _now_ busy?
>
> Anyway, following the kernel examples, my program considers a non-zero 
> return as success.  At that point I release the region.  If instead, I 
> get a zero return, then I treat that as a failure, and don't release 
> the region.
>
> The part I don't understand is why I get the "Trying to free 
> nonexistent resource" messages.  Since I am getting an EBUSY, I 
> thought that meant I owned the resource, and that I should release it...
>
> Also, the addresses printed above are a bit strange.  For example, I 
> would have thought that instead of 
> "<0000000000000000-00000000c0000001>", it would print 
> "<00000001c0000000-00000001c0000013>".  Perhaps that is a clue - maybe 
> the start and length are not being passed correctly.
>
> One more question.  It appears that if my program crashes, that the 
> region will never be released.  So, the normal behavior of an exiting 
> process freeing all its resources doesn't seem to be guaranteed.
>
>     Steve
>
>
> Philippe Gerum wrote:
>> Philippe Gerum wrote:
>>   
>>> Steven A. Falco wrote:
>>>     
>>>> The rt_misc_get_io_region() has the "start" argument as an unsigned 
>>>> long.  On the PPC440, we have a 36-bit address space, where the I/O 
>>>> registers are generally above the 4GB area.  For example, the UART is at 
>>>> address 0x1ef600300.
>>>>
>>>> The Linux request_region call has "start" typed as a resource_size_t, 
>>>> which is a u64 on the PPC440 (i.e. CONFIG_RESOURCES_64BIT is set even 
>>>> though this is a 23-bit processor).
>>>>
>>>> Is this something that should be handled by xeno-config?  It could 
>>>> append a CFLAG indicating the size of a resource.
>>>>       
>>> Or use a 64bit long unconditionally, to keep the same kernel-based
>>> implementation, since there is no performance issue for this call. In
>>> any case, we need to fix the API before 2.4 final is out -- which will
>>> also affect the ABI, but it already changed during the 2.4 development
>>> phase anyway.
>>>
>>>     
>>
>> Does this patch work for you?
>>
>>   

[-- Attachment #2: Type: text/html, Size: 4310 bytes --]

Re: [Xenomai-core] User space drivers on PPC440

[Gilles Chanteperdrix]

On Nov 9, 2007 5:03 PM, Steven A. Falco <sfalco@domain.hid> wrote:
>
>  Your patch makes sense.
>
>  I have some results, but I'm not sure I understand what they mean.  I've
> attached the test program that I am using.  Here is what it outputs:
>
>  bash-3.00# ./o2
>  Trying to free nonexistent resource <0000000000000000-00000000c0000001>
>  get leds: -16 Device or resource busy
>  put leds: 0 Success
>
>  Trying to free nonexistent resource <0000000000000000-ffffffffffffffff>
>  get low_mem: -16 Device or resource busy
>  put low_mem: 0 Success
>
>  I am a little unclear on request_resource() - the return code is backwards
> of what I would have expected.  Looking at examples in the kernel, it
> appears that request_resource() returns EBUSY when things go well, and it
> returns 0 when things go badly.  Like I said, that seems backwards, but I
> guess it makes sense - EBUSY apparently means that the resource is _now_
> busy?

request_region returns a pointer to a struct resource, and NULL if the
resource is already reserved.


-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-core] User space drivers on PPC440

[Philippe Gerum]

Steven A. Falco wrote:
> Your patch makes sense.
> 
> I have some results, but I'm not sure I understand what they mean.  I've
> attached the test program that I am using.  Here is what it outputs:
> 
> bash-3.00# ./o2
> Trying to free nonexistent resource <0000000000000000-00000000c0000001>
> get leds: -16 Device or resource busy
> put leds: 0 Success
> 
> Trying to free nonexistent resource <0000000000000000-ffffffffffffffff>
> get low_mem: -16 Device or resource busy
> put low_mem: 0 Success

Actually, we should define rt_misc_put_io_region() as a void routine,
since the kernel does not return any status from release_region(). At
this chance, I've fixed this, since returning 0 albeit a failure message
is dumped to the kernel log upon error is disturbing.

> 
> I am a little unclear on request_resource() - the return code is
> backwards of what I would have expected.  Looking at examples in the
> kernel, it appears that request_resource() returns EBUSY when things go
> well, and it returns 0 when things go badly.  Like I said, that seems
> backwards, but I guess it makes sense - EBUSY apparently means that the
> resource is _now_ busy?
>

request_resource() should return a valid resource descriptor address
upon success, which Xenomai converts to zero. Conversely, -EBUSY is
returned if request_region() sends us back a NULL value, since this is
how check_region() behaves.

> Anyway, following the kernel examples, my program considers a non-zero
> return as success.  At that point I release the region.  If instead, I
> get a zero return, then I treat that as a failure, and don't release the
> region.
> 
> The part I don't understand is why I get the "Trying to free nonexistent
> resource" messages.  Since I am getting an EBUSY, I thought that meant I
> owned the resource, and that I should release it...
> 

I suspect request_region() did actually fail.

> Also, the addresses printed above are a bit strange.  For example, I
> would have thought that instead of
> "<0000000000000000-00000000c0000001>", it would print
> "<00000001c0000000-00000001c0000013>".  Perhaps that is a clue - maybe
> the start and length are not being passed correctly.
> 
> One more question.  It appears that if my program crashes, that the
> region will never be released.  So, the normal behavior of an exiting
> process freeing all its resources doesn't seem to be guaranteed.
> 

As a matter of fact, we track all common objects like sema4s, mutexes,
queues, and so on, but not I/O regions. Consider this as an illustration
of our absolute laziness, since we do have the proper infrastructure to
handle I/O regions in the auto-cleanup process too.

>     Steve
> 
> 
> Philippe Gerum wrote:
>> Philippe Gerum wrote:
>>   
>>> Steven A. Falco wrote:
>>>     
>>>> The rt_misc_get_io_region() has the "start" argument as an unsigned 
>>>> long.  On the PPC440, we have a 36-bit address space, where the I/O 
>>>> registers are generally above the 4GB area.  For example, the UART is at 
>>>> address 0x1ef600300.
>>>>
>>>> The Linux request_region call has "start" typed as a resource_size_t, 
>>>> which is a u64 on the PPC440 (i.e. CONFIG_RESOURCES_64BIT is set even 
>>>> though this is a 23-bit processor).
>>>>
>>>> Is this something that should be handled by xeno-config?  It could 
>>>> append a CFLAG indicating the size of a resource.
>>>>       
>>> Or use a 64bit long unconditionally, to keep the same kernel-based
>>> implementation, since there is no performance issue for this call. In
>>> any case, we need to fix the API before 2.4 final is out -- which will
>>> also affect the ABI, but it already changed during the 2.4 development
>>> phase anyway.
>>>
>>>     
>>
>> Does this patch work for you?
>>
>>   


-- 
Philippe.

Re: [Xenomai-core] User space drivers on PPC440

[Steven A. Falco]

[-- Attachment #1.1: Type: text/plain, Size: 4409 bytes --]

Solved.  As you pointed out, Xenomai inverts the returned value from 
request_region.  So, that was a bug in my application.

However, turns out that instead of request_region, I have to use 
request_mem_region.  This is because the I/O region only goes up to 
2^32, but the mem region goes up to 2^64.

So, attached is a patch to add two new syscalls: rt_misc_get_mem_region 
and rt_misc_put_mem_region.

    Steve


Philippe Gerum wrote:
> Steven A. Falco wrote:
>   
>> Your patch makes sense.
>>
>> I have some results, but I'm not sure I understand what they mean.  I've
>> attached the test program that I am using.  Here is what it outputs:
>>
>> bash-3.00# ./o2
>> Trying to free nonexistent resource <0000000000000000-00000000c0000001>
>> get leds: -16 Device or resource busy
>> put leds: 0 Success
>>
>> Trying to free nonexistent resource <0000000000000000-ffffffffffffffff>
>> get low_mem: -16 Device or resource busy
>> put low_mem: 0 Success
>>     
>
> Actually, we should define rt_misc_put_io_region() as a void routine,
> since the kernel does not return any status from release_region(). At
> this chance, I've fixed this, since returning 0 albeit a failure message
> is dumped to the kernel log upon error is disturbing.
>
>   
>> I am a little unclear on request_resource() - the return code is
>> backwards of what I would have expected.  Looking at examples in the
>> kernel, it appears that request_resource() returns EBUSY when things go
>> well, and it returns 0 when things go badly.  Like I said, that seems
>> backwards, but I guess it makes sense - EBUSY apparently means that the
>> resource is _now_ busy?
>>
>>     
>
> request_resource() should return a valid resource descriptor address
> upon success, which Xenomai converts to zero. Conversely, -EBUSY is
> returned if request_region() sends us back a NULL value, since this is
> how check_region() behaves.
>
>   
>> Anyway, following the kernel examples, my program considers a non-zero
>> return as success.  At that point I release the region.  If instead, I
>> get a zero return, then I treat that as a failure, and don't release the
>> region.
>>
>> The part I don't understand is why I get the "Trying to free nonexistent
>> resource" messages.  Since I am getting an EBUSY, I thought that meant I
>> owned the resource, and that I should release it...
>>
>>     
>
> I suspect request_region() did actually fail.
>
>   
>> Also, the addresses printed above are a bit strange.  For example, I
>> would have thought that instead of
>> "<0000000000000000-00000000c0000001>", it would print
>> "<00000001c0000000-00000001c0000013>".  Perhaps that is a clue - maybe
>> the start and length are not being passed correctly.
>>
>> One more question.  It appears that if my program crashes, that the
>> region will never be released.  So, the normal behavior of an exiting
>> process freeing all its resources doesn't seem to be guaranteed.
>>
>>     
>
> As a matter of fact, we track all common objects like sema4s, mutexes,
> queues, and so on, but not I/O regions. Consider this as an illustration
> of our absolute laziness, since we do have the proper infrastructure to
> handle I/O regions in the auto-cleanup process too.
>
>   
>>     Steve
>>
>>
>> Philippe Gerum wrote:
>>     
>>> Philippe Gerum wrote:
>>>   
>>>       
>>>> Steven A. Falco wrote:
>>>>     
>>>>         
>>>>> The rt_misc_get_io_region() has the "start" argument as an unsigned 
>>>>> long.  On the PPC440, we have a 36-bit address space, where the I/O 
>>>>> registers are generally above the 4GB area.  For example, the UART is at 
>>>>> address 0x1ef600300.
>>>>>
>>>>> The Linux request_region call has "start" typed as a resource_size_t, 
>>>>> which is a u64 on the PPC440 (i.e. CONFIG_RESOURCES_64BIT is set even 
>>>>> though this is a 23-bit processor).
>>>>>
>>>>> Is this something that should be handled by xeno-config?  It could 
>>>>> append a CFLAG indicating the size of a resource.
>>>>>       
>>>>>           
>>>> Or use a 64bit long unconditionally, to keep the same kernel-based
>>>> implementation, since there is no performance issue for this call. In
>>>> any case, we need to fix the API before 2.4 final is out -- which will
>>>> also affect the ABI, but it already changed during the 2.4 development
>>>> phase anyway.
>>>>
>>>>     
>>>>         
>>> Does this patch work for you?
>>>
>>>   
>>>       
>
>
>   

[-- Attachment #1.2: Type: text/html, Size: 5234 bytes --]

[-- Attachment #2: rt_misc_get_mem_region.patch --]
[-- Type: text/x-patch, Size: 3772 bytes --]

Index: include/native/misc.h
===================================================================
--- include/native/misc.h	(revision 3101)
+++ include/native/misc.h	(working copy)
@@ -39,6 +39,13 @@
 int rt_misc_put_io_region(unsigned long start,
 			  unsigned long len);
 
+int rt_misc_get_mem_region(uint64_t start,
+			  unsigned long len,
+			  const char *label);
+
+int rt_misc_put_mem_region(uint64_t start,
+			  unsigned long len);
+
 #ifdef __cplusplus
 }
 #endif
Index: include/native/syscall.h
===================================================================
--- include/native/syscall.h	(revision 3101)
+++ include/native/syscall.h	(working copy)
@@ -119,6 +119,8 @@
 #define __native_timer_tsc2ns       93
 #define __native_queue_write        94
 #define __native_queue_read         95
+#define __native_misc_get_mem_region 96
+#define __native_misc_put_mem_region 97
 
 struct rt_arg_bulk {
 
Index: src/skins/native/misc.c
===================================================================
--- src/skins/native/misc.c	(revision 3101)
+++ src/skins/native/misc.c	(working copy)
@@ -35,3 +35,17 @@
 	return XENOMAI_SKINCALL2(__native_muxid,
 				 __native_misc_put_io_region, start, len);
 }
+
+int rt_misc_get_mem_region(uint64_t start,
+			  unsigned long len, const char *label)
+{
+	return XENOMAI_SKINCALL3(__native_muxid,
+				 __native_misc_get_mem_region, &start, len,
+				 label);
+}
+
+int rt_misc_put_mem_region(uint64_t start, unsigned long len)
+{
+	return XENOMAI_SKINCALL2(__native_muxid,
+				 __native_misc_put_mem_region, &start, len);
+}
Index: ksrc/skins/native/syscall.c
===================================================================
--- ksrc/skins/native/syscall.c	(revision 3101)
+++ ksrc/skins/native/syscall.c	(working copy)
@@ -3692,6 +3692,64 @@
 	return 0;
 }
 
+/*
+ * int __rt_misc_get_mem_region(uint64_t *start,
+ *                             unsigned long len,
+ *                             const char *label)
+ */
+
+static int __rt_misc_get_mem_region(struct task_struct *curr,
+				   struct pt_regs *regs)
+{
+	unsigned long len;
+	uint64_t start;
+	char label[64];
+
+	if (!__xn_access_ok
+	    (curr, VERIFY_READ, __xn_reg_arg1(regs), sizeof(start)))
+		return -EFAULT;
+
+	if (!__xn_access_ok
+	    (curr, VERIFY_READ, __xn_reg_arg3(regs), sizeof(label)))
+		return -EFAULT;
+
+	__xn_copy_from_user(curr, &start, (void __user *)__xn_reg_arg1(regs),
+			    sizeof(start));
+
+	__xn_strncpy_from_user(curr, label,
+			       (const char __user *)__xn_reg_arg3(regs),
+			       sizeof(label) - 1);
+	label[sizeof(label) - 1] = '\0';
+
+	len = __xn_reg_arg2(regs);
+
+	return request_mem_region(start, len, label) ? 0 : -EBUSY;
+}
+
+/*
+ * int __rt_misc_put_mem_region(uint64_t *start,
+ *                             unsigned long len)
+ */
+
+static int __rt_misc_put_mem_region(struct task_struct *curr,
+				   struct pt_regs *regs)
+{
+	unsigned long len;
+	uint64_t start;
+
+	if (!__xn_access_ok
+	    (curr, VERIFY_READ, __xn_reg_arg1(regs), sizeof(start)))
+		return -EFAULT;
+
+	__xn_copy_from_user(curr, &start, (void __user *)__xn_reg_arg1(regs),
+			    sizeof(start));
+
+	len = __xn_reg_arg2(regs);
+	release_mem_region(start, len);
+
+	return 0;
+}
+
 static __attribute__ ((unused))
 int __rt_call_not_available(struct task_struct *curr, struct pt_regs *regs)
 {
@@ -3852,6 +3910,10 @@
 	    {&__rt_misc_put_io_region, __xn_exec_lostage},
 	[__native_timer_ns2tsc] = {&__rt_timer_ns2tsc, __xn_exec_any},
 	[__native_timer_tsc2ns] = {&__rt_timer_tsc2ns, __xn_exec_any},
+	[__native_misc_get_mem_region] =
+	    {&__rt_misc_get_mem_region, __xn_exec_lostage},
+	[__native_misc_put_mem_region] =
+	    {&__rt_misc_put_mem_region, __xn_exec_lostage},
 };
 
 extern xntbase_t *__native_tbase;

Re: [Xenomai-core] User space drivers on PPC440

[Philippe Gerum]

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

Steven A. Falco wrote:
> Solved.  As you pointed out, Xenomai inverts the returned value from
> request_region.  So, that was a bug in my application.
> 
> However, turns out that instead of request_region, I have to use
> request_mem_region.  This is because the I/O region only goes up to
> 2^32, but the mem region goes up to 2^64.
> 
> So, attached is a patch to add two new syscalls: rt_misc_get_mem_region
> and rt_misc_put_mem_region.
> 

Thanks. At this chance, I've reworked the I/O region support to
introduce descriptors, so that this API conforms to the
one-descriptor-per-object rule commonly followed by other services from
the native skin. I've merged your MMIO support on top of this. The added
bonus is that auto-cleanup upon process exit becomes available with I/O
regions too, since we now have the proper descriptor to hold the cleanup
data.

The calls supporting this scheme are named rt_io_get_region, and
rt_io_put_region, taking a RT_IOREGION object descriptor to hold the
internal resource information. The rt_misc_io_get/put_region API is now
deprecated starting with 2.4-rc6, albeit still available to allow for
smooth transition; one will only get a warning as a reminder to upgrade
to the new calls when using the old ones. e.g.

RT_IOREGION iorn;

rt_io_get_region(&iorn, label, start, len, IORN_IOPORT)
is equivalent to calling:
rt_misc_get_io_region(start, len, label)

the same way,

rt_io_get_region(&iorn, label, start, len, IORN_MEMORY)
is equivalent to calling:
rt_misc_get_mem_region(start, len, label)

Conversely,

rt_io_put_region(&iorn)
is equivalent to calling:
rt_misc_put_io/mem_region(start, len)

-- 
Philippe.

[-- Attachment #2: introduce-io-region-descriptors.patch --]
[-- Type: text/x-patch, Size: 12855 bytes --]

Index: include/native/misc.h
===================================================================
--- include/native/misc.h	(revision 3166)
+++ include/native/misc.h	(working copy)
@@ -24,21 +24,109 @@
 
 #include <native/types.h>
 
-#if !defined(__KERNEL__) && !defined(__XENO_SIM__)
+#define IORN_IOPORT	0x1
+#define IORN_MEMORY	0x2
 
+typedef struct rt_ioregion_placeholder {
+	xnhandle_t opaque;
+	/*
+	 * We keep the region start and length in the userland
+	 * placeholder to support deprecated rt_misc_io_*() calls.
+	 */
+	uint64_t start;
+	uint64_t len;
+} RT_IOREGION_PLACEHOLDER;
+
+#if defined(__KERNEL__) || defined(__XENO_SIM__)
+
+#include <native/ppd.h>
+
+#define XENO_IOREGION_MAGIC 0x55550b0b
+
+typedef struct rt_ioregion {
+
+	unsigned magic;		/* !< Magic code - must be first */
+
+	xnhandle_t handle;	/* !< Handle in registry -- must be registered. */
+
+	uint64_t start;		/* !< Start of I/O region. */
+
+	uint64_t len;		/* !< Length of I/O region. */
+
+	char name[XNOBJECT_NAME_LEN]; /* !< Symbolic name. */
+
+	int flags;		/* !< Operation flags. */
+
+	pid_t cpid;		/* !< Creator's pid. */
+
+	xnholder_t rlink;	/* !< Link in resource queue. */
+
+#define rlink2ioregion(ln)	container_of(ln, RT_IOREGION, rlink)
+
+	xnqueue_t *rqueue;     /* !< Backpointer to resource queue. */
+
+} RT_IOREGION;
+
+int rt_ioregion_delete(RT_IOREGION *iorn);
+
+static inline void __native_ioregion_flush_rq(xnqueue_t *rq)
+{
+	xeno_flush_rq(RT_IOREGION, rq, ioregion);
+}
+
+static inline int __native_misc_pkg_init(void)
+{
+	return 0;
+}
+
+static inline void __native_misc_pkg_cleanup(void)
+{
+	__native_ioregion_flush_rq(&__native_global_rholder.ioregionq);
+}
+
+#else /* !(__KERNEL__ && __XENO_SIM__) */
+
+typedef RT_IOREGION_PLACEHOLDER RT_IOREGION;
+
 #ifdef __cplusplus
 extern "C" {
 #endif
 
 /* Public interface. */
 
-int rt_misc_get_io_region(uint64_t start,
-			  unsigned long len,
-			  const char *label);
+int rt_io_get_region(RT_IOREGION *iorn,
+		     const char *name,
+		     uint64_t start,
+		     uint64_t len,
+		     int flags);
 
-void rt_misc_put_io_region(uint64_t start,
-			   unsigned long len);
+int rt_io_put_region(RT_IOREGION *iorn);
 
+__deprecated_call__
+static inline int  rt_misc_get_io_region(unsigned long start,
+					 unsigned long len,
+					 const char *label)
+{
+	RT_IOREGION iorn;
+
+	return rt_io_get_region(&iorn, label, (uint64_t)start,
+				(uint64_t)len, IORN_IOPORT);
+}
+
+__deprecated_call__
+static inline int rt_misc_put_io_region(unsigned long start,
+					unsigned long len)
+{
+	RT_IOREGION iorn;
+
+	iorn.opaque = XN_NO_HANDLE;
+	iorn.start = (uint64_t)start;
+	iorn.len = (uint64_t)len;
+	rt_io_put_region(&iorn);
+
+	return 0;
+}
+
 #ifdef __cplusplus
 }
 #endif
Index: include/native/syscall.h
===================================================================
--- include/native/syscall.h	(revision 3166)
+++ include/native/syscall.h	(working copy)
@@ -113,8 +113,8 @@
 #define __native_pipe_write         87
 #define __native_pipe_stream        88
 #define __native_unimp_89           89
-#define __native_misc_get_io_region 90
-#define __native_misc_put_io_region 91
+#define __native_io_get_region      90
+#define __native_io_put_region      91
 #define __native_timer_ns2tsc       92
 #define __native_timer_tsc2ns       93
 #define __native_queue_write        94
Index: include/native/ppd.h
===================================================================
--- include/native/ppd.h	(revision 3166)
+++ include/native/ppd.h	(working copy)
@@ -41,6 +41,7 @@
 	xnqueue_t pipeq;
 	xnqueue_t queueq;
 	xnqueue_t semq;
+	xnqueue_t ioregionq;
 
 } xeno_rholder_t;
 
Index: src/skins/native/misc.c
===================================================================
--- src/skins/native/misc.c	(revision 3166)
+++ src/skins/native/misc.c	(working copy)
@@ -16,22 +16,21 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA.
  */
 
-#include <stdio.h>
 #include <native/syscall.h>
-#include <native/intr.h>
+#include <native/misc.h>
 
 extern int __native_muxid;
 
-int rt_misc_get_io_region(uint64_t start,
-			  unsigned long len, const char *label)
+int rt_io_get_region(RT_IOREGION *iorn, const char *name,
+		     uint64_t start, uint64_t len, int flags)
 {
-	return XENOMAI_SKINCALL3(__native_muxid,
-				 __native_misc_get_io_region, &start, len,
-				 label);
+	return XENOMAI_SKINCALL5(__native_muxid,
+				 __native_io_get_region, iorn, name,
+				 &start, &len, flags);
 }
 
-void rt_misc_put_io_region(uint64_t start, unsigned long len)
+int rt_io_put_region(RT_IOREGION *iorn)
 {
-	XENOMAI_SKINCALL2(__native_muxid,
-			  __native_misc_put_io_region, &start, len);
+	return XENOMAI_SKINCALL1(__native_muxid,
+				 __native_io_put_region, iorn);
 }
Index: ksrc/skins/native/syscall.c
===================================================================
--- ksrc/skins/native/syscall.c	(revision 3166)
+++ ksrc/skins/native/syscall.c	(working copy)
@@ -36,6 +36,7 @@
 #include <native/alarm.h>
 #include <native/intr.h>
 #include <native/pipe.h>
+#include <native/misc.h>
 
 /* This file implements the Xenomai syscall wrappers;
  *
@@ -3656,60 +3657,178 @@
 #endif /* CONFIG_XENO_OPT_NATIVE_PIPE */
 
 /*
- * int __rt_misc_get_io_region(uint64_t *start,
- *                             unsigned long len,
- *                             const char *label)
+ * int __rt_io_get_region(RT_IOREGION_PLACEHOLDER *ph,
+ *                        const char *name,
+ *                        uint64_t *startp,
+ *                        uint64_t *lenp,
+ *                        int flags)
  */
 
-static int __rt_misc_get_io_region(struct task_struct *curr,
-				   struct pt_regs *regs)
+static int __rt_io_get_region(struct task_struct *curr,
+			      struct pt_regs *regs)
 {
-	unsigned long len;
-	uint64_t start;
-	char label[64];
+	RT_IOREGION_PLACEHOLDER ph;
+	uint64_t start, len;
+	RT_IOREGION *iorn;
+	int err, flags;
+	spl_t s;
 
 	if (!__xn_access_ok
-	    (curr, VERIFY_READ, __xn_reg_arg1(regs), sizeof(start)))
+	    (curr, VERIFY_WRITE, __xn_reg_arg1(regs), sizeof(ph)))
 		return -EFAULT;
 
 	if (!__xn_access_ok
-	    (curr, VERIFY_READ, __xn_reg_arg3(regs), sizeof(label)))
+	    (curr, VERIFY_READ, __xn_reg_arg2(regs), sizeof(iorn->name)))
 		return -EFAULT;
 
-	__xn_copy_from_user(curr, &start, (void __user *)__xn_reg_arg1(regs),
+	if (!__xn_access_ok
+	    (curr, VERIFY_READ, __xn_reg_arg3(regs), sizeof(start)))
+		return -EFAULT;
+
+	if (!__xn_access_ok
+	    (curr, VERIFY_READ, __xn_reg_arg4(regs), sizeof(len)))
+		return -EFAULT;
+
+	iorn = (RT_IOREGION *)xnmalloc(sizeof(*iorn));
+
+	if (!iorn)
+		return -ENOMEM;
+
+	__xn_strncpy_from_user(curr, iorn->name,
+			       (const char __user *)__xn_reg_arg2(regs),
+			       sizeof(iorn->name) - 1);
+	iorn->name[sizeof(iorn->name) - 1] = '\0';
+
+	err = xnregistry_enter(iorn->name, iorn, &iorn->handle, NULL);
+
+	if (err)
+		goto fail;
+
+	__xn_copy_from_user(curr, &start, (void __user *)__xn_reg_arg3(regs),
 			    sizeof(start));
 
-	__xn_strncpy_from_user(curr, label,
-			       (const char __user *)__xn_reg_arg3(regs),
-			       sizeof(label) - 1);
-	label[sizeof(label) - 1] = '\0';
+	__xn_copy_from_user(curr, &len, (void __user *)__xn_reg_arg4(regs),
+			    sizeof(len));
 
-	len = __xn_reg_arg2(regs);
+	flags = __xn_reg_arg5(regs);
 
-	return request_region(start, len, label) ? 0 : -EBUSY;
+	if (flags & IORN_IOPORT)
+		err = request_region(start, len, iorn->name) ? 0 : -EBUSY;
+	else if (flags & IORN_MEMORY)
+		err = request_mem_region(start, len, iorn->name) ? 0 : -EBUSY;
+	else
+		err = -EINVAL;
+
+	if (unlikely(err != 0))
+		goto fail;
+
+	iorn->magic = XENO_IOREGION_MAGIC;
+	iorn->start = start;
+	iorn->len = len;
+	iorn->flags = flags;
+	inith(&iorn->rlink);
+	iorn->rqueue = &xeno_get_rholder()->ioregionq;
+	xnlock_get_irqsave(&nklock, s);
+	appendq(iorn->rqueue, &iorn->rlink);
+	xnlock_put_irqrestore(&nklock, s);
+	iorn->cpid = curr->pid;
+	/* Copy back the registry handle to the ph struct. */
+	ph.opaque = iorn->handle;
+	ph.start = start;
+	ph.len = len;
+	__xn_copy_to_user(curr, (void __user *)__xn_reg_arg1(regs), &ph, sizeof(ph));
+
+	return 0;
+
+fail:
+	xnfree(iorn);
+
+	return err;
 }
 
+/* Provided for auto-cleanup support. */
+int rt_ioregion_delete(RT_IOREGION *iorn)
+{
+	uint64_t start, len;
+	int flags;
+	spl_t s;
+
+	xnlock_get_irqsave(&nklock, s);
+
+	flags = iorn->flags;
+	start = iorn->start;
+	len = iorn->len;
+	removeq(iorn->rqueue, &iorn->rlink);
+	xnregistry_remove(iorn->handle);
+
+	xnlock_put_irqrestore(&nklock, s);
+
+	if (flags & IORN_IOPORT)
+		release_region(start, len);
+	else if (flags & IORN_MEMORY)
+		release_mem_region(start, len);
+
+	return 0;
+}
+
 /*
- * int __rt_misc_put_io_region(uint64_t *start,
- *                             unsigned long len)
+ * int __rt_io_put_region(RT_IOREGION_PLACEHOLDER *ph)
  */
 
-static int __rt_misc_put_io_region(struct task_struct *curr,
-				   struct pt_regs *regs)
+static int __rt_io_put_region(struct task_struct *curr,
+			      struct pt_regs *regs)
 {
-	unsigned long len;
-	uint64_t start;
+	RT_IOREGION_PLACEHOLDER ph;
+	uint64_t start, len;
+	RT_IOREGION *iorn;
+	int flags;
+	spl_t s;
 
 	if (!__xn_access_ok
-	    (curr, VERIFY_READ, __xn_reg_arg1(regs), sizeof(start)))
+	    (curr, VERIFY_READ, __xn_reg_arg1(regs), sizeof(ph)))
 		return -EFAULT;
 
-	__xn_copy_from_user(curr, &start, (void __user *)__xn_reg_arg1(regs),
-			    sizeof(start));
+	__xn_copy_from_user(curr, &ph, (void __user *)__xn_reg_arg1(regs),
+			    sizeof(ph));
 
-	len = __xn_reg_arg2(regs);
-	release_region(start, len);
+	xnlock_get_irqsave(&nklock, s);
 
+	if (unlikely(ph.opaque == XN_NO_HANDLE)) { /* Legacy compat. */
+		xnqueue_t *rq = &xeno_get_rholder()->ioregionq;
+		RT_IOREGION *_iorn;
+		xnholder_t *holder;
+
+		for (holder = getheadq(rq), iorn = NULL;
+		     holder; holder = nextq(rq, holder)) {
+			_iorn = rlink2ioregion(holder);
+			if (_iorn->start == ph.start && _iorn->len == ph.len) {
+				iorn = _iorn;
+				break;
+			}
+		}
+	} else
+		iorn = (RT_IOREGION *)xnregistry_fetch(ph.opaque);
+
+	if (iorn == NULL) {
+		xnlock_put_irqrestore(&nklock, s);
+		return -ESRCH;
+	}
+
+	flags = iorn->flags;
+	start = iorn->start;
+	len = iorn->len;
+	removeq(iorn->rqueue, &iorn->rlink);
+	xnregistry_remove(iorn->handle);
+
+	xnlock_put_irqrestore(&nklock, s);
+
+	xnfree(iorn);
+
+	if (flags & IORN_IOPORT)
+		release_region(start, len);
+	else if (flags & IORN_MEMORY)
+		release_mem_region(start, len);
+
 	return 0;
 }
 
@@ -3746,6 +3865,7 @@
 		initq(&rh->pipeq);
 		initq(&rh->queueq);
 		initq(&rh->semq);
+		initq(&rh->ioregionq);
 
 		return &rh->ppd;
 
@@ -3761,6 +3881,7 @@
 		__native_pipe_flush_rq(&rh->pipeq);
 		__native_queue_flush_rq(&rh->queueq);
 		__native_sem_flush_rq(&rh->semq);
+		__native_ioregion_flush_rq(&rh->ioregionq);
 
 		xnarch_free_host_mem(rh, sizeof(*rh));
 
@@ -3867,10 +3988,10 @@
 	[__native_pipe_write] = {&__rt_pipe_write, __xn_exec_any},
 	[__native_pipe_stream] = {&__rt_pipe_stream, __xn_exec_any},
 	[__native_unimp_89] = {&__rt_call_not_available, __xn_exec_any},
-	[__native_misc_get_io_region] =
-	    {&__rt_misc_get_io_region, __xn_exec_lostage},
-	[__native_misc_put_io_region] =
-	    {&__rt_misc_put_io_region, __xn_exec_lostage},
+	[__native_io_get_region] =
+	    {&__rt_io_get_region, __xn_exec_lostage},
+	[__native_io_put_region] =
+	    {&__rt_io_put_region, __xn_exec_lostage},
 	[__native_timer_ns2tsc] = {&__rt_timer_ns2tsc, __xn_exec_any},
 	[__native_timer_tsc2ns] = {&__rt_timer_tsc2ns, __xn_exec_any},
 };
Index: ksrc/skins/native/module.c
===================================================================
--- ksrc/skins/native/module.c	(revision 3166)
+++ ksrc/skins/native/module.c	(working copy)
@@ -45,6 +45,7 @@
 #include <native/heap.h>
 #include <native/alarm.h>
 #include <native/intr.h>
+#include <native/misc.h>
 
 MODULE_DESCRIPTION("Native skin");
 MODULE_AUTHOR("rpm@xenomai.org");
@@ -80,6 +81,7 @@
 	initq(&__native_global_rholder.pipeq);
 	initq(&__native_global_rholder.queueq);
 	initq(&__native_global_rholder.semq);
+	initq(&__native_global_rholder.ioregionq);
 
 	err = xnpod_init();
 
@@ -93,11 +95,16 @@
 
 	xntbase_start(__native_tbase);
 
-	err = __native_task_pkg_init();
+	err = __native_misc_pkg_init();
 
 	if (err)
 		goto cleanup_pod;
 
+	err = __native_task_pkg_init();
+
+	if (err)
+		goto cleanup_misc;
+
 	err = __native_sem_pkg_init();
 
 	if (err)
@@ -192,6 +199,10 @@
 
 	__native_task_pkg_cleanup();
 
+      cleanup_misc:
+
+	__native_misc_pkg_cleanup();
+
       cleanup_pod:
 
 	xntbase_free(__native_tbase);
@@ -219,6 +230,7 @@
 	__native_event_pkg_cleanup();
 	__native_sem_pkg_cleanup();
 	__native_task_pkg_cleanup();
+	__native_misc_pkg_cleanup();
 	__native_syscall_cleanup();
 
 	xntbase_free(__native_tbase);

Re: [Xenomai-core] User space drivers on PPC440

[Philippe Gerum]

Philippe Gerum wrote:
> Steven A. Falco wrote:
>> Solved.  As you pointed out, Xenomai inverts the returned value from
>> request_region.  So, that was a bug in my application.
>>
>> However, turns out that instead of request_region, I have to use
>> request_mem_region.  This is because the I/O region only goes up to
>> 2^32, but the mem region goes up to 2^64.
>>
>> So, attached is a patch to add two new syscalls: rt_misc_get_mem_region
>> and rt_misc_put_mem_region.
>>
> 
> Thanks. At this chance, I've reworked the I/O region support to
> introduce descriptors, so that this API conforms to the
> one-descriptor-per-object rule commonly followed by other services from
> the native skin. I've merged your MMIO support on top of this. The added
> bonus is that auto-cleanup upon process exit becomes available with I/O
> regions too, since we now have the proper descriptor to hold the cleanup
> data.
> 
> The calls supporting this scheme are named rt_io_get_region, and
> rt_io_put_region, taking a RT_IOREGION object descriptor to hold the
> internal resource information. The rt_misc_io_get/put_region API is now
> deprecated starting with 2.4-rc6, albeit still available to allow for
> smooth transition; one will only get a warning as a reminder to upgrade
> to the new calls when using the old ones. e.g.
> 
> RT_IOREGION iorn;
> 
> rt_io_get_region(&iorn, label, start, len, IORN_IOPORT)
> is equivalent to calling:
> rt_misc_get_io_region(start, len, label)
> 
> the same way,
> 
> rt_io_get_region(&iorn, label, start, len, IORN_MEMORY)

s,IORN_MEMORY,IORN_IOMEM,

(for consistency reason with Linux's naming scheme)

> is equivalent to calling:
> rt_misc_get_mem_region(start, len, label)
> 
> Conversely,
> 
> rt_io_put_region(&iorn)
> is equivalent to calling:
> rt_misc_put_io/mem_region(start, len)
> 
> 


-- 
Philippe.

Re: [Xenomai-core] User space drivers on PPC440

[Steven A. Falco]

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

That works perfectly.  Thanks!

    Steve


Philippe Gerum wrote:
> Philippe Gerum wrote:
>   
>> Steven A. Falco wrote:
>>     
>>> Solved.  As you pointed out, Xenomai inverts the returned value from
>>> request_region.  So, that was a bug in my application.
>>>
>>> However, turns out that instead of request_region, I have to use
>>> request_mem_region.  This is because the I/O region only goes up to
>>> 2^32, but the mem region goes up to 2^64.
>>>
>>> So, attached is a patch to add two new syscalls: rt_misc_get_mem_region
>>> and rt_misc_put_mem_region.
>>>
>>>       
>> Thanks. At this chance, I've reworked the I/O region support to
>> introduce descriptors, so that this API conforms to the
>> one-descriptor-per-object rule commonly followed by other services from
>> the native skin. I've merged your MMIO support on top of this. The added
>> bonus is that auto-cleanup upon process exit becomes available with I/O
>> regions too, since we now have the proper descriptor to hold the cleanup
>> data.
>>
>> The calls supporting this scheme are named rt_io_get_region, and
>> rt_io_put_region, taking a RT_IOREGION object descriptor to hold the
>> internal resource information. The rt_misc_io_get/put_region API is now
>> deprecated starting with 2.4-rc6, albeit still available to allow for
>> smooth transition; one will only get a warning as a reminder to upgrade
>> to the new calls when using the old ones. e.g.
>>
>> RT_IOREGION iorn;
>>
>> rt_io_get_region(&iorn, label, start, len, IORN_IOPORT)
>> is equivalent to calling:
>> rt_misc_get_io_region(start, len, label)
>>
>> the same way,
>>
>> rt_io_get_region(&iorn, label, start, len, IORN_MEMORY)
>>     
>
> s,IORN_MEMORY,IORN_IOMEM,
>
> (for consistency reason with Linux's naming scheme)
>
>   
>> is equivalent to calling:
>> rt_misc_get_mem_region(start, len, label)
>>
>> Conversely,
>>
>> rt_io_put_region(&iorn)
>> is equivalent to calling:
>> rt_misc_put_io/mem_region(start, len)
>>
>>
>>     
>
>
>   

[-- Attachment #2: Type: text/html, Size: 2485 bytes --]

[Xenomai-help] buildbot and state of xenomai on PPC440?

[Niklaus Giger]

Hi

For a series of personal problems I have been away from the xenomai project 
and the buildbot I maintained for some time is quite bit rotten. If there is 
interest around I think I will soon be able to put in some work to bring into 
shape again.

I have a Yosemite PPC440 board at home which I could easily integrate in my 
buildbot environment. At work I sometimes can run tests on our Sequoia 
evaluation board.

At work I was very busy bringing up a custom HW board with a PPC440EPx (very 
close to the Sequoia evaluation board from AMCC) on it. It is running U-Boot 
and in June I ported Linux in a spare couple of hours and it compiled during 
a weekend happily the Linux kernel. As I am having problems getting a 
proprietary OS into a good shape (performance problems, unable to change the 
default page size). Also sometimes I observe a odd application behaviour 
(e.g. spurious problems running some testsuites).

Therefore I would like to get my old (but only half finished) port of our base 
library to the Xenomai vxWorks skin working again.

Following the xenomai mailing list there seems to be some activity on PPC440. 
Could someone please tell me which kernel (denx, stock kernel.org) 
flavour/version against which xenomai worked well? What were the exacts 
parameters for the prepare-kernel.sh? Are these parameters still correct 
against the trunk?

Any hints would be greatly appreciated.

Best regards

Niklaus Giger

Re: [Xenomai-help] buildbot and state of xenomai on PPC440?

[Niklaus Giger]

Hi Steve

Thanks for your reply. I compiled the kernel.
But I can only load a kernel which was configured for the ppc architecture
make -j2 ARCH=ppc CROSS_COMPILE=ppc_4xx- O=../build-linux-sequoia-DENX-v2.6.23 
sequoia_defconfig

If I pass
make -j2 ARCH=powerpc CROSS_COMPILE=ppc_4xx- 
O=../build-linux-sequoia-DENX-v2.6.23 sequoia_defconfig
the board hangs after 
> ## Booting image at 00200000 ...
>    Image Name:   Linux-2.6.23
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    1461799 Bytes =  1.4 MB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
I passed the same arguments to the kernel as before. Do I have to specify 
something different? For the kernel? or a u-boot parameter?

Thanks in advance for your help

Best regards


Am Donnerstag, 15. November 2007 schrieb Steven A. Falco:
> I have a Sequoia board.  I am using ELDK 4.1 for compiler tools, and the
> kernel is from the denx git (version 2.6.23).  I am using the svn
> version of Xenomai.  All seems pretty good.
>
>     Steve
>
> Niklaus Giger wrote:
> > Hi
> >
> > For a series of personal problems I have been away from the xenomai
> > project and the buildbot I maintained for some time is quite bit rotten.
> > If there is interest around I think I will soon be able to put in some
> > work to bring into shape again.
> >
> > I have a Yosemite PPC440 board at home which I could easily integrate in
> > my buildbot environment. At work I sometimes can run tests on our Sequoia
> > evaluation board.
> >
> > At work I was very busy bringing up a custom HW board with a PPC440EPx
> > (very close to the Sequoia evaluation board from AMCC) on it. It is
> > running U-Boot and in June I ported Linux in a spare couple of hours and
> > it compiled during a weekend happily the Linux kernel. As I am having
> > problems getting a proprietary OS into a good shape (performance
> > problems, unable to change the default page size). Also sometimes I
> > observe a odd application behaviour (e.g. spurious problems running some
> > testsuites).
> >
> > Therefore I would like to get my old (but only half finished) port of our
> > base library to the Xenomai vxWorks skin working again.
> >
> > Following the xenomai mailing list there seems to be some activity on
> > PPC440. Could someone please tell me which kernel (denx, stock
> > kernel.org) flavour/version against which xenomai worked well? What were
> > the exacts parameters for the prepare-kernel.sh? Are these parameters
> > still correct against the trunk?
> >
> > Any hints would be greatly appreciated.
> >
> > Best regards
> >
> > Niklaus Giger



-- 
Niklaus Giger
Wieshoschet 6
CH-8753 Mollis
Tel. ++41 55 612 20 54 (privat)
Tel. ++41 55 618 64 68 (Geschäft)

Re: [Xenomai-help] buildbot and state of xenomai on PPC440?

[Philippe Gerum]

Hi Niklaus,

Niklaus Giger wrote:
> Hi
> 
> For a series of personal problems I have been away from the xenomai project 
> and the buildbot I maintained for some time is quite bit rotten. If there is 
> interest around I think I will soon be able to put in some work to bring into 
> shape again.
> 

FWIW, I'm relying on your buildbot, so it would be nice if it could
remain available. TIA,

-- 
Philippe.