[Xenomai-help] Xenomai on the TS-7553 ARM SBC

[Xenomai-help] Xenomai on the TS-7553 ARM SBC

[aubin.rebillat]

Hello, 

I am trying to port Xenomai on the TS-7553 SBC from Technologic systems, based on the ECONA CNS2132 (STAR8132) from Cavium networks (250 MHz arm922t).
A Linux kernel is available for this board, version 2.6.24.4, which is running fine.
I patched this kernel with adeos-ipipe-2.6.24-arm-1.9-01.patch and I implemented all the IPIPE code for the CNS2132 and everything is compiling and booting fine.

Therefore, I applied the procedure to add the Xenomai nucleus (version 2.5.6) to my IPIPE patched kernel:

> prepare_kernel.sh --arch=arm --linux=../linux-2.6.24.4 make 
> O=../build_root ts7500_defconfig make O=../build_root bzImage modules

And everything is compiling fine (Just an error due to the non-existence of the phy_addr_t type in 2.6.24 kernel which is easy to fix).

Also, This board does not support standard bootloaders (GRUB, U-BOOT, …), it uses a specific one (TS-BOOTROM) developed by the board manufacturer.
The bootloader is quite simple, it initialises some hardware and loads the kernel and initrd into ram before jumping on the kernel code.
Then after the kernel boot, an initialisation script in the initrd mounts a debian partition, executes pivot_root on it and launches the debian init program.
Due to this boot process to have a debian environment, I preferred to have a fine running kernel with Xenomai before adding any user space support.

My problem is that during the initialisation script in the initrd the kernel hangs and only if Xenomai is enabled in the kernel configuration. Without Xenomai, the kernel is booting to debian correctly.

Could it be because of the lack of user space support ? 
It does not seem likely because if Xenomai crashes a log should be printed. Am I wrong ?

Could it be because of the initrd ? Do I need a xenomai specific initrd ? 
I did not see anything about initrd and xenomai anywhere so I assume that the answers are ''no''. Am I wrong ?

In my tests, I disabled the pivot_root call in the init script but it does not change anything.

Nevertheless, here is the boot log :

