[Xenomai-help] Marvell sheeva support

[Xenomai-help] Marvell sheeva support

[Tim Cussins]

Hi all,

We're looking at migrating to one of Marvell's MV88F series SOC's, and
are very keen to deploy Xenomai as part of our solution.

I noticed Sergey Didenko was looking at this a few months back and
things looked to be ok - has his (or anyone else's) work made it into a
stable release?

I will be able to assist in about a fortnight if that would be useful
for squaring that work away.

Let me know if I can help!

Cheers,
Tim

Re: [Xenomai-help] Marvell sheeva support

[Gilles Chanteperdrix]

Tim Cussins wrote:
> Hi all,
> 
> We're looking at migrating to one of Marvell's MV88F series SOC's, and
> are very keen to deploy Xenomai as part of our solution.
> 
> I noticed Sergey Didenko was looking at this a few months back and
> things looked to be ok - has his (or anyone else's) work made it into a
> stable release?
> 
> I will be able to assist in about a fortnight if that would be useful
> for squaring that work away.
> 
> Let me know if I can help!

We are interested. I seem to remember that Serguey had unexplained
latencies issues, so, if you start with his work, please bear this in
mind, there was probably something wrong with his port. A guide
explaining how to port the I-pipe patch on ARM exists:
http://www.xenomai.org/index.php/I-pipe:ArmPorting

The section about chained GPIOs irqs is outdated, if your platform has
some, I will explain how it should be implemented.

Please start from the I-pipe git (git://git.denx.de/ipipe-2.6.git),
merging it with the branch you will use if needed, so that you can
submit a patch only containing the modifications necessary for the
Sheeva platform.

We can also provide you with a root filesystem for validating this platform.

-- 
					    Gilles.

Re: [Xenomai-help] Marvell sheeva support

[Philippe Gerum]

On Thu, 2010-07-15 at 13:53 +0200, Gilles Chanteperdrix wrote:
> Tim Cussins wrote:
> > Hi all,
> > 
> > We're looking at migrating to one of Marvell's MV88F series SOC's, and
> > are very keen to deploy Xenomai as part of our solution.
> > 
> > I noticed Sergey Didenko was looking at this a few months back and
> > things looked to be ok - has his (or anyone else's) work made it into a
> > stable release?
> > 
> > I will be able to assist in about a fortnight if that would be useful
> > for squaring that work away.
> > 
> > Let me know if I can help!
> 
> We are interested. I seem to remember that Serguey had unexplained
> latencies issues, so, if you start with his work, please bear this in
> mind, there was probably something wrong with his port. A guide
> explaining how to port the I-pipe patch on ARM exists:
> http://www.xenomai.org/index.php/I-pipe:ArmPorting
> 
> The section about chained GPIOs irqs is outdated, if your platform has
> some, I will explain how it should be implemented.
> 
> Please start from the I-pipe git (git://git.denx.de/ipipe-2.6.git),
> merging it with the branch you will use if needed, so that you can
> submit a patch only containing the modifications necessary for the
> Sheeva platform.
> 
> We can also provide you with a root filesystem for validating this platform.
> 

You can also use the patch below as a starting point for your port:
http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch

caveats:

- it is based on an old kernel release, and moving to 2.6.3x would
require some work. If you need so, then you should merge the
arm-dependent bits from the patch above with the generic I-pipe bits
from a newer release as available here (e.g. 2.6.33):
http://download.gna.org/adeos/patches/v2.6/arm/

- the fcse implementation in that patch won't work with the l2 outer
cache enabled. The two options have been made mutually exclusive via
Kconfig.

- you should use Xenomai 2.5.3 or above to get this running.

As a reference point, the worst-case scheduling latency for user-space
threads, observed on a mv88f6290 using that patch with fcse enabled (no
l2), is below 70 us.

HTH,

-- 
Philippe.

Re: [Xenomai-help] Marvell sheeva support

[Tim Cussins]

Hi guys,

I hope you don't mind if I reply to you together.

On Thu, 2010-07-15 at 18:11 +0200, Philippe Gerum wrote:
> On Thu, 2010-07-15 at 13:53 +0200, Gilles Chanteperdrix wrote:
> > Tim Cussins wrote:
> > > Hi all,
> > > 
> > > We're looking at migrating to one of Marvell's MV88F series SOC's, and
> > > are very keen to deploy Xenomai as part of our solution.
> > > 
> > > I noticed Sergey Didenko was looking at this a few months back and
> > > things looked to be ok - has his (or anyone else's) work made it into a
> > > stable release?
> > > 
> > > I will be able to assist in about a fortnight if that would be useful
> > > for squaring that work away.
> > > 
> > > Let me know if I can help!
> > 
> > We are interested. I seem to remember that Serguey had unexplained
> > latencies issues, so, if you start with his work, please bear this in
> > mind, there was probably something wrong with his port. A guide
> > explaining how to port the I-pipe patch on ARM exists:
> > http://www.xenomai.org/index.php/I-pipe:ArmPorting

> > The section about chained GPIOs irqs is outdated, if your platform has
> > some, I will explain how it should be implemented.
> > 
> > Please start from the I-pipe git (git://git.denx.de/ipipe-2.6.git),
> > merging it with the branch you will use if needed, so that you can
> > submit a patch only containing the modifications necessary for the
> > Sheeva platform.

Not a problem :)

> > We can also provide you with a root filesystem for validating this platform.

That would be brilliant. I imagine I'll be iterating though uImages on
an SD card loaded with your rootfs. Sound ok? Let me know how to obtain
the rootfs (or better, show me how you prefer to do it, so I learn
something! Ta.)

> 
> You can also use the patch below as a starting point for your port:
> http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch

I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't
apply cleanly (well, fails :P). Am I approaching this the wrong way?
Also tried chucking the patch into the xenomai tree and getting
prepare_kernel.sh to try: still no joy.

> caveats:
> 
> - it is based on an old kernel release, and moving to 2.6.3x would
> require some work. If you need so, then you should merge the
> arm-dependent bits from the patch above with the generic I-pipe bits
> from a newer release as available here (e.g. 2.6.33):
> http://download.gna.org/adeos/patches/v2.6/arm/

Building and running the current patch (2.6.29) seems like a reasonable
starting point, but producing a 2.6.33 patch seems like the right thing
to do...

> - the fcse implementation in that patch won't work with the l2 outer
> cache enabled. The two options have been made mutually exclusive via
> Kconfig.

Out of interest: is this a fundamental limitation, or do you believe
that the L2 and FCSE might be happy together after a bit of work?

>  you should use Xenomai 2.5.3 or above to get this running.
> 
> As a reference point, the worst-case scheduling latency for user-space
> threads, observed on a mv88f6290 using that patch with fcse enabled (no
> l2), is below 70 us.

That's brilliant. Our requirements aren't for super-low latency, but
definitely realtime. We might go with L2 and no FCSE if the latency is
still ok. Just FYI :)

> HTH,
> 

Yep, thanks. I'll be able to do this work: I'm just trying to estimate
how long it'll take me to get up to speed and produce a patch for 2.6.33.
Any thoughts on the volume and nature of the work remaining would be helpful.

Cheers,
Tim

Re: [Xenomai-help] Marvell sheeva support

[Gilles Chanteperdrix]

Tim Cussins wrote:
>>> We can also provide you with a root filesystem for validating this platform.
> 
> That would be brilliant. I imagine I'll be iterating though uImages on
> an SD card loaded with your rootfs. Sound ok? Let me know how to obtain
> the rootfs (or better, show me how you prefer to do it, so I learn
> something! Ta.)

You will find the rootfs for orion SOCs, here:
http://www.xenomai.org/~gch/pub/rootfs-orion.tar.bz2

Edit etc/inittab to modify the serial console it needs (if it is not
/dev/ttyS0 running at 115200 bauds). The rootfs is meant to be booted by
NFS with the kernel IP auto-configuration, so, if you want to boot it on
an SD card, you will have to connect to the serial console once the
board is booted, and run "udhcpc" to configure the network by DHCP, or
use ifconfig to configure it by hand, then launch "telnetd" to be able
to connect to that board through telnet (if the kernel booted by NFS,
the telnet server will have been launched automatically)

In a first telnet session, run:
latency
In a second telnet session, if you have FCSE disabled, run:
dohell
if you have FCSE enabled, run:
noltp_hell 14400
(14400 means that you will generate some load during 14400s, that is 4
hours).
When either noltp_hell or dohell displays the line:
Listening on any address 5566
On the host, run:
netcat <target-ip> 5566 > /dev/null

Now you can return to the telnet session running latency. When the test
is finished the latency program should stop.

As for generating the root filesystem, it is not that it is really hard,
but it is a bit tedious. So, we made a tool to build a root filesystem
which suits our needs, that is testing Xenomai under load. I have just
finished working on a version of this tool (called mkrootfs, but I think
we should find a better name, as this one already exists) user-friendly
enough to be published. Currently, it is still lacking a documentation.
You will find it here:

http://www.xenomai.org/~gch/pub/mkrootfs.tar.bz2

However, to use it, you will need a few explanations. It is based on
Kbuild, the Linux kernel build system, so, it will build the same way.
Create a build directory, cd to it, then run:

make -C /path/to/mkrootfs O=`pwd` xconfig

Tweak the configuration. Then run:
make

It should build everything.

It does not download and patch the sources of the packages it uses, you
have to do this yourself, then pass the path where to look for them to
the configuration system. We use standard versions of the packages,
except for LTP, which we modified a bit to run on low-end platforms, and
which you can find here:

http://www.xenomai.org/~gch/ltp-20081130-patched.tar.bz2


>> You can also use the patch below as a starting point for your port:
>> http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch
> 
> I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't
> apply cleanly (well, fails :P). Am I approaching this the wrong way?
> Also tried chucking the patch into the xenomai tree and getting
> prepare_kernel.sh to try: still no joy.

It probably does not apply to vanilla because vanilla has no support for
the Sheevaplug board. Or am I missing something?

-- 
					    Gilles.

Re: [Xenomai-help] Marvell sheeva support

[Tim Cussins]

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

Hi guys,

Managed to get started on the Sheevaplug/xenomai stuff:
  Used mkrootfs. Cool.
  Massaged the mv88fxxxx patch so that it builds with 2.6.33.
  Can't log into the device to run tests. Augh.

Details below! :P

On Wed, 2010-07-21 at 08:23 +0200, Gilles Chanteperdrix wrote:
> Tim Cussins wrote:
> >>> We can also provide you with a root filesystem for validating this platform.
> > 
> > That would be brilliant. I imagine I'll be iterating though uImages on
> > an SD card loaded with your rootfs. Sound ok? Let me know how to obtain
> > the rootfs (or better, show me how you prefer to do it, so I learn
> > something! Ta.)
> 
> You will find the rootfs for orion SOCs, here:
> http://www.xenomai.org/~gch/pub/rootfs-orion.tar.bz2
> 
> Edit etc/inittab to modify the serial console it needs (if it is not
> /dev/ttyS0 running at 115200 bauds). The rootfs is meant to be booted by
> NFS with the kernel IP auto-configuration, so, if you want to boot it on
> an SD card, you will have to connect to the serial console once the
> board is booted, and run "udhcpc" to configure the network by DHCP, or
> use ifconfig to configure it by hand, then launch "telnetd" to be able
> to connect to that board through telnet (if the kernel booted by NFS,
> the telnet server will have been launched automatically)
> 
> In a first telnet session, run:
> latency
> In a second telnet session, if you have FCSE disabled, run:
> dohell
> if you have FCSE enabled, run:
> noltp_hell 14400
> (14400 means that you will generate some load during 14400s, that is 4
> hours).
> When either noltp_hell or dohell displays the line:
> Listening on any address 5566
> On the host, run:
> netcat <target-ip> 5566 > /dev/null
> 
> Now you can return to the telnet session running latency. When the test
> is finished the latency program should stop.
> 
> As for generating the root filesystem, it is not that it is really hard,
> but it is a bit tedious. So, we made a tool to build a root filesystem
> which suits our needs, that is testing Xenomai under load. I have just
> finished working on a version of this tool (called mkrootfs, but I think
> we should find a better name, as this one already exists) user-friendly
> enough to be published. Currently, it is still lacking a documentation.
> You will find it here:
> 
> http://www.xenomai.org/~gch/pub/mkrootfs.tar.bz2
> 
> However, to use it, you will need a few explanations. It is based on
> Kbuild, the Linux kernel build system, so, it will build the same way.
> Create a build directory, cd to it, then run:
> 
> make -C /path/to/mkrootfs O=`pwd` xconfig
> 
> Tweak the configuration. Then run:
> make
> 
> It should build everything.
> 
> It does not download and patch the sources of the packages it uses, you
> have to do this yourself, then pass the path where to look for them to
> the configuration system. We use standard versions of the packages,
> except for LTP, which we modified a bit to run on low-end platforms, and
> which you can find here:
> 
> http://www.xenomai.org/~gch/ltp-20081130-patched.tar.bz2


I've had a good play with mkrootfs - nice. I had to make a couple of
changes to meet my needs (and system, ubuntu 10.04). Is there a git repo
for mkrootfs that I can base my patches on? They're very small btw. More
on that off-list if you want.

> 
> >> You can also use the patch below as a starting point for your port:
> >> http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch
> > 
> > I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't
> > apply cleanly (well, fails :P). Am I approaching this the wrong way?
> > Also tried chucking the patch into the xenomai tree and getting
> > prepare_kernel.sh to try: still no joy.
> 
> It probably does not apply to vanilla because vanilla has no support for
> the Sheevaplug board. Or am I missing something?

Well, I don't think so. Some hunks are expecting lines of context that
simply don't exist in 2.6.29 == fail.

I took the mv88f6290 patch and bullied it into applying to vanilla
2.6.29. Built ok, but was at home and no way to test, so I just got on
with migrating it to 2.6.33. That seems to be done - check the 2.6.33
boot output:
  
   ...
  I-pipe: Domain Xenomai registered.
  Xenomai: hal/arm started.
  Xenomai: scheduling class idle registered.
  Xenomai: scheduling class rt registered.
  Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
  Xenomai: starting native API services.
  Xenomai: starting POSIX services.
  Xenomai: starting RTDM services.
   ...

Full boot output is attached FYI.

However, I've got a problem with busybox/getty and /dev/ttyS0 so I can't
log in via console OR telnet. Once that's solved, I'll be able to run
the xenomai tests. (In case you've seen it before - /var/log/messages is
slowly filling with:

Aug 11 16:03:36 init: starting pid 638, tty '/dev/ttyS0': '/sbin/getty
115200 ttyS0'
Aug 11 16:03:36 getty[638]: ttyS0: TCGETS: Inappropriate ioctl for
device

)

Cheers,
Tim


[-- Attachment #2: boot-output --]
[-- Type: text/plain, Size: 6349 bytes --]

Linux version 2.6.33 (timc@domain.hid) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #3 PREEMPT Wed Aug 11 14:30:06 BST 2010
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Marvell SheevaPlug Reference Board
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
Kernel command line: console=ttyS0,115200 mtdparts=orion_nand:0x400000@domain.hid),
0x8000000@domain.hid) root=/dev/nfs rw ip=dhcp nfsroo
t=10.2.7.70:/home/timc/nfs/orion-rootfs
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 256MB 256MB = 512MB total
Memory: 513152KB available (4548K code, 1546K data, 120K init, 0K highmem)
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:114
I-pipe 1.17-02: pipeline enabled.
Console: colour dummy device 80x30
Calibrating delay loop... 1192.75 BogoMIPS (lpj=5963776)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
Kirkwood: MV88F6281-A0, TCLK=200000000.
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
cfg80211: Using static regulatory domain info
cfg80211: Regulatory domain: 00
    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
    (2457000 KHz - 2482000 KHz @ 20000 KHz), (600 mBi, 2000 mBm)
    (2474000 KHz - 2494000 KHz @ 20000 KHz), (600 mBi, 2000 mBm)
    (5170000 KHz - 5250000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
    (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
cfg80211: Calling CRDA to update world regulatory domain
Switching to clocksource orion_clocksource
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
I-pipe: Domain Xenomai registered.
Xenomai: hal/arm started.
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
msgmni has been set to 1002
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
console [ttyS0] enabled
loop: module loaded
NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 2330 at 0x000012340000
Bad eraseblock 3396 at 0x00001a880000
7 cmdlinepart partitions found on MTD device orion_nand
Creating 7 MTD partitions on "orion_nand":
0x000000100000-0x000000500000 : "uImage-default"
0x000000500000-0x000000900000 : "uImage-fallback"
0x000000900000-0x000000d00000 : "uImage-main"
0x000000d00000-0x000008d00000 : "rootfs-fallback"
0x000008d00000-0x000010d00000 : "rootfs-main"
0x000010d00000-0x000011d00000 : "persistent"
0x000011d00000-0x000012d00000 : "update"
MV-643xx 10/100/1000 ethernet driver version 1.4
mv643xx_eth smi: probed
net eth0: port 0 with MAC address 00:50:43:01:50:eb
libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
orion-ehci orion-ehci.0: Marvell Orion EHCI
orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1
orion-ehci orion-ehci.0: irq 19, io mem 0xf1050000
orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver ums-datafab
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
mice: PS/2 mouse device common for all mice
rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0
i2c /dev entries driver
cpuidle: using governor ladder
cpuidle: using governor menu
mmc0: mvsdio driver initialized, lacking card detect (fall back to polling)
Registered led device: plug:green:health
mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver
mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver
mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy )
mv_xor mv_xor.2: Marvell XOR: ( xor cpy )
mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy )
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using timer interrupt.
TCP cubic registered
NET: Registered protocol family 17
lib80211: common routines for IEEE802.11 drivers
rtc-mv rtc-mv: setting system clock to 2010-08-11 13:58:13 UTC (1281535093)
Sending DHCP requests .
eth0: link up, 1000 Mb/s, full duplex, flow control disabled
., OK
IP-Config: Got DHCP answer from 10.2.7.70, my address is 10.2.9.37
IP-Config: Complete:
     device=eth0, addr=10.2.9.37, mask=255.255.0.0, gw=10.2.3.7,
     host=10.2.9.37, domain=linn.co.uk, nis-domain=(none),
     bootserver=10.2.7.70, rootserver=10.2.7.70, rootpath=
Looking up port of RPC 100003/2 on 10.2.7.70
Looking up port of RPC 100005/1 on 10.2.7.70
VFS: Mounted root (nfs filesystem) on device 0:13.
Freeing init memory: 120K
nfs: server 10.2.7.70 not responding, still trying
nfs: server 10.2.7.70 OK

Re: [Xenomai-help] Marvell sheeva support

[Gilles Chanteperdrix]

Tim Cussins wrote:
> I've had a good play with mkrootfs - nice. I had to make a couple of
> changes to meet my needs (and system, ubuntu 10.04). Is there a git repo
> for mkrootfs that I can base my patches on? They're very small btw. More
> on that off-list if you want.

Yes, there is a git repo for mkrootfs, it is not public yet, which does
not really make sense, since I talked about it publicly. I am going to
make it public. I just do not want to pollute the Xenomai mailing list
with the mkrootfs maintenance, so, we will have to set-up a mailing list
elsewhere.

> 
>>>> You can also use the patch below as a starting point for your port:
>>>> http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch
>>> I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't
>>> apply cleanly (well, fails :P). Am I approaching this the wrong way?
>>> Also tried chucking the patch into the xenomai tree and getting
>>> prepare_kernel.sh to try: still no joy.
>> It probably does not apply to vanilla because vanilla has no support for
>> the Sheevaplug board. Or am I missing something?
> 
> Well, I don't think so. Some hunks are expecting lines of context that
> simply don't exist in 2.6.29 == fail.

Well yes, that is exactly my point: the patch is made to be applied to
another kernel tree, a marvell specific kernel tree.

> 
> I took the mv88f6290 patch and bullied it into applying to vanilla
> 2.6.29. Built ok, but was at home and no way to test, so I just got on
> with migrating it to 2.6.33. That seems to be done - check the 2.6.33
> boot output:
>   
>    ...
>   I-pipe: Domain Xenomai registered.
>   Xenomai: hal/arm started.
>   Xenomai: scheduling class idle registered.
>   Xenomai: scheduling class rt registered.
>   Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
>   Xenomai: starting native API services.
>   Xenomai: starting POSIX services.
>   Xenomai: starting RTDM services.
>    ...
> 
> Full boot output is attached FYI.
> 
> However, I've got a problem with busybox/getty and /dev/ttyS0 so I can't
> log in via console OR telnet. Once that's solved, I'll be able to run
> the xenomai tests. (In case you've seen it before - /var/log/messages is
> slowly filling with:

There are two ptys style, the BSD one corresponding to the
CONFIG_LEGACY_PTYS in kernel configuration, and the new style,
corresponding to the CONFIG_UNIX98_PTYS. busybox uses one style by
default (I believe it is the new style), but will not work if your
kernel is only configured for the other style. Anyway, you have to check
that the busybox and kernel configurations match. This is probably the
reason why telnetd does not work.

As for the reason why ttyS0 is not working, well, it is strange. Maybe
something missing in the kernel configuration? Could you send me your
.config?

-- 
					    Gilles.

Re: [Xenomai-help] Marvell sheeva support

[Tim Cussins]

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

On Wed, 2010-08-11 at 17:25 +0200, Gilles Chanteperdrix wrote:
> Tim Cussins wrote:
> > I've had a good play with mkrootfs - nice. I had to make a couple of
> > changes to meet my needs (and system, ubuntu 10.04). Is there a git repo
> > for mkrootfs that I can base my patches on? They're very small btw. More
> > on that off-list if you want.
> 
> Yes, there is a git repo for mkrootfs, it is not public yet, which does
> not really make sense, since I talked about it publicly. I am going to
> make it public. I just do not want to pollute the Xenomai mailing list
> with the mkrootfs maintenance, so, we will have to set-up a mailing list
> elsewhere.
> 
> > 
> >>>> You can also use the patch below as a starting point for your port:
> >>>> http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch
> >>> I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't
> >>> apply cleanly (well, fails :P). Am I approaching this the wrong way?
> >>> Also tried chucking the patch into the xenomai tree and getting
> >>> prepare_kernel.sh to try: still no joy.
> >> It probably does not apply to vanilla because vanilla has no support for
> >> the Sheevaplug board. Or am I missing something?
> > 
> > Well, I don't think so. Some hunks are expecting lines of context that
> > simply don't exist in 2.6.29 == fail.
> 
> Well yes, that is exactly my point: the patch is made to be applied to
> another kernel tree, a marvell specific kernel tree.

Right - now I'm on the same page, far too long afterwards :j I didn't
even consider the marvell tree. Duh.

> 
> > 
> > I took the mv88f6290 patch and bullied it into applying to vanilla
> > 2.6.29. Built ok, but was at home and no way to test, so I just got on
> > with migrating it to 2.6.33. That seems to be done - check the 2.6.33
> > boot output:
> >   
> >    ...
> >   I-pipe: Domain Xenomai registered.
> >   Xenomai: hal/arm started.
> >   Xenomai: scheduling class idle registered.
> >   Xenomai: scheduling class rt registered.
> >   Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
> >   Xenomai: starting native API services.
> >   Xenomai: starting POSIX services.
> >   Xenomai: starting RTDM services.
> >    ...
> > 
> > Full boot output is attached FYI.
> > 
> > However, I've got a problem with busybox/getty and /dev/ttyS0 so I can't
> > log in via console OR telnet. Once that's solved, I'll be able to run
> > the xenomai tests. (In case you've seen it before - /var/log/messages is
> > slowly filling with:
> 
> There are two ptys style, the BSD one corresponding to the
> CONFIG_LEGACY_PTYS in kernel configuration, and the new style,
> corresponding to the CONFIG_UNIX98_PTYS. busybox uses one style by
> default (I believe it is the new style), but will not work if your
> kernel is only configured for the other style. Anyway, you have to check
> that the busybox and kernel configurations match. This is probably the
> reason why telnetd does not work.

UNIX_PTYS and LEGACY_PTYS are both set.

telnetd accepts the first connection, but this then causes telnetd to
exit.

> 
> As for the reason why ttyS0 is not working, well, it is strange. Maybe
> something missing in the kernel configuration? Could you send me your
> .config?
> 

Just to clarify - the kernel boot output is on ttyS0, no problem.

config is attached.

Cheers,
Tim

[-- Attachment #2: .config --]
[-- Type: application/x-config, Size: 46513 bytes --]

Re: [Xenomai-help] Marvell sheeva support

[Philippe Gerum]

On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote:
> Hi guys,
> 
> Managed to get started on the Sheevaplug/xenomai stuff:
>   Used mkrootfs. Cool.
>   Massaged the mv88fxxxx patch so that it builds with 2.6.33.
>   Can't log into the device to run tests. Augh.
> 
> Details below! :P
> 
> On Wed, 2010-07-21 at 08:23 +0200, Gilles Chanteperdrix wrote:
> > Tim Cussins wrote:
> > >>> We can also provide you with a root filesystem for validating this platform.
> > > 
> > > That would be brilliant. I imagine I'll be iterating though uImages on
> > > an SD card loaded with your rootfs. Sound ok? Let me know how to obtain
> > > the rootfs (or better, show me how you prefer to do it, so I learn
> > > something! Ta.)
> > 
> > You will find the rootfs for orion SOCs, here:
> > http://www.xenomai.org/~gch/pub/rootfs-orion.tar.bz2
> > 
> > Edit etc/inittab to modify the serial console it needs (if it is not
> > /dev/ttyS0 running at 115200 bauds). The rootfs is meant to be booted by
> > NFS with the kernel IP auto-configuration, so, if you want to boot it on
> > an SD card, you will have to connect to the serial console once the
> > board is booted, and run "udhcpc" to configure the network by DHCP, or
> > use ifconfig to configure it by hand, then launch "telnetd" to be able
> > to connect to that board through telnet (if the kernel booted by NFS,
> > the telnet server will have been launched automatically)
> > 
> > In a first telnet session, run:
> > latency
> > In a second telnet session, if you have FCSE disabled, run:
> > dohell
> > if you have FCSE enabled, run:
> > noltp_hell 14400
> > (14400 means that you will generate some load during 14400s, that is 4
> > hours).
> > When either noltp_hell or dohell displays the line:
> > Listening on any address 5566
> > On the host, run:
> > netcat <target-ip> 5566 > /dev/null
> > 
> > Now you can return to the telnet session running latency. When the test
> > is finished the latency program should stop.
> > 
> > As for generating the root filesystem, it is not that it is really hard,
> > but it is a bit tedious. So, we made a tool to build a root filesystem
> > which suits our needs, that is testing Xenomai under load. I have just
> > finished working on a version of this tool (called mkrootfs, but I think
> > we should find a better name, as this one already exists) user-friendly
> > enough to be published. Currently, it is still lacking a documentation.
> > You will find it here:
> > 
> > http://www.xenomai.org/~gch/pub/mkrootfs.tar.bz2
> > 
> > However, to use it, you will need a few explanations. It is based on
> > Kbuild, the Linux kernel build system, so, it will build the same way.
> > Create a build directory, cd to it, then run:
> > 
> > make -C /path/to/mkrootfs O=`pwd` xconfig
> > 
> > Tweak the configuration. Then run:
> > make
> > 
> > It should build everything.
> > 
> > It does not download and patch the sources of the packages it uses, you
> > have to do this yourself, then pass the path where to look for them to
> > the configuration system. We use standard versions of the packages,
> > except for LTP, which we modified a bit to run on low-end platforms, and
> > which you can find here:
> > 
> > http://www.xenomai.org/~gch/ltp-20081130-patched.tar.bz2
> 
> 
> I've had a good play with mkrootfs - nice. I had to make a couple of
> changes to meet my needs (and system, ubuntu 10.04). Is there a git repo
> for mkrootfs that I can base my patches on? They're very small btw. More
> on that off-list if you want.
> 
> > 
> > >> You can also use the patch below as a starting point for your port:
> > >> http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch
> > > 
> > > I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't
> > > apply cleanly (well, fails :P). Am I approaching this the wrong way?
> > > Also tried chucking the patch into the xenomai tree and getting
> > > prepare_kernel.sh to try: still no joy.
> > 
> > It probably does not apply to vanilla because vanilla has no support for
> > the Sheevaplug board. Or am I missing something?
> 
> Well, I don't think so. Some hunks are expecting lines of context that
> simply don't exist in 2.6.29 == fail.
> 
> I took the mv88f6290 patch and bullied it into applying to vanilla
> 2.6.29. Built ok, but was at home and no way to test, so I just got on
> with migrating it to 2.6.33. That seems to be done - check the 2.6.33
> boot output:
>   
>    ...
>   I-pipe: Domain Xenomai registered.
>   Xenomai: hal/arm started.
>   Xenomai: scheduling class idle registered.
>   Xenomai: scheduling class rt registered.
>   Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
>   Xenomai: starting native API services.
>   Xenomai: starting POSIX services.
>   Xenomai: starting RTDM services.
>    ...
> 
> Full boot output is attached FYI.
> 
> However, I've got a problem with busybox/getty and /dev/ttyS0 so I can't
> log in via console OR telnet. Once that's solved, I'll be able to run
> the xenomai tests. (In case you've seen it before - /var/log/messages is
> slowly filling with:
> 
> Aug 11 16:03:36 init: starting pid 638, tty '/dev/ttyS0': '/sbin/getty
> 115200 ttyS0'
> Aug 11 16:03:36 getty[638]: ttyS0: TCGETS: Inappropriate ioctl for
> device
> 
> )
> 

Does /dev/ttyS0 have major=4, minor=64 on your rootfs?

> Cheers,
> Tim
> 

-- 
Philippe.

Re: [Xenomai-help] Marvell sheeva support

[Tim Cussins]

On Wed, 2010-08-11 at 17:28 +0200, Philippe Gerum wrote:
> On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote:
> > Hi guys,
> > 
> > Managed to get started on the Sheevaplug/xenomai stuff:
> >   Used mkrootfs. Cool.
> >   Massaged the mv88fxxxx patch so that it builds with 2.6.33.
> >   Can't log into the device to run tests. Augh.
> > 
> > Details below! :P
> > 
> > On Wed, 2010-07-21 at 08:23 +0200, Gilles Chanteperdrix wrote:
> > > Tim Cussins wrote:
> > > >>> We can also provide you with a root filesystem for validating this platform.
> > > > 
> > > > That would be brilliant. I imagine I'll be iterating though uImages on
> > > > an SD card loaded with your rootfs. Sound ok? Let me know how to obtain
> > > > the rootfs (or better, show me how you prefer to do it, so I learn
> > > > something! Ta.)
> > > 
> > > You will find the rootfs for orion SOCs, here:
> > > http://www.xenomai.org/~gch/pub/rootfs-orion.tar.bz2
> > > 
> > > Edit etc/inittab to modify the serial console it needs (if it is not
> > > /dev/ttyS0 running at 115200 bauds). The rootfs is meant to be booted by
> > > NFS with the kernel IP auto-configuration, so, if you want to boot it on
> > > an SD card, you will have to connect to the serial console once the
> > > board is booted, and run "udhcpc" to configure the network by DHCP, or
> > > use ifconfig to configure it by hand, then launch "telnetd" to be able
> > > to connect to that board through telnet (if the kernel booted by NFS,
> > > the telnet server will have been launched automatically)
> > > 
> > > In a first telnet session, run:
> > > latency
> > > In a second telnet session, if you have FCSE disabled, run:
> > > dohell
> > > if you have FCSE enabled, run:
> > > noltp_hell 14400
> > > (14400 means that you will generate some load during 14400s, that is 4
> > > hours).
> > > When either noltp_hell or dohell displays the line:
> > > Listening on any address 5566
> > > On the host, run:
> > > netcat <target-ip> 5566 > /dev/null
> > > 
> > > Now you can return to the telnet session running latency. When the test
> > > is finished the latency program should stop.
> > > 
> > > As for generating the root filesystem, it is not that it is really hard,
> > > but it is a bit tedious. So, we made a tool to build a root filesystem
> > > which suits our needs, that is testing Xenomai under load. I have just
> > > finished working on a version of this tool (called mkrootfs, but I think
> > > we should find a better name, as this one already exists) user-friendly
> > > enough to be published. Currently, it is still lacking a documentation.
> > > You will find it here:
> > > 
> > > http://www.xenomai.org/~gch/pub/mkrootfs.tar.bz2
> > > 
> > > However, to use it, you will need a few explanations. It is based on
> > > Kbuild, the Linux kernel build system, so, it will build the same way.
> > > Create a build directory, cd to it, then run:
> > > 
> > > make -C /path/to/mkrootfs O=`pwd` xconfig
> > > 
> > > Tweak the configuration. Then run:
> > > make
> > > 
> > > It should build everything.
> > > 
> > > It does not download and patch the sources of the packages it uses, you
> > > have to do this yourself, then pass the path where to look for them to
> > > the configuration system. We use standard versions of the packages,
> > > except for LTP, which we modified a bit to run on low-end platforms, and
> > > which you can find here:
> > > 
> > > http://www.xenomai.org/~gch/ltp-20081130-patched.tar.bz2
> > 
> > 
> > I've had a good play with mkrootfs - nice. I had to make a couple of
> > changes to meet my needs (and system, ubuntu 10.04). Is there a git repo
> > for mkrootfs that I can base my patches on? They're very small btw. More
> > on that off-list if you want.
> > 
> > > 
> > > >> You can also use the patch below as a starting point for your port:
> > > >> http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch
> > > > 
> > > > I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't
> > > > apply cleanly (well, fails :P). Am I approaching this the wrong way?
> > > > Also tried chucking the patch into the xenomai tree and gettingdev.txt (from mkrootfs) would imply that it is 4,64. Without being able to log in, I can't confirm though :) Unless you know a cunning trick? :D

> > > > prepare_kernel.sh to try: still no joy.
> > > 
> > > It probably does not apply to vanilla because vanilla has no support for
> > > the Sheevaplug board. Or am I missing something?
> > 
> > Well, I don't think so. Some hunks are expecting lines of context that
> > simply don't exist in 2.6.29 == fail.
> > 
> > I took the mv88f6290 patch and bullied it into applying to vanilla
> > 2.6.29. Built ok, but was at home and no way to test, so I just got on
> > with migrating it to 2.6.33. That seems to be done - check the 2.6.33
> > boot output:
> >   
> >    ...
> >   I-pipe: Domain Xenomai registered.
> >   Xenomai: hal/arm started.
> >   Xenomai: scheduling class idle registered.
> >   Xenomai: scheduling class rt registered.
> >   Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
> >   Xenomai: starting native API services.
> >   Xenomai: starting POSIX services.
> >   Xenomai: starting RTDM services.
> >    ...
> > 
> > Full boot output is attached FYI.
> > 
> > However, I've got a problem with busybox/getty and /dev/ttyS0 so I can't
> > log in via console OR telnet. Once that's solved, I'll be able to run
> > the xenomai tests. (In case you've seen it before - /var/log/messages is
> > slowly filling with:
> > 
> > Aug 11 16:03:36 init: starting pid 638, tty '/dev/ttyS0': '/sbin/getty
> > 115200 ttyS0'
> > Aug 11 16:03:36 getty[638]: ttyS0: TCGETS: Inappropriate ioctl for
> > device
> > 
> > )
> > 
> 
> Does /dev/ttyS0 have major=4, minor=64 on your rootfs?

dev.txt (from mkrootfs) would imply that it is 4,64. Without being able
to log in, I can't confirm though :) Unless you know a cunning trick? :D


> > Cheers,
> > Tim
> > 
> 

Re: [Xenomai-help] Marvell sheeva support

[Tim Cussins]

On Wed, 2010-08-11 at 18:29 +0200, Philippe Gerum wrote:
> On Wed, 2010-08-11 at 17:24 +0100, Tim Cussins wrote:
> > On Wed, 2010-08-11 at 17:28 +0200, Philippe Gerum wrote:
> > > On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote:
> > > > Hi guys,
> > > > 
> > > > Managed to get started on the Sheevaplug/xenomai stuff:
> > > >   Used mkrootfs. Cool.
> > > >   Massaged the mv88fxxxx patch so that it builds with 2.6.33.
> > > >   Can't log into the device to run tests. Augh.
> > > > 
> > > > Details below! :P
> > > > 
> > > > On Wed, 2010-07-21 at 08:23 +0200, Gilles Chanteperdrix wrote:
> > > > > Tim Cussins wrote:
> > > > > >>> We can also provide you with a root filesystem for validating this platform.
> > > > > > 
> > > > > > That would be brilliant. I imagine I'll be iterating though uImages on
> > > > > > an SD card loaded with your rootfs. Sound ok? Let me know how to obtain
> > > > > > the rootfs (or better, show me how you prefer to do it, so I learn
> > > > > > something! Ta.)
> > > > > 
> > > > > You will find the rootfs for orion SOCs, here:
> > > > > http://www.xenomai.org/~gch/pub/rootfs-orion.tar.bz2
> > > > > 
> > > > > Edit etc/inittab to modify the serial console it needs (if it is not
> > > > > /dev/ttyS0 running at 115200 bauds). The rootfs is meant to be booted by
> > > > > NFS with the kernel IP auto-configuration, so, if you want to boot it on
> > > > > an SD card, you will have to connect to the serial console once the
> > > > > board is booted, and run "udhcpc" to configure the network by DHCP, or
> > > > > use ifconfig to configure it by hand, then launch "telnetd" to be able
> > > > > to connect to that board through telnet (if the kernel booted by NFS,
> > > > > the telnet server will have been launched automatically)
> > > > > 
> > > > > In a first telnet session, run:
> > > > > latency
> > > > > In a second telnet session, if you have FCSE disabled, run:
> > > > > dohell
> > > > > if you have FCSE enabled, run:
> > > > > noltp_hell 14400
> > > > > (14400 means that you will generate some load during 14400s, that is 4
> > > > > hours).
> > > > > When either noltp_hell or dohell displays the line:
> > > > > Listening on any address 5566
> > > > > On the host, run:
> > > > > netcat <target-ip> 5566 > /dev/null
> > > > > 
> > > > > Now you can return to the telnet session running latency. When the test
> > > > > is finished the latency program should stop.
> > > > > 
> > > > > As for generating the root filesystem, it is not that it is really hard,
> > > > > but it is a bit tedious. So, we made a tool to build a root filesystem
> > > > > which suits our needs, that is testing Xenomai under load. I have just
> > > > > finished working on a version of this tool (called mkrootfs, but I think
> > > > > we should find a better name, as this one already exists) user-friendly
> > > > > enough to be published. Currently, it is still lacking a documentation.
> > > > > You will find it here:
> > > > > 
> > > > > http://www.xenomai.org/~gch/pub/mkrootfs.tar.bz2
> > > > > 
> > > > > However, to use it, you will need a few explanations. It is based on
> > > > > Kbuild, the Linux kernel build system, so, it will build the same way.
> > > > > Create a build directory, cd to it, then run:
> > > > > 
> > > > > make -C /path/to/mkrootfs O=`pwd` xconfig
> > > > > 
> > > > > Tweak the configuration. Then run:
> > > > > make
> > > > > 
> > > > > It should build everything.
> > > > > 
> > > > > It does not download and patch the sources of the packages it uses, you
> > > > > have to do this yourself, then pass the path where to look for them to
> > > > > the configuration system. We use standard versions of the packages,
> > > > > except for LTP, which we modified a bit to run on low-end platforms, and
> > > > > which you can find here:
> > > > > 
> > > > > http://www.xenomai.org/~gch/ltp-20081130-patched.tar.bz2
> > > > 
> > > > 
> > > > I've had a good play with mkrootfs - nice. I had to make a couple of
> > > > changes to meet my needs (and system, ubuntu 10.04). Is there a git repo
> > > > for mkrootfs that I can base my patches on? They're very small btw. More
> > > > on that off-list if you want.
> > > > 
> > > > > 
> > > > > >> You can also use the patch below as a starting point for your port:
> > > > > >> http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch
> > > > > > 
> > > > > > I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't
> > > > > > apply cleanly (well, fails :P). Am I approaching this the wrong way?
> > > > > > Also tried chucking the patch into the xenomai tree and gettingdev.txt (from mkrootfs) would imply that it is 4,64. Without being able to log in, I can't confirm though :) Unless you know a cunning trick? :D
> > 
> > > > > > prepare_kernel.sh to try: still no joy.
> > > > > 
> > > > > It probably does not apply to vanilla because vanilla has no support for
> > > > > the Sheevaplug board. Or am I missing something?
> > > > 
> > > > Well, I don't think so. Some hunks are expecting lines of context that
> > > > simply don't exist in 2.6.29 == fail.
> > > > 
> > > > I took the mv88f6290 patch and bullied it into applying to vanilla
> > > > 2.6.29. Built ok, but was at home and no way to test, so I just got on
> > > > with migrating it to 2.6.33. That seems to be done - check the 2.6.33
> > > > boot output:
> > > >   
> > > >    ...
> > > >   I-pipe: Domain Xenomai registered.
> > > >   Xenomai: hal/arm started.
> > > >   Xenomai: scheduling class idle registered.
> > > >   Xenomai: scheduling class rt registered.
> > > >   Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
> > > >   Xenomai: starting native API services.
> > > >   Xenomai: starting POSIX services.
> > > >   Xenomai: starting RTDM services.
> > > >    ...
> > > > 
> > > > Full boot output is attached FYI.
> > > > 
> > > > However, I've got a problem with busybox/getty and /dev/ttyS0 so I can't
> > > > log in via console OR telnet. Once that's solved, I'll be able to run
> > > > the xenomai tests. (In case you've seen it before - /var/log/messages is
> > > > slowly filling with:
> > > > 
> > > > Aug 11 16:03:36 init: starting pid 638, tty '/dev/ttyS0': '/sbin/getty
> > > > 115200 ttyS0'
> > > > Aug 11 16:03:36 getty[638]: ttyS0: TCGETS: Inappropriate ioctl for
> > > > device
> > > > 
> > > > )
> > > > 
> > > 
> > > Does /dev/ttyS0 have major=4, minor=64 on your rootfs?
> > 
> > dev.txt (from mkrootfs) would imply that it is 4,64. Without being able
> > to log in, I can't confirm though :) Unless you know a cunning trick? :D
> 
> Well, maybe. ls -l on the nfs server side exporting your rootfs :>

Pfff :D All the nodes appear as regular files that way - I assumed that
was normal, and that some special magic was happening in busybox to
replace them with nodes... Is there something I'm not doing right?

I've mounted a debian rootfs over nfs no problems - that tree has *real*
nodes in it, and the show up as such using the ls -l , uh, 'trick' :P

> > 
> > 
> > > > Cheers,
> > > > Tim
> > > > 
> > > 
> > 
> > 
> 

Re: [Xenomai-help] Marvell sheeva support

[Gilles Chanteperdrix]

Tim Cussins wrote:
> On Wed, 2010-08-11 at 18:29 +0200, Philippe Gerum wrote:
>> On Wed, 2010-08-11 at 17:24 +0100, Tim Cussins wrote:
>>> On Wed, 2010-08-11 at 17:28 +0200, Philippe Gerum wrote:
>>>> On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote:
>>>>> Hi guys,
>>>>>
>>>>> Managed to get started on the Sheevaplug/xenomai stuff:
>>>>>   Used mkrootfs. Cool.
>>>>>   Massaged the mv88fxxxx patch so that it builds with 2.6.33.
>>>>>   Can't log into the device to run tests. Augh.
>>>>>
>>>>> Details below! :P
>>>>>
>>>>> On Wed, 2010-07-21 at 08:23 +0200, Gilles Chanteperdrix wrote:
>>>>>> Tim Cussins wrote:
>>>>>>>>> We can also provide you with a root filesystem for validating this platform.
>>>>>>> That would be brilliant. I imagine I'll be iterating though uImages on
>>>>>>> an SD card loaded with your rootfs. Sound ok? Let me know how to obtain
>>>>>>> the rootfs (or better, show me how you prefer to do it, so I learn
>>>>>>> something! Ta.)
>>>>>> You will find the rootfs for orion SOCs, here:
>>>>>> http://www.xenomai.org/~gch/pub/rootfs-orion.tar.bz2
>>>>>>
>>>>>> Edit etc/inittab to modify the serial console it needs (if it is not
>>>>>> /dev/ttyS0 running at 115200 bauds). The rootfs is meant to be booted by
>>>>>> NFS with the kernel IP auto-configuration, so, if you want to boot it on
>>>>>> an SD card, you will have to connect to the serial console once the
>>>>>> board is booted, and run "udhcpc" to configure the network by DHCP, or
>>>>>> use ifconfig to configure it by hand, then launch "telnetd" to be able
>>>>>> to connect to that board through telnet (if the kernel booted by NFS,
>>>>>> the telnet server will have been launched automatically)
>>>>>>
>>>>>> In a first telnet session, run:
>>>>>> latency
>>>>>> In a second telnet session, if you have FCSE disabled, run:
>>>>>> dohell
>>>>>> if you have FCSE enabled, run:
>>>>>> noltp_hell 14400
>>>>>> (14400 means that you will generate some load during 14400s, that is 4
>>>>>> hours).
>>>>>> When either noltp_hell or dohell displays the line:
>>>>>> Listening on any address 5566
>>>>>> On the host, run:
>>>>>> netcat <target-ip> 5566 > /dev/null
>>>>>>
>>>>>> Now you can return to the telnet session running latency. When the test
>>>>>> is finished the latency program should stop.
>>>>>>
>>>>>> As for generating the root filesystem, it is not that it is really hard,
>>>>>> but it is a bit tedious. So, we made a tool to build a root filesystem
>>>>>> which suits our needs, that is testing Xenomai under load. I have just
>>>>>> finished working on a version of this tool (called mkrootfs, but I think
>>>>>> we should find a better name, as this one already exists) user-friendly
>>>>>> enough to be published. Currently, it is still lacking a documentation.
>>>>>> You will find it here:
>>>>>>
>>>>>> http://www.xenomai.org/~gch/pub/mkrootfs.tar.bz2
>>>>>>
>>>>>> However, to use it, you will need a few explanations. It is based on
>>>>>> Kbuild, the Linux kernel build system, so, it will build the same way.
>>>>>> Create a build directory, cd to it, then run:
>>>>>>
>>>>>> make -C /path/to/mkrootfs O=`pwd` xconfig
>>>>>>
>>>>>> Tweak the configuration. Then run:
>>>>>> make
>>>>>>
>>>>>> It should build everything.
>>>>>>
>>>>>> It does not download and patch the sources of the packages it uses, you
>>>>>> have to do this yourself, then pass the path where to look for them to
>>>>>> the configuration system. We use standard versions of the packages,
>>>>>> except for LTP, which we modified a bit to run on low-end platforms, and
>>>>>> which you can find here:
>>>>>>
>>>>>> http://www.xenomai.org/~gch/ltp-20081130-patched.tar.bz2
>>>>>
>>>>> I've had a good play with mkrootfs - nice. I had to make a couple of
>>>>> changes to meet my needs (and system, ubuntu 10.04). Is there a git repo
>>>>> for mkrootfs that I can base my patches on? They're very small btw. More
>>>>> on that off-list if you want.
>>>>>
>>>>>>>> You can also use the patch below as a starting point for your port:
>>>>>>>> http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch
>>>>>>> I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't
>>>>>>> apply cleanly (well, fails :P). Am I approaching this the wrong way?
>>>>>>> Also tried chucking the patch into the xenomai tree and gettingdev.txt (from mkrootfs) would imply that it is 4,64. Without being able to log in, I can't confirm though :) Unless you know a cunning trick? :D
>>>>>>> prepare_kernel.sh to try: still no joy.
>>>>>> It probably does not apply to vanilla because vanilla has no support for
>>>>>> the Sheevaplug board. Or am I missing something?
>>>>> Well, I don't think so. Some hunks are expecting lines of context that
>>>>> simply don't exist in 2.6.29 == fail.
>>>>>
>>>>> I took the mv88f6290 patch and bullied it into applying to vanilla
>>>>> 2.6.29. Built ok, but was at home and no way to test, so I just got on
>>>>> with migrating it to 2.6.33. That seems to be done - check the 2.6.33
>>>>> boot output:
>>>>>   
>>>>>    ...
>>>>>   I-pipe: Domain Xenomai registered.
>>>>>   Xenomai: hal/arm started.
>>>>>   Xenomai: scheduling class idle registered.
>>>>>   Xenomai: scheduling class rt registered.
>>>>>   Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
>>>>>   Xenomai: starting native API services.
>>>>>   Xenomai: starting POSIX services.
>>>>>   Xenomai: starting RTDM services.
>>>>>    ...
>>>>>
>>>>> Full boot output is attached FYI.
>>>>>
>>>>> However, I've got a problem with busybox/getty and /dev/ttyS0 so I can't
>>>>> log in via console OR telnet. Once that's solved, I'll be able to run
>>>>> the xenomai tests. (In case you've seen it before - /var/log/messages is
>>>>> slowly filling with:
>>>>>
>>>>> Aug 11 16:03:36 init: starting pid 638, tty '/dev/ttyS0': '/sbin/getty
>>>>> 115200 ttyS0'
>>>>> Aug 11 16:03:36 getty[638]: ttyS0: TCGETS: Inappropriate ioctl for
>>>>> device
>>>>>
>>>>> )
>>>>>
>>>> Does /dev/ttyS0 have major=4, minor=64 on your rootfs?
>>> dev.txt (from mkrootfs) would imply that it is 4,64. Without being able
>>> to log in, I can't confirm though :) Unless you know a cunning trick? :D
>> Well, maybe. ls -l on the nfs server side exporting your rootfs :>
> 
> Pfff :D All the nodes appear as regular files that way - I assumed that
> was normal, and that some special magic was happening in busybox to
> replace them with nodes... Is there something I'm not doing right?
> 
> I've mounted a debian rootfs over nfs no problems - that tree has *real*
> nodes in it, and the show up as such using the ls -l , uh, 'trick' :P

It means we have an issue with fakeroot. Just run make clean, then make
again to see if it fixes it.


-- 
					    Gilles.

Re: [Xenomai-help] Marvell sheeva support

[Tim Cussins]

On Wed, 2010-08-11 at 18:56 +0200, Gilles Chanteperdrix wrote:
> Tim Cussins wrote:
> > On Wed, 2010-08-11 at 18:29 +0200, Philippe Gerum wrote:
> >> On Wed, 2010-08-11 at 17:24 +0100, Tim Cussins wrote:
> >>> On Wed, 2010-08-11 at 17:28 +0200, Philippe Gerum wrote:
> >>>> On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote:

> >>>>> However, I've got a problem with busybox/getty and /dev/ttyS0 so I can't
> >>>>> log in via console OR telnet. Once that's solved, I'll be able to run
> >>>>> the xenomai tests. (In case you've seen it before - /var/log/messages is
> >>>>> slowly filling with:
> >>>>>
> >>>>> Aug 11 16:03:36 init: starting pid 638, tty '/dev/ttyS0': '/sbin/getty
> >>>>> 115200 ttyS0'
> >>>>> Aug 11 16:03:36 getty[638]: ttyS0: TCGETS: Inappropriate ioctl for
> >>>>> device
> >>>>>
> >>>>> )
> >>>>>
> >>>> Does /dev/ttyS0 have major=4, minor=64 on your rootfs?
> >>> dev.txt (from mkrootfs) would imply that it is 4,64. Without being able
> >>> to log in, I can't confirm though :) Unless you know a cunning trick? :D
> >> Well, maybe. ls -l on the nfs server side exporting your rootfs :>
> > 
> > Pfff :D All the nodes appear as regular files that way - I assumed that
> > was normal, and that some special magic was happening in busybox to
> > replace them with nodes... Is there something I'm not doing right?
> > 
> > I've mounted a debian rootfs over nfs no problems - that tree has *real*
> > nodes in it, and the show up as such using the ls -l , uh, 'trick' :P
> 
> It means we have an issue with fakeroot. Just run make clean, then make
> again to see if it fixes it.

For anyone following this: the files in /dev were regular files instead
of real device nodes - hence the ioctl failure.

The nodes were created in a staging tree using fakeroot. I exported the
tree by invoking tar directly, so the files appear as regular empty
files.

The solution is to invoke tar using fakeroot: this ensures you'll get
real device nodes in /dev.

Cheers,
Tim

Re: [Xenomai-help] Marvell sheeva support

[Gilles Chanteperdrix]

Tim Cussins wrote:
> On Wed, 2010-08-11 at 18:56 +0200, Gilles Chanteperdrix wrote:
>> Tim Cussins wrote:
>>> On Wed, 2010-08-11 at 18:29 +0200, Philippe Gerum wrote:
>>>> On Wed, 2010-08-11 at 17:24 +0100, Tim Cussins wrote:
>>>>> On Wed, 2010-08-11 at 17:28 +0200, Philippe Gerum wrote:
>>>>>> On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote:
> 
>>>>>>> However, I've got a problem with busybox/getty and /dev/ttyS0 so I can't
>>>>>>> log in via console OR telnet. Once that's solved, I'll be able to run
>>>>>>> the xenomai tests. (In case you've seen it before - /var/log/messages is
>>>>>>> slowly filling with:
>>>>>>>
>>>>>>> Aug 11 16:03:36 init: starting pid 638, tty '/dev/ttyS0': '/sbin/getty
>>>>>>> 115200 ttyS0'
>>>>>>> Aug 11 16:03:36 getty[638]: ttyS0: TCGETS: Inappropriate ioctl for
>>>>>>> device
>>>>>>>
>>>>>>> )
>>>>>>>
>>>>>> Does /dev/ttyS0 have major=4, minor=64 on your rootfs?
>>>>> dev.txt (from mkrootfs) would imply that it is 4,64. Without being able
>>>>> to log in, I can't confirm though :) Unless you know a cunning trick? :D
>>>> Well, maybe. ls -l on the nfs server side exporting your rootfs :>
>>> Pfff :D All the nodes appear as regular files that way - I assumed that
>>> was normal, and that some special magic was happening in busybox to
>>> replace them with nodes... Is there something I'm not doing right?
>>>
>>> I've mounted a debian rootfs over nfs no problems - that tree has *real*
>>> nodes in it, and the show up as such using the ls -l , uh, 'trick' :P
>> It means we have an issue with fakeroot. Just run make clean, then make
>> again to see if it fixes it.
> 
> For anyone following this: the files in /dev were regular files instead
> of real device nodes - hence the ioctl failure.
> 
> The nodes were created in a staging tree using fakeroot. I exported the
> tree by invoking tar directly, so the files appear as regular empty
> files.
> 
> The solution is to invoke tar using fakeroot: this ensures you'll get
> real device nodes in /dev.

There is a configuration option in mkrootfs to generate the tarball
directly.

-- 
					    Gilles.

Re: [Xenomai-help] Marvell sheeva support

[Philippe Gerum]

On Wed, 2010-08-11 at 17:28 +0200, Philippe Gerum wrote:
> On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote:
> > Hi guys,
> > 
> > Managed to get started on the Sheevaplug/xenomai stuff:
> >   Used mkrootfs. Cool.
> >   Massaged the mv88fxxxx patch so that it builds with 2.6.33.
> >   Can't log into the device to run tests. Augh.
> > 
> > Details below! :P
> > 
> > On Wed, 2010-07-21 at 08:23 +0200, Gilles Chanteperdrix wrote:
> > > Tim Cussins wrote:
> > > >>> We can also provide you with a root filesystem for validating this platform.
> > > > 
> > > > That would be brilliant. I imagine I'll be iterating though uImages on
> > > > an SD card loaded with your rootfs. Sound ok? Let me know how to obtain
> > > > the rootfs (or better, show me how you prefer to do it, so I learn
> > > > something! Ta.)
> > > 
> > > You will find the rootfs for orion SOCs, here:
> > > http://www.xenomai.org/~gch/pub/rootfs-orion.tar.bz2
> > > 
> > > Edit etc/inittab to modify the serial console it needs (if it is not
> > > /dev/ttyS0 running at 115200 bauds). The rootfs is meant to be booted by
> > > NFS with the kernel IP auto-configuration, so, if you want to boot it on
> > > an SD card, you will have to connect to the serial console once the
> > > board is booted, and run "udhcpc" to configure the network by DHCP, or
> > > use ifconfig to configure it by hand, then launch "telnetd" to be able
> > > to connect to that board through telnet (if the kernel booted by NFS,
> > > the telnet server will have been launched automatically)
> > > 
> > > In a first telnet session, run:
> > > latency
> > > In a second telnet session, if you have FCSE disabled, run:
> > > dohell
> > > if you have FCSE enabled, run:
> > > noltp_hell 14400
> > > (14400 means that you will generate some load during 14400s, that is 4
> > > hours).
> > > When either noltp_hell or dohell displays the line:
> > > Listening on any address 5566
> > > On the host, run:
> > > netcat <target-ip> 5566 > /dev/null
> > > 
> > > Now you can return to the telnet session running latency. When the test
> > > is finished the latency program should stop.
> > > 
> > > As for generating the root filesystem, it is not that it is really hard,
> > > but it is a bit tedious. So, we made a tool to build a root filesystem
> > > which suits our needs, that is testing Xenomai under load. I have just
> > > finished working on a version of this tool (called mkrootfs, but I think
> > > we should find a better name, as this one already exists) user-friendly
> > > enough to be published. Currently, it is still lacking a documentation.
> > > You will find it here:
> > > 
> > > http://www.xenomai.org/~gch/pub/mkrootfs.tar.bz2
> > > 
> > > However, to use it, you will need a few explanations. It is based on
> > > Kbuild, the Linux kernel build system, so, it will build the same way.
> > > Create a build directory, cd to it, then run:
> > > 
> > > make -C /path/to/mkrootfs O=`pwd` xconfig
> > > 
> > > Tweak the configuration. Then run:
> > > make
> > > 
> > > It should build everything.
> > > 
> > > It does not download and patch the sources of the packages it uses, you
> > > have to do this yourself, then pass the path where to look for them to
> > > the configuration system. We use standard versions of the packages,
> > > except for LTP, which we modified a bit to run on low-end platforms, and
> > > which you can find here:
> > > 
> > > http://www.xenomai.org/~gch/ltp-20081130-patched.tar.bz2
> > 
> > 
> > I've had a good play with mkrootfs - nice. I had to make a couple of
> > changes to meet my needs (and system, ubuntu 10.04). Is there a git repo
> > for mkrootfs that I can base my patches on? They're very small btw. More
> > on that off-list if you want.
> > 
> > > 
> > > >> You can also use the patch below as a starting point for your port:
> > > >> http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch
> > > > 
> > > > I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't
> > > > apply cleanly (well, fails :P). Am I approaching this the wrong way?
> > > > Also tried chucking the patch into the xenomai tree and getting
> > > > prepare_kernel.sh to try: still no joy.
> > > 
> > > It probably does not apply to vanilla because vanilla has no support for
> > > the Sheevaplug board. Or am I missing something?
> > 
> > Well, I don't think so. Some hunks are expecting lines of context that
> > simply don't exist in 2.6.29 == fail.
> > 
> > I took the mv88f6290 patch and bullied it into applying to vanilla
> > 2.6.29. Built ok, but was at home and no way to test, so I just got on
> > with migrating it to 2.6.33. That seems to be done - check the 2.6.33
> > boot output:
> >   
> >    ...
> >   I-pipe: Domain Xenomai registered.
> >   Xenomai: hal/arm started.
> >   Xenomai: scheduling class idle registered.
> >   Xenomai: scheduling class rt registered.
> >   Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
> >   Xenomai: starting native API services.
> >   Xenomai: starting POSIX services.
> >   Xenomai: starting RTDM services.
> >    ...
> > 
> > Full boot output is attached FYI.
> > 
> > However, I've got a problem with busybox/getty and /dev/ttyS0 so I can't
> > log in via console OR telnet. Once that's solved, I'll be able to run
> > the xenomai tests. (In case you've seen it before - /var/log/messages is
> > slowly filling with:
> > 
> > Aug 11 16:03:36 init: starting pid 638, tty '/dev/ttyS0': '/sbin/getty
> > 115200 ttyS0'
> > Aug 11 16:03:36 getty[638]: ttyS0: TCGETS: Inappropriate ioctl for
> > device
> > 
> > )
> > 
> 
> Does /dev/ttyS0 have major=4, minor=64 on your rootfs?
> 

Well, maybe. ls -l on the nfs server side exporting your rootfs :>

> > Cheers,
> > Tim
> > 
> 

-- 
Philippe.

Re: [Xenomai-help] Marvell sheeva support

[Tim Cussins]

Hi all,

On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote:

> I took the mv88f6290 patch and bullied it into applying to vanilla
> 2.6.29. Built ok, but was at home and no way to test, so I just got on
> with migrating it to 2.6.33. That seems to be done - check the 2.6.33
> boot output:
>   
>    ...
>   I-pipe: Domain Xenomai registered.
>   Xenomai: hal/arm started.
>   Xenomai: scheduling class idle registered.
>   Xenomai: scheduling class rt registered.
>   Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
>   Xenomai: starting native API services.
>   Xenomai: starting POSIX services.
>   Xenomai: starting RTDM services.
>    ...

Just a status update - I think I'm pretty much were Sergey was back here
(+ some):

vanilla 2.6.33 kernel +
adeos-ipipe-2.6.33-arm-1.17-02.patch +
kirkwood specific stuff (taken from adeos-ipipe-2.6.29-mv88f6290.patch)

I can run all the xenomai apps. As with Sergey I'm seeing negative
values for the minimum latency, which seems odd. See Sergey's post if
interested:

http://www.mail-archive.com/xenomai@xenomai.org

Cheers,
Tim

Re: [Xenomai-help] Marvell sheeva support

[Philippe Gerum]

On Thu, 2010-08-12 at 16:45 +0100, Tim Cussins wrote:
> Hi all,
> 
> On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote:
> 
> > I took the mv88f6290 patch and bullied it into applying to vanilla
> > 2.6.29. Built ok, but was at home and no way to test, so I just got on
> > with migrating it to 2.6.33. That seems to be done - check the 2.6.33
> > boot output:
> >   
> >    ...
> >   I-pipe: Domain Xenomai registered.
> >   Xenomai: hal/arm started.
> >   Xenomai: scheduling class idle registered.
> >   Xenomai: scheduling class rt registered.
> >   Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
> >   Xenomai: starting native API services.
> >   Xenomai: starting POSIX services.
> >   Xenomai: starting RTDM services.
> >    ...
> 
> Just a status update - I think I'm pretty much were Sergey was back here
> (+ some):
> 
> vanilla 2.6.33 kernel +
> adeos-ipipe-2.6.33-arm-1.17-02.patch +
> kirkwood specific stuff (taken from adeos-ipipe-2.6.29-mv88f6290.patch)
> 
> I can run all the xenomai apps. As with Sergey I'm seeing negative
> values for the minimum latency, which seems odd. See Sergey's post if
> interested:

Negative values are ok, they just mean that the timer shot is too much
anticipated for your hardware, which has better latency than defined by
the default calibration value.

Try reducing the value in /proc/xenomai/latency (i.e. echo (ns)
> /proc/xenomai/latency), until the latency test shows a minimum latency
slightly above 0.

> 
> http://www.mail-archive.com/xenomai@xenomai.org
> 
> Cheers,
> Tim
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] Marvell sheeva support

[Philippe Gerum]

On Thu, 2010-08-12 at 17:58 +0200, Philippe Gerum wrote:
> On Thu, 2010-08-12 at 16:45 +0100, Tim Cussins wrote:
> > Hi all,
> > 
> > On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote:
> > 
> > > I took the mv88f6290 patch and bullied it into applying to vanilla
> > > 2.6.29. Built ok, but was at home and no way to test, so I just got on
> > > with migrating it to 2.6.33. That seems to be done - check the 2.6.33
> > > boot output:
> > >   
> > >    ...
> > >   I-pipe: Domain Xenomai registered.
> > >   Xenomai: hal/arm started.
> > >   Xenomai: scheduling class idle registered.
> > >   Xenomai: scheduling class rt registered.
> > >   Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
> > >   Xenomai: starting native API services.
> > >   Xenomai: starting POSIX services.
> > >   Xenomai: starting RTDM services.
> > >    ...
> > 
> > Just a status update - I think I'm pretty much were Sergey was back here
> > (+ some):
> > 
> > vanilla 2.6.33 kernel +
> > adeos-ipipe-2.6.33-arm-1.17-02.patch +
> > kirkwood specific stuff (taken from adeos-ipipe-2.6.29-mv88f6290.patch)
> > 
> > I can run all the xenomai apps. As with Sergey I'm seeing negative
> > values for the minimum latency, which seems odd. See Sergey's post if
> > interested:
> 
> Negative values are ok, they just mean that the timer shot is too much
> anticipated for your hardware, which has better latency than defined by
> the default calibration value.
> 

Assuming that those negative values are in the micro-second range though
(say, 1-20 us maybe?). Huge negative values would rather mean that
something is broken in the timing sub-system.

> Try reducing the value in /proc/xenomai/latency (i.e. echo (ns)
> > /proc/xenomai/latency), until the latency test shows a minimum latency
> slightly above 0.
> 
> > 
> > http://www.mail-archive.com/xenomai@xenomai.org
> > 
> > Cheers,
> > Tim
> > 
> > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> 

-- 
Philippe.

Re: [Xenomai-help] Marvell sheeva support

[Tim Cussins]

On Thu, 2010-08-12 at 18:03 +0200, Philippe Gerum wrote:
> On Thu, 2010-08-12 at 17:58 +0200, Philippe Gerum wrote:
> > On Thu, 2010-08-12 at 16:45 +0100, Tim Cussins wrote:
> > > Hi all,
> > > 
> > > On Wed, 2010-08-11 at 15:58 +0100, Tim Cussins wrote:
> > > 
> > > > I took the mv88f6290 patch and bullied it into applying to vanilla
> > > > 2.6.29. Built ok, but was at home and no way to test, so I just got on
> > > > with migrating it to 2.6.33. That seems to be done - check the 2.6.33
> > > > boot output:
> > > >   
> > > >    ...
> > > >   I-pipe: Domain Xenomai registered.
> > > >   Xenomai: hal/arm started.
> > > >   Xenomai: scheduling class idle registered.
> > > >   Xenomai: scheduling class rt registered.
> > > >   Xenomai: real-time nucleus v2.5.4 (Sleep Walk) loaded.
> > > >   Xenomai: starting native API services.
> > > >   Xenomai: starting POSIX services.
> > > >   Xenomai: starting RTDM services.
> > > >    ...
> > > 
> > > Just a status update - I think I'm pretty much were Sergey was back here
> > > (+ some):
> > > 
> > > vanilla 2.6.33 kernel +
> > > adeos-ipipe-2.6.33-arm-1.17-02.patch +
> > > kirkwood specific stuff (taken from adeos-ipipe-2.6.29-mv88f6290.patch)
> > > 
> > > I can run all the xenomai apps. As with Sergey I'm seeing negative
> > > values for the minimum latency, which seems odd. See Sergey's post if
> > > interested:
> > 
> > Negative values are ok, they just mean that the timer shot is too much
> > anticipated for your hardware, which has better latency than defined by
> > the default calibration value.
> > 
> 
> Assuming that those negative values are in the micro-second range though
> (say, 1-20 us maybe?). Huge negative values would rather mean that
> something is broken in the timing sub-system.

Yeah, about -4us +/- 1us

> 
> > Try reducing the value in /proc/xenomai/latency (i.e. echo (ns)
> > > /proc/xenomai/latency), until the latency test shows a minimum latency
> > slightly above 0.

Thanks!

> > 
> > > 
> > > http://www.mail-archive.com/xenomai@xenomai.org
> > > 
> > > Cheers,
> > > Tim
> > > 
> > > 
> > > _______________________________________________
> > > Xenomai-help mailing list
> > > Xenomai-help@domain.hid
> > > https://mail.gna.org/listinfo/xenomai-help
> > 
> 

Re: [Xenomai-help] Marvell sheeva support

[Tim Cussins]

On Wed, 2010-07-21 at 08:23 +0200, Gilles Chanteperdrix wrote:

> It does not download and patch the sources of the packages it uses, you
> have to do this yourself, then pass the path where to look for them to
> the configuration system. We use standard versions of the packages,
> except for LTP, which we modified a bit to run on low-end platforms, and
> which you can find here:
> 
> http://www.xenomai.org/~gch/ltp-20081130-patched.tar.bz2
> 

This doesn't appear to be a valid now - can you make it available again
please?

Cheers,
Tim

Re: [Xenomai-help] Marvell sheeva support

[Philippe Gerum]

On Tue, 2010-07-20 at 12:00 +0100, Tim Cussins wrote:
> Hi guys,
> 
> I hope you don't mind if I reply to you together.
> 
> On Thu, 2010-07-15 at 18:11 +0200, Philippe Gerum wrote:
> > On Thu, 2010-07-15 at 13:53 +0200, Gilles Chanteperdrix wrote:
> > > Tim Cussins wrote:
> > > > Hi all,
> > > > 
> > > > We're looking at migrating to one of Marvell's MV88F series SOC's, and
> > > > are very keen to deploy Xenomai as part of our solution.
> > > > 
> > > > I noticed Sergey Didenko was looking at this a few months back and
> > > > things looked to be ok - has his (or anyone else's) work made it into a
> > > > stable release?
> > > > 
> > > > I will be able to assist in about a fortnight if that would be useful
> > > > for squaring that work away.
> > > > 
> > > > Let me know if I can help!
> > > 
> > > We are interested. I seem to remember that Serguey had unexplained
> > > latencies issues, so, if you start with his work, please bear this in
> > > mind, there was probably something wrong with his port. A guide
> > > explaining how to port the I-pipe patch on ARM exists:
> > > http://www.xenomai.org/index.php/I-pipe:ArmPorting
> 
> > > The section about chained GPIOs irqs is outdated, if your platform has
> > > some, I will explain how it should be implemented.
> > > 
> > > Please start from the I-pipe git (git://git.denx.de/ipipe-2.6.git),
> > > merging it with the branch you will use if needed, so that you can
> > > submit a patch only containing the modifications necessary for the
> > > Sheeva platform.
> 
> Not a problem :)
> 
> > > We can also provide you with a root filesystem for validating this platform.
> 
> That would be brilliant. I imagine I'll be iterating though uImages on
> an SD card loaded with your rootfs. Sound ok? Let me know how to obtain
> the rootfs (or better, show me how you prefer to do it, so I learn
> something! Ta.)
> 
> > 
> > You can also use the patch below as a starting point for your port:
> > http://download.gna.org/adeos/patches/tmp/adeos-ipipe-2.6.29-mv88f6290.patch
> 
> I've tried applying this to vanilla 2.6.29 and 2.6.29.6 - it doesn't
> apply cleanly (well, fails :P). Am I approaching this the wrong way?
> Also tried chucking the patch into the xenomai tree and getting
> prepare_kernel.sh to try: still no joy.

The patch applies to a non-mainline tree including the board support for
the mv88f6290; this support is missing from 2.6.29 mainline, hence the
two rejects I see here.

What is your target kernel and MV88 variant exactly?

> 
> > caveats:
> > 
> > - it is based on an old kernel release, and moving to 2.6.3x would
> > require some work. If you need so, then you should merge the
> > arm-dependent bits from the patch above with the generic I-pipe bits
> > from a newer release as available here (e.g. 2.6.33):
> > http://download.gna.org/adeos/patches/v2.6/arm/
> 
> Building and running the current patch (2.6.29) seems like a reasonable
> starting point, but producing a 2.6.33 patch seems like the right thing
> to do...
> 
> > - the fcse implementation in that patch won't work with the l2 outer
> > cache enabled. The two options have been made mutually exclusive via
> > Kconfig.
> 
> Out of interest: is this a fundamental limitation, or do you believe
> that the L2 and FCSE might be happy together after a bit of work?
> 

It should be possible to fix this, but that would require some surgery
in the arch-dep mm code.

> >  you should use Xenomai 2.5.3 or above to get this running.
> > 
> > As a reference point, the worst-case scheduling latency for user-space
> > threads, observed on a mv88f6290 using that patch with fcse enabled (no
> > l2), is below 70 us.
> 
> That's brilliant. Our requirements aren't for super-low latency, but
> definitely realtime. We might go with L2 and no FCSE if the latency is
> still ok. Just FYI :)
> 
> > HTH,
> > 
> 
> Yep, thanks. I'll be able to do this work: I'm just trying to estimate
> how long it'll take me to get up to speed and produce a patch for 2.6.33.
> Any thoughts on the volume and nature of the work remaining would be helpful.
> 
> Cheers,
> Tim
> 

-- 
Philippe.