Xenomai for A13 - A10

[Tele]

They all exist...

Ok now you try to make some more tests, but its not sure if these utilities (file and ldd) do exist on your rootfs, it depends where did you get your rootfs from.
try this on your Oli card:

Code Select Expand


cd /usr/bin/xenomai/bin
file ./latency

it should answer:

Code Select Expand


ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux...

but not:

Code Select Expand


ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux...

If its ok then try:

Code Select Expand


ldd ./latency

Xenomai libs are ok but what about libc.so shared ? What does it want? eglibc or uclibc or libc things? They are not compatible. Can you see any missing library?

[ehj666]

Code Select Expand


cd /usr/bin/xenomai/bin
file ./latency

it should answer:

Code Select Expand


ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux...


It does come back with essentially that:

Code Select Expand


ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.31, BuildID[sha1]=..., not stripped


Code Select Expand


ldd ./latency

Xenomai libs are ok but what about libc.so shared ? What does it want? eglibc or uclibc or libc things? They are not compatible. Can you see any missing library?

Returns:

Code Select Expand


       not a dynamic executable


[Tele]

Returns:

Code Select Expand


       not a dynamic executable


Oooops, there is something fishy about that.

2 more tests please:

Code Select Expand


strace ./latency

In the 1st line, execve() can find it ? can not ?

and at last

Code Select Expand


readelf -a ./latency

This one will dump a bit longer text, maybe try to catch it
readelf - a ./latency > elftest.txt

Look for "Requesting program interpreter:" and "Shared library:" lines in the text. Can you find those files all in your lib paths (/lib : /usr/lib : /usr/local/lib)?
Probably "Req. prog. interpreter" will be missing. Thats my guess.

[ehj666]

2 more tests please:

Code Select Expand


strace ./latency

In the 1st line, execve() can find it ? can not ?

and at last

Code Select Expand


readelf -a ./latency

This one will dump a bit longer text, maybe try to catch it
readelf - a ./latency > elftest.txt

Look for "Requesting program interpreter:" and "Shared library:" lines in the text. Can you find those files all in your lib paths (/lib : /usr/lib : /usr/local/lib)?
Probably "Req. prog. interpreter" will be missing. Thats my guess.

Both come back with "No such file or directory". The first line of strace reads:

Code Select Expand


execve("./latency", ["./latency"], [/* 13 vars */]) = -1 ENOENT (No such file or directory)


[Tele]

Code Select Expand


execve("./latency", ["./latency"], [/* 13 vars */]) = -1 ENOENT (No such file or directory)


Exactly as I thought, execve cannot find it.
Unfortunately readelf utility is not installed on your Oli. Im almost sure about the problem:
There is a missing or incompatible library in your rootfs /lib:
/lib/ld-linux.so.2
or
/lib/ld-linux.so.3
They are usually symbolic links.

For example your compiled program (by yourself with a linaro gcc and glibc 2.16?) is looking for /lib/ld-linux.so.3 but cannot find that, only /lib/ld-linux.so.2 is installed.(this is just an example, Im not sure about the details, readelf utility would be necessary for the precise proof)
Probably your toolchain uses newer (or not the same at least) libc than installed on your Oli.

What is the source of your rootfs, how did you get it? Its a downloaded rootfs.cpio, or you have built it by your own hands, or something big distro like Ubuntu, or Debian?
Is there gcc installed on your Oli? ( gcc -v gives the base of version (gcc4.6.3 or gcc 4.7.2 or gcc4.7.2linaro2012...) and version of glibc) You should use similar cross-compiler (same gcc version and same glibc) on your desktop PC.
Probably you have to install libc6-arm package on your Oli, and the installing process depends on many things (above questions and more...does Oli have an internet connection, is there any package handler(apt, dpkg, rpm, opkg) installed...so on)

If youre willing to give me some datas I can send you a prepared 'buildroot' configuration, and then you can build a rootfs for yourself. Its a simple process (run this and that, then 'hit enter and wait'), although it takes some time,  1..2 hours. Buildroot builds its own toolchain, and builds rootfs with that, so your compiled user programs cannot be incompatible with rootfs anymore.
Datas needed for that:
Which Oli card do you have (Olinuxino, Oli-WIFI, Oli-MICRO), kind of ethernet adapter (usb stick or wifi?) if you wanna connect to internet: IP address (static or dhcp) gateway address, DNS server address, timezone (US/Eastern or US/Pacific or Central or what?)
Of course you can reconfigure anything, anytime in your rootfs.