[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
[    0.000000] Kernel command line: root=/dev/ram0 init=/linuxrc console=null lpj=958464
[    0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[    0.000000] I-pipe 1.9-01: pipeline enabled.
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.010000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.020000] Memory:MB64MB total
[    0.020000] Memory: 58252KB available (2100K code, 329K data, 88K init)
[    0.030000] Calibrating delay loop (skipped)... 191.69 BogoMIPS preset
[    0.030000] Mount-cache hash table entries: 512
[    0.040000] CPU: Testing write buffer coherency: [    0.050000] net_namespace: 64 bytes
[    0.050000] NET: Registered protocol family 16
[    0.060000] PCI clock at 33M
[    0.060000] PCI: bus0: Fast back to back transfers disabled
[    0.060000] PCI Bridge found
[    0.070000] PCI: enabling device 0000:00:00.0 (0140 -> 0142)
[    0.070000] PCI map irq: 00:00.00 slot 0, pin 1, irq: 0
[    0.150000] NET: Registered protocol family 2
[    0.250000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.250000] IPv4 FIB: Using LC-trie version 0.408
[    0.250000] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[    0.260000] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[    0.270000] TCP: Hash tables configured (established 2048 bind 2048)
[    0.270000] TCP reno registered
[    0.310000] checking if image is initramfs...isn't (bad gzip magic numbers); looks like an d
[    0.480000] Freeing initrd memory: 4096K
[    0.480000] NetWinder Floating Point Emulator V0.97 (extended precision)
[    0.490000] I-pipe: Domain Xenomai registered.
[    0.490000] Xenomai: hal/arm started.
[    0.500000] Xenomai: scheduling class idle registered.
[    0.500000] Xenomai: scheduling class rt registered.
[    0.540000] Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.
[    0.550000] Xenomai: starting native API services.
[    0.550000] Xenomai: starting POSIX services.
[    0.560000] Xenomai: starting RTDM services.
[    0.560000] io scheduler noop registered
[    0.560000] io scheduler deadline registered (default)
[    0.560000] Serial: 8250/16550 driver $Revision: 1.1.1.1 $ 2 ports, IRQ sharing disabled
[    0.560000] serial8250: ttyS0 at MMIO 0x78000000 (irq = 9) is a 16550A
[    0.560000] serial8250: ttyS1 at MMIO 0x78800000 (irq = 10) is a 16550A
[    0.560000] RAMDISK driver initialized: 4 RAM disks of 16384K size 1024 blocksize
[    0.560000] nbd: registered device at major 43
[    0.560000] Star NIC Driver(for Linux Kernel 2.6) - Star Semiconductor
[    0.560000]     rxring.vir_addr=0xFFC00000 rxring.phy_addr=0x03552000
[    0.560000]     txring.vir_addr=0xFFC01000 txring.phy_addr=0x03553000
[    0.560000] Star Internal PHY
[    0.560000] MAC Addr: 00:d0:69:45:40:14
[    0.560000] 
[    0.560000] star_nic_init_module: internal phy patch included.
[    0.560000] star_nic_init_module: scatter/gather enabled.
[    0.560000] 
[    0.560000] i2c /dev entries driver
[    0.560000] str8100_i2c_dev_init: i2c module version 1.0.0
[    0.560000] str8100_i2c_init: current_clock=400000l, CLKDIV=77
[    0.560000] TCP cubic registered
[    0.560000] NET: Registered protocol family 1
[    0.560000] NET: Registered protocol family 17
[    0.560000] RPC: Registered udp transport module.
[    0.560000] RPC: Registered tcp transport module.
[    0.560000] RAMDISK: ext2 filesystem found at block 0
[    0.560000] RAMDISK: Loading 2048KiB [1 disk] into ram disk... e.
[    0.560000] EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
[    0.560000] VFS: Mounted root (ext2 filesystem).
[    0.560000] Freeing init memory: 88K
[    0.560000] Warning: unable to open an initial console.

As you can see no problem is reported at all.

Does anyone have an idea about what may go wrong ?

Thank you very much,

Best regards,

-- 
Aubin REBILLAT

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[Gilles Chanteperdrix]

On 05/10/2012 03:26 PM, aubin.rebillat@domain.hid wrote:
> Hello, 
> 
> I am trying to port Xenomai on the TS-7553 SBC from Technologic
systems, based on the ECONA CNS2132 (STAR8132) from Cavium networks (250
MHz arm922t).
> A Linux kernel is available for this board, version 2.6.24.4, which
> is
running fine.
> I patched this kernel with adeos-ipipe-2.6.24-arm-1.9-01.patch and I
implemented all the IPIPE code for the CNS2132 and everything is
compiling and booting fine.
> 
> Therefore, I applied the procedure to add the Xenomai nucleus
> (version
2.5.6) to my IPIPE patched kernel:
> 
>> prepare_kernel.sh --arch=arm --linux=../linux-2.6.24.4 make 
>> O=../build_root ts7500_defconfig make O=../build_root bzImage
>> modules
> 
> And everything is compiling fine (Just an error due to the
non-existence of the phy_addr_t type in 2.6.24 kernel which is easy to fix).
> 
> Also, This board does not support standard bootloaders (GRUB,
> U-BOOT,
…), it uses a specific one (TS-BOOTROM) developed by the board manufacturer.
> The bootloader is quite simple, it initialises some hardware and
> loads
the kernel and initrd into ram before jumping on the kernel code.
> Then after the kernel boot, an initialisation script in the initrd
mounts a debian partition, executes pivot_root on it and launches the
debian init program.
> Due to this boot process to have a debian environment, I preferred
> to
have a fine running kernel with Xenomai before adding any user space
support.
> 
> My problem is that during the initialisation script in the initrd
> the
kernel hangs and only if Xenomai is enabled in the kernel configuration.
Without Xenomai, the kernel is booting to debian correctly.
> 
> Could it be because of the lack of user space support ? It does not
> seem likely because if Xenomai crashes a log should be
printed. Am I wrong ?
> 
> Could it be because of the initrd ? Do I need a xenomai specific
> initrd ? I did not see anything about initrd and xenomai anywhere so
> I assume
that the answers are ''no''. Am I wrong ?
> 
> In my tests, I disabled the pivot_root call in the init script but
> it
does not change anything.
> 
> Nevertheless, here is the boot log :
> 
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
> [    0.000000] Kernel command line: root=/dev/ram0 init=/linuxrc console=null lpj=958464
> (...)
> [    0.560000] Warning: unable to open an initial console.
> 
> As you can see no problem is reported at all.
> 
> Does anyone have an idea about what may go wrong ?

root=/dev/ram0 means that you are using an initrd, which has been
deprecated for many years.

"unable to open an initial console" means that you will not get further
output from the kernel. The kernel looks for the "/dev/null" file, but
does not seem to find it. But even if it found it, it would probably
stop outputting anything. So, I suggest you use whatever serial port is
outputting these messages to see further output messages. Using
console=ttyS0,115200 as a kernel parameter for instance.

If the kernel mysteriously fails when running init, you have to pay
attention at the kernel OABI/EABI settings.

To know if the issue is really related to xenomai, try disabling
CONFIG_IPIPE and CONFIG_XENOMAI starting from the failing kernel
configuration, and see if booting still fails. If it still fails, then
your issue is likely not related to Xenomai or the I-pipe patch.

Another trick is to use an NFS mounted root filesystem, this way, by
capturing the network traffic with wireshark, you can see in details
what accesses the board does to the filesystem, and what fails.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[aubin.rebillat]

> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "aubin rebillat" <aubin.rebillat@domain.hid>
> Cc: xenomai@xenomai.org
> Envoyé: Jeudi 10 Mai 2012 15:42:32
> Objet: Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
> 
> On 05/10/2012 03:26 PM, aubin.rebillat@domain.hid wrote:
> > Hello,
> > 
> > I am trying to port Xenomai on the TS-7553 SBC from Technologic
> systems, based on the ECONA CNS2132 (STAR8132) from Cavium networks
> (250
> MHz arm922t).
> > A Linux kernel is available for this board, version 2.6.24.4, which
> > is
> running fine.
> > I patched this kernel with adeos-ipipe-2.6.24-arm-1.9-01.patch and
> > I
> implemented all the IPIPE code for the CNS2132 and everything is
> compiling and booting fine.
> > 
> > Therefore, I applied the procedure to add the Xenomai nucleus
> > (version
> 2.5.6) to my IPIPE patched kernel:
> > 
> >> prepare_kernel.sh --arch=arm --linux=../linux-2.6.24.4 make
> >> O=../build_root ts7500_defconfig make O=../build_root bzImage
> >> modules
> > 
> > And everything is compiling fine (Just an error due to the
> non-existence of the phy_addr_t type in 2.6.24 kernel which is easy
> to fix).
> > 
> > Also, This board does not support standard bootloaders (GRUB,
> > U-BOOT,
> …), it uses a specific one (TS-BOOTROM) developed by the board
> manufacturer.
> > The bootloader is quite simple, it initialises some hardware and
> > loads
> the kernel and initrd into ram before jumping on the kernel code.
> > Then after the kernel boot, an initialisation script in the initrd
> mounts a debian partition, executes pivot_root on it and launches the
> debian init program.
> > Due to this boot process to have a debian environment, I preferred
> > to
> have a fine running kernel with Xenomai before adding any user space
> support.
> > 
> > My problem is that during the initialisation script in the initrd
> > the
> kernel hangs and only if Xenomai is enabled in the kernel
> configuration.
> Without Xenomai, the kernel is booting to debian correctly.
> > 
> > Could it be because of the lack of user space support ? It does not
> > seem likely because if Xenomai crashes a log should be
> printed. Am I wrong ?
> > 
> > Could it be because of the initrd ? Do I need a xenomai specific
> > initrd ? I did not see anything about initrd and xenomai anywhere
> > so
> > I assume
> that the answers are ''no''. Am I wrong ?
> > 
> > In my tests, I disabled the pivot_root call in the init script but
> > it
> does not change anything.
> > 
> > Nevertheless, here is the boot log :
> > 
> > [    0.000000] Built 1 zonelists in Zone order, mobility grouping
> > on.  Total pages: 16256
> > [    0.000000] Kernel command line: root=/dev/ram0 init=/linuxrc
> > console=null lpj=958464
> > (...)
> > [    0.560000] Warning: unable to open an initial console.
> > 
> > As you can see no problem is reported at all.
> > 
> > Does anyone have an idea about what may go wrong ?
> 
> root=/dev/ram0 means that you are using an initrd, which has been
> deprecated for many years.

I don't really have another option because the board does not support U-BOOT (according to the manufacturer) and due to the specific bootloader on the board I need an initrd : The bootloader only initialises some hardware and loads the kernel image and the initrd in memory before jumping on the kernel code. Then it uses the "linux booting linux" technique to launch debian.
I agree with you that it is not the way of doing it today and i suspect the board manufacturer to do so to sell a "fast booting board" because linux is booted in less than 4 secs (of course for debian, it takes really more).
They actually made many things that seemed nice when i read the description but when i wanted to develop with it I saw a lot of really strange technique / behaviors (See the UART after for example).

>
> "unable to open an initial console" means that you will not get
> further
> output from the kernel. The kernel looks for the "/dev/null" file,
> but
> does not seem to find it. But even if it found it, it would probably
> stop outputting anything. So, I suggest you use whatever serial port
> is
> outputting these messages to see further output messages. Using
> console=ttyS0,115200 as a kernel parameter for instance.
> 

The UARTs accessed by ttyS0 and ttyS1 do not have any corresponding ports on the board so i can't use any console.
Instead, I use a special serial output implemented on the fpga on the board.
The problem is that this serial output is really not standard and I don't really know how the console API works so I modified printk to also display directly on this serial output before calling the console driver. Therefore, any printk displayed on the console is also displayed using this serial output.

> If the kernel mysteriously fails when running init, you have to pay
> attention at the kernel OABI/EABI settings.
> 
> To know if the issue is really related to xenomai, try disabling
> CONFIG_IPIPE and CONFIG_XENOMAI starting from the failing kernel
> configuration, and see if booting still fails. If it still fails,
> then
> your issue is likely not related to Xenomai or the I-pipe patch.

I have troubles only with CONFIG_XENOMAI enabled. With the normal kernel or the IPIPE kernel the board is booting fine with exactly the same configuration (except CONFIG_IPIPE of course).

>
> Another trick is to use an NFS mounted root filesystem, this way, by
> capturing the network traffic with wireshark, you can see in details
> what accesses the board does to the filesystem, and what fails.
> 
> --
> 					    Gilles.
> 
>

I will look into the OABI and EABI settings then.
I will also set up an NFS file system to mount debian from and see what is happening.

Thank you Gilles for your reply. I will keep posting about my progresses.

Best regards,

-- 
Aubin REBILLAT

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[Gilles Chanteperdrix]

On 05/10/2012 05:18 PM, aubin.rebillat@domain.hid wrote:
>> root=/dev/ram0 means that you are using an initrd, which has been 
>> deprecated for many years.
> 
> I don't really have another option because the board does not support
> U-BOOT (according to the manufacturer) and due to the specific
> bootloader on the board I need an initrd : The bootloader only
> initialises some hardware and loads the kernel image and the initrd
> in memory before jumping on the kernel code. Then it uses the "linux
> booting linux" technique to launch debian. I agree with you that it
> is not the way of doing it today and i suspect the board manufacturer
> to do so to sell a "fast booting board" because linux is booted in
> less than 4 secs (of course for debian, it takes really more). They
> actually made many things that seemed nice when i read the
> description but when i wanted to develop with it I saw a lot of
> really strange technique / behaviors (See the UART after for
> example).

There is no difference that I know of from the bootloader side whether
booting with an initrd or an initramfs. Anyway, the only difference is
that initramfs wastes more memory, it is not what is causing the
problem. Either using an initrd or an initramfs wastes boot time, which
is usually a scarse resource on embedded systems. Whatever the
bootloader, I do not see what prevents you from passing different
parameters than "root=/dev/ram0" to the kernel, which would be enough to
boot from another device.

But all this is unimportant.

> I will look into the OABI and EABI settings then. I will also set up
> an NFS file system to mount debian from and see what is happening.
> 
> Thank you Gilles for your reply. I will keep posting about my
> progresses.

The issue may simply well be that your timer code does not work. Could
you post the code for your port? That is, the code you added to get it
work with the I-pipe patch. Have you checked that linux timer is still
ticking after Xenomai has been started?

You can also try to boot with CONFIG_IPIPE but without CONFIG_XENOMAI.

Note that in case you do not know it, there is a guide for porting the
I-pipe patch on new ARM platforms:

http://www.xenomai.org/index.php/I-pipe:ArmPorting

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[aubin.rebillat]

> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "aubin rebillat" <aubin.rebillat@domain.hid>
> Cc: xenomai@xenomai.org
> Envoyé: Jeudi 10 Mai 2012 17:30:30
> Objet: Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
> 
> On 05/10/2012 05:18 PM, aubin.rebillat@domain.hid wrote:
> >> root=/dev/ram0 means that you are using an initrd, which has been
> >> deprecated for many years.
> > 
> > I don't really have another option because the board does not
> > support
> > U-BOOT (according to the manufacturer) and due to the specific
> > bootloader on the board I need an initrd : The bootloader only
> > initialises some hardware and loads the kernel image and the initrd
> > in memory before jumping on the kernel code. Then it uses the
> > "linux
> > booting linux" technique to launch debian. I agree with you that it
> > is not the way of doing it today and i suspect the board
> > manufacturer
> > to do so to sell a "fast booting board" because linux is booted in
> > less than 4 secs (of course for debian, it takes really more). They
> > actually made many things that seemed nice when i read the
> > description but when i wanted to develop with it I saw a lot of
> > really strange technique / behaviors (See the UART after for
> > example).
> 
> There is no difference that I know of from the bootloader side
> whether
> booting with an initrd or an initramfs. Anyway, the only difference
> is
> that initramfs wastes more memory, it is not what is causing the
> problem. Either using an initrd or an initramfs wastes boot time,
> which
> is usually a scarse resource on embedded systems. Whatever the
> bootloader, I do not see what prevents you from passing different
> parameters than "root=/dev/ram0" to the kernel, which would be enough
> to
> boot from another device.
> 
> But all this is unimportant.
>

I'm not that experienced with initrd/initramfs and that was what the manufacturer recommended and i followed it so i can have support from them. But yes, at first, i think it can boot from another device.

> 
> > I will look into the OABI and EABI settings then. I will also set
> > up
> > an NFS file system to mount debian from and see what is happening.
> > 
> > Thank you Gilles for your reply. I will keep posting about my
> > progresses.
> 
> The issue may simply well be that your timer code does not work.
> Could
> you post the code for your port? That is, the code you added to get
> it
> work with the I-pipe patch. 
> Have you checked that linux timer is
> still
> ticking after Xenomai has been started?

No, i did not check that the linux timer is still ticking.
But i think it is because parts of the init script are executed and it is a shell script calling several sub-processes.
Nevertheless, I will put some printk in the linux timer handler to be sure.

> 
> You can also try to boot with CONFIG_IPIPE but without
> CONFIG_XENOMAI.

I did, and it's booting just fine.

> 
> Note that in case you do not know it, there is a guide for porting
> the
> I-pipe patch on new ARM platforms:
> 
> http://www.xenomai.org/index.php/I-pipe:ArmPorting

This is the HOWTO I followed to make the port.

Here is the code :

- Timer :

#ifdef CONFIG_IPIPE
# ifdef CONFIG_NO_IDLE_HZ
#  error "Dynamic tick timer not yet supported with IPIPE"
# endif /* CONFIG_NO_IDLE_HZ */

union tsc_reg
{
#ifdef __BIG_ENDIAN
    struct
    {
        unsigned long high;
        unsigned long low;
    };
#else
    struct
    {
        unsigned long low;
        unsigned long high;
    };
#endif
    unsigned long long full;
};

#ifdef CONFIG_SMP
static union tsc_reg tsc[NR_CPUS];
#else /* !CONFIG_SMP */
static union tsc_reg tsc[1];
#endif

int __ipipe_mach_timerint = INTC_TIMER1_BIT_INDEX;
int __ipipe_mach_timerstolen = 0;
unsigned __ipipe_mach_ticks_per_jiffy = LATCH;
int str8100_timer_initialised = 0;
#endif /* CONFIG_IPIPE */


#ifdef CONFIG_IPIPE
void ipipe_mach_update_tsc(void)
{
  union tsc_reg *local_tsc;
  unsigned long stamp;
  unsigned long flags;

  local_irq_save_hw(flags);
  local_tsc = &tsc[ipipe_processor_id()];
  stamp = str8100_read_timer_counter();
  if (stamp < local_tsc->low)
    local_tsc->high++;
  local_tsc->low = stamp;
  local_irq_restore_hw(flags);
}

void __ipipe_mach_acktimer(void)
{
#ifndef CONFIG_VIC_INTERRUPT
  write_seqlock(&xtime_lock);
  str8100_clear_timer_interrupt_status(__ipipe_mach_timerint);
  write_sequnlock(&xtime_lock);
#endif

  ipipe_mach_update_tsc();
}

notrace unsigned long long __ipipe_mach_get_tsc(void)
{
  if (likely(str8100_timer_initialised))
  {
    union tsc_reg *local_tsc, result;
    unsigned long stamp;

    local_tsc = &tsc[ipipe_processor_id()];

    __asm__ ("ldmia %1, %M0\n"
             : "=r"(result.full), "+&r"(local_tsc)
             : "m"(*local_tsc));
    barrier();
    stamp = str8100_read_timer_counter();
    if (stamp < result.low)
      result.high++;
    result.low = stamp;
    return result.full;
  }
  return 0;
}

#ifdef CONFIG_SMP
void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
  info->type = IPIPE_TSC_TYPE_NONE;
}
#else /* !CONFIG_SMP */
void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
  info->type = IPIPE_TSC_TYPE_FREERUNNING;
  info->u.fr.counter = (unsigned *)(SYSPA_TIMER_BASE_ADDR + 0x40);
  info->u.fr.mask = 0xFFFFFFFF;
  info->u.fr.tsc = &tsc->full;
}
#endif /* !CONFIG_SMP */

