inflo | 1 Dec 19:35 2010
Picon

Re: xenomai user lib build error

hi,
the code compiles without errors. I got it once compiled, but after replaying what i have done, it wont work
again :(

The prepare-kernel.sh script i can call from whereever i am, i mean, i could go to e.g. /tmp and could call

/usr/src/xenomai-2.5.5.2/scripts/prepare-kernel.sh --arch=powerpc
--adeos=/usr/src/xenomai-2.5.5.2/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.35.7-ppc-1.5-*.patch --linux=/usr/src/linux-2.6.35.7

then i could go 
cd /usr/src/linux-2.6.35.7 and configure and build the kernel from within this directory ? whats with
this linux/ shadow copy ?

After building patched kernel, i need to configure xenomai user libs. This is done from whereever i want? i
mean, i could go to e.g. /tmp and call

/usr/src/xenomai-2.5.5.2/configure --host=powerpc-linux-gnu
and then also call inside this dir

make

to build xenomai libs?

The user libs build fails mostly with the same procedure
deleting linux/
copying linux source to linux/
hanging

my cross tools are prefixed with powerpc-linux-gnu- like powerpc-linux-gnu-gcc

(Continue reading)

Gilles Chanteperdrix | 2 Dec 00:08 2010

Re: xenomai user lib build error

inflo wrote:
> hi, the code compiles without errors. I got it once compiled, but
> after replaying what i have done, it wont work again :(

Ok. Send me the result of this code compiled with
powerpc-linux-gnu-gcc -E.

> 
> The prepare-kernel.sh script i can call from whereever i am, i mean,
> i could go to e.g. /tmp and could call
> 
> /usr/src/xenomai-2.5.5.2/scripts/prepare-kernel.sh --arch=powerpc
> --adeos=/usr/src/xenomai-2.5.5.2/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.35.7-ppc-1.5-*.patch
> --linux=/usr/src/linux-2.6.35.7
> 
> then i could go cd /usr/src/linux-2.6.35.7 and configure and build
> the kernel from within this directory ? whats with this linux/ shadow
> copy ?

prepare-kernel does not make a shadow copy, it modifies
/usr/src/linux-2.6.35.7 in place. So, if you have linux/ it comes from
somewhere else.

> 
> After building patched kernel, i need to configure xenomai user libs.
> This is done from whereever i want? i mean, i could go to e.g. /tmp
> and call
> 
> /usr/src/xenomai-2.5.5.2/configure --host=powerpc-linux-gnu and then
> also call inside this dir
(Continue reading)

inflo | 2 Dec 19:17 2010
Picon

Re: xenomai user lib build error

hi,
i deleted the linux and xenomai sources directories and replayed the whole thing. It worked directly. I
dont know what i have done soo wrong last time. I tried it now again and again and it works.

thanks for help and sorry for wasting your time :)

flo

On Thu, 02 Dec 2010 00:08:28 +0100
Gilles Chanteperdrix <gilles.chanteperdrix <at> xenomai.org> wrote:

> inflo wrote:
> > hi, the code compiles without errors. I got it once compiled, but
> > after replaying what i have done, it wont work again :(
> 
> Ok. Send me the result of this code compiled with
> powerpc-linux-gnu-gcc -E.
> 
> > 
> > The prepare-kernel.sh script i can call from whereever i am, i mean,
> > i could go to e.g. /tmp and could call
> > 
> > /usr/src/xenomai-2.5.5.2/scripts/prepare-kernel.sh --arch=powerpc
> > --adeos=/usr/src/xenomai-2.5.5.2/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.35.7-ppc-1.5-*.patch
> > --linux=/usr/src/linux-2.6.35.7
> > 
> > then i could go cd /usr/src/linux-2.6.35.7 and configure and build
> > the kernel from within this directory ? whats with this linux/ shadow
> > copy ?
> 
(Continue reading)

adilkaraoz | 4 Dec 08:16 2010
Picon

How to Obtaining Pci Device Private Data ( base Address ) with RTDM

Hi,


I want to obtain private data of my PLX pci device but I don't understand anything what I do. Starting of my code below please help me.

/**
* define devices our driver supports
*/
static struct pci_device_id pic1711_ids[]={ { PCI_DEVICE(PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_1711) },{0,}, };

/**
* export pci_device_id structure to user space, allowing hotplug
*/
MODULE_DEVICE_TABLE (pci, pic1711_ids);

/**
* create pci_driver structure,
* and register it in cpci_ea221_driver_init_module,
* unregister in cpci_ea221_driver_exit_module
*/
static struct pci_driver pci1711_driver = {

.name     = DRV_NAME,
.id_table = pic1711_ids,
.probe    = pci1711_probe,
.remove  = __devexit_p(pci1711_remove),
};

/**
* Init module function
*/
static int xeno_pic1711_driver_init_module(void){

static int ret_val;
printk( KERN_DEBUG "Module xenoPci1711_driver init\n" );

ret_val = pci_register_driver(&pci1711_driver);
return ret_val;
}

And I found this code for obtain private data.

struct pci_dev *pcidev;

printk("PCI-1711 DETECT PCI \n");
  pcidev=NULL;
  pcidev =pci_get_device (PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_1711, pcidev );
 
  if (pcidev==NULL){
       printk("PCI-1711 CANNOT BE FOUND \n");
  }
  else{
 
     printk("PCI-1711 LOCATED \n");
     if (pci_enable_device(pcidev)){
    
         printk("PCI-1711 NOT ENABLED \n");
        
         return(-EIO);
        
       }
       else{
         printk("PCI-1711 ENABLED \n");
       }
       
     //PCI_BASE_ADRESS_1711= pci_resource_start(pcidev, 1)&   
  //PCI_BASE_ADDRESS_MEM_MASK; printk("PCI-1711 DETECT PCI %x \n",PCI_BASE_ADRESS_1711);

With this code pci_dev used but my code has pci_driver I don't understand relation between pci_dev and pci_driver.

--
Adil Karaöz
C TECH Yazılım Geliştiricisi
GYTE Bilgisayar Mühendisliği

_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help
Gilles Chanteperdrix | 4 Dec 10:10 2010

Re: How to Obtaining Pci Device Private Data ( base Address ) with RTDM

adilkaraoz wrote:
> Hi,
> 
> I want to obtain private data of my PLX pci device but I don't understand
> anything what I do. Starting of my code below please help me.

The way you would do this with RTDM is the same you would do it with
Linux. RTDM does not define any API, it lets you use Linux API.

If your trouble is about writing a PCI driver with Linux, then you are
asking the wrong list, since you ask to a Xenomai mailing list, mainly
talking about Xenomai.

Though we can suggest you to read the chapter on PCI devices of the
"Linux device drivers" book. Available online here:
http://lwn.net/Kernel/LDD3/

Hopefully, when you have read that book, you will understand better what
you are doing

--

-- 
                                                                Gilles.
krzyma krzyma | 4 Dec 16:26 2010
Picon

Freeze after rt_sem_broadcast

Hi,
I have a simple program which only has to start some tasks. I wanted
to start the tasks with rt_sem_broadcast. The problem is when I have
more than ~50 tasks, then the system just freezes and nothing works
(keyboard). and I need to restart it hardly. I figured out that the
problem exists only with rt_sem_broadcast, without it the number of
tasks is not the problem. I have Xenomai 2.4.4 on Fedora 3 (2.6.25.11)
with all the xenomai debug  and watchdog options enabled.

Thanks,
Krzysztof
Gilles Chanteperdrix | 4 Dec 21:08 2010

Re: Freeze after rt_sem_broadcast

krzyma krzyma wrote:
> Hi,
> I have a simple program which only has to start some tasks. I wanted
> to start the tasks with rt_sem_broadcast. The problem is when I have
> more than ~50 tasks, then the system just freezes and nothing works
> (keyboard). and I need to restart it hardly. I figured out that the
> problem exists only with rt_sem_broadcast, without it the number of
> tasks is not the problem. I have Xenomai 2.4.4 on Fedora 3 (2.6.25.11)
> with all the xenomai debug  and watchdog options enabled.

http://www.xenomai.org/index.php/Request_for_information

--

-- 
                                                                Gilles.
Henri Roosen | 7 Dec 15:47 2010
Picon

Ipipe support for 'longterm' kernel versions

Hi all,

I was pleased to read on the Linux Kernel Mailing List Greg's message
about Linux stable kernel release procedure changes, that the longterm
supported stable kernels will be made more explicit by getting the
'longterm' name.

https://lkml.org/lkml/2010/12/2/388

We are embedding Linux in products and therefore those longterm
kernels are very valuable for us. We chose 2.6.32 kernel because of
that a while ago.

However, unfortunately there is no Ipipe patch that applies cleanly on
the latest 2.6.32.26 stable, nor is there an ARM version.

It would be great if Xenomai would also recognize this need and would
do some kind of 'long term' support for the Ipipe for the longterm
kernels. I understand maintaining the Ipipe is a lot of work.
Personally I think it would be an option to only support the longterm
kernels...

What do the Xenomai/Ipipe developers think?

Thanks,
Henri.
Jan Kiszka | 7 Dec 18:59 2010
Picon

Re: Ipipe support for 'longterm' kernel versions

Am 07.12.2010 15:47, Henri Roosen wrote:
> Hi all,
> 
> I was pleased to read on the Linux Kernel Mailing List Greg's message
> about Linux stable kernel release procedure changes, that the longterm
> supported stable kernels will be made more explicit by getting the
> 'longterm' name.
> 
> https://lkml.org/lkml/2010/12/2/388
> 
> We are embedding Linux in products and therefore those longterm
> kernels are very valuable for us. We chose 2.6.32 kernel because of
> that a while ago.
> 
> However, unfortunately there is no Ipipe patch that applies cleanly on
> the latest 2.6.32.26 stable, nor is there an ARM version.
> 
> It would be great if Xenomai would also recognize this need and would
> do some kind of 'long term' support for the Ipipe for the longterm
> kernels. I understand maintaining the Ipipe is a lot of work.
> Personally I think it would be an option to only support the longterm
> kernels...
> 
> What do the Xenomai/Ipipe developers think?

Of course, supporting kernel releases over a longer period is a good
thing. However, it takes resources to do this job, to backport fixes or
even features from latest I-pipe versions and to resolve patch conflicts
over older kernels. If you are willing to support our community, you are
always welcome!

How this new (actually it is not that new) longterm strategy of the
Linux kernel will influence I-pipe tip development is not yet well
predictable. Right now I would say the need for certain features only
available in newer kernels will continue to drive updates of I-pipe, not
that some kernel is declared longterm stable. But this also depends on
when the longterm tags will be announced, ahead of releases or much later.

Jan

--

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Gilles Chanteperdrix | 7 Dec 21:31 2010

Re: Ipipe support for 'longterm' kernel versions

Henri Roosen wrote:
> Hi all,
> 
> I was pleased to read on the Linux Kernel Mailing List Greg's message
> about Linux stable kernel release procedure changes, that the longterm
> supported stable kernels will be made more explicit by getting the
> 'longterm' name.
> 
> https://lkml.org/lkml/2010/12/2/388
> 
> We are embedding Linux in products and therefore those longterm
> kernels are very valuable for us. We chose 2.6.32 kernel because of
> that a while ago.
> 
> However, unfortunately there is no Ipipe patch that applies cleanly on
> the latest 2.6.32.26 stable, nor is there an ARM version.
> 
> It would be great if Xenomai would also recognize this need and would
> do some kind of 'long term' support for the Ipipe for the longterm
> kernels. I understand maintaining the Ipipe is a lot of work.
> Personally I think it would be an option to only support the longterm
> kernels...
> 
> What do the Xenomai/Ipipe developers think?

Well, 2.6.35 is also a long term version. Maintaining all the long term
versions is a lot of work (it takes time to simply validate a patch for
every new release). So, we probably can not maintain support for all the
long term versions, we would probably have to pick one.

Since the I-pipe patch for ARM skips even versions (in order to reduce
the time spent issuing I-pipe patches), and since it is more recent, I
would rather go for 2.6.35.

--

-- 
                                                                Gilles.

Gmane