[Tele]

Sorry for being offtopic in xenomai thread. I will send personal messages to Eric about this problem, I promise.

UMinded, will you share your new timer configurations, a few days ago you said you were changing timers to get PLL6/6 clocksource working on them.

[ehj666]

What is the source of your rootfs, how did you get it? Its a downloaded rootfs.cpio, or you have built it by your own hands, or something big distro like Ubuntu, or Debian?

I downloaded it here:
wget http://hands.com/~lkcl/mele_debian_armhf_minimal.cpio.gz
I have been documenting what I have been doing on my blog here:
http://lcncolinuxino.blogspot.com/p/building.html

Is there gcc installed on your Oli? ( gcc -v gives the base of version (gcc4.6.3 or gcc 4.7.2 or gcc4.7.2linaro2012...) and version of glibc) You should use similar cross-compiler (same gcc version and same glibc) on your desktop PC.

There is now. I went ahead and setup a local tool chain to build my ultimate objective, Linuxcnc. I believe I have a working tool chain to build that, which I expect would work for Xenomai.

If youre willing to give me some datas I can send you a prepared 'buildroot' configuration, and then you can build a rootfs for yourself. Its a simple process (run this and that, then 'hit enter and wait'), although it takes some time,  1..2 hours. Buildroot builds its own toolchain, and builds rootfs with that, so your compiled user programs cannot be incompatible with rootfs anymore.
Datas needed for that:
Which Oli card do you have (Olinuxino, Oli-WIFI, Oli-MICRO), kind of ethernet adapter (usb stick or wifi?) if you wanna connect to internet: IP address (static or dhcp) gateway address, DNS server address, timezone (US/Eastern or US/Pacific or Central or what?)
Of course you can reconfigure anything, anytime in your rootfs.

The Oli card is the A13-Olinuxino-wifi, the interface is wifi but I also have a USB to Ethernet adapter. Networking is setup using DHCP, EST time zone.

Ideally I would like to document the whole build process. I think cross compiling from Debian / Ubuntu would be a common approach in addition to as much as can be built locally.

BTW, I am fairly tied up until the weekend, so it will probably be then before I have time to do any serious work.

[uMinded]

Sorry for the hiatus, I dropped my laptop and shattered the screen so I worked some overtime to get a new one. Tomorrow is my first day off in quite some time.

It is possible to dump those registers from user space, with a regular user application, I have uploaded a little sample onto https://code.google.com/p/a13-olinuxino/ ,it can be handy if you wanna be sure what is their current contents.

Thanks for that program, I was dumping about 30 registers in the kernel and its was causing some glitches and slowdowns. Also when you dump the registers make sure you use the virtual addresses and the physical ones do not act the same and some even give weird byte size errors. I imagine their is something similar to bit-banding going on so you have atomic access to the registers but I did not dig deeper.

Here is my code modifications, very simple and have been proven to work:

arch/arm/march-sun5i/clock/ccmu/ccm_sys_clk.c: (Line 930)

Code Select Expand


            //aw_ccu_reg->Pll6Ctl.FactorN = tmpFactorN;
            //aw_ccu_reg->Pll6Ctl.FactorK = tmpFactorK;
    aw_ccu_reg->Pll6Ctl.FactorN = 25;
            aw_ccu_reg->Pll6Ctl.FactorK = 2;

That above will put PLL6 running at 1800MHz and provide a 300MHz clock to Tmr0 and Tmr1

arch/arm/march-sun5i/core.c

I would put out a patch but I have a ton of other files I modified and I need to create a new clean folder before I can get around to that.

So I simply dump the timer registers twice in a row. I know the rate of Tim2 as its the kernel scheduling clock I can figure out the speed of Tmr0 and Tmr1

Results:

Code Select Expand


Timer0_Delta = 1423529
Timer1_Delta = 1423495
Timer2_Delta =    7176

Timer2 is running off HOSC25M/16 so 1.5MHz then 1.5MHz/7176*1423495 = 297.5MHz (Essentially 300MHz)


[Tele]

Eric, I have sent personal message about your things, check your mailbox please.

Sorry for the hiatus...