void __ipipe_mach_set_dec(unsigned long delay)
{
  unsigned long flags;

  if (delay > 8)
  {
    local_irq_save_hw(flags);
    TIMER1_MATCH_VALUE1_REG = TIMER1_COUNTER_REG + delay;
    local_irq_restore_hw(flags);
  }
  else
    ipipe_trigger_irq(__ipipe_mach_timerint);
}

unsigned long __ipipe_mach_get_dec(void)
{
  return (TIMER1_MATCH_VALUE1_REG - TIMER1_COUNTER_REG);
}

void __ipipe_mach_release_timer(void)
{
  __ipipe_mach_set_dec(__ipipe_mach_ticks_per_jiffy);
}

#endif /* CONFIG_IPIPE */

- Interrupts :

#ifdef CONFIG_IPIPE
void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs)
{
  // No cascaded interrupt using the VIC
}
#endif /* CONFIG_IPIPE */

Best regards,

-- 
Aubin REBILLAT

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[Gilles Chanteperdrix]

On 05/10/2012 06:04 PM, aubin.rebillat@domain.hid wrote:
> I'm not that experienced with initrd/initramfs and that was what the
> manufacturer recommended and i followed it so i can have support from
> them. But yes, at first, i think it can boot from another device.

Could you wrap your lines around 72 characters ? I have to do it for you
when I want to reply your posts.

