Xenomai for A13 - A10

[ehj666]

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.

Feel free to get on that kind of roll any time.

As to GUIs, even the Python based ones? I was looking to do one specifically for the A13-LCD7-TS using Glade + Python or possibly Gladevcp

http://www.linuxcnc.org/docs/2.5/html/gui/gladevcp.html

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.

While Tele advised,and for good reason, cross compiling that seems to agree with what the lcnc folks working on the Beaglebone found as well.

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

Will do.

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.

Yea, that is the next problem to address once the base lcnc is working. I also do not believe the Oli is going to be fast enough to directly drive stepper motors (or pwms for that matter), so need some way of communicating velocity information off to something that can, like an Arduino, FPGA, etc.

[crubille]

Hello everybody,

I am glad xenomai work with sunxi-v3.4.24-r2, and i am going to use it now.

Progress with LinuxCNC is very important too, and i think it will be a good idea to create a new topic in the A13 part. Not only because there is a lot of message here, but also because visibility would be better.

I am not surprised of the good behaviour of the A13 in compiling large code as i use it too compile the kernel too (in this case, it needs some time of course).

I am nearly sure my xenomai patch work on A10 without any change. This is the main reason i don't attempt to do tricky things with pll6. In the new patch, the sun4i part is already done but still not tested.

[uMinded]

As to GUIs, even the Python based ones? I was looking to do one specifically for the A13-LCD7-TS using Glade + Python or possibly Gladevcp

I also do not believe the Oli is going to be fast enough to directly drive stepper motors (or pwms for that matter), so need some way of communicating velocity information off to something that can, like an Arduino, FPGA, etc.

I did not try any of the GUI's as I run headless and the core HAL functionality is the main goal.

As for the Oli not being fast enough that's kind of the whole point of this Xenomai on A13 project! If you just need simple gcode to movements then the RepRap project and arduino have that covered, if you want LinuxCNC and HAL then theirs SPI PIC32 addons for the Rasberry PI already developed. However both of these are only capable of around 30kHz step generation. Given my numbers I have tested with I think I can get at least 31KHz worst case.

I will start a new thread for LinuxCNC on the Oli.

[Tele]

I succesfully ported the ipipe patch to sunxi-v3.4.29-r1 kernel. For the time being this is the last tagged sunxi kernel.

Its based on Crubille's 3.4.24 patch, had to modify that, at about 10 spots.
It seems ok, no problems so far.
High-res timer runs at 200MHz (PLL6 = 1.2GHz), I set it on the regular way, uMinded you can hack it to 300MHz, if you want.

Load your .config (or a13_defconfig) then highly recommended to go through it, because there are many new options (for example a new gpio driver, not that ugly one).

ipipe-linuxsun5i-3.4.29-r1.patch

Vanilla sunxi kernel source:
https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.29-r1.tar.gz

[uMinded]

I succesfully ported the ipipe patch to sunxi-v3.4.29-r1 kernel. For the time being this is the last tagged sunxi kernel.

Awesome, Thanks!

I have gone over the commits and this does have quite a few improvements and the proper GPIO driver is great to have. The trend seems to be to merge as much common code between the sun3/4/5i architectures as possible which makes since but looking at the new layout I am a bit cautious of my 300MHz hack.

I think the current setting of PLL6 @ 600MHz is the good default setting for the base kernel as 99% of people will never touch it. As we are interested in its value then I propose we wrap that setting with arch defines so that anyone using the ipipe patch on an A10 will not loose their SATA but the A13's can have it set higher. AS it only pertains to us we might as well be the maintainers right?

I still have no idea if we even need a 300MHz clock. Once we have the HAL Layer running with GPIO I want to do a IO response test with my scope so see if its even needed over 100MHz.

[crubille]

Hello everybody,

I patch roughly the AMBA bus clocks divisors and the results are very interesting and the A13 become a rather decent xenomai platform :

first "echo 0 > /proc/xenomai/latency"  so there is no pre calibration of the delay.

xenomai task in user mode:
"latency -p 100" minimal time from 8.9 micro seconds to 4.0 micro seconds - more than twice
"latency -p 100" average time from 10.4 micro seconds to 4.8 micro seconds - more than twice

xenomai driver in kernel mode:
"latency -p 100 -t 2" minimal time from 4.58 micro seconds to 1.33 micro seconds - more than three times faster
"latency -p 100 -t 2" average time from 5.58 micro seconds to 1.77 micro seconds - more than three times faster

"latency -p 20 -t 2" run fine without overloading the A13.

"preempt -p 100" minimal time from 333 nanos to 124 nanos and average from 374 nanos down to 166 nanos.

Look at this:

https://www.olimex.com/forum/index.php?topic=1049.15

[Tele]

Crubille you are genius

This is a very adventurous step, maybe a little bit risky, but can be very advantageous. I'm gonna test it rigorously, and if its stable, I'm gonna port it to 3.4.29 kernel of course.

[crubille]

In comments somewhere in hte sun5i parts, i found comments saying
AXI max 450 MHz, AHB max 250, APB max 125 -- but I don't know if this true, and the (non used code around is not correct).
- Slower 450 MHZ ARM soc have AHB around 100 MHz.
- I don't touch AXI