No problem, although I thought you were escaped for good.
My question was a few days ago, I've been walking my own way, since then. I got very similar results to yours.
I started with setting PLL6 higher, Its default 600MHz.
In file 'arch/arm/mach-sun5i/clock/clock.c'  in function 'clk_init()', line 171:

Code Select Expand


...
    tmpSclk = &ccu_sys_clk[AW_SYS_CLK_PLL6];
    tmpSclk->clk->rate  = 600000000;
    tmpSclk->set_clk(tmpSclk->clk);
    tmpSclk->clk->onoff = AW_CCU_CLK_ON;
    tmpSclk->set_clk(tmpSclk->clk);
    tmpSclk = &ccu_sys_clk[AW_SYS_CLK_PLL6M];
    tmpSclk->clk->rate  = 100000000;
    tmpSclk->set_clk(tmpSclk->clk);
    tmpSclk = &ccu_sys_clk[AW_SYS_CLK_PLL62];
    tmpSclk->clk->rate  = 300000000;
    tmpSclk->set_clk(tmpSclk->clk);
    tmpSclk->clk->onoff = AW_CCU_CLK_ON;
    tmpSclk->set_clk(tmpSclk->clk);
...

I tested this part, and only this part, nothing else were changed in original sunxi kernel, no timers were set to PLL6/6.
SYS_CLK_PLL6 = 1800000000 did not work, kernel got frozen while was setting MMC card's clock. PLL6 has some kind of connection with MMC clock. Hmmmm.
SYS_CLK_PLL6 = 1200000000 does work, kernel can boot, then doing its job, looks healthy. Wooot !
What else do I know about PLL6:

• AW_SYS_CLK_PLL6 cannot be set higher than 950000000 if you have SATA2 drive.
  Who cares. We are in mach-sun5i directory, its an A13, we wish we had a SATA2 interface with a biiiig 512GB SSD drive, but we have no, and will never have.
  But in a mach-sun4i directory, with A10 Soc, that could be a limitation. PPL6=950MHz means 160MHz timer frequency, still it must be more than enough.
• AW_SYS_CLK_PLL6M must be set to 100000000 if SATA interface is used. Same as above. We just don't care.
• AW_SYS_CLK_PLL62 always must be set to AW_SYS_CLK_PLL6 divided by 2. Its a strict rule.