> 
>>
>>> I will look into the OABI and EABI settings then. I will also set
>>> up
>>> an NFS file system to mount debian from and see what is happening.
>>>
>>> Thank you Gilles for your reply. I will keep posting about my
>>> progresses.
>>
>> The issue may simply well be that your timer code does not work.
>> Could
>> you post the code for your port? That is, the code you added to get
>> it
>> work with the I-pipe patch. 
>> Have you checked that linux timer is
>> still
>> ticking after Xenomai has been started?
> 
> No, i did not check that the linux timer is still ticking.
> But i think it is because parts of the init script are executed and
> it is a shell script calling several sub-processes.

If subprocesses were an issue, nobody would be able to run xenomai.

> Nevertheless, I will put some printk in the linux timer handler to be sure.
> 
>>
>> You can also try to boot with CONFIG_IPIPE but without
>> CONFIG_XENOMAI.
> 
> I did, and it's booting just fine.

Ok. Then it is really likely the timer code which is broken. As the only
difference when xenomai is started is that linux timer is handled by
xenomai.


> void ipipe_mach_update_tsc(void)
> {
>   union tsc_reg *local_tsc;
>   unsigned long stamp;
>   unsigned long flags;
> 
>   local_irq_save_hw(flags);
>   local_tsc = &tsc[ipipe_processor_id()];
>   stamp = str8100_read_timer_counter();
>   if (stamp < local_tsc->low)
>     local_tsc->high++;
>   local_tsc->low = stamp;
>   local_irq_restore_hw(flags);
> }