So AXI @ 333, AHB @ 166 and APB @ 83 look coherent and not so risky.

But, if the comment from the code are true and come from a secret but accurate spec for A13,
AXI @ 450, AHB @ 225 and APB @ 112,5  will be significantly better but to do it, CPU should be set down to 900 MHz (but perhaps the whole system will be faster at least for irq/timer intensive use).

[olimex]

I just asked Allwinner what these frequencies should be and this is what they answered:

here is the clock distribution:



Allwinner recommends the second divider to be used so:

AXI=CPU-CLK/2,AHB=AXI/2,APB0=AHB/2

or

AXI=1008/2=504MHZ,AHB=504/2=252MHZ,APB0=252/2=126MHZ

[olimex]

another e-mail just arrived from Allwinner they recommend speed change to be done in steps:

we check two frequency point: 204Mhz, 408Mhz, 816Mhz and 1200Mhz.
*             if increase cpu frequency, the flow should be:
*               low(1:1:1:2) -> 204Mhz(1:1:1:2) -> 204Mhz(1:1:2:2) -> 408Mhz(1:1:2:2)
*               -> 408Mhz(1:2:2:2) -> 816Mhz(1:2:2:2) -> 816Mhz(1:3:2:2) -> 1200Mhz(1:3:2:2)
*               -> 1200Mhz(1:4:2:2) -> target(1:4:2:2) -> target(x:x:x:x)
*             if decrease cpu frequency, the flow should be:
*               high(x:x:x:x) -> target(1:4:2:2) -> 1200Mhz(1:4:2:2) -> 1200Mhz(1:3:2:2)
*               -> 816Mhz(1:3:2:2) -> 816Mhz(1:2:2:2) -> 408Mhz(1:2:2:2) -> 408Mhz(1:1:2:2)
*               -> 204Mhz(1:1:2:2) -> 204Mhz(1:1:1:2) -> target(1:1:1:2)

[uMinded]

Thanks for the info, I can't believe that the Sunxi kernel is so slow without a good reason? Maybe back in the day they did not have very good drivers or something and it was never turned back up to its full speed.

This should defiantly be brought to their attention though.

[olimex]

actually I did and Turl said that there is option frequencies to be changed via cpufreq governor https://www.olimex.com/irc?date=2013-03-15

[crubille]

Hello,

Three points:

I look at the u-boot part (get from git), and from u-boot, A13 Olimex is set AXI at 333, AHB at 166, APB at 83 - it is not so bad even if the setting from allwinner are better.

On my kernel clock frequency manager is disable.
If I boot on a SD with the u-boot I recompile, i get the AXI, AHB, APB values from u-boot. The very slow vAHB and APB are from the u-boot on the ready to use SD-card i get from Olimex. Does anybody know when this has been upgraded?

It is not at this point a kernel issue.



As I am here, i play with the ram parameters. They are not set or reset anywhere else.

I test:
- 528 MHz the board boot, run test half an hour and ... fail
- 504 MHz no problem, but i don't test it for a very long time ... Perhaps good enough for games but the topic here is real time.
- 480 MHz can be ok, i will test it
- 456 MHz and cas 6 has few interest as
- 432 MHz can run at CAS 5! This is my favourite at this time. Run fine with AXI at 504, AHB at 252, APB at 126. Xenomai run fine and the nbench-byte give a very good place for A13 Olimex.



Then, I remember (and search) for an old message about 40 MHz issue:
Attempt to get the  LCD/VGA display running with 1024x768 or better end with a message saying that there is somewhere a 40 MHz obscure limit.
A 40 MHz limit, now we know one , the old AHB rate ... and there is no trace for another one.

Perhaps, perhaps, it could have some interest to rerun some tests about that?

[awallin]

Hi all,

I was wondering what the latest progress is with xenomai on A13 - A10s ?

I tried applying
http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch
to this repo
git clone git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-3.4

but I get a lot of "error: patch failed" lines. is that correct?
Where do I find step-by-step instructions for the standard xenomai-2.6.2.1 procedure?

thanks,
Anders

[Tele]

Hi Anders,

I have found that 3.4.24 and 3.4.29 kernels were a little bit unstable, they had some tendency to get frozen once or twice a day.

I don't know the reason sorry. So I returned to 3.4.12 kernel and this is very stable. I've been using it for 2 months now. I don't remember even 1 crash neither.

I have uploaded a xeno version of it onto uMinded's site, I hope he wont get angry with me. The above patches about clocks and dividers (Crubille) are all applied, so its the fastest (AXI=504MHz, no more possible on Oli card) kernel.

If you are interested:
https://code.google.com/p/a13-olinuxino/downloads/list

SUNXI Linux Kernel v3.4.12-r4 patched with Xenomai 2.6.2.1
Build instructions on that page.

After making you can find 'uImage' in the directory:
arch/arm/boot

You can find kernel modules in the directory:
out

If you want to make an SD card, you will need a script.bin and u-boot also. Read uMinded's instructions about those things on his site.