Next step was the timers. We don't need timer4, because timer1 is free and idle in the original kernel. Timer0, timer1, timer2, this trio will do. In theory all three timer's clock can be set to PLL6/6. (timer4,5 can't be set). In theory only. Almost. I have found that, if timer2 source is set to PLL6/6 then kernel will freeze at the first network operation. My kernel tries to start ntpd daemon at booting, so my kernel cannot boot.
Only timer0 and timer1 source can be set to PLL6/6 without any problems. Reasons are unknown at the moment. Do we care at all?

One more thing. I tested sunxi-v3.2.24-r2, and Crubille's ipipe patch works on it like charm, without any modification ! We have no reason to use r1 any more, because probably r2 is better (sunxi says: "disp dynamic mode, leds, and assorted fixes and improvements before jumping to 3.4.29" ).

Here is a way to make a working xenomai kernel.:
Put the downloaded patch (ipipe-linuxsun5i-3.4.24-r2.patch) in an empty work directory.
Then:

Code Select Expand


wget https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r2.tar.gz
tar xf linux-sunxi-sunxi-v3.4.24-r2.tar.gz
cd linux-sunxi-sunxi-v3.4.24-r2
patch -p1 < ../ipipe-linuxsun5i-3.4.24-r2.patch

Github works slowly, be patient (Connecting...), it assembles the tarball on the fly.

There is no config file inside. You have to use your favourite .config file or you can use the default one:

Code Select Expand


cp ./arch/arm/configs/a13_defconfig ./.config


You can modify the configuration:

Code Select Expand


make ARCH=arm menuconfig


and then make the kernel in the usual way:

Code Select Expand


make ARCH=arm CROSS_COMPILE=<xcompiler prefix> uImage
mkdir out
make ARCH=arm CROSS_COMPILE=<xcompiler prefix> INSTALL_MOD_PATH=out modules
make ARCH=arm CROSS_COMPILE=<xcompiler prefix> INSTALL_MOD_PATH=out modules_install

,where your <xcompiler prefix> is arm-linux-gnueabihf or arm-cortex_a8-linux-gnueabi or something like that.

...but I have a ton of other files I modified...

What else did you modify?  You made me curious. Speak! 

[uMinded]

Tele: SYS_CLK_PLL6 = 1800000000 did not work, kernel got frozen while was setting MMC card's clock. PLL6 has some kind of connection with MMC clock. Hmmmm.

I found that setting the tmpSclk->clk->rate  = 1800000000; does not work as the giant switch statement that sets PLL6M recieves the speed as 1200000000. But in that same switch statement if you manually set N and K values then PLL6M sets the M value to suite and all is good. If we wanted a more configurable setting then we would need to track down where that rate is limited back to 1200000000 and pepper some defines around.

Tele:  I have found that, if timer2 source is set to PLL6/6 then kernel will freeze at the first network operation. My kernel tries to start ntpd daemon at booting, so my kernel cannot boot.

I also had this problem but it turns out to be nothing to do with the timer for me. If the module clock PLL6M is not set to 100MHz I got some strange errors. I had my PLL6 as (24MHz * 3 * 27) / 3 / 6 = 108MHz and figured it was close enough (this gives a 324MHz timer clock which is absolute max) and my kernel would always freeze when loading the network and loading modules.

Tele:  I tested sunxi-v3.2.24-r2, and Crubille's ipipe patch works on it like charm, without any modification ! We have no reason to use r1 any more

If you check out the mergers after a few simple mods on .29 the entire branch was merged into the stable reference so we are in very good standing with a few minor upstream changes. I have been working on compiling the kernel from the master branch but stopped to sort out what some of these internal clocks feed.

Tele: AW_SYS_CLK_PLL6 cannot be set higher than 950000000 if you have SATA2 drive.
Who cares. We are in mach-sun5i directory, its an A13, we wish we had a SATA2 interface with a biiiig 512GB SSD drive, but we have no, and will never have.

I agree that the sun5i directory does not need these limitations however after we make changes we need to make them compatible  with the current coding standards to have any hope of making a difference.

------------------------

One LARGE note on PLL62, it is horribly configured in the kernel as it ignores any settings and defines itself in a few places as just 200000000UL instead of even using the clock structure. This is bad as the power management system has the ability to switch to this clock. I will be adding a config option to the kernel and wrapping things so that if any power management is enabled the timers clocks will downgrade to 24MHz to suit. I did not bother tracing the power management structure as I do not have any or plan to use any, but its a very large issue to note.

[Tele]

...would need to track down where that rate is limited back to 1200000000 and pepper some defines around....

Mmmmm. Now I understand your dirty-direct settings on N and K.

I have found another data:
If we have a SATA I drive, we must not set SYS_CLK_PLL6 higher than 600000000. Ooops gotcha. This is where the default magic 600MHz comes from.
Same as earlier: this is not important if we set for A13/sun5i, but it is important if we set for A10/sun4i (Cubieboard, or something like that). This brings the maximum high-res timer frequency down to 100MHz for A10 cards. (If it uses an old SATA I drive of course)

[uMinded]

I have made quite a bit of progress today while watching really bad sci-fi movies.

1) Modified u-boot for one single EXT4 partition (Makes everything easier one its only one partitions to worry about)

1) Complete debian debootstrap tutorial complete with apt for armel

2) Initial testing of linuxcnc-v2.5.2

I am dumping some pretty badly edited version into the wiki, I will edit them while I am at work when I don't have an oli to work on.

[uMinded]

I think we have hope! But time for me to go to bed...

Code Select Expand


uminded@a13-olinuxino:~/linuxcnc-rtos/bin$ sudo ./halcmd status
HAL locking status:
  current lock value 0 (00)
  HAL_LOCK_NONE - nothing is locked
HAL memory status
  used/total shared memory:   1337/262000
  active/recycled components: 2/0
  active/recycled pins:       9/0
  active/recycled parameters: 2/0
  active/recycled aliases:    0/0
  active/recycled signals:    0/0
  active/recycled functions:  1/0
  active/recycled threads:    0/0
 
uminded@a13-olinuxino:~/linuxcnc-rtos/bin$ sudo ./halcmd show comp
Loaded HAL Components:
ID      Type  Name                                      PID   State
    12  User  halcmd22705                               22705 ready
     6  RT    siggen                                          ready