Since this code is called from the timer ack routine, the interrupts are
already off, so, you should not need local_irq_save_hw. On the other
hand, calling ipipe_mach_update_tsc in the timer ack routine adds to the
timer interrupt latency, so, should be done only if the time source is
wrapping really fast. As your timesource is a 32 bits timesource
(according to what you wrote in __ipipe_mach_get_tscinfo), it is
probably not wrapping fast, and you can call ipipe_mach_update_tsc from
linux timer interrupt.

> 
> void __ipipe_mach_acktimer(void)
> {
> #ifndef CONFIG_VIC_INTERRUPT
>   write_seqlock(&xtime_lock);
>   str8100_clear_timer_interrupt_status(__ipipe_mach_timerint);
>   write_sequnlock(&xtime_lock);
> #endif
> 
>   ipipe_mach_update_tsc();
> }

Wrong: you can not call write_seqlock from the acktimer routine. The
seqlock are reserved to usage by Linux. Also note that you should remove
the call to str8100_clear_timer_interrupt_status from Linux timer interrupt.


> void __ipipe_mach_set_dec(unsigned long delay)
> {
>   unsigned long flags;
> 
>   if (delay > 8)
>   {
>     local_irq_save_hw(flags);
>     TIMER1_MATCH_VALUE1_REG = TIMER1_COUNTER_REG + delay;
>     local_irq_restore_hw(flags);
>   }
>   else
>     ipipe_trigger_irq(__ipipe_mach_timerint);
> }

ipipe_mach_set_dec is called with interrupts already off, so there is no
need to call local_irq_save_hw/local_irq_restore_hw.

Also, from the sources I could gather (snakeos-sdk), the hardware timer
for str8100 is programmed in periodic, auto-reload mode. Obviously, when
CONFIG_IPIPE is on, you have to change this to make the timer run in
one-shot mode, as required by Xenomai.

> #ifdef CONFIG_IPIPE
> void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs)
> {
>   // No cascaded interrupt using the VIC
> }
> #endif /* CONFIG_IPIPE */

You probably do not need to define this function if you #define
ipipe_mach_irq_mux_p to always be 0.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[aubin.rebillat]

> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "aubin rebillat" <aubin.rebillat@domain.hid>
> Cc: xenomai@xenomai.org
> Envoyé: Jeudi 10 Mai 2012 18:34:38
> Objet: Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
> 
> On 05/10/2012 06:04 PM, aubin.rebillat@domain.hid wrote:
> > I'm not that experienced with initrd/initramfs and that was what
> > the
> > manufacturer recommended and i followed it so i can have support
> > from
> > them. But yes, at first, i think it can boot from another device.
> 
> Could you wrap your lines around 72 characters ? I have to do it for
> you
> when I want to reply your posts.

I will, sorry for the inconvenience.

> 
> > 
> >>
> >>> I will look into the OABI and EABI settings then. I will also set
> >>> up
> >>> an NFS file system to mount debian from and see what is
> >>> happening.
> >>>
> >>> Thank you Gilles for your reply. I will keep posting about my
> >>> progresses.
> >>
> >> The issue may simply well be that your timer code does not work.
> >> Could
> >> you post the code for your port? That is, the code you added to
> >> get
> >> it
> >> work with the I-pipe patch.
> >> Have you checked that linux timer is
> >> still
> >> ticking after Xenomai has been started?
> > 
> > No, i did not check that the linux timer is still ticking.
> > But i think it is because parts of the init script are executed and
> > it is a shell script calling several sub-processes.
> 
> If subprocesses were an issue, nobody would be able to run xenomai.
> 
>
> > Nevertheless, I will put some printk in the linux timer handler to
> > be sure.
> > 
> >>
> >> You can also try to boot with CONFIG_IPIPE but without
> >> CONFIG_XENOMAI.
> > 
> > I did, and it's booting just fine.
> 
> Ok. Then it is really likely the timer code which is broken. As the
> only
> difference when xenomai is started is that linux timer is handled by
> xenomai.
> 
> 
> > void ipipe_mach_update_tsc(void)
> > {
> >   union tsc_reg *local_tsc;
> >   unsigned long stamp;
> >   unsigned long flags;
> > 
> >   local_irq_save_hw(flags);
> >   local_tsc = &tsc[ipipe_processor_id()];
> >   stamp = str8100_read_timer_counter();
> >   if (stamp < local_tsc->low)
> >     local_tsc->high++;
> >   local_tsc->low = stamp;
> >   local_irq_restore_hw(flags);
> > }
> 
> Since this code is called from the timer ack routine, the interrupts
> are
> already off, so, you should not need local_irq_save_hw. On the other
> hand, calling ipipe_mach_update_tsc in the timer ack routine adds to
> the
> timer interrupt latency, so, should be done only if the time source
> is
> wrapping really fast. As your timesource is a 32 bits timesource
> (according to what you wrote in __ipipe_mach_get_tscinfo), it is
> probably not wrapping fast, and you can call ipipe_mach_update_tsc
> from
> linux timer interrupt.
> 
> > 
> > void __ipipe_mach_acktimer(void)
> > {
> > #ifndef CONFIG_VIC_INTERRUPT
> >   write_seqlock(&xtime_lock);
> >   str8100_clear_timer_interrupt_status(__ipipe_mach_timerint);
> >   write_sequnlock(&xtime_lock);
> > #endif
> > 
> >   ipipe_mach_update_tsc();
> > }
> 
> Wrong: you can not call write_seqlock from the acktimer routine. The
> seqlock are reserved to usage by Linux. Also note that you should
> remove
> the call to str8100_clear_timer_interrupt_status from Linux timer
> interrupt.

Actually, it's only if the Vector Interrupt Controller from the CNS2132
is not enabled, which is not my case. But at least i should erase this.

> 
> 
> > void __ipipe_mach_set_dec(unsigned long delay)
> > {
> >   unsigned long flags;
> > 
> >   if (delay > 8)
> >   {
> >     local_irq_save_hw(flags);
> >     TIMER1_MATCH_VALUE1_REG = TIMER1_COUNTER_REG + delay;
> >     local_irq_restore_hw(flags);
> >   }
> >   else
> >     ipipe_trigger_irq(__ipipe_mach_timerint);
> > }
> 
> ipipe_mach_set_dec is called with interrupts already off, so there is
> no
> need to call local_irq_save_hw/local_irq_restore_hw.
> 
> Also, from the sources I could gather (snakeos-sdk), the hardware
> timer
> for str8100 is programmed in periodic, auto-reload mode. Obviously,
> when
> CONFIG_IPIPE is on, you have to change this to make the timer run in
> one-shot mode, as required by Xenomai.

I did not know that it was required, i thought it was handy not to reprogram 
the timer each time.

> 
> > #ifdef CONFIG_IPIPE
> > void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs)
> > {
> >   // No cascaded interrupt using the VIC
> > }
> > #endif /* CONFIG_IPIPE */
> 
> You probably do not need to define this function if you #define
> ipipe_mach_irq_mux_p to always be 0.
>

I do, to avoid an undefined reference.

Nevertheless, thank you very much for all this.

When i developped the IPIPE code for this board i followed the
HOWTO but it's quite vague so I mostly read what has been done 
with other boards and what has been done with linux for this board 
to implement it.
Therefore, I'm clearly not aware of the interactions between Linux 
and Xenomai. I will definitely read the publications available on 
the Xenomai website.

Best regards,

-- 
REBILLAT Aubin

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[Gilles Chanteperdrix]

On 05/10/2012 07:29 PM, aubin.rebillat@domain.hid wrote:
>> Also, from the sources I could gather (snakeos-sdk), the hardware
>> timer
>> for str8100 is programmed in periodic, auto-reload mode. Obviously,
>> when
>> CONFIG_IPIPE is on, you have to change this to make the timer run in
>> one-shot mode, as required by Xenomai.
> 
> I did not know that it was required, i thought it was handy not to reprogram 
> the timer each time.

That is likely your problem. You can not assume that a decreasing
counter is all of a sudden a free-running counter with match register.
You have to find the processor datasheet and look at how its registers
must be programmed to run in one-shot mode, if at all possible.

Note that since linux 2.6.24, linux itself switched to one-shot mode,
because it allows high resolution software timers.

>>> #ifdef CONFIG_IPIPE
>>> void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs)
>>> {
>>>   // No cascaded interrupt using the VIC
>>> }
>>> #endif /* CONFIG_IPIPE */
>>
>> You probably do not need to define this function if you #define
>> ipipe_mach_irq_mux_p to always be 0.
>>
> 
> I do, to avoid an undefined reference.

If you #define ipipe_mach_irq_mux_p(irq) 0

The compilers optimizes away the function call, and there is no
undefined reference. At least with current compilers.

> 
> Nevertheless, thank you very much for all this.
> 
> When i developped the IPIPE code for this board i followed the
> HOWTO but it's quite vague so I mostly read what has been done 
> with other boards and what has been done with linux for this board 
> to implement it.

This HOWTO assumes that you understand what you are doing. No HOWTO
guide is a substitute for that unfortunately.

> Therefore, I'm clearly not aware of the interactions between Linux 
> and Xenomai. I will definitely read the publications available on 
> the Xenomai website.

Well, it is not all that complicated. When xenomai wants to program the
timer it calls ipipe_mach_set_dec, and when a timer interrupt happens,
ipipe_mach_acktimer is called, whether the timer is handled by Linux, or
it has been taken over by Xenomai.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[aubin.rebillat]

Hi Gilles,

I've followed your advices and reimplemented the timer management. 
Now it's an up counter wrapping to 0 on overflow, it uses a match 
register to trigger the interrupt and it's never disabled.

I've also cleaned the code : suppressed linux specific calls, move 
update_tsc to linux handler, etc... as you advised me.

Then, I tested this with both CONFIG_IPIPE and CONFIG_XENOMAI 
disabled, and it's working fine.
I also tested with only CONFIG_XENOMAI disabled and it's still
working as expected.

Nevertheless, the issue is still the same. It hangs after starting
the init program. 