uminded@a13-olinuxino:~/linuxcnc-rtos/bin$ sudo ./halcmd show pin
Component Pins:
Owner   Type  Dir         Value  Name
     6  float IN              1  siggen.0.amplitude
     6  bit   OUT         FALSE  siggen.0.clock
     6  float OUT             0  siggen.0.cosine
     6  float IN              1  siggen.0.frequency
     6  float IN              0  siggen.0.offset
     6  float OUT             0  siggen.0.sawtooth
     6  float OUT             0  siggen.0.sine
     6  float OUT             0  siggen.0.square
     6  float OUT             0  siggen.0.triangle

uminded@a13-olinuxino:~/linuxcnc-rtos/bin$ sudo ./halcmd loadrt threads name1=test-thread period1=1000000

uminded@a13-olinuxino:~/linuxcnc-rtos/bin$ sudo ./halcmd show thread
Realtime Threads:
     Period  FP     Name               (     Time, Max-Time )
    1000000  YES           test-thread (        0,        0 )

uminded@a13-olinuxino:~/linuxcnc-rtos/bin$ sudo ./halcmd  addf siggen.0.update test-thread

uminded@a13-olinuxino:~/linuxcnc-rtos/bin$ sudo ./halcmd start     

uminded@a13-olinuxino:~/linuxcnc-rtos/bin$ sudo ./halcmd show pin
Component Pins:
Owner   Type  Dir         Value  Name
     6  float IN              1  siggen.0.amplitude
     6  bit   OUT         FALSE  siggen.0.clock
     6  float OUT     0.7542514  siggen.0.cosine
     6  float IN              1  siggen.0.frequency
     6  float IN              0  siggen.0.offset
     6  float OUT        -0.772  siggen.0.sawtooth
     6  float OUT     0.6565858  siggen.0.sine
     6  float OUT            -1  siggen.0.square
     6  float OUT         0.544  siggen.0.triangle

uminded@a13-olinuxino:~/linuxcnc-rtos/bin$ sudo ./halcmd show pin
Component Pins:
Owner   Type  Dir         Value  Name
     6  float IN              1  siggen.0.amplitude
     6  bit   OUT          TRUE  siggen.0.clock
     6  float OUT    -0.8409446  siggen.0.cosine
     6  float IN              1  siggen.0.frequency
     6  float IN              0  siggen.0.offset
     6  float OUT         0.184  siggen.0.sawtooth
     6  float OUT    -0.5516459  siggen.0.sine
     6  float OUT             1  siggen.0.square
     6  float OUT        -0.624  siggen.0.triangle


[ehj666]

2) Initial testing of linuxcnc-v2.5.2

I am dumping some pretty badly edited version into the wiki, I will edit them while I am at work when I don't have an oli to work on.

Whoa, I did not realize you were working on that part too. How far did you get? I ran into a dependency problem with a set of header files. One of the guys on the lcnc mailing list just removed that dependency for me yesterday and I have not had a chance to test it.

Have you been working from this:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Debian_Wheezy_Linux-Rt_Compile_LinuxCNC

or something else?

I would really like to know what you have done just so we are not duplicating our efforts.

If you need help with the doc, I am happy to help out.

Good job, BTW.

[uMinded]

Whoa, I did not realize you were working on that part too. How far did you get? I ran into a dependency problem with a set of header files. One of the guys on the lcnc mailing list just removed that dependency for me yesterday and I have not had a chance to test it.

Have you been working from this:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Debian_Wheezy_Linux-Rt_Compile_LinuxCNC

I was on a roll yesterday and the stars seemed to align. It is by far a fully working LinuxCNC build though, about 33 of the tests fail but it does compile without any errors and the only warnings are that kernel headers are being used which is not a problem on our custom builds. Pretty much all of the GUI programs do not run but the HAL layer is fully functional it seems.

I found the only way to get the program compiled was to do it on the olinuxino which is surprisingly quite fast at compiling! With it being on the target hardware their was no complaints about missing files or wrong locations as autotools was able to put everything in its place. I will dump a crude page on the wiki so have a look if you would like.

If you want commit access to the wiki just PM me your gmail address and I will add you.

NOTE: LinuxCNC currently has no pin toggling capabilities in rtapi/rtapi_bitops.h, I put null functions in to get it to compile. I recommend we create a HAL component hal_parport to access our hardware so as to leave the LinuxCNC code base unaffected.