After investigations, the problem is that __ipipe__mach_set_dec is 
never called after Xenomai has taken control of the  timer. The last 
timer update was done in rthal_timer_calibrate and it effectively 
triggers an interrupt after MAXINT ticks (I've put a printk in the 
linux timer handler and it's displayed after a few time).

My problem is that i don't really understand the timer management by
Xenomai. As i understood each skin has its own timers and Xenomai
manages to trigger them when expected. But what code is managing the
linux timer ?
I'm expecting to probably have errors in my ipipe code that's why i'm
asking this, to follow the execution and see where it is broken.

Thank you very much,

-- 
Aubin REBILLAT

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[Gilles Chanteperdrix]

On 05/14/2012 06:13 PM, aubin.rebillat@domain.hid wrote:
> Hi Gilles,
> 
> I've followed your advices and reimplemented the timer management. 
> Now it's an up counter wrapping to 0 on overflow, it uses a match 
> register to trigger the interrupt and it's never disabled.
> 
> I've also cleaned the code : suppressed linux specific calls, move 
> update_tsc to linux handler, etc... as you advised me.
> 
> Then, I tested this with both CONFIG_IPIPE and CONFIG_XENOMAI 
> disabled, and it's working fine.
> I also tested with only CONFIG_XENOMAI disabled and it's still
> working as expected.
> 
> Nevertheless, the issue is still the same. It hangs after starting
> the init program. 
> 
> After investigations, the problem is that __ipipe__mach_set_dec is 
> never called after Xenomai has taken control of the  timer. The last 
> timer update was done in rthal_timer_calibrate and it effectively 
> triggers an interrupt after MAXINT ticks (I've put a printk in the 
> linux timer handler and it's displayed after a few time).
> 
> My problem is that i don't really understand the timer management by
> Xenomai. As i understood each skin has its own timers and Xenomai
> manages to trigger them when expected. But what code is managing the
> linux timer ?
> I'm expecting to probably have errors in my ipipe code that's why i'm
> asking this, to follow the execution and see where it is broken.
> 
> Thank you very much,


If the interrupt triggers only once, it probably means that the timer
needs some acknowledgement that must be put in __ipipe_mach_acktimer.

The code managing Linux timer works and has been validated on all the
port so far. So, the thing probably at fault is the timer management
code in the I-pipe patch. Do not worry for Linux timer interrupt, only
take care of ipipe_mach_set_dec and ipipe_mach_acktimer.

Also, if some timer programming is done in linux timer interrupt, it
should not be done once ipipe_mach_timerstolen is true.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[Gilles Chanteperdrix]

On 05/14/2012 06:18 PM, Gilles Chanteperdrix wrote:
> On 05/14/2012 06:13 PM, aubin.rebillat@domain.hid wrote:
>> Hi Gilles,
>>
>> I've followed your advices and reimplemented the timer management. 
>> Now it's an up counter wrapping to 0 on overflow, it uses a match 
>> register to trigger the interrupt and it's never disabled.
>>
>> I've also cleaned the code : suppressed linux specific calls, move 
>> update_tsc to linux handler, etc... as you advised me.
>>
>> Then, I tested this with both CONFIG_IPIPE and CONFIG_XENOMAI 
>> disabled, and it's working fine.
>> I also tested with only CONFIG_XENOMAI disabled and it's still
>> working as expected.
>>
>> Nevertheless, the issue is still the same. It hangs after starting
>> the init program. 
>>
>> After investigations, the problem is that __ipipe__mach_set_dec is 
>> never called after Xenomai has taken control of the  timer. The last 
>> timer update was done in rthal_timer_calibrate and it effectively 
>> triggers an interrupt after MAXINT ticks (I've put a printk in the 
>> linux timer handler and it's displayed after a few time).
>>
>> My problem is that i don't really understand the timer management by
>> Xenomai. As i understood each skin has its own timers and Xenomai
>> manages to trigger them when expected. But what code is managing the
>> linux timer ?
>> I'm expecting to probably have errors in my ipipe code that's why i'm
>> asking this, to follow the execution and see where it is broken.
>>
>> Thank you very much,
> 
> 
> If the interrupt triggers only once, it probably means that the timer
> needs some acknowledgement that must be put in __ipipe_mach_acktimer.
> 
> The code managing Linux timer works and has been validated on all the
> port so far. So, the thing probably at fault is the timer management
> code in the I-pipe patch. Do not worry for Linux timer interrupt, only
> take care of ipipe_mach_set_dec and ipipe_mach_acktimer.
> 
> Also, if some timer programming is done in linux timer interrupt, it
> should not be done once ipipe_mach_timerstolen is true.
> 

To summarize, there are two states in the system:

Either Linux is handling the timer, in which case:
- ipipe_mach_timerstolen == 0
- ipipe_mach_acktimer is called to acknowledge the linux timer interrupt
- linux timer interrupt routine is called for each timer interrupt, HZ
times a second, and in charge to reprogram the timer hardware if it
needs to be reprogrammed

Either xenomai is handling the timer, in which case:
- ipipe_mach_timerstolen == 1
- ipipe_mach_acktimer is called to acknowledge the xenomai timer interrupt
- ipipe_mach_set_dec is called by xenomai to program the next timer
interrupt

linux timer interrupt is called HZ times a second, but should not touch
anything related to the timer hardware, because that part is handled by
xenomai now (vie ipipe_mach_set_dec).

if CONFIG_IPIPE is enabled and CONFIG_XENOMI is disabled, only the first
state happens.

if CONFIG_XENOMAI is enabled, as soon as xenomai is started, we enter
the second state.

-- 
                                                                Gilles.

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[aubin.rebillat]

> To summarize, there are two states in the system:
> 
> Either Linux is handling the timer, in which case:
> - ipipe_mach_timerstolen == 0
> - ipipe_mach_acktimer is called to acknowledge the linux timer
> interrupt
> - linux timer interrupt routine is called for each timer interrupt,
> HZ
> times a second, and in charge to reprogram the timer hardware if it
> needs to be reprogrammed
> 
> Either xenomai is handling the timer, in which case:
> - ipipe_mach_timerstolen == 1
> - ipipe_mach_acktimer is called to acknowledge the xenomai timer
> interrupt
> - ipipe_mach_set_dec is called by xenomai to program the next timer
> interrupt
> 
> linux timer interrupt is called HZ times a second, but should not
> touch
> anything related to the timer hardware, because that part is handled
> by
> xenomai now (vie ipipe_mach_set_dec).
> 
> if CONFIG_IPIPE is enabled and CONFIG_XENOMI is disabled, only the
> first
> state happens.
> 
> if CONFIG_XENOMAI is enabled, as soon as xenomai is started, we enter
> the second state.
> 

Ok this is pretty much what I understood but my problem was that 
ipipe_mach_set_dec was never called once the skin services were started. 

I really didn't see how my code could influence this so I checked the 
bug fixes for Xenomai 2.5 and i found one which was not fixed in my 
version of xenomai. The bug was the return value of rthal_timer_request.

I applied the fix and Xenomai is now booting fine on my TS-7553.

I will now perform tests on it to insure the stability of the system and 
the latency.

Thank you very much for your help,

Best regards,

-- 
Aubin REBILLAT

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[Gilles Chanteperdrix]

On 05/15/2012 04:34 PM, aubin.rebillat@domain.hid wrote:
> I really didn't see how my code could influence this so I checked the 
> bug fixes for Xenomai 2.5 and i found one which was not fixed in my 
> version of xenomai. The bug was the return value of rthal_timer_request.

Oh, I missed that, don't do that. Please use Xenomai 2.6. It is backward
compatible with old I-pipe patches.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[Gilles Chanteperdrix]

On 05/10/2012 03:26 PM, aubin.rebillat@domain.hid wrote:
> Hello, 
> 
> I am trying to port Xenomai on the TS-7553 SBC from Technologic systems, based on the ECONA CNS2132 (STAR8132) from Cavium networks (250 MHz arm922t).
> A Linux kernel is available for this board, version 2.6.24.4, which is running fine.
> I patched this kernel with adeos-ipipe-2.6.24-arm-1.9-01.patch and I implemented all the IPIPE code for the CNS2132 and everything is compiling and booting fine.

Note that the following page:
http://www.openembedded.org/wiki/TS-7500

Proposes patches for linux 2.6.35, which is really, really, really more
current than 2.6.24, and for which an I-pipe patch also exists.

I mean, with 2.6.24, you may find bugs we do not even remember, because
they were fixed such a long time ago.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[aubin.rebillat]

> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
> À: "aubin rebillat" <aubin.rebillat@domain.hid>
> Cc: xenomai@xenomai.org
> Envoyé: Jeudi 10 Mai 2012 19:28:46
> Objet: Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
> 
> On 05/10/2012 03:26 PM, aubin.rebillat@domain.hid wrote:
> > Hello,
> > 
> > I am trying to port Xenomai on the TS-7553 SBC from Technologic
> > systems, based on the ECONA CNS2132 (STAR8132) from Cavium
> > networks (250 MHz arm922t).
> > A Linux kernel is available for this board, version 2.6.24.4, which
> > is running fine.
> > I patched this kernel with adeos-ipipe-2.6.24-arm-1.9-01.patch and
> > I implemented all the IPIPE code for the CNS2132 and everything is
> > compiling and booting fine.
> 
> Note that the following page:
> http://www.openembedded.org/wiki/TS-7500
> 
> Proposes patches for linux 2.6.35, which is really, really, really
> more
> current than 2.6.24, and for which an I-pipe patch also exists.
> 
> I mean, with 2.6.24, you may find bugs we do not even remember,
> because
> they were fixed such a long time ago.
> 

I preferred to use the version 2.6.24  which is shipped with the board 
because the manufacturer can provide support in case of trouble.
But, I compiled and tested the version 2.6.35 and it's running fine at 
first but the dmesg output is corrupted with a lot of "BAD IRQ".
I thought that this version was not really stable yet and I don't have
enough time in my project to ensure it. That's why I preferred to use
the version 2.6.24.

If a bug is happening with our application, I will definitely move
to the most recent one.

Best regards,

-- 
REBILLAT Aubin

Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC

[Gilles Chanteperdrix]

On 05/10/2012 07:38 PM, aubin.rebillat@domain.hid wrote:
>> De: "Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org>
>> À: "aubin rebillat" <aubin.rebillat@domain.hid>
>> Cc: xenomai@xenomai.org
>> Envoyé: Jeudi 10 Mai 2012 19:28:46
>> Objet: Re: [Xenomai-help] Xenomai on the TS-7553 ARM SBC
>>
>> On 05/10/2012 03:26 PM, aubin.rebillat@domain.hid wrote:
>>> Hello,
>>>
>>> I am trying to port Xenomai on the TS-7553 SBC from Technologic
>>> systems, based on the ECONA CNS2132 (STAR8132) from Cavium
>>> networks (250 MHz arm922t).
>>> A Linux kernel is available for this board, version 2.6.24.4, which
>>> is running fine.
>>> I patched this kernel with adeos-ipipe-2.6.24-arm-1.9-01.patch and
>>> I implemented all the IPIPE code for the CNS2132 and everything is
>>> compiling and booting fine.
>>
>> Note that the following page:
>> http://www.openembedded.org/wiki/TS-7500
>>
>> Proposes patches for linux 2.6.35, which is really, really, really
>> more
>> current than 2.6.24, and for which an I-pipe patch also exists.
>>
>> I mean, with 2.6.24, you may find bugs we do not even remember,
>> because
>> they were fixed such a long time ago.
>>
> 
> I preferred to use the version 2.6.24  which is shipped with the board 
> because the manufacturer can provide support in case of trouble.

As soon as you patch with the I-pipe patch, the manufacturer can answer
to your support requests that you are not using its kernel.

> But, I compiled and tested the version 2.6.35 and it's running fine at 
> first but the dmesg output is corrupted with a lot of "BAD IRQ".
> I thought that this version was not really stable yet and I don't have
> enough time in my project to ensure it. That's why I preferred to use
> the version 2.6.24.
> 
> If a bug is happening with our application, I will definitely move
> to the most recent one.

Well, I had a look at the patches for 2.6.35, and they really mess with
things with which they should not (cache and TLB handling for instance).
If you intend to do some serious work with this platform, you should
really consider doing a clean linux port, or get some specialist to do
it. Otherwise this will byte you sooner or later.

-- 
					    Gilles.