Olimex Support Forum

Hello.

I just order an A13 board. I need xenomai to some project I have, the first project is to port xenomai on it.

I expect to send you good news in the future.

Paul

----------------------------------------------------------------------------------------------------------
Message edited:

Here is a first port for OLINUXINO A13

http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch

and apply the standart xenomai procedure.

Running it, i get

latency -t 2 -p 100

RTT|  00:00:01  (in-kernel timer handler, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      5.583|      6.265|     11.167|       0|     0|      5.583|     11.167
RTD|      6.125|      6.258|     10.917|       0|     0|      5.583|     11.167
RTD|      5.500|      6.270|     12.000|       0|     0|      5.500|     12.000


"lat worst" is mostly under 20 us but can go up for 30 ns.

(To get these value, i tune the Olinuxino A13 setting the dram cas to 5).

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

The patch for the last version is here

http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.patch

It include :
       - priority based interrupt controller muting
       - (untested as i have no A10 board) support for the sun4i.

To get the sunxi kernel

tar xf linux-sunxi-sunxi-v3.4.24-r2.tar.gz


Have fun.

I am trying to do the same thing. So far to not a lot of success since I have yet to get a kernel I built to boot.

Please keep us posted.

At this point, i load

- xenomai-2.6.2.1 with patchs for 3.0.36 and for 3.4.6.
- the sunxi 3.0 and 3.4 kernels
- the patch 3.4.1 ... up to 3.4.6 seems to be already applied on the 3.4 sunxi kernel. So it is not clear what is the closest linux vanilla kernel version.
- appling the patch from the xenomai distribution on the sunxi kernels, there is not so many fails.
  Here are the files where the patchs cant obviously apply in either kernels:
          saving rejects to file arch/arm/include/asm/cacheflush.h.rej
          saving rejects to file arch/arm/include/asm/pgtable.h.rej
          saving rejects to file arch/arm/kernel/smp.c.rej
          saving rejects to file arch/arm/vfp/entry.S.rej
          saving rejects to file arch/arm/vfp/vfphw.S.rej

  and two more files from the sunxi 3.0.8
          saving rejects to file arch/arm/vfp/vfpmodule.c.rej
          saving rejects to file kernel/sched.c.rej

I start to look at these files.

Quote from: crubille on February 07, 2013, 12:05:38 AM

At this point, i load

- xenomai-2.6.2.1 with patchs for 3.0.36 and for 3.4.6.
- the sunxi 3.0 and 3.4 kernels
- the patch 3.4.1 ... up to 3.4.6 seems to be already applied on the 3.4 sunxi kernel. So it is not clear what is the closest linux vanilla kernel version.
- appling the patch from the xenomai distribution on the sunxi kernels, there is not so many fails.
  Here are the files where the patchs cant obviously apply in either kernels:
          saving rejects to file arch/arm/include/asm/cacheflush.h.rej
          saving rejects to file arch/arm/include/asm/pgtable.h.rej
          saving rejects to file arch/arm/kernel/smp.c.rej
          saving rejects to file arch/arm/vfp/entry.S.rej
          saving rejects to file arch/arm/vfp/vfphw.S.rej

  and two more files from the sunxi 3.0.8
          saving rejects to file arch/arm/vfp/vfpmodule.c.rej
          saving rejects to file kernel/sched.c.rej

I start to look at these files.

Hi crubille,

Have you tried these things:
https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.0.36-0.tar.gz
https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.0.36-r1.tar.gz

sunxi-3.0 and sunxi-3.4 are not the best idea because they are always the last versions,
currently (9th of February)
3.0 -> 3.0.57
3.4 -> 3.4.29

And they are changing, tomorrow they can be newer and newer.

FWIW, here is what I have managed so far.

Notes:

• I had previously built a generic kernel and copied a13_defconfig from arch/arm/configs primarily based on the instructions found here:
  https://www.olimex.com/wiki/Build_Bootable_SD_Card_with_Debian (https://www.olimex.com/wiki/Build_Bootable_SD_Card_with_Debian)


• I am using Ubuntu 12.04 as the build envirnonment.

The latest kernal on which Xenomai appears to work is 3.0.36. Here are the build instructions up to needing to implement a high res timer.


mkdir kernel
cd kernel
git clone https://github.com/linux-sunxi/linux-sunxi linux-sunxi
git checkout v3.0.36
cd ..

mkdir xenomai
cd xenomai
wget http://download.gna.org/xenomai/stable/LATEST_IS-v2.6.2.1.tar.bz2
tar -jxf LATEST_IS-v2.6.2.1.tar.bz2
cd xenomai-2.6.2.1

scripts/prepare-kernel.sh --arch=arm \
  --adeos=/ksrc/arch/arm/patches/adeos-ipipe-3.0.36-arm-* \
  --linux=../../kernel/linux-sunxi


Now copy a13_defconfig referenced above to kernel/arch/arm/configs.

I will include the next make command below, but this blow out on an error because it needs a high res timer.


cd ../..
cd kernel/linux-sunxi
make ARCH=arm CROSS_COMPLIE=arm-linux-gnueabi- a13_defconfig


I am now working my way through this:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Hardware_timer (http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Hardware_timer)

To figure out how to do that. If anyone has already done this for the A13-olinuxino (ARM A8) or has any insight to simplify the process, I am all ears.

My blog on this can be found here:
http://lcncolinuxino.blogspot.com/ (http://lcncolinuxino.blogspot.com/)

Hello

Tele, you are right but it is very easy to correct the very littles problems patching the 3.4 sunxi kernel from the xenomai patch for 3.4.6. I will try the patched kernel (without ipipe of course on the arm) soon, but after testing the unpatched one.

I still attempt to patch the 3.0.36 stable version but i have to fixe the patch for arch/arm/vfp/vfphw.S : the modification in the patch are already partially applied, but not in the same order ...


ehj666: really, you get the sunxi kernel patched just fine with the standart xenomai patch?
No .rej files anywhere? I test exactly what you do.

I know the tutorial to port xenomai on arm platform and sure we have to use it.

Quote from: ehj666 on February 10, 2013, 02:55:57 AM
FWIW, here is what I have managed so far.

Notes:

• I had previously built a generic kernel and copied a13_defconfig from arch/arm/configs primarily based on the instructions found here:
  https://www.olimex.com/wiki/Build_Bootable_SD_Card_with_Debian (https://www.olimex.com/wiki/Build_Bootable_SD_Card_with_Debian)


• I am using Ubuntu 12.04 as the build envirnonment.

The latest kernal on which Xenomai appears to work is 3.0.36. Here are the build instructions up to needing to implement a high res timer.

Code Select Expand


mkdir kernel
cd kernel
git clone https://github.com/linux-sunxi/linux-sunxi linux-sunxi
git checkout v3.0.36
cd ..



My blog on this can be found here:
http://lcncolinuxino.blogspot.com/ (http://lcncolinuxino.blogspot.com/)

Hi Eric and Crubille,

Sry Eric, I think you are not on the right way. Yet.
Because you download the vanilla v3.0.36 kernel from github. Its not modified for sunxi yet. There is no Allwinner A10 or A13 configuration inside, so it wont work on Olinuxino A13. Try 'make menuconfig' and you will see. This is why you can patch it with the adeos-ipipe-3.0.36*.patch without any error. You have found the original kernel, I think.
Sunxi guys modified it and released the sunxi-3.0.36 kernel (2 versions of that) , what I have shown to Crubille before.
And the adeos-ipipe*.patch fails on sunxi-3.0.36-r1, at about 10 places. Just like Crubille pointed that. Thats the real problem.
Our task is obvious I think. We have to find the difference between 'v3.0.36' and 'sunxi-3.0.36-r1' and we have to modify the adeos-ipipe*.patch to work on sunxi-3.0.36-r1 (or maybe on sunxi-3.0.36-0 would be nice also).
Those problems you mentioned, (high res timer...so on) will be walk in the park you will see.

You can find all downloadable kernels here:
https://github.com/linux-sunxi/linux-sunxi/tags
If a kernel marked only with 'v' and a version number that one is a vanilla thingy, (like v3.0.36)
Later on the list you can find stuffs like 'sunxi-3.x.y'...those are the real things for A10,A13.

Im working on it because I want xenomai kernel as well. I keep you guys posted. I expect the same from you both.

I guess I should have realized that was too easy. I assumed the v just meant version. I also got a bunch of errors when trying to apply the Xenomai patch to the 3.0.57 version.

ehj666, i send you a private message with my mail adress.


uMinded, if you want and if you have a board, if you can check if timer2 and timer4 behave as described in this doc: http://linux-sunxi.org/A10/TIMER
An another point is: is there problems or constraints using PLL6 as base clock for the xenomai clock?


The linux sunxi kernel use timer0 as linux timer and timer2 as clock.

the points are:
- timer3 is 32khz only, so nothing to do with it.
- timer4 is ok but cant use the PLL6 base, so it can be user as xenomai timer wih 24MHz base
- timer2 can be used as xenomai clock either at 24Mhz or at PLL6/6 (in 150-200 MHz) so it can be used as xenomai clock.

What do you think about these ideas?

Paul

Here is a copy of the adeos patch for 3.0.36-r1 I used the following:

sunxi-v3.0.36-r1 (https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.0.36-r1.tar.gz)
xenomai-2.6.2.1 (http://download.gna.org/xenomai/stable/xenomai-2.6.2.1.tar.bz2)

adeos-ipipe-3.0.36-arm-1.18-11.patch.fixed (https://www.dropbox.com/s/60uzjd2uw9xtigl/adeos-ipipe-3.0.36-arm-1.18-11.patch.fixed)

I can do:
make ARCH=arm menuconfig

And I get the real time options. I will test a build once I have the arm tool chain set up.

My steps:

$ cd xenomai-2.6.2.1
$ ./scripts/prepare-kernel.sh --arch=arm \
  --adeos=./ksrc/arch/arm/patches/adeos-ipipe-3.0.36-arm-1.18-11.patch.fixed \
  --linux=../linux-sunxi-sunxi-v3.0.36-r1
$ cd ../linux-sunxi-sunxi-v3.0.36-r1


These two commands do the same thing, the Xenomai documentation makes it sound like the second version will build and then config but it only spits out a .config for me.

$ make ARCH=arm a13_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- a13_defconfig


So then I usses a uImage build like normal for a uboot setup:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage


My error I get:

In file included from kernel/xenomai/arch/generic/hal.c:44:0:
/home/uminded/Downloads/A13-RT-Kernel/sunxi-xenomai/arch/arm/include/asm/xenomai/hal.h:99:2: error: #error "Unsupported ARM machine"


I assume this is because we need to port a high resolution timer for Xenomai and add the timer definitions to this hal.c file.

Other than that it compiles with the same warnings as a vanilla sunxi kernel.

I have ported over IPIPE for the sun5i architecture using Timer2 with PLL6/4 as its source giving a 300MHz tick. I can compile to an error free uImage but I have no hardware so no idea if it will even boot.

I will fork the linux-sunxi 3.0.36 to my own git and compile patches or even just incorporate the changes completely (Xenomai uses symbolic links to its own directory which is a pain)

Would anybody be willing to give my kernel a try? I think I am going to try and get a board next week if I can but it will be two weeks at best before I know if it works without any help.

Quote from: uMinded on February 14, 2013, 11:15:25 PM
Would anybody be willing to give my kernel a try? I think I am going to try and get a board next week if I can but it will be two weeks at best before I know if it works without any help.

I am quite happy to give it a shot.

Quote from: uMinded on February 14, 2013, 11:15:25 PM

Would anybody be willing to give my kernel a try? I think I am going to try and get a board next week if I can but it will be two weeks at best before I know if it works without any help.

Upload it quickly. Quickly. We cant wait for it. I have an Oli Wifi board with NAND.

PS.
And of course: thank you for your great job !!!!!!!!!!

Here is my dropbox with the kernels (https://www.dropbox.com/sh/apc7j2jy2i1yj06/k_yOWOH-4o)

I am compiling the following for testing:
- vanilla 3.0.36-r1 (To make sure the base is sound)
- Xenomai 2.6.2.1   (If it boots check the kernel logs for 'Xenomai: ' lines)
- IPIPE 1.18-11     (My code to implement a 300MHz counter for the IPIPE service)

I will let you know when the IPIPE one is up for testing, thanks!

https://github.com/iceblu3710/SUNXI_XENOMAI/ is my repo for the project

Quote from: uMinded on February 15, 2013, 03:30:21 PM
- vanilla 3.0.36-r1 (To make sure the base is sound)

So uImage_sunxi-v3.0.36-r1 is a vanilla kernal? I was not able to get it to boot, and worse, there was not much to indicate what went wrong. So far I have just had time to do a quick test on booting the kernel, I have not looked into it any closer.

Here is the beginning of the boot log for a working kernel:

U-Boot SPL 2012.10-04268-gf925eea (Feb 05 2013 - 19:19:54)
DRAM: 512MB
SUNXI SD/MMC: 0


U-Boot 2012.10-04268-gf925eea (Feb 05 2013 - 19:19:54) Allwinner Technology

CPU:   SUNXI Family
Board: A13-OLinuXino
I2C:   ready
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  3  2  1  0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
Loading file "uEnv.txt" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/uEnv.txt" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
Loading file "boot.scr" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/boot.scr" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading script.bin

28156 bytes read
reading uImage

3879212 bytes read
## Booting kernel from Legacy Image at 48000000 ...
   Image Name:   Linux-3.0.57+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3879148 Bytes = 3.7 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

<6>Initializing cgroup subsys cpuset

<5>Linux version 3.0.57+


And here is the boot log of that kernel up to the point it freezes:

U-Boot SPL 2012.10-04268-gf925eea (Feb 05 2013 - 19:19:54)
DRAM: 512MB
SUNXI SD/MMC: 0


U-Boot 2012.10-04268-gf925eea (Feb 05 2013 - 19:19:54) Allwinner Technology

CPU:   SUNXI Family
Board: A13-OLinuXino
I2C:   ready
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  3  2  1  0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
Loading file "uEnv.txt" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/uEnv.txt" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
Loading file "boot.scr" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/boot.scr" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading script.bin

28156 bytes read
reading uImage

3825264 bytes read
## Booting kernel from Legacy Image at 48000000 ...
   Image Name:   Linux-3.0.36+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3825200 Bytes = 3.6 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...



Quote from: ehj666 on February 15, 2013, 05:20:45 PM
And here is the boot log of that kernel up to the point it freezes:
...

Hi Eric and uMinded,

I assume that you are logging on a serial port, and it looks like kernel freezes at the starting point.
Im almost sure that the problem is the bad uart port number. There is a config parameter for the kernel .config file (if you type make menuconfig):
CONFIG_SW_DEBUG_UART
and it must be 1 on my Oli card. In the A13_defconfig, that param is 0.

uMinded, please compile the kernel with that parameter also (System Type --> UART to use for low-level debug)
, and/or share the configuration file to check.

Eric, you said that vanilla didnt work, I think the problem was just the same. Type 'make menuconfig' then set the above parameter to the opposite value as the current one (0 or 1), then make a try.

Quote from: Tele on February 15, 2013, 06:32:25 PM
CONFIG_SW_DEBUG_UART

Maybe I was confusing, I explain this in details. The default config of the kernel is the .config file in the root of the kernel source dir. (it begins with dot so its hidden). If you build the kernel without that current config file than you have to set the default config explicitly.
You just do it with:

make ARCH=arm a13_defconfig

The make will use the ./arch/arm/configs/a13_defconfig file for configuration.

But if you copy the default configuration (you wanna modify it or something):

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

And then you modify this .config by:
make menuconfig
then you must not call make with 'a13_defconfig' anymore, just simply

make

is enough to build the whole kernel.
Now you can see the problem:
In the sunxi_3.0 kernel in the a13_defconfig file the CONFIG_SW_DEBUG_UART=1
In the sunxi_3.0.36 kernel in the a13_defconfig file the CONFIG_SW_DEBUG_UART=0 so the the kernel sends the characters to the other console uart, you wont see nothing but "Starting Kernel..." then big silence.

Im sorry if I repeated obvious well known boring things, just I thought I wasnt exactly clear before.
Have nice weekend.

Thanks for the info, I don't have a board so I was just compiling what I thought I needed. Can anybody post a known working .config to pastebin.com so I can make sure I have a stable base?

Also my router and adsl modem died in a power outage yesterday in the early morning so I am on my cell phone right now and can not upload very quick. I will see if I can get the uImage uploaded at least but the modules are a 600mb beast so I will upload that when I get internet back. (Hopefully by this evening)

EDIT:
I switched my files to google drive as my dropbox is to small.
3.0.36-r1 SW_DEBUG_UART=1 (https://docs.google.com/file/d/0B0HKuT2T-RfEaWFLbzJkVi1VeXM/edit?usp=sharing)

Quote from: Tele on February 15, 2013, 06:32:25 PM
Eric, you said that vanilla didnt work, I think the problem was just the same. Type 'make menuconfig' then set the above parameter to the opposite value as the current one (0 or 1), then make a try.

I pulled the kernel posted by uMinded from github and made the suggested change. That was it and it did boot. It appears that was the vanilla kernel, as there were no references to Xenomai in the boot log, nor can I run 'xeno'.

The boot log is posted here:
http://pastebin.com/d1tmR9TY (http://pastebin.com/d1tmR9TY)

Quote from: uMinded on February 16, 2013, 06:01:14 PM
Thanks for the info, I don't have a board so I was just compiling what I thought I needed. Can anybody post a known working .config to pastebin.com so I can make sure I have a stable base?

Also my router and adsl modem died in a power outage yesterday in the early morning so I am on my cell phone right now and can not upload very quick. I will see if I can get the uImage uploaded at least but the modules are a 600mb beast so I will upload that when I get internet back. (Hopefully by this evening)

EDIT:
I switched my files to google drive as my dropbox is to small.
3.0.36-r1 SW_DEBUG_UART=1 (https://docs.google.com/file/d/0B0HKuT2T-RfEaWFLbzJkVi1VeXM/edit?usp=sharing)

I tried the kernel and found that it would freeze up in a couple different spots (3 so far). The furthest I got is posted here:
http://pastebin.com/tpCw9fkk (http://pastebin.com/tpCw9fkk)

The last line is:
[....] Checking file systems...fsck from util-linux 2.20.1

I let it run for at least 1/2 hour to see if it would complete, but so far has not.

Quote from: ehj666 on February 16, 2013, 06:42:56 PM
I pulled the kernel posted by uMinded from github and made the suggested change. That was it and it did boot. It appears that was the vanilla kernel, as there were no references to Xenomai in the boot log, nor can I run 'xeno'.

The boot log is posted here:
http://pastebin.com/d1tmR9TY (http://pastebin.com/d1tmR9TY)

That would be a good base for uMinded. Eric could you send this .config to him please ? It should work after xenomai and timer patch. At least I hope so.

Quote from: ehj666 on February 16, 2013, 06:42:56 PM
I pulled the kernel posted by uMinded from github and made the suggested change. That was it and it did boot. It appears that was the vanilla kernel, as there were no references to Xenomai in the boot log, nor can I run 'xeno'.

Can you please dump your .config to pastebin, their must be some memory offsets or something in the kernel that the a13_defconfig does not set up correctly. Once I get by bloody internet fixed I can push my xenomai and ipipe changes to the git.

EDIT:
You can pull a copy of the xenomai-2.6.2.1 branch off my repo and it will have my ported ipipe code. Copy your .config to a safe place before the pull and then copy it back and do a make menuconfig to select the real-time systems.

Quote from: Tele on February 17, 2013, 01:45:32 AM
That would be a good base for uMinded. Eric could you send this .config to him please ? It should work after xenomai and timer patch. At least I hope so.

Here is the config file:
http://pastebin.com/Ui8B8sVU (http://pastebin.com/Ui8B8sVU)

Thanks for the post. The only difference between the a13_defconfig and your working one is that SW_DEBUG_UART=1

I did some drunk driving around my git repo and it needs some serious help but the master and xeno branches work and compile clean. I am in the process of making this a full fledged project by setting up an eclipse project for the kernel, properly branching and merging my IPIPE patch and setting up a decent readme to follow. This is handy so that when I have a board I can attach to the debugger on the olinuxino and do proper analysis.

Can you give this one a try:
uImage - 3.0.36-r1-xenomai (https://docs.google.com/file/d/0B0HKuT2T-RfEalJ3TWpRUmhpUHc/edit?usp=sharing) It should report Xenomai in the kernel log.

xenomai-2.6.2.1 userspace programs (https://docs.google.com/file/d/0B0HKuT2T-RfEVVYwMWlnMDFLamc/edit?usp=sharing) (18MB - 7zip Format)

If you extract the archive above to the root of the SDCard then you will have the complete Xenomai userspace suite. You can run xeno-test in /usr/xenomai/bin and hopefully you get something besides a segfault!

On Olinuxino:

$ sudo addgroup xenomai
$ sudo usermod -a -G xenomai USERNAME
$ id
uid=XXXX gid=YYYY

$ sudo cp /etc/ld.so.conf.d/libc.conf /etc/ld.so.conf.d/xenomai.conf
$sudo nano /etc/ld.so.conf.d/xenomai.conf
  # xenomai libs
  /usr/local/lib

$sudo ldconfig


In script.bin put your gid in:
append `xeno_nucleus.xenomai_gid=YYYY` to the kernel line

I donno where is Eric. Sorry I cant make a try till Monday.

Hello, as i tell you, i cant send news from a few days, but, at this time, i can get a running IPIPE kernel on the A13. The patch is not the one from uminded.

It is a 3.4.24 version.

The kernel boot, and i dont have any bad behaviour.

I get coherent infos in /proc/ipipe/trace/max:

CPU: 0, Begin: 335309655 cycles, Trace Points: 3792, ...
Calibrated minimum trace-point overhead: 0:800 us

...
...
...


dmesg | grep ipipe
show too a lot of messages and it look to be ok.

I have to recompile to see if it is ok with xenomai.

Quote from: uMinded on February 17, 2013, 06:45:09 AM
Can you give this one a try:
uImage - 3.0.36-r1-xenomai (https://docs.google.com/file/d/0B0HKuT2T-RfEalJ3TWpRUmhpUHc/edit?usp=sharing) It should report Xenomai in the kernel log.



U-Boot SPL 2012.10-rc1-03956-gd7ea23d (Oct 11 2012 - 15:48:58)
MMC:   SUNXI SD/MMC: 0
Loading U-Boot...   OK!
Jumping to U-Boot...


U-Boot 2012.10-rc1-03956-gd7ea23d (Oct 11 2012 - 15:48:58) Allwinner Technology

CPU:   SUNXI Family
Board: A13-OLinuXino
I2C:   ready
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
Loading file "uEnv.txt" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/uEnv.txt" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
Loading file "boot.scr" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/boot.scr" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading script.bin

28156 bytes read
reading uImage

4008320 bytes read
## Booting kernel from Legacy Image at 48000000 ...
   Image Name:   Linux-3.0.36-r1-xenomai+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4008256 Bytes = 3.8 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

<6>Initializing cgroup subsys cpuset
<5>Linux version 3.0.36-r1-xenomai+ (uminded@uminded-desktop) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #11 PREEMPT Sat Feb 16 22:28:49 CST 2013
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: sun5i
DRAM: 512<6>Total Detected Memory: 512MB with 1 banks
<4>Ignoring unrecognised tag 0x00000000
<6>Memory Reserved(in bytes):
<6>     LCD: 0x5a000000, 0x02000000
<6>     SYS: 0x43000000, 0x00010000
<6>     G2D: 0x58000000, 0x01000000
<6>     VE : 0x44000000, 0x05000000
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 114688
<7>free_area_init_node: node 0, pgdat c079a1b0, node_mem_map c09e2000
<7>  Normal zone: 896 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 113792 pages, LIFO batch:31
<7>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
<5>Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait loglevel=8 panic=10
<6>PID hash table entries: 2048 (order: 1, 8192 bytes)
<6>Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>Memory: 448MB = 448MB total
<5>Memory: 329852k/329852k available, 128900k reserved, 0K highmem
<5>Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xdc800000 - 0xf0000000   ( 312 MB)
    lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .init : 0xc0008000 - 0xc0032000   ( 168 kB)
      .text : 0xc0032000 - 0xc075c000   (7336 kB)
      .data : 0xc075c000 - 0xc079f9f8   ( 271 kB)
       .bss : 0xc079fa1c - 0xc09e1d80   (2313 kB)
<6>SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
<6>NR_IRQS:96 nr_irqs:96 96
<6>timer0: Periodic Mode
<6>I-pipe 1.18-11: pipeline enabled.
<6>Console: colour dummy device 80x30
<3>ram_console: buffer   (null), invalid size 0, datasize 4294967284
<6>Calibrating delay loop... <c>1001.88 BogoMIPS (lpj=5009408)
<6>pid_max: default: 32768 minimum: 301
<6>Mount-cache hash table entries: 512
<6>Initializing cgroup subsys cpuacct
<6>Initializing cgroup subsys devices
<6>Initializing cgroup subsys freezer
<6>Initializing cgroup subsys blkio
<6>CPU: Testing write buffer coherency: ok
<6>hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
<6>devtmpfs: initialized
<6>print_constraints: dummy:
<6>NET: Registered protocol family 16
<6>hw-breakpoint: debug architecture 0x4 unsupported.
<6>I-pipe, 300.000 MHz clocksource
SOFTWINNER DMA Driver, (c) 2003-2004,2006 Simtec Electronics
<6>Initialize DMAC OK
<6>bio: create slab <bio-0> at 0
<5>SCSI subsystem initialized
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>Advanced Linux Sound Architecture Driver Version 1.0.24.
Init eGon pin module V2.0
<6>cfg80211: Calling CRDA to update world regulatory domain
<6>Switching to clocksource ipipe_tsc
<5>FS-Cache: Loaded
<6>CacheFiles: Loaded
[usb_manager]: CONFIG_USB_SW_SUN5I_USB0_OTG
[sw_hcd0]: usb host driver initialize........
[sw_hcd0]: [sw_hcd_host0]: open_usb_clock
[hcd0]: open, 0x60(0xc141), 0xcc(0x143)
[sw_hcd0]: host_init_state = 0
[sw_hcd0]: platform is usb host
[sw_hcd0]: sw_hcd_init_controller: sw_hcd_host0: USB Host mode controller at f1c13000 using PIO, IRQ 38
<6>sw_hcd_host0 sw_hcd_host0: sw_hcd host driver
<6>sw_hcd_host0 sw_hcd_host0: new USB bus registered, assigned bus number 1
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 1 port detected
wrn: hcd is not enable, need not start hcd
[sw_hcd0]: sw_usb_host0_disable start
-------sw_hcd0_soft_disconnect---------
[sw_hcd_host0]: Set USB Power OFF
wrn: hcd is not enable, need not stop hcd
[sw_hcd0]: sw_usb_host0_disable end
[sw_udc]: udc_init: version 20080411
axp driver uning configuration failed(561)
axp driver uning configuration failed(573)
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
<6>TCP established hash table entries: 16384 (order: 5, 131072 bytes)
<6>TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
<6>TCP: Hash tables configured (established 16384 bind 16384)
<6>TCP reno registered
<6>UDP hash table entries: 256 (order: 0, 4096 bytes)
<6>UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
<6>NET: Registered protocol family 1
<6>RPC: Registered named UNIX socket transport module.
<6>RPC: Registered udp transport module.
<6>RPC: Registered tcp transport module.
<6>RPC: Registered tcp NFSv4.1 backchannel transport module.
[pm]aw_pm_init!
<6>audit: initializing netlink socket (disabled)
<5>type=2000 audit(0.160:1): initialized
<6>I-pipe: Domain Xenomai registered.
<6>Xenomai: hal/arm started.
<6>Xenomai: scheduling class idle registered.
<6>Xenomai: scheduling class rt registered.

U-Boot SPL 2012.10-rc1-03956-gd7ea23d (Oct 11 2012 - 15:48:58)
MMC:   SUNXI SD/MMC: 0
Loading U-Boot...   OK!
Jumping to U-Boot...


U-Boot 2012.10-rc1-03956-gd7ea23d (Oct 11 2012 - 15:48:58) Allwinner Technology

CPU:   SUNXI Family
Board: A13-OLinuXino
I2C:   ready
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
Loading file "uEnv.txt" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/uEnv.txt" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
Loading file "boot.scr" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/boot.scr" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading script.bin

28156 bytes read
reading uImage

4008320 bytes read
## Booting kernel from Legacy Image at 48000000 ...
   Image Name:   Linux-3.0.36-r1-xenomai+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4008256 Bytes = 3.8 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

<6>Initializing cgroup subsys cpuset
<5>Linux version 3.0.36-r1-xenomai+ (uminded@uminded-desktop) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #11 PREEMPT Sat Feb 16 22:28:49 CST 2013
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: sun5i
DRAM: 512<6>Total Detected Memory: 512MB with 1 banks
<4>Ignoring unrecognised tag 0x00000000
<6>Memory Reserved(in bytes):
<6>     LCD: 0x5a000000, 0x02000000
<6>     SYS: 0x43000000, 0x00010000
<6>     G2D: 0x58000000, 0x01000000
<6>     VE : 0x44000000, 0x05000000
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 114688
<7>free_area_init_node: node 0, pgdat c079a1b0, node_mem_map c09e2000
<7>  Normal zone: 896 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 113792 pages, LIFO batch:31
<7>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
<5>Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait loglevel=8 panic=10
<6>PID hash table entries: 2048 (order: 1, 8192 bytes)
<6>Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>Memory: 448MB = 448MB total
<5>Memory: 329852k/329852k available, 128900k reserved, 0K highmem
<5>Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xdc800000 - 0xf0000000   ( 312 MB)
    lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .init : 0xc0008000 - 0xc0032000   ( 168 kB)
      .text : 0xc0032000 - 0xc075c000   (7336 kB)
      .data : 0xc075c000 - 0xc079f9f8   ( 271 kB)
       .bss : 0xc079fa1c - 0xc09e1d80   (2313 kB)
<6>SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
<6>NR_IRQS:96 nr_irqs:96 96
<6>timer0: Periodic Mode
<6>I-pipe 1.18-11: pipeline enabled.
<6>Console: colour dummy device 80x30
<3>ram_console: buffer   (null), invalid size 0, datasize 4294967284
<6>Calibrating delay loop... <c>1001.88 BogoMIPS (lpj=5009408)
<6>pid_max: default: 32768 minimum: 301
<6>Mount-cache hash table entries: 512
<6>Initializing cgroup subsys cpuacct
<6>Initializing cgroup subsys devices
<6>Initializing cgroup subsys freezer
<6>Initializing cgroup subsys blkio
<6>CPU: Testing write buffer coherency: ok
<6>hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
<6>devtmpfs: initialized
<6>print_constraints: dummy:
<6>NET: Registered protocol family 16
<6>hw-breakpoint: debug architecture 0x4 unsupported.
<6>I-pipe, 300.000 MHz clocksource
SOFTWINNER DMA Driver, (c) 2003-2004,2006 Simtec Electronics
<6>Initialize DMAC OK
<6>bio: create slab <bio-0> at 0
<5>SCSI subsystem initialized
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>Advanced Linux Sound Architecture Driver Version 1.0.24.
Init eGon pin module V2.0
<6>cfg80211: Calling CRDA to update world regulatory domain
<6>Switching to clocksource ipipe_tsc
<5>FS-Cache: Loaded
<6>CacheFiles: Loaded
[usb_manager]: CONFIG_USB_SW_SUN5I_USB0_OTG
[sw_hcd0]: usb host driver initialize........
[sw_hcd0]: [sw_hcd_host0]: open_usb_clock
[hcd0]: open, 0x60(0xc141), 0xcc(0x143)
[sw_hcd0]: host_init_state = 0
[sw_hcd0]: platform is usb host
[sw_hcd0]: sw_hcd_init_controller: sw_hcd_host0: USB Host mode controller at f1c13000 using PIO, IRQ 38
<6>sw_hcd_host0 sw_hcd_host0: sw_hcd host driver
<6>sw_hcd_host0 sw_hcd_host0: new USB bus registered, assigned bus number 1
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 1 port detected
wrn: hcd is not enable, need not start hcd
[sw_hcd0]: sw_usb_host0_disable start
-------sw_hcd0_soft_disconnect---------
[sw_hcd_host0]: Set USB Power OFF
wrn: hcd is not enable, need not stop hcd
[sw_hcd0]: sw_usb_host0_disable end
[sw_udc]: udc_init: version 20080411
axp driver uning configuration failed(561)
axp driver uning configuration failed(573)
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
<6>TCP established hash table entries: 16384 (order: 5, 131072 bytes)
<6>TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
<6>TCP: Hash tables configured (established 16384 bind 16384)
<6>TCP reno registered
<6>UDP hash table entries: 256 (order: 0, 4096 bytes)
<6>UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
<6>NET: Registered protocol family 1
<6>RPC: Registered named UNIX socket transport module.
<6>RPC: Registered udp transport module.
<6>RPC: Registered tcp transport module.
<6>RPC: Registered tcp NFSv4.1 backchannel transport module.
[pm]aw_pm_init!
<6>audit: initializing netlink socket (disabled)
<5>type=2000 audit(0.160:1): initialized
<6>I-pipe: Domain Xenomai registered.
<6>Xenomai: hal/arm started.
<6>Xenomai: scheduling class idle registered.
<6>Xenomai: scheduling class rt registered.


Then it freezes. Doesn't boot, no login prompt. It seems xenomai is broken.
Any idea? Try to compile it with higher log level, we get more useful info maybe, I donno.

Quote from: uMinded on February 17, 2013, 06:45:09 AM


Can you give this one a try:
uImage - 3.0.36-r1-xenomai (https://docs.google.com/file/d/0B0HKuT2T-RfEalJ3TWpRUmhpUHc/edit?usp=sharing) It should report Xenomai in the kernel log.

Sorry for the delay guys, I had other obligations yesterday.

At any rate, tried that kernel and it is reporting as a Xenomai kernel. It is still locking up on boot however. Here is the boot log up to the point where it freezes.

U-Boot SPL 2012.10-04268-gf925eea (Feb 05 2013 - 19:19:54)
DRAM: 512MB
SUNXI SD/MMC: 0

U-Boot 2012.10-04268-gf925eea (Feb 05 2013 - 19:19:54) Allwinner Technology

CPU:   SUNXI Family
Board: A13-OLinuXino
I2C:   ready
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  3  2  1  0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
Loading file "uEnv.txt" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/uEnv.txt" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
Loading file "boot.scr" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/boot.scr" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading script.bin

28156 bytes read
reading uImage

4008320 bytes read
## Booting kernel from Legacy Image at 48000000 ...
   Image Name:   Linux-3.0.36-r1-xenomai+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4008256 Bytes = 3.8 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

<6>Initializing cgroup subsys cpuset
<5>Linux version 3.0.36-r1-xenomai+ (uminded@uminded-desktop) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #11 PREEMPT Sat Feb 16 22:28:49 CST 2013
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: sun5i
DRAM: 512<6>Total Detected Memory: 512MB with 1 banks
<4>Ignoring unrecognised tag 0x00000000
<6>Memory Reserved(in bytes):
<6> LCD: 0x5a000000, 0x02000000
<6> SYS: 0x43000000, 0x00010000
<6> G2D: 0x58000000, 0x01000000
<6> VE : 0x44000000, 0x05000000

Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 114688
<7>free_area_init_node: node 0, pgdat c079a1b0, node_mem_map c09e2000
<7>  Normal zone: 896 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 113792 pages, LIFO batch:31
<7>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>pcpu-alloc: [0] 0

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
<5>Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait loglevel=8 panic=10
<6>PID hash table entries: 2048 (order: 1, 8192 bytes)
<6>Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>Memory: 448MB = 448MB total
<5>Memory: 329852k/329852k available, 128900k reserved, 0K highmem
<5>Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xdc800000 - 0xf0000000   ( 312 MB)
    lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .init : 0xc0008000 - 0xc0032000   ( 168 kB)
      .text : 0xc0032000 - 0xc075c000   (7336 kB)
      .data : 0xc075c000 - 0xc079f9f8   ( 271 kB)
       .bss : 0xc079fa1c - 0xc09e1d80   (2313 kB)
<6>SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
<6>NR_IRQS:96 nr_irqs:96 96
<6>timer0: Periodic Mode
<6>I-pipe 1.18-11: pipeline enabled.
<6>Console: colour dummy device 80x30
<3>ram_console: buffer   (null), invalid size 0, datasize 4294967284
<6>Calibrating delay loop... <c>1001.88 BogoMIPS (lpj=5009408)
<6>pid_max: default: 32768 minimum: 301
<6>Mount-cache hash table entries: 512
<6>Initializing cgroup subsys cpuacct
<6>Initializing cgroup subsys devices
<6>Initializing cgroup subsys freezer
<6>Initializing cgroup subsys blkio
<6>CPU: Testing write buffer coherency: ok
<6>hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
<6>devtmpfs: initialized
<6>print_constraints: dummy:
<6>NET: Registered protocol family 16
<6>hw-breakpoint: debug architecture 0x4 unsupported.
<6>I-pipe, 300.000 MHz clocksource
SOFTWINNER DMA Driver, (c) 2003-2004,2006 Simtec Electronics
<6>Initialize DMAC OK
<6>bio: create slab <bio-0> at 0
<5>SCSI subsystem initialized
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>Advanced Linux Sound Architecture Driver Version 1.0.24.
<6>cfg80211: Calling CRDA to update world regulatory domain
Init eGon pin module V2.0
<6>Switching to clocksource ipipe_tsc
<5>FS-Cache: Loaded
<6>CacheFiles: Loaded
[usb_manager]: CONFIG_USB_SW_SUN5I_USB0_OTG
[sw_hcd0]: usb host driver initialize........
[sw_hcd0]: [sw_hcd_host0]: open_usb_clock
[hcd0]: open, 0x60(0xc141), 0xcc(0x143)
[sw_hcd0]: host_init_state = 0
[sw_hcd0]: platform is usb host
[sw_hcd0]: sw_hcd_init_controller: sw_hcd_host0: USB Host mode controller at f1c13000 using PIO, IRQ 38
<6>sw_hcd_host0 sw_hcd_host0: sw_hcd host driver
<6>sw_hcd_host0 sw_hcd_host0: new USB bus registered, assigned bus number 1
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 1 port detected
wrn: hcd is not enable, need not start hcd
[sw_hcd0]: sw_usb_host0_disable start
-------sw_hcd0_soft_disconnect---------
[sw_hcd_host0]: Set USB Power OFF
wrn: hcd is not enable, need not stop hcd
[sw_hcd0]: sw_usb_host0_disable end
[sw_udc]: udc_init: version 20080411
axp driver uning configuration failed(561)
axp driver uning configuration failed(573)
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
<6>TCP established hash table entries: 16384 (order: 5, 131072 bytes)
<6>TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
<6>TCP: Hash tables configured (established 16384 bind 16384)
<6>TCP reno registered
<6>UDP hash table entries: 256 (order: 0, 4096 bytes)
<6>UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
<6>NET: Registered protocol family 1
<6>RPC: Registered named UNIX socket transport module.
<6>RPC: Registered udp transport module.
<6>RPC: Registered tcp transport module.
<6>RPC: Registered tcp NFSv4.1 backchannel transport module.
[pm]aw_pm_init!
<6>audit: initializing netlink socket (disabled)
<5>type=2000 audit(0.150:1): initialized
<6>I-pipe: Domain Xenomai registered.
<6>Xenomai: hal/arm started.
<6>Xenomai: scheduling class idle registered.


On the upside from the log it is loading the required xenomai kernel level stuff and the ipipe is registered and loaded with the correct timer2 clock frequency.

The kernel does not compile with a specific log level, you can enable what things dump printk() messages but the boot loader controls the overall kernel verboseness. I will re-compile with maximum debugging enabled on the xenomai stuff though.


Create a file on your SDCard with script.bin called uEnv.txt:
setenv panicarg 'panic=10'
setenv extra 'debug ignore_loglevel'
setenv setargs 'setenv bootargs ${panicarg} ${extra}'


I have no idea if thaw will work or if script.bin will overwrite these values but I see uBoot does look for it.


EDIT:

Slag that, under `Boot Options` you can put in a default boot string. I am building a debug kernel now. I would love to know if the above works though as it would allow for easy dual booting!

New Kernel (https://docs.google.com/folder/d/0B0HKuT2T-RfEeXV3TUFXdkJVRm8/edit?usp=sharing)

Please try the uImage-debug (rename to uImage) and also unzip the modules archive to /lib/modules please. I do not see anything that Xenomai uses but it will take any questions out of it.

Also the next log is going to be VERY long if it boots, sometimes the print buffer can overfill before it can be dumped to the console...

Thanks for the help guys, I am going to order my board from digikey on Wensday so I will have it for next weekend!

Quote from: uMinded on February 18, 2013, 06:58:16 PM
New Kernel (https://docs.google.com/folder/d/0B0HKuT2T-RfEeXV3TUFXdkJVRm8/edit?usp=sharing)

Please try the uImage-debug (rename to uImage) and also unzip the modules archive to /lib/modules please. I do not see anything that Xenomai uses but it will take any questions out of it.

Also the next log is going to be VERY long if it boots, sometimes the print buffer can overfill before it can be dumped to the console...

Thanks for the help guys, I am going to order my board from digikey on Wensday so I will have it for next weekend!

If it is not too late, call your order in to Digikey and ask to speak with Rick Woodruff. He is aware of the problem with the SD port. See if there is any way they can test the SD port. All they should need is to power it via USB, connect a monitor and have a formatted SD card. Boot to Android, then my experience is that if the card can be read by Android it should boot. If Android cannot read it, it will report "Damaged SD".

Here is the latest boot log. Still not a lot to go on as far as I can tell.


U-Boot SPL 2012.10-04268-gf925eea (Feb 05 2013 - 19:19:54)
DRAM: 512MB
SUNXI SD/MMC: 0


U-Boot 2012.10-04268-gf925eea (Feb 05 2013 - 19:19:54) Allwinner Technology

CPU:   SUNXI Family
Board: A13-OLinuXino
I2C:   ready
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  3 reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
Loading file "uEnv.txt" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/uEnv.txt" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
Loading file "boot.scr" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/boot.scr" from mmc device 0:1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading script.bin

28156 bytes read
reading uImage

4229908 bytes read
## Booting kernel from Legacy Image at 48000000 ...
   Image Name:   Linux-3.0.36-r1-xeno-debug+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4229844 Bytes = 4 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

<6>Initializing cgroup subsys cpuset
<5>Linux version 3.0.36-r1-xeno-debug+ (uminded@uminded-desktop) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #17 PREEMPT Mon Feb 18 10:43:44 CST 2013
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: sun5i
DRAM: 512<6>Total Detected Memory: 512MB with 1 banks
<4>Ignoring unrecognised tag 0x00000000
<6>Memory Reserved(in bytes):
<6> LCD: 0x5a000000, 0x02000000
<6> SYS: 0x43000000, 0x00010000
<6> G2D: 0x58000000, 0x01000000
<6> VE : 0x44000000, 0x05000000
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 114688
<7>free_area_init_node: node 0, pgdat c083a5a8, node_mem_map c0a86000
<7>  Normal zone: 896 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 113792 pages, LIFO batch:31
<7>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
<5>Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait loglevel=8 panic=10
<6>PID hash table entries: 2048 (order: 1, 8192 bytes)
<6>Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>Memory: 448MB = 448MB total
<5>Memory: 329196k/329196k available, 129556k reserved, 0K highmem
<5>Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xdc800000 - 0xf0000000   ( 312 MB)
    lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .init : 0xc0008000 - 0xc0033000   ( 172 kB)
      .text : 0xc0033000 - 0xc07fb000   (7968 kB)
      .data : 0xc07fc000 - 0xc083fdf8   ( 272 kB)
       .bss : 0xc083fe1c - 0xc0a853c0   (2326 kB)
<6>SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
<6>NR_IRQS:96 nr_irqs:96 96
<6>timer0: Periodic Mode
<6>I-pipe 1.18-11: pipeline enabled.
<6>Console: colour dummy device 80x30
<3>ram_console: buffer   (null), invalid size 0, datasize 4294967284
<6>Calibrating delay loop... <c>1001.88 BogoMIPS (lpj=5009408)
<6>pid_max: default: 32768 minimum: 301
<6>Mount-cache hash table entries: 512
<6>Initializing cgroup subsys cpuacct
<6>Initializing cgroup subsys devices
<6>Initializing cgroup subsys freezer
<6>Initializing cgroup subsys blkio
<6>CPU: Testing write buffer coherency: ok
<6>hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
<6>devtmpfs: initialized
<6>print_constraints: dummy:
<6>NET: Registered protocol family 16
<6>hw-breakpoint: debug architecture 0x4 unsupported.
<6>I-pipe, 300.000 MHz clocksource
SOFTWINNER DMA Driver, (c) 2003-2004,2006 Simtec Electronics
<6>Initialize DMAC OK
<6>bio: create slab <bio-0> at 0
<5>SCSI subsystem initialized
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>Advanced Linux Sound Architecture Driver Version 1.0.24.
<6>cfg80211: Calling CRDA to update world regulatory domain
Init eGon pin module V2.0
<6>Switching to clocksource ipipe_tsc
<5>FS-Cache: Loaded
<6>CacheFiles: Loaded
<6>timer0: Oneshot Mode
[usb_manager]: CONFIG_USB_SW_SUN5I_USB0_OTG
[sw_hcd0]: usb host driver initialize........
[sw_hcd0]: [sw_hcd_host0]: open_usb_clock
[hcd0]: open, 0x60(0xc141), 0xcc(0x143)
[sw_hcd0]: host_init_state = 0
[sw_hcd0]: platform is usb host
[sw_hcd0]: sw_hcd_init_controller: sw_hcd_host0: USB Host mode controller at f1c13000 using PIO, IRQ 38
<6>sw_hcd_host0 sw_hcd_host0: sw_hcd host driver
<6>sw_hcd_host0 sw_hcd_host0: new USB bus registered, assigned bus number 1
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 1 port detected
wrn: hcd is not enable, need not start hcd
[sw_hcd0]: sw_usb_host0_disable start
-------sw_hcd0_soft_disconnect---------
[sw_hcd_host0]: Set USB Power OFF
wrn: hcd is not enable, need not stop hcd
[sw_hcd0]: sw_usb_host0_disable end
[sw_udc]: udc_init: version 20080411
axp driver uning configuration failed(561)
axp driver uning configuration failed(573)
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
<6>TCP established hash table entries: 16384 (order: 5, 131072 bytes)
<6>TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
<6>TCP: Hash tables configured (established 16384 bind 16384)
<6>TCP reno registered
<6>UDP hash table entries: 256 (order: 0, 4096 bytes)
<6>UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
<6>NET: Registered protocol family 1
<6>RPC: Registered named UNIX socket transport module.
<6>RPC: Registered udp transport module.
<6>RPC: Registered tcp transport module.
<6>RPC: Registered tcp NFSv4.1 backchannel transport module.
[pm]aw_pm_init!
<6>audit: initializing netlink socket (disabled)
<5>type=2000 audit(0.150:1): initialized
<6>I-pipe: Domain Xenomai registered.
<6>Xenomai: hal/arm started.
<6>Xenomai: scheduling class idle registered.


It appears that the script.bin file has kernel parameters that overrule the compiled ones,I have forced ignore kernel options from bootloader and I have added a bunch of prink() calls to my clock code as well as enabled debugging in a few source files.

Can you give this one a go? If we don't get a better output then I am going to need a board to continue as I will need to dump memory and probe with a debugger.

New Debug Kernel (https://docs.google.com/file/d/0B0HKuT2T-RfEZjhhU01CNE9PZXM/edit?usp=sharing)

Hello,
;D ;D ;D ;D
i get a running  xenomai on my A13. The base kernel is the sunxi3.4.24 (the dev version some says ago).

I compile and test xenomai application this evening.

Quote from: uMinded on February 19, 2013, 01:53:54 AM
Can you give this one a go?
New Debug Kernel (https://docs.google.com/file/d/0B0HKuT2T-RfEZjhhU01CNE9PZXM/edit?usp=sharing)

This is your last kernel:


U-Boot 2012.10-rc1-03956-gd7ea23d (Oct 11 2012 - 15:48:58) Allwinner Technology

CPU:   SUNXI Family
Board: A13-OLinuXino
I2C:   ready
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
reading uEnv.txt

** Unable to read "uEnv.txt" from mmc 0:1 **
Loading file "uEnv.txt" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/uEnv.txt" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
Loading file "boot.scr" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/boot.scr" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading script.bin

28156 bytes read
reading uImage

4230664 bytes read
## Booting kernel from Legacy Image at 48000000 ...
   Image Name:   Linux-3.0.36-r1-xeno-debug+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4230600 Bytes = 4 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

<6>Initializing cgroup subsys cpuset
<5>Linux version 3.0.36-r1-xeno-debug+ (uminded@uminded-desktop) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #18 PREEMPT Mon Feb 18 17:50:33 CST 2013
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: sun5i
DRAM: 512<6>Total Detected Memory: 512MB with 1 banks
<4>Ignoring tag cmdline (using the default kernel command line)
<4>Ignoring unrecognised tag 0x00000000
<6>debug: ignoring loglevel setting.
<6>Memory Reserved(in bytes):
<6>     LCD: 0x5a000000, 0x02000000
<6>     SYS: 0x43000000, 0x00010000
<6>     G2D: 0x58000000, 0x01000000
<6>     VE : 0x44000000, 0x05000000
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 114688
<7>free_area_init_node: node 0, pgdat c083a5a8, node_mem_map c0a86000
<7>  Normal zone: 896 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 113792 pages, LIFO batch:31
<7>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
<5>Kernel command line: mem=448M@0x40000000 console=ttyS0,115200 panic=10 debug ignore_loglevel print_fatal_signals=1 LOGLEVEL=8
<6>PID hash table entries: 2048 (order: 1, 8192 bytes)
<6>Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>Memory: 448MB = 448MB total
<5>Memory: 329196k/329196k available, 129556k reserved, 0K highmem
<5>Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xdc800000 - 0xf0000000   ( 312 MB)
    lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .init : 0xc0008000 - 0xc0033000   ( 172 kB)
      .text : 0xc0033000 - 0xc07fb000   (7968 kB)
      .data : 0xc07fc000 - 0xc083fdf8   ( 272 kB)
       .bss : 0xc083fe1c - 0xc0a853c0   (2326 kB)
<6>SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
<6>NR_IRQS:96 nr_irqs:96 96
<6>timer0: Periodic Mode
<6>I-pipe 1.18-11: pipeline enabled.
<6>Console: colour dummy device 80x30
<3>ram_console: buffer   (null), invalid size 0, datasize 4294967284
<6>Calibrating delay loop... <c>1001.88 BogoMIPS (lpj=5009408)
<6>pid_max: default: 32768 minimum: 301
<6>Mount-cache hash table entries: 512
<6>Initializing cgroup subsys cpuacct
<6>Initializing cgroup subsys devices
<6>Initializing cgroup subsys freezer
<6>Initializing cgroup subsys blkio
<6>CPU: Testing write buffer coherency: ok
<6>hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
<6>devtmpfs: initialized
<6>print_constraints: dummy:
<6>NET: Registered protocol family 16
<6>hw-breakpoint: debug architecture 0x4 unsupported.
__init timer2_clkevt_init()
[CLKSRC] set up ipipe timer2 clock event irq!
<6>I-pipe, 300.000 MHz clocksource
[CLKSRC] register ipipe timer2 clock event device!
[CLKSRC] set up all-winners clock event irq!
[CLKSRC] register all-winners clock event device!
[CLKSRC] all-winners clock source init!
[CLKSRC] register all-winners clock source!
SOFTWINNER DMA Driver, (c) 2003-2004,2006 Simtec Electronics
<6>Initialize DMAC OK
<6>bio: create slab <bio-0> at 0
<5>SCSI subsystem initialized
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>Advanced Linux Sound Architecture Driver Version 1.0.24.
Init eGon pin module V2.0
<6>cfg80211: Calling CRDA to update world regulatory domain
<6>Switching to clocksource ipipe_tsc
<5>FS-Cache: Loaded
<6>CacheFiles: Loaded
<6>timer0: Oneshot Mode
[usb_manager]: CONFIG_USB_SW_SUN5I_USB0_OTG
[sw_hcd0]: usb host driver initialize........
[sw_hcd0]: [sw_hcd_host0]: open_usb_clock
[hcd0]: open, 0x60(0xc141), 0xcc(0x143)
[sw_hcd0]: host_init_state = 0
[sw_hcd0]: platform is usb host
[sw_hcd0]: sw_hcd_init_controller: sw_hcd_host0: USB Host mode controller at f1c13000 using PIO, IRQ 38
<6>sw_hcd_host0 sw_hcd_host0: sw_hcd host driver
<6>sw_hcd_host0 sw_hcd_host0: new USB bus registered, assigned bus number 1
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 1 port detected
wrn: hcd is not enable, need not start hcd
[sw_hcd0]: sw_usb_host0_disable start
-------sw_hcd0_soft_disconnect---------
[sw_hcd_host0]: Set USB Power OFF
wrn: hcd is not enable, need not stop hcd
[sw_hcd0]: sw_usb_host0_disable end
[sw_udc]: udc_init: version 20080411
axp driver uning configuration failed(561)
axp driver uning configuration failed(573)
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
<6>TCP established hash table entries: 16384 (order: 5, 131072 bytes)
<6>TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
<6>TCP: Hash tables configured (established 16384 bind 16384)
<6>TCP reno registered
<6>UDP hash table entries: 256 (order: 0, 4096 bytes)
<6>UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
<6>NET: Registered protocol family 1
<6>RPC: Registered named UNIX socket transport module.
<6>RPC: Registered udp transport module.
<6>RPC: Registered tcp transport module.
<6>RPC: Registered tcp NFSv4.1 backchannel transport module.
[pm]aw_pm_init!
<6>audit: initializing netlink socket (disabled)
<5>type=2000 audit(0.190:1): initialized
<6>I-pipe: Domain Xenomai registered.
<6>Xenomai: hal/arm started.
__ipipe_mach_set_dec()
timer2_set_next_clkevt()
[CLKSRC] timer2_set_next_clkevt: 4294966295
__ipipe_mach_set_dec()
timer2_set_next_clkevt()
[CLKSRC] timer2_set_next_clkevt: 4294966295


This is your last kernel with uExt.txt (almost the same):


U-Boot SPL 2012.10-rc1-03956-gd7ea23d (Oct 11 2012 - 15:48:58)
MMC:   SUNXI SD/MMC: 0
Loading U-Boot...   OK!
Jumping to U-Boot...


U-Boot 2012.10-rc1-03956-gd7ea23d (Oct 11 2012 - 15:48:58) Allwinner Technology

CPU:   SUNXI Family
Board: A13-OLinuXino
I2C:   ready
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
reading uEnv.txt

119 bytes read
Loaded environment from uEnv.txt
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
Loading file "boot.scr" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/boot.scr" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading script.bin

28156 bytes read
reading uImage

4230664 bytes read
## Booting kernel from Legacy Image at 48000000 ...
   Image Name:   Linux-3.0.36-r1-xeno-debug+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4230600 Bytes = 4 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

<6>Initializing cgroup subsys cpuset
<5>Linux version 3.0.36-r1-xeno-debug+ (uminded@uminded-desktop) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #18 PREEMPT Mon Feb 18 17:50:33 CST 2013
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: sun5i
DRAM: 512<6>Total Detected Memory: 512MB with 1 banks
<4>Ignoring tag cmdline (using the default kernel command line)
<4>Ignoring unrecognised tag 0x00000000
<6>debug: ignoring loglevel setting.
<6>Memory Reserved(in bytes):
<6>     LCD: 0x5a000000, 0x02000000
<6>     SYS: 0x43000000, 0x00010000
<6>     G2D: 0x58000000, 0x01000000
<6>     VE : 0x44000000, 0x05000000
Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 114688
<7>free_area_init_node: node 0, pgdat c083a5a8, node_mem_map c0a86000
<7>  Normal zone: 896 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 113792 pages, LIFO batch:31
<7>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
<7>pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
<5>Kernel command line: mem=448M@0x40000000 console=ttyS0,115200 panic=10 debug ignore_loglevel print_fatal_signals=1 LOGLEVEL=8
<6>PID hash table entries: 2048 (order: 1, 8192 bytes)
<6>Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>Memory: 448MB = 448MB total
<5>Memory: 329196k/329196k available, 129556k reserved, 0K highmem
<5>Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xdc800000 - 0xf0000000   ( 312 MB)
    lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .init : 0xc0008000 - 0xc0033000   ( 172 kB)
      .text : 0xc0033000 - 0xc07fb000   (7968 kB)
      .data : 0xc07fc000 - 0xc083fdf8   ( 272 kB)
       .bss : 0xc083fe1c - 0xc0a853c0   (2326 kB)
<6>SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
<6>NR_IRQS:96 nr_irqs:96 96
<6>timer0: Periodic Mode
<6>I-pipe 1.18-11: pipeline enabled.
<6>Console: colour dummy device 80x30
<3>ram_console: buffer   (null), invalid size 0, datasize 4294967284
<6>Calibrating delay loop... <c>1001.88 BogoMIPS (lpj=5009408)
<6>pid_max: default: 32768 minimum: 301
<6>Mount-cache hash table entries: 512
<6>Initializing cgroup subsys cpuacct
<6>Initializing cgroup subsys devices
<6>Initializing cgroup subsys freezer
<6>Initializing cgroup subsys blkio
<6>CPU: Testing write buffer coherency: ok
<6>hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
<6>devtmpfs: initialized
<6>print_constraints: dummy:
<6>NET: Registered protocol family 16
<6>hw-breakpoint: debug architecture 0x4 unsupported.
__init timer2_clkevt_init()
[CLKSRC] set up ipipe timer2 clock event irq!
<6>I-pipe, 300.000 MHz clocksource
[CLKSRC] register ipipe timer2 clock event device!
[CLKSRC] set up all-winners clock event irq!
[CLKSRC] register all-winners clock event device!
[CLKSRC] all-winners clock source init!
[CLKSRC] register all-winners clock source!
SOFTWINNER DMA Driver, (c) 2003-2004,2006 Simtec Electronics
<6>Initialize DMAC OK
<6>bio: create slab <bio-0> at 0
<5>SCSI subsystem initialized
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>Advanced Linux Sound Architecture Driver Version 1.0.24.
Init eGon pin module V2.0
<6>cfg80211: Calling CRDA to update world regulatory domain
<6>Switching to clocksource ipipe_tsc
<5>FS-Cache: Loaded
<6>CacheFiles: Loaded
<6>timer0: Oneshot Mode
[usb_manager]: CONFIG_USB_SW_SUN5I_USB0_OTG
[sw_hcd0]: usb host driver initialize........
[sw_hcd0]: [sw_hcd_host0]: open_usb_clock
[hcd0]: open, 0x60(0xc141), 0xcc(0x143)
[sw_hcd0]: host_init_state = 0
[sw_hcd0]: platform is usb host
[sw_hcd0]: sw_hcd_init_controller: sw_hcd_host0: USB Host mode controller at f1c13000 using PIO, IRQ 38
<6>sw_hcd_host0 sw_hcd_host0: sw_hcd host driver
<6>sw_hcd_host0 sw_hcd_host0: new USB bus registered, assigned bus number 1
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 1 port detected
wrn: hcd is not enable, need not start hcd
[sw_hcd0]: sw_usb_host0_disable start
-------sw_hcd0_soft_disconnect---------
[sw_hcd_host0]: Set USB Power OFF
wrn: hcd is not enable, need not stop hcd
[sw_hcd0]: sw_usb_host0_disable end
[sw_udc]: udc_init: version 20080411
axp driver uning configuration failed(561)
axp driver uning configuration failed(573)
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
<6>TCP established hash table entries: 16384 (order: 5, 131072 bytes)
<6>TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
<6>TCP: Hash tables configured (established 16384 bind 16384)
<6>TCP reno registered
<6>UDP hash table entries: 256 (order: 0, 4096 bytes)
<6>UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
<6>NET: Registered protocol family 1
<6>RPC: Registered named UNIX socket transport module.
<6>RPC: Registered udp transport module.
<6>RPC: Registered tcp transport module.
<6>RPC: Registered tcp NFSv4.1 backchannel transport module.
[pm]aw_pm_init!
<6>audit: initializing netlink socket (disabled)
<5>type=2000 audit(0.190:1): initialized
<6>I-pipe: Domain Xenomai registered.
<6>Xenomai: hal/arm started.
__ipipe_mach_set_dec()
timer2_set_next_clkevt()
[CLKSRC] timer2_set_next_clkevt: 4294966295
__ipipe_mach_set_dec()
timer2_set_next_clkevt()
[CLKSRC] timer2_set_next_clkevt: 4294966295
__ipipe_mach_set_dec()


Do you wanna modify script.bin ? No problem, easy-peasy, we can recompile it.
This is the source of my current script.bin:


[product]
version = "1.0"
machine = "A13-EVB-V1.0"

[target]
boot_clock = 1008
dcdc2_vol = 1400
dcdc3_vol = 1200
ldo2_vol = 3000
ldo3_vol = 3300
ldo4_vol = 3300
pll4_freq = 960
pll6_freq = 720

[card_boot]
logical_start = 40960
sprite_gpio0 =

[card_boot0_para]
card_ctrl = 0
card_high_speed = 1
card_line = 4
sdc_d1 = port:PF00<2><1><default><default>
sdc_d0 = port:PF01<2><1><default><default>
sdc_clk = port:PF02<2><1><default><default>
sdc_cmd = port:PF03<2><1><default><default>
sdc_d3 = port:PF04<2><1><default><default>
sdc_d2 = port:PF05<2><1><default><default>

[twi_para]
twi_port = 0
twi_scl = port:PB00<2><1><default><default>
twi_sda = port:PB01<2><1><default><default>

[uart_para]
uart_debug_port = 1
uart_debug_tx = port:PG03<4><1><default><default>
uart_debug_rx = port:PG04<4><1><default><default>

[jtag_para]
jtag_enable = 0
jtag_ms = port:PF00<4><1><default><default>
jtag_ck = port:PF05<4><1><default><default>
jtag_do = port:PF03<4><1><default><default>
jtag_di = port:PF01<4><1><default><default>

[dram_para]
dram_baseaddr = 0x40000000
dram_clk = 408
dram_type = 3
dram_rank_num = 1
dram_chip_density = 2048
dram_io_width = 8
dram_bus_width = 16
dram_cas = 9
dram_zq = 0x7b
dram_odt_en = 0
dram_size = 512
dram_tpr0 = 0x42d899b7
dram_tpr1 = 0xa090
dram_tpr2 = 0x22a00
dram_tpr3 = 0x0
dram_tpr4 = 0x0
dram_tpr5 = 0x0
dram_emr1 = 0x0
dram_emr2 = 0x10
dram_emr3 = 0x0

[nand_para]
nand_used = 1
nand_we = port:PC00<2><default><default><default>
nand_ale = port:PC01<2><default><default><default>
nand_cle = port:PC02<2><default><default><default>
nand_ce1 = port:PC03<2><default><default><default>
nand_ce0 = port:PC04<2><default><default><default>
nand_nre = port:PC05<2><default><default><default>
nand_rb0 = port:PC06<2><default><default><default>
nand_rb1 = port:PC07<2><default><default><default>
nand_d0 = port:PC08<2><default><default><default>
nand_d1 = port:PC09<2><default><default><default>
nand_d2 = port:PC10<2><default><default><default>
nand_d3 = port:PC11<2><default><default><default>
nand_d4 = port:PC12<2><default><default><default>
nand_d5 = port:PC13<2><default><default><default>
nand_d6 = port:PC14<2><default><default><default>
nand_d7 = port:PC15<2><default><default><default>
nand_wp =
nand_ce2 =
nand_ce3 =
nand_ce4 =
nand_ce5 =
nand_ce6 =
nand_ce7 =
nand_spi =
nand_ndqs = port:PC19<2><default><default><default>

[mali_para]
mali_used = 1
mali_clkdiv = 2

[twi0_para]
twi0_used = 1
twi0_scl = port:PB00<2><default><default><default>
twi0_sda = port:PB01<2><default><default><default>

[twi1_para]
twi1_used = 1
twi1_scl = port:PB15<2><default><default><default>
twi1_sda = port:PB16<2><default><default><default>

[twi2_para]
twi2_used = 1
twi2_scl = port:PB17<2><default><default><default>
twi2_sda = port:PB18<2><default><default><default>

[uart_para0]
uart_used = 0
uart_port = 0
uart_type = 2
uart_tx = port:PB19<2><1><default><default>
uart_rx = port:PB20<2><1><default><default>

[uart_para1]
uart_used = 1
uart_port = 1
uart_type = 2
uart_tx = port:PG03<4><1><default><default>
uart_rx = port:PG04<4><1><default><default>

[spi1_para]
spi_used = 0
spi_cs0 = port:PG09<2><default><default><default>
spi_cs1 = port:PG13<2><default><default><default>
spi_sclk = port:PG10<2><default><default><default>
spi_mosi = port:PG11<2><default><default><default>
spi_miso = port:PG12<2><default><default><default>

[spi2_para]
spi_used = 1
spi_cs0 = port:PE00<4><default><default><default>
spi_sclk = port:PE01<4><default><default><default>
spi_mosi = port:PE02<4><default><default><default>
spi_miso = port:PE03<4><default><default><default>

[rtp_para]
rtp_used = 1
rtp_screen_size = 5
rtp_regidity_level = 5
rtp_press_threshold_enable = 0
rtp_press_threshold = 0x1f40
rtp_sensitive_level = 0xf
rtp_exchange_x_y_flag = 0

[ctp_para]
ctp_used = 0
ctp_name = "ft5x_ts"
ctp_twi_id = 2
ctp_twi_addr = 0x70
ctp_screen_max_x = 800
ctp_screen_max_y = 480
ctp_revert_x_flag = 0
ctp_revert_y_flag = 0
ctp_exchange_x_y_flag = 0
ctp_int_port = port:PH21<6><default><default><default>
ctp_wakeup = port:PB13<1><default><default><1>
ctp_io_port = port:PH21<0><default><default><default>

[tkey_para]
tkey_used = 0
tkey_name = "hv_keypad"
tkey_twi_id = 2
tkey_twi_addr = 0x62
tkey_int =

[motor_para]
motor_used = 0
motor_shake =

[disp_init]
disp_init_enable = 1
disp_mode = 0
screen0_output_type = 1
screen0_output_mode = 5
screen1_output_type = 1
screen1_output_mode = 5
fb0_framebuffer_num = 2
fb0_format = 9
fb0_pixel_sequence = 2
fb0_scaler_mode_enable = 0
fb1_framebuffer_num = 2
fb1_format = 9
fb1_pixel_sequence = 2
fb1_scaler_mode_enable = 0

[lcd0_para]
lcd_used = 1
lcd_x = 800
lcd_y = 480
lcd_dclk_freq = 33
lcd_pwm_not_used = 0
lcd_pwm_ch = 0
lcd_pwm_freq = 10000
lcd_pwm_pol = 0
lcd_if = 0
lcd_hbp = 46
lcd_ht = 1055
lcd_vbp = 23
lcd_vt = 1050
lcd_hv_if = 0
lcd_hv_smode = 0
lcd_hv_s888_if = 0
lcd_hv_syuv_if = 0
lcd_hv_vspw = 1
lcd_hv_hspw = 30
lcd_lvds_ch = 0
lcd_lvds_mode = 0
lcd_lvds_bitwidth = 0
lcd_lvds_io_cross = 0
lcd_cpu_if = 0
lcd_frm = 1
lcd_io_cfg0 = 268435456
lcd_gamma_correction_en = 0
lcd_gamma_tbl_0 = 0x0
lcd_gamma_tbl_1 = 0x10101
lcd_gamma_tbl_255 = 0xffffff
lcd_bl_en_used = 1
lcd_bl_en = port:power1<1><0><default><1>
lcd_power_used = 1
lcd_power = port:power0<1><0><default><1>
lcd_pwm_used = 0
lcd_pwm = port:PB02<2><0><default><default>
lcd_gpio_0 =
lcd_gpio_1 =
lcd_gpio_2 =
lcd_gpio_3 =
lcdd0 = port:PD00<2><0><default><default>
lcdd1 = port:PD01<2><0><default><default>
lcdd2 = port:PD02<2><0><default><default>
lcdd3 = port:PD03<2><0><default><default>
lcdd4 = port:PD04<2><0><default><default>
lcdd5 = port:PD05<2><0><default><default>
lcdd6 = port:PD06<2><0><default><default>
lcdd7 = port:PD07<2><0><default><default>
lcdd8 = port:PD08<2><0><default><default>
lcdd9 = port:PD09<2><0><default><default>
lcdd10 = port:PD10<2><0><default><default>
lcdd11 = port:PD11<2><0><default><default>
lcdd12 = port:PD12<2><0><default><default>
lcdd13 = port:PD13<2><0><default><default>
lcdd14 = port:PD14<2><0><default><default>
lcdd15 = port:PD15<2><0><default><default>
lcdd16 = port:PD16<2><0><default><default>
lcdd17 = port:PD17<2><0><default><default>
lcdd18 = port:PD18<2><0><default><default>
lcdd19 = port:PD19<2><0><default><default>
lcdd20 = port:PD20<2><0><default><default>
lcdd21 = port:PD21<2><0><default><default>
lcdd22 = port:PD22<2><0><default><default>
lcdd23 = port:PD23<2><0><default><default>
lcdclk = port:PD24<2><0><default><default>
lcdde = port:PD25<2><0><default><default>
lcdhsync = port:PD26<2><0><default><default>
lcdvsync = port:PD27<2><0><default><default>

[tv_out_dac_para]
dac_used = 1
dac0_src = 0

[hdmi_para]
hdmi_used = 0

[csi0_para]
csi_used = 0
csi_mode = 0
csi_dev_qty = 1
csi_stby_mode = 1
csi_mname = "gc0308"
csi_twi_id = 2
csi_twi_addr = 0x42
csi_if = 0
csi_vflip = 0
csi_hflip = 1
csi_iovdd = ""
csi_avdd = ""
csi_dvdd = ""
csi_flash_pol = 1
csi_mname_b = ""
csi_twi_id_b = 1
csi_twi_addr_b = 0x78
csi_if_b = 0
csi_vflip_b = 1
csi_hflip_b = 0
csi_iovdd_b = ""
csi_avdd_b = ""
csi_dvdd_b = ""
csi_flash_pol_b = 1
csi_pck = port:PE00<3><default><default><default>
csi_ck = port:PE01<3><default><default><default>
csi_hsync = port:PE02<3><default><default><default>
csi_vsync = port:PE03<3><default><default><default>
csi_d0 = port:PE04<3><default><default><default>
csi_d1 = port:PE05<3><default><default><default>
csi_d2 = port:PE06<3><default><default><default>
csi_d3 = port:PE07<3><default><default><default>
csi_d4 = port:PE08<3><default><default><default>
csi_d5 = port:PE09<3><default><default><default>
csi_d6 = port:PE10<3><default><default><default>
csi_d7 = port:PE11<3><default><default><default>
csi_reset = port:power3<1><default><default><0>
csi_power_en =
csi_stby = port:PB10<1><default><default><1>
csi_flash =
csi_af_en =
csi_reset_b =
csi_power_en_b =
csi_stby_b =
csi_flash_b =
csi_af_en_b =

[csi1_para]
csi_used = 0
csi_mode = 0
csi_dev_qty = 1
csi_stby_mode = 1
csi_mname = ""
csi_twi_id = 1
csi_twi_addr = 0xba
csi_if = 0
csi_vflip = 0
csi_hflip = 0
csi_iovdd = ""
csi_avdd = ""
csi_dvdd = ""
csi_flash_pol = 1
csi_mname_b = ""
csi_twi_id_b = 1
csi_twi_addr_b = 0x78
csi_if_b = 0
csi_vflip_b = 1
csi_hflip_b = 0
csi_iovdd_b = ""
csi_avdd_b = ""
csi_dvdd_b = ""
csi_flash_pol_b = 1
csi_reset =
csi_power_en =
csi_stby =
csi_flash =
csi_af_en =
csi_reset_b =
csi_power_en_b =
csi_stby_b =
csi_flash_b =
csi_af_en_b =

[mmc0_para]
sdc_used = 1
sdc_detmode = 1
bus_width = 4
sdc_d1 = port:PF00<2><1><2><default>
sdc_d0 = port:PF01<2><1><2><default>
sdc_clk = port:PF02<2><1><2><default>
sdc_cmd = port:PF03<2><1><2><default>
sdc_d3 = port:PF04<2><1><2><default>
sdc_d2 = port:PF05<2><1><2><default>
sdc_det = port:PG00<0><0><default><default>
sdc_use_wp = 0
sdc_wp =

[mmc1_para]
sdc_used = 0
sdc_detmode =
bus_width =
sdc_cmd =
sdc_clk =
sdc_d0 =
sdc_d1 =
sdc_d2 =
sdc_d3 =
sdc_det =
sdc_use_wp =
sdc_wp =

[mmc2_para]
sdc_used = 0
sdc_detmode = 3
bus_width = 4
sdc_cmd = port:PE08<4><1><2><default>
sdc_clk = port:PE09<4><1><2><default>
sdc_d0 = port:PE04<4><1><2><default>
sdc_d1 = port:PE05<4><1><2><default>
sdc_d2 = port:PE06<4><1><2><default>
sdc_d3 = port:PE07<4><1><2><default>
sdc_det =
sdc_use_wp = 0
sdc_wp =

[ms_para]
ms_used = 0
ms_bs =
ms_clk =
ms_d0 =
ms_d1 =
ms_d2 =
ms_d3 =
ms_det =

[keypad_para]
kp_used = 0
kp_in_size =
kp_out_size =
kp_in0 =
kp_in1 =
kp_in2 =
kp_in3 =
kp_in4 =
kp_in5 =
kp_in6 =
kp_in7 =
kp_out0 =
kp_out1 =
kp_out2 =
kp_out3 =
kp_out4 =
kp_out5 =
kp_out6 =
kp_out7 =

[usbc0]
usb_used = 1
usb_port_type = 2
usb_detect_type = 1
usb_id_gpio = port:PG02<0><1><default><default>
usb_det_vbus_gpio = port:PG01<0><0><default><default>
usb_drv_vbus_gpio = port:PG12<1><0><default><0>
usb_host_init_state = 0

[usbc1]
usb_used = 1
usb_port_type = 1
usb_detect_type = 0
usb_id_gpio =
usb_det_vbus_gpio =
usb_drv_vbus_gpio = port:PG11<1><0><default><0>
usb_host_init_state = 1

[usb_feature]
vendor_id = 6353
mass_storage_id = 1
adb_id = 2
manufacturer_name = "USB Developer"
product_name = "Android"
serial_number = "20080411"

[msc_feature]
vendor_name = "USB 2.0"
product_name = "USB Flash Driver"
release = 100
luns = 3

[gsensor_para]
gsensor_used = 0
gsensor_name = "bma222"
gsensor_twi_id = 1
gsensor_twi_addr = 0x18
gsensor_int1 =
gsensor_int2 =

[gps_para]
gps_used = 0
gps_spi_id =
gps_spi_cs_num =
gps_lradc =
gps_clk =
gps_sign =
gps_mag =
gps_vcc_en =
gps_osc_en =
gps_rx_en =

[sdio_wifi_para]
sdio_wifi_used = 0
sdio_wifi_sdc_id =
sdio_wifi_mod_sel =

[usb_wifi_para]
usb_wifi_used = 1
usb_wifi_usbc_num = 1

[3g_para]
3g_used = 0
3g_name =
3g_usbc_num =
3g_on_off =
3g_reset =
3g_poweron =
3g_wakeup_out =
3g_wakeup_in =

[gy_para]
gy_used = 0
gy_twi_id = 1
gy_twi_addr = 0
gy_int1 =
gy_int2 =

[ls_para]
ls_used = 1
ls_name = "ltr501als"
ls_twi_id = 1
ls_twi_addr =
ls_int =

[compass_para]
compass_used = 0
compass_twi_id =
compass_twi_addr =
compass_int =

[bt_para]
bt_used = 0
bt_uart_id =
bt_mod_type =

[i2s_para]
i2s_used = 0
i2s_channel =
i2s_mclk =
i2s_bclk =
i2s_lrclk =
i2s_dout0 =
i2s_dout1 =
i2s_dout2 =
i2s_dout3 =
i2s_din =

[spdif_para]
spdif_used = 0
spdif_mclk =
spdif_dout =
spdif_din =

[audio_para]
audio_used = 1
audio_pa_ctrl = port:PG10<1><default><default><0>

[ir_para]
ir_used = 0
ir0_rx = port:PB04<2><default><default><default>

[rtc_para]
rtc_used = 1
rtc_name = "pcf8563"
rtc_twi_id = 1
rtc_twi_addr = 81

[pmu_para]
pmu_used = 1
pmu_twi_addr = 52
pmu_twi_id = 0
pmu_irq_id = 0
pmu_battery_rdc = 200
pmu_battery_cap = 2600
pmu_init_chgcur = 300
pmu_earlysuspend_chgcur = 600
pmu_suspend_chgcur = 1000
pmu_resume_chgcur = 300
pmu_shutdown_chgcur = 1000
pmu_init_chgvol = 4200
pmu_init_chgend_rate = 15
pmu_init_chg_enabled = 1
pmu_init_adc_freq = 100
pmu_init_adc_freqc = 100
pmu_init_chg_pretime = 50
pmu_init_chg_csttime = 720
pmu_bat_para1 = 0
pmu_bat_para2 = 0
pmu_bat_para3 = 1
pmu_bat_para4 = 5
pmu_bat_para5 = 7
pmu_bat_para6 = 13
pmu_bat_para7 = 16
pmu_bat_para8 = 26
pmu_bat_para9 = 36
pmu_bat_para10 = 46
pmu_bat_para11 = 53
pmu_bat_para12 = 61
pmu_bat_para13 = 73
pmu_bat_para14 = 84
pmu_bat_para15 = 92
pmu_bat_para16 = 100
pmu_usbvol = 4000
pmu_usbcur = 0
pmu_usbvol_pc = 4000
pmu_usbcur_pc = 0
pmu_pwroff_vol = 3300
pmu_pwron_vol = 2900
pmu_pekoff_time = 6000
pmu_pekoff_en = 1
pmu_peklong_time = 1500
pmu_pekon_time = 1000
pmu_pwrok_time = 64
pmu_pwrnoe_time = 2000
pmu_intotp_en = 1
pmu_used2 = 0
pmu_adpdet =
pmu_init_chgcur2 = 400
pmu_earlysuspend_chgcur2 = 600
pmu_suspend_chgcur2 = 1200
pmu_resume_chgcur2 = 400
pmu_shutdown_chgcur2 = 1200
pmu_suspendpwroff_vol = 3500
pmu_batdeten = 1

[recovery_key]
key_min = 4
key_max = 6

[gpio_para]
gpio_used = 1
gpio_num = 15
gpio_pin_1 = port:PB03<0><default><default><default>
gpio_pin_2 = port:PB04<0><default><default><default>
gpio_pin_3 = port:PB10<0><default><default><default>
gpio_pin_4 = port:PE04<0><default><default><default>
gpio_pin_5 = port:PE05<0><default><default><default>
gpio_pin_6 = port:PE06<0><default><default><default>
gpio_pin_7 = port:PE07<0><default><default><default>
gpio_pin_8 = port:PE08<0><default><default><default>
gpio_pin_9 = port:PE09<0><default><default><default>
gpio_pin_10 = port:PE10<0><default><default><default>
gpio_pin_11 = port:PE11<0><default><default><default>
gpio_pin_12 = port:PG09<1><default><default><default>
gpio_pin_13 = port:PG10<0><default><default><default>
gpio_pin_14 = port:PG11<0><default><default><default>
gpio_pin_15 = port:PB02<0><default><default><0>


Just show me, what do I have to change, or upload a modified script.fex, I will recompile it.

Quote from: crubille on February 19, 2013, 09:28:45 AM
Hello,
;D ;D ;D ;D
i get a running  xenomai on my A13. The base kernel is the sunxi3.4.24 (the dev version some says ago).

I compile and test xenomai application this evening.

Its fine Im happy about that, but you forgot to share any specific code or info with us. It seems you wanna tease us, dont you?

Quote from: crubille on February 19, 2013, 09:28:45 AM
Hello,
;D ;D ;D ;D
i get a running  xenomai on my A13. The base kernel is the sunxi3.4.24 (the dev version some says ago).

I compile and test xenomai application this evening.

Please share, I found the I-Pipe patch with the current Xenomai release had to many changes to be an easy port (>300) have the sunxi guys recently brought it into sync?

Where you got it, steps you used to compile and a boot log would be appreciated!

Tele:

The last few lines on that boot log told the story I think. The Xenomai clock was set for a 300MHz clock source but the reload register was set for a 303MHz reload cycle. I was off by a zero in my __ipipe_mach_ticks_per_jiffy.

I will upload another kernel before lunch with the changed rate. I also eagerly await Crubille's news as that 3.4x kernel has quite a few I-Pipe problems fixed deep in the kernel.

Quote from: uMinded on February 19, 2013, 01:53:54 AM
It appears that the script.bin file has kernel parameters that overrule the compiled ones,I have forced ignore kernel options from bootloader and I have added a bunch of prink() calls to my clock code as well as enabled debugging in a few source files.

Can you give this one a go? If we don't get a better output then I am going to need a board to continue as I will need to dump memory and probe with a debugger.

New Debug Kernel (https://docs.google.com/file/d/0B0HKuT2T-RfEZjhhU01CNE9PZXM/edit?usp=sharing)

I see a couple posts since I last checked in. I will not be able to test anything until sometime this evening (EST). Specifically, do you want me to test the latest debug kernel with the modified script.bin?

Quote from: ehj666 on February 19, 2013, 02:46:19 PM
I see a couple posts since I last checked in. I will not be able to test anything until sometime this evening (EST). Specifically, do you want me to test the latest debug kernel with the modified script.bin?

Their is nothing boot related in the script.bin file. uBoot might have some kernel option suppression turned on or something but building the kernel with options forced works out. In a usual situation their would never be a need to add kernel options so I'm sure its not uBoots fault.

I will build a new kernel with an updated tick rate and see if that doesn't freeze the kernel. The problem was the real time ISR was constantly being called and gave no no time for the system calls to function. I will edit this post with a link within 2-3hrs.

Thanks!

Quote from: uMinded on February 19, 2013, 01:04:33 PM
Tele:
I will upload another kernel before lunch with the changed rate.
...

I cant check your code, because of missing documentation. I have no idea about timer registers of A10/A13.
Where the hell did you get the info about the timer control register bits?

Ive seen a suspicious things although:

#ifdef CONFIG_IPIPE
static int __init timer2_clkevt_init(void)
{
...
...
    /* config PLL clock source for timer2 */
    TMR_REG_TMR1_CTL |= (2<<2);
    /* configure PLL/4 for 300MHz clock */
    TMR_REG_TMR1_CTL |= (2<<4);
    /* reload inter value */
    TMR_REG_TMR1_CTL |= (1<<1);


You talk about timer2 then you set the timer1 ctl register. Is that what you want indeed, or this is just a copy/paste-forgot-to-modify error?
I cant decide because I donno the meaning of bits,

Who is Jiffy, you can talk about him a bit more.
Currently the function__ipipe_mach_set_dec(unsigned long delay) is called with delay=1000 and that makes those magic numbers 4294966295 = 0xffffffff - 1000
It has something to do with Jiffy?
Teach me, then maybe I can help more.

A10 Timer Registers (http://linux-sunxi.org/A10/TIMER#TMR_2_CTRL)

If you follow to procession on code it starts to make since, here is a quick flow:

// Call to tell system to init timer
arch_initcall(timer2_clkevt_init);
// Setup clocks, enable timer and define TSC
__init timer2_clkevt_init(void)
  // Register timer with ipipe
  __ipipe_tsc_register(&tsc_info);
  // Enable kernel level IRQ handling
  setup_irq(SW_INT_IRQNO_TIMER2, &timer2_clkevt_irqact);
  // Register timer with kernel
  clockevents_register_device(&timer2_clock_event);

// Structure to point to functions, names, count capacity, etc
static struct clock_event_device timer2_clock_event
static struct irqaction timer2_clkevt_irqact

// Just clears the interrupt bits and calls the function below
static irqreturn_t timer2_clkevt_irq(int irq, void *handle)
// Used to reset the counter, ipipe hijacks this with the __ipipe functions
static int timer2_set_next_clkevt(unsigned long delta, struct clock_event_device *dev)

It the harder part was porting the patches and not remove any needed code, some of the patch lines had no data before/after so you had to insert spinlocks into functions with some forsight.

The timer2 structure delta_max/min I calculated on a 32bit register and 3.3ns(300MHz) clock. The max is only 75% of the max 32bit string but its at around 10 seconds so it will never go that high.

In __ipipe_mach_release_timer() the timer is set to ONESHOT and delayed by __ipipe_mach_ticks_per_jiffy so I assume based on kernel output that Xenomai sets up the timer as ONESHOT and reloads it this way (although the function names do NOT make you think that). Also the __ipipe_mach_ticks_per_jiffy is an exported symbol so the kernel can modify it while running.

Latest & Greatest Kernal (https://docs.google.com/file/d/0B0HKuT2T-RfEOFlWQ2gtc0p2NG8/edit?usp=sharing)


EDIT:
Can you give this one a try too:
3.4.24-r1-xeno-debug (https://docs.google.com/file/d/0B0HKuT2T-RfEeHJiRklLWFhYZ28/edit?usp=sharing)
I have been working on getting the 3.4.x patched and some latest merges have made it possible. If this one works then were quite a few steps ahead.

Quote from: uMinded on February 19, 2013, 08:28:22 PM
A10 Timer Registers (http://linux-sunxi.org/A10/TIMER#TMR_2_CTRL)

Thank you very much I couldnt find my glass because it was on my nose. Im so stupid.

Quote from: uMinded on February 19, 2013, 08:28:22 PM

If you follow to procession on code it starts to make since, here is a quick flow:

Thank you for the lesson, Im getting there slowly. I started to understand things.
Now Im almost sure there is (or was?) a bug in aw_clocksrc.c


#ifdef CONFIG_IPIPE
static int __init timer2_clkevt_init(void)
{
    /* register clock event irq */
    CLKSRC_DBG("set up ipipe timer2 clock event irq!\n");
    /* clear timer2 setting */
    TMR_REG_TMR2_CTL = 0;
    /* initialise timer inter value to 1 tick */
    TMR_REG_TMR2_INTV = TIMER2_HPET_CLOCK_EVENT_HZ/HZ;

    /* config PLL clock source for timer2 */
    TMR_REG_TMR1_CTL |= (2<<2);
    /* configure PLL/4 for 300MHz clock */
    TMR_REG_TMR1_CTL |= (2<<4);
    /* reload inter value */
    TMR_REG_TMR1_CTL |= (1<<1);
...


you have to change

    /* config PLL clock source for timer2 */
    TMR_REG_TMR2_CTL |= (2<<2);      // bit 2:3=0x2 TMR_2_CLK_SRC = PLL6 / 6 = 200 MHz!!! PLL6 = 1.2GHz! You forgot to divide it with 6
    /* configure TMR_2_CLK_SRC/1 for 200MHz clock */
//    TMR_REG_TMR2_CTL |= (2<<4);     This line is not necessary because prescale-divisor should be 1, 4:5 bit must be 0x0
    /* reload inter value */
    TMR_REG_TMR2_CTL |= (1<<1);

So you have to change TMR1 -> TMR2, we have nothing to do with TMR1.
And the maximum clock source is 200MHz because PLL6/6 can be the highest clock source for timer2.
You have to change TIMER2_HPET_CLOCK_EVENT_HZ to 200MHz and have to recalculate min/max deltas. It will be 200MHz instead of 300MHz, its still fine, not so few, dont let it bring you down.
Tell me if Im wrong, Im a slow learner, I wont get offended.

Unfortunately I cant test it now, only later, in about 10 hours, because my Oli card isnt here at the moment.
Could you refresh your github's xenomai branch please, I want to see the latest aw_clocksrc.c

Hello,

so if i get a running kernel, i dont still have xenomai application working - and i dont know why.

If you suspect me to dont send infos, i remember you i send infos about patchs and A10 timers, but last week i cant do anything and have no mail.

If you wand, send me your mail adress in private messages and i send you back the files in a more convenient forms.

Saturday, i start write some code and let it compile (on the A13) sunday in the night.
Monday, i get a kernel which hang the A13.
In the evening i check it and recompile.
This morning i get a kernel, boot the A13 and go to my office.

So, it is for the sunxi 3.4 kernel.
The xenomai ipipe-core-3.4.6-arm-4.patch fail in some place but it is obvious to correct the faillures.
I then have to
- add one line in arch/arm/Kconfig for the sun5i as for several others arm:

       select IPIPE_ARM_KUSER_TSC if IPIPE


- add definition for TIMER2 and TIMER4 in arch/arm/plat-sunxi/include/plat/platform.h


#ifdef CONFIG_IPIPE
#define SW_TIMER2_CTL_REG                 (SW_VA_TIMERC_IO_BASE + 0x30)
#define SW_TIMER2_INTVAL_REG              (SW_VA_TIMERC_IO_BASE + 0x34)
#define SW_TIMER2_CNTVAL_REG              (SW_VA_TIMERC_IO_BASE + 0x38)

#define SW_TIMER4_CTL_REG                 (SW_VA_TIMERC_IO_BASE + 0x50)
#define SW_TIMER4_INTVAL_REG              (SW_VA_TIMERC_IO_BASE + 0x54)
#define SW_TIMER4_CNTVAL_REG              (SW_VA_TIMERC_IO_BASE + 0x58)
#endif /* CONFIG_IPIPE */



add the code in arch/arm/mach_sun5i/core.c


*** arch/arm/mach-sun5i/core.c.ori 2013-02-20 00:07:57.000000000 +0100
--- arch/arm/mach-sun5i/core.c 2013-02-19 01:35:44.000000000 +0100
***************
*** 64,69 ****
--- 64,74 ----
  #include <plat/core.h>
  #include <plat/sys_config.h>
 
+ #include <linux/ipipe.h>
+ #include <linux/ipipe_tickdev.h>
+
+
+
  /**
   * Machine Implementations
   *
*************** static int timer_set_next_event(unsigned
*** 317,322 ****
--- 322,472 ----
  return 0;
  }
 
+
+ #ifdef CONFIG_IPIPE
+
+ /* ***********************************************
+    The IPIPE TIMER
+    *********************************************** */
+ /*
+  * Reprogram the timer
+  */
+ static int sun5i_set_timer4(unsigned long evt, void *timer)
+ {
+   volatile u32  val = 0;
+
+   val = readl(SW_TIMER4_CTL_REG);
+   if( (val & 0x1 ) == 1 )
+     {
+       /* running */
+       val &= ~(0x1);  /* stop the timer */
+       writel(val, SW_TIMER4_CTL_REG);
+       // sleep for 2 T_cycle that is 2 ticks
+       __delay(50); // wait for hardware synchronisation
+       if( evt > 1 ) evt --;
+     }
+   /* set the timer */
+   writel( evt, SW_TIMER4_CNTVAL_REG);
+   /* start the timer */
+   val |=  0x2; // reload!
+   writel(val, SW_TIMER4_CTL_REG);
+   val |=  0x1 ; // start
+   writel(val, SW_TIMER4_CTL_REG);
+   return 0;
+ }
+
+ /*
+  * IRQ handler for the timer.
+  */
+ static void sun5i_ack_timer4(void)
+ {
+ writel(0x1<<4, SW_TIMER_INT_STA_REG);
+ }
+
+ static void sun5i_request_timer4(struct ipipe_timer *timer, int steal)
+ {
+ /* Set timer on  - Enable interrupt. */
+ volatile u32  val = 0;
+
+ val = readl(SW_TIMER4_CTL_REG);
+ val &= ~(0x07<<4);
+ val &= ~(0x03<<2);
+ val |=  (1<<2) ; // 24 MHz
+ val &= ~(1<<1);
+ val |= 1<<7; // single mode -- stop continuous mode
+ writel(val, SW_TIMER4_CTL_REG);
+ __delay(50);
+ sun5i_ack_timer4();
+ /* Enable timer4 interrupt */
+ val = readl(SW_TIMER_INT_CTL_REG);
+ val |= (1<<4);
+ writel(val, SW_TIMER_INT_CTL_REG);
+ }
+
+ static void sun5i_release_timer4(struct ipipe_timer *timer)
+ {
+ volatile u32  val = 0;
+ /* Disable interrupt. */
+ val = readl(SW_TIMER_INT_CTL_REG);
+ val &= ~(1<<4);
+ writel(val, SW_TIMER_INT_CTL_REG);
+
+ }
+
+ static struct ipipe_timer sun5i_itimer = {
+   .irq = SW_INT_IRQNO_TIMER4 ,
+   .request = sun5i_request_timer4,
+   .set = sun5i_set_timer4,
+   .ack = sun5i_ack_timer4,
+   .release = sun5i_release_timer4,
+   .name = "sun5i_timer4",
+   .rating =  240 ,
+   .freq = 24000000 ,
+   .min_delay_ticks = 20 ,
+   //  .cpumask = ,
+ };
+
+ /* ***********************************************
+    The IPIPE CLOCK
+    *********************************************** */
+
+ static struct __ipipe_tscinfo tsc_info = {
+   .type = IPIPE_TSC_TYPE_FREERUNNING_COUNTDOWN ,
+   .freq = 24000000 , // ATTENTION should go to PPL6/6
+   .counter_vaddr = SW_TIMER2_CNTVAL_REG ,
+   .u = {
+     {
+       .counter_paddr = SW_TIMER2_CNTVAL_REG - SW_VA_TIMERC_IO_BASE + SW_PA_TIMERC_IO_BASE,
+       .mask = 0xffffffff,
+     },
+   },
+ };
+
+ void  sun5i_ipipe_tsc_timer2_init( void )
+ {
+ /* Set timer on  */
+ volatile u32  val = 0;
+
+ /* set clock source to HOSC (24Mhz) LOOK for PLL6/6 for future */
+ val = readl(SW_TIMER2_CTL_REG);
+ val &= ~(0x1); // stop timer
+ val &= ~(0x07<<4); // clear divisor
+ val &= ~(0x03<<2); // clear source
+
+ val &= ~(0x1<<7); // continous mode
+ val |=  (1<<2) ;  // 24 Mhz
+ writel(val, SW_TIMER2_CTL_REG);
+
+ /* set value */
+ writel( tsc_info.u.mask, SW_TIMER2_INTVAL_REG);
+ /* start and auto reload */
+ __delay(50); // wait for hardware synchronisation
+ val = readl(SW_TIMER2_CTL_REG);
+ val |= 1 | (1<<1);
+ writel(val, SW_TIMER2_CTL_REG);
+
+ }
+
+ /* ***********************************************
+    The IPIPE IRQ
+    *********************************************** */
+
+ /* ***********************************************
+    Register IPIPE
+    *********************************************** */
+
+
+
+ void sun5i_ipipe_init( void )
+ {
+   ipipe_timer_register(&sun5i_itimer); // register timer
+
+   //  tsc_info.freq = clock_tick_rate;// from the example dont care
+   sun5i_ipipe_tsc_timer2_init();
+   __ipipe_tsc_register(&tsc_info); // register clock
+ }
+ #endif /* CONFIG_IPIPE */
+
  static struct clock_event_device timer0_clockevent = {
  .name = "timer0",
  .shift = 32,
*************** static irqreturn_t sw_timer_interrupt(in
*** 331,336 ****
--- 481,490 ----
  {
  struct clock_event_device *evt = (struct clock_event_device *)dev_id;
 
+ #ifdef CONFIG_IPIPE
+  __ipipe_tsc_update();
+ #endif /* CONFIG_IPIPE */
+
  writel(0x1, SW_TIMER_INT_STA_REG);
 
  /*
*************** static void __init sw_timer_init(void)
*** 383,388 ****
--- 537,546 ----
  timer0_clockevent.cpumask = cpumask_of(0);
  timer0_clockevent.irq = sw_timer_irq.irq;
  clockevents_register_device(&timer0_clockevent);
+
+ #ifdef CONFIG_IPIPE
+ sun5i_ipipe_init();
+ #endif
  }
 
  struct sys_timer sw_sys_timer = {



Quote from: Tele on February 19, 2013, 11:14:13 PM
So you have to change TMR1 -> TMR2, we have nothing to do with TMR1.
And the maximum clock source is 200MHz because PLL6/6 can be the highest clock source for timer2.
You have to change TIMER2_HPET_CLOCK_EVENT_HZ to 200MHz and have to recalculate min/max deltas. It will be 200MHz instead of 300MHz, its still fine, not so few, dont let it bring you down.
Tell me if Im wrong, Im a slow learner, I wont get offended.

- Nice catch on the PLL6/6, When I read the datasheet for the processor I saw the big notice that PLL6 outputs 1.2GHz and nothing else and I wrote off the div6 defore it even hit the TMR_2_CLK_PRESCALE.

- The Tim1's where a copy-paste mistake but they where fixed on my second kernel.

- I will re-calculate the values based on 200MHz clock but it shouldn't change much as I think the kernel was hanging due to a to-often ISR or pushing wrong TSC to the processor. I will go through crubille's change and see if were on the same track.

Crubille:

   I notice you are using a different convention for inserting the timer into the system and registering it with the I-Pipe. Where did you find documentation to do it your way? When I compiled my 3.0.x and 3.4.x kernels they demanded the following functions to work:

int __ipipe_mach_ticks_per_jiffy
int __ipipe_mach_timerstolen
int __ipipe_mach_timerint
__ipipe_mach_get_tsc(void)
__ipipe_mach_get_dec(void)
__ipipe_mach_release_timer(void)
__ipipe_mach_set_dec(unsigned long delay)
__ipipe_mach_acktimer(void)


That was with Xenomai-2.6.2.1 patched into the kernel.

At this time, i use the 24 Mhz clock for the clock (TIMER 2) and the clocktest show it is ok
and for the timer (TIMER4) and nothing append.

It is not a problem to swith the clock to PLL6/6, just check ticks are coherents.

At this time, my main question is: is the IRQ for TIMER4 really 67 ?


root@debian:/usr/xenomai/bin# ./latency
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      2.166|      2.624|     14.583|       0|     0|      2.166|     14.583
RTD|      1.416|      2.208|     25.749|       0|     0|      1.416|     25.749
RTD|      1.416|      2.166|     21.083|       0|     0|      1.416|     25.749
RTD|      1.416|      2.124|     25.583|       0|     0|      1.416|     25.749
RTD|      1.416|      2.166|     20.499|       0|     0|      1.416|     25.749
RTD|      1.416|      2.166|     24.958|       0|     0|      1.416|     25.749
RTD|      1.416|      2.124|     20.666|       0|     0|      1.416|     25.749
RTD|      1.416|      2.124|     24.916|       0|     0|      1.416|     25.749
RTD|      1.499|      2.208|     23.833|       0|     0|      1.416|     25.749
RTD|      1.416|      2.249|     29.666|       0|     0|      1.416|     29.666
^C---|-----------|-----------|-----------|--------|------|-------------------------
RTS|      1.416|      2.208|     29.666|       0|     0|    00:00:11/00:00:11


I just add the following in the core.c file:


writel( evt, SW_TIMER4_INTVAL_REG);


before

  writel( evt, SW_TIMER4_CNTVAL_REG);


and

     __delay(50);

after

Quote from: uMinded on February 19, 2013, 08:28:22 PM
Latest & Greatest Kernal (https://docs.google.com/file/d/0B0HKuT2T-RfEOFlWQ2gtc0p2NG8/edit?usp=sharing)

EDIT:
Can you give this one a try too:
3.4.24-r1-xeno-debug (https://docs.google.com/file/d/0B0HKuT2T-RfEeHJiRklLWFhYZ28/edit?usp=sharing)
I have been working on getting the 3.4.x patched and some latest merges have made it possible. If this one works then were quite a few steps ahead.

Latest and greatest kernel boot log:
http://pastebin.com/2TPFtwqL (http://pastebin.com/2TPFtwqL)

3.4.24-r1 kernel boot log:
http://pastebin.com/qQBn9LJY (http://pastebin.com/qQBn9LJY)

Quote from: ehj666 on February 20, 2013, 05:06:12 AM
3.4.24-r1 kernel boot log:
http://pastebin.com/qQBn9LJY (http://pastebin.com/qQBn9LJY)

Now that's some real kernel debug messages eh! The I-Pipe TSC/cpu sync is the main problem with 3.0.36 so I am going to dump that kernel in favor of 3.4.24 as that actually boots with Xenomai.

I'm going to take a shot at doing it the way crubille did and see if we can get it booted and loaded.

crubille:

  I would be careful of the 3.4.24 version of arch/arm/plat-sunxi/include/plat/platform.h as some of the virtual address pointers are offset by 0x10 and you could reset a system clock unintentionally or worse. See the linux-sunxi.org site for the register definitions.

This should boot up now:
Linux-3.4.24-r1-xeno-debug-r1-xe (https://docs.google.com/file/d/0B0HKuT2T-RfEYUlxWHg5WEEzOEU/edit?usp=sharing)
Xenomai-2.6.2.1 User Progs (https://docs.google.com/file/d/0B0HKuT2T-RfEVVYwMWlnMDFLamc/edit?usp=sharing)

Hopefully the user programs work, I compiled them for -march=armv7-a -mfpu=vfp3

If it does can you please run the following:

/usr/xenomai/bin/clocktest -C sun5i_timer2  // Or just clocktest to test them all
/usr/xenomai/bin/latency


As usual dump them all please.

I talked to DigiKey, they didn't want to test my board and said they would call back. They have not so I will call them tomorrow and see if they can do it and ship ASAP.

Quote from: uMinded on February 20, 2013, 06:28:25 AM
This should boot up now:
Linux-3.4.24-r1-xeno-debug-r1-xe (https://docs.google.com/file/d/0B0HKuT2T-RfEYUlxWHg5WEEzOEU/edit?usp=sharing)
As usual dump them all please.



U-Boot SPL 2012.10-rc1-03956-gd7ea23d (Oct 11 2012 - 15:48:58)
MMC:   SUNXI SD/MMC: 0
Loading U-Boot...   OK!
Jumping to U-Boot...


U-Boot 2012.10-rc1-03956-gd7ea23d (Oct 11 2012 - 15:48:58) Allwinner Technology

CPU:   SUNXI Family
Board: A13-OLinuXino
I2C:   ready
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
reading uEnv.txt

119 bytes read
Loaded environment from uEnv.txt
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
Loading file "boot.scr" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
Loading file "boot/boot.scr" from mmc device 0:1 xxa1
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - mmc 0:1 **
ext2load - load binary file from a Ext2 filesystem

Usage:
ext2load <interface> <dev[:part]> [addr] [filename] [bytes]
    - load binary file 'filename' from 'dev' on 'interface'
      to address 'addr' from ext2 filesystem
reading script.bin

28156 bytes read
reading uImage

4139296 bytes read
## Booting kernel from Legacy Image at 48000000 ...
   Image Name:   Linux-3.4.24-r1-xeno-debug-r1-xe
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4139232 Bytes = 3.9 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

<6>Booting Linux on physical CPU 0
<6>Initializing cgroup subsys cpuset
<5>Linux version 3.4.24-r1-xeno-debug-r1-xeno-debug-dirty (uminded@uminded-desktop) (gcc version 4.7.3 20130102 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.01-20130125 - Linaro GCC 2013.01) ) #3 PREEMPT Tue Feb 19 22:20:06 CST 2013
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: sun5i
<6>Memory cut off:
<6>     MALI : 0x5c000000 - 0x5fffffff  (  64 MB)
<4>Ignoring tag cmdline (using the default kernel command line)
<4>Ignoring unrecognised tag 0x00000000
<6>debug: ignoring loglevel setting.
<6>Memory Reserved:
<6>     SYS  : 0x43000000 - 0x4300ffff  (  64 kB)
<6>     VE   : 0x44000000 - 0x48ffffff  (  80 MB)
Memory policy: ECC disabled, Data cache writeback
<6>chip-id: Unknown (AW1625)
<7>On node 0 totalpages: 114688
<7>free_area_init_node: node 0, pgdat c07ea920, node_mem_map c0a2f000
<7>  Normal zone: 896 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 113792 pages, LIFO batch:31
<7>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768<c>
<7>pcpu-alloc: <c>[0] <c>0 <c>
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
<5>Kernel command line: mem=448M@0x40000000 console=ttyS0,115200 panic=10 debug ignore_loglevel print_fatal_signals=1
<6>PID hash table entries: 2048 (order: 1, 8192 bytes)
<6>Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
<6>Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
<6>Memory: 448MB = 448MB total
<5>Memory: 362300k/362300k available, 96452k reserved, 0K highmem
<5>Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xdc800000 - 0xff000000   ( 552 MB)
    lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc0770000   (7584 kB)
      .init : 0xc0770000 - 0xc07a0000   ( 192 kB)
      .data : 0xc07a0000 - 0xc07f03a8   ( 321 kB)
       .bss : 0xc07f03cc - 0xc0a2ea60   (2298 kB)
<6>SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
<6>NR_IRQS:96
<6>timer0: Periodic Mode
<6>I-pipe, 200.000 MHz clocksource
<6>sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
<6>Interrupt pipeline (release #4)
<6>Console: colour dummy device 80x30
<6>Calibrating delay loop... <c>1001.88 BogoMIPS (lpj=5009408)
<6>pid_max: default: 32768 minimum: 301
<6>Mount-cache hash table entries: 512
<6>Initializing cgroup subsys cpuacct
<6>Initializing cgroup subsys devices
<6>Initializing cgroup subsys freezer
<6>Initializing cgroup subsys blkio
<6>CPU: Testing write buffer coherency: ok
<6>hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
<6>Setting up static identity map for 0x4055de48 - 0x4055dea0
<6>devtmpfs: initialized
<6>dummy:
<6>NET: Registered protocol family 16
<6>hw-breakpoint: debug architecture 0x4 unsupported.
SOFTWINNER DMA Driver, (c) 2003-2004,2006 Simtec Electronics
<6>Initialize DMAC OK
<6>bio: create slab <bio-0> at 0
<5>SCSI subsystem initialized
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>Advanced Linux Sound Architecture Driver Version 1.0.25.
<6>cfg80211: Calling CRDA to update world regulatory domain
<6>Init eGon pin module V2.0
<6>Switching to clocksource ipipe_tsc
<5>FS-Cache: Loaded
<6>CacheFiles: Loaded
<6>timer0: Oneshot Mode
[usb_manager]: CONFIG_USB_SW_SUN5I_USB0_HOST_ONLY
[sw_hcd0]: usb host driver initialize........
[sw_hcd0]: [sw_hcd_host0]: open_usb_clock
[hcd0]: open, 0x60(0xc141), 0xcc(0x143)
[sw_hcd0]: host_init_state = 0
[sw_hcd0]: platform is usb host
[sw_hcd0]: sw_hcd_host0: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx (X), HB-ISO Tx (X), SoftConn)
[sw_hcd0]: sw_hcd_init_controller: sw_hcd_host0: USB Host mode controller at f1c13000 using PIO, IRQ 38
<6>sw_hcd_host0 sw_hcd_host0: sw_hcd host driver
<6>sw_hcd_host0 sw_hcd_host0: new USB bus registered, assigned bus number 1
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 1 port detected
[sw_hcd_host0]: Set USB Power ON
axp driver uning configuration failed(562)
axp driver uning configuration failed(574)
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
<6>TCP established hash table entries: 16384 (order: 5, 131072 bytes)
<6>TCP bind hash table entries: 16384 (order: 6, 327680 bytes)
<6>TCP: Hash tables configured (established 16384 bind 16384)
<6>TCP: reno registered
<6>UDP hash table entries: 256 (order: 1, 12288 bytes)
<6>UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)
<6>NET: Registered protocol family 1
<6>RPC: Registered named UNIX socket transport module.
<6>RPC: Registered udp transport module.
<6>RPC: Registered tcp transport module.
<6>RPC: Registered tcp NFSv4.1 backchannel transport module.
[pm]aw_pm_init!
Initializing RT-Tester: OK
<6>audit: initializing netlink socket (disabled)
<5>type=2000 audit(0.170:1): initialized
<6>I-pipe: head domain Xenomai registered.
<6>Xenomai: hal/arm started.
<6>Xenomai: scheduling class idle registered.
<6>Xenomai: scheduling class rt registered.
<6>Xenomai: real-time nucleus v2.6.2.1 (Day At The Beach) loaded.
<6>Xenomai: debug mode enabled.
<6>Xenomai: starting native API services.
<6>Xenomai: starting POSIX services.
<6>Xenomai: starting RTDM services.
<5>VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
<6>NTFS driver 2.1.30 [Flags: R/W].
<6>fuse init (API version 7.18)
<6>msgmni has been set to 707
<6>alg: No test for stdrng (krng)
<6>Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
<6>io scheduler noop registered
<6>io scheduler deadline registered
<6>io scheduler cfq registered (default)
<6>start plist test
<6>end plist test
<6>Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
<3>[uart]: failed to get uart2's used information
<3>[uart]: failed to get uart3's used information
<6>[uart]: used uart info.: 0x02
<6>[uart]: serial probe 1 irq 2 mapbase 0x01c28400
<6>sunxi-uart.1: ttyS0 at MMIO 0x1c28400 (irq = 2) is a U6_16550A
[    0.000000] Booting Linux on physical CPU 0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Linux version 3.4.24-r1-xeno-debug-r1-xeno-debug-dirty (uminded@uminded-desktop) (gcc version 4.7.3 20130102 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.01-20130125 - Linaro GCC 2013.01) ) #3 PREEMPT Tue Feb 19 22:20:06 CST 2013
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: sun5i
[    0.000000] Memory cut off:
[    0.000000]  MALI : 0x5c000000 - 0x5fffffff  (  64 MB)
[    0.000000] Ignoring tag cmdline (using the default kernel command line)
[    0.000000] Ignoring unrecognised tag 0x00000000
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] Memory Reserved:
[    0.000000]  SYS  : 0x43000000 - 0x4300ffff  (  64 kB)
[    0.000000]  VE   : 0x44000000 - 0x48ffffff  (  80 MB)
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] chip-id: Unknown (AW1625)
[    0.000000] On node 0 totalpages: 114688
[    0.000000] free_area_init_node: node 0, pgdat c07ea920, node_mem_map c0a2f000
[    0.000000]   Normal zone: 896 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 113792 pages, LIFO batch:31
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
[    0.000000] Kernel command line: mem=448M@0x40000000 console=ttyS0,115200 panic=10 debug ignore_loglevel print_fatal_signals=1
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 448MB = 448MB total
[    0.000000] Memory: 362300k/362300k available, 96452k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xdc800000 - 0xff000000   ( 552 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0770000   (7584 kB)
[    0.000000]       .init : 0xc0770000 - 0xc07a0000   ( 192 kB)
[    0.000000]       .data : 0xc07a0000 - 0xc07f03a8   ( 321 kB)
[    0.000000]        .bss : 0xc07f03cc - 0xc0a2ea60   (2298 kB)
[    0.000000] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:96
[    0.000000] timer0: Periodic Mode
[    0.000000] I-pipe, 200.000 MHz clocksource
[    0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
[    0.000000] Interrupt pipeline (release #4)
[    0.000000] Console: colour dummy device 80x30
[    0.010000] Calibrating delay loop... 1001.88 BogoMIPS (lpj=5009408)
[    0.060000] pid_max: default: 32768 minimum: 301
[    0.060000] Mount-cache hash table entries: 512
[    0.070000] Initializing cgroup subsys cpuacct
[    0.070000] Initializing cgroup subsys devices
[    0.070000] Initializing cgroup subsys freezer
[    0.080000] Initializing cgroup subsys blkio
[    0.080000] CPU: Testing write buffer coherency: ok
[    0.090000] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[    0.090000] Setting up static identity map for 0x4055de48 - 0x4055dea0
[    0.100000] devtmpfs: initialized
[    0.100000] dummy:
[    0.110000] NET: Registered protocol family 16
[    0.110000] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.120000] SOFTWINNER DMA Driver, (c) 2003-2004,2006 Simtec Electronics
[    0.120000] Initialize DMAC OK
[    0.130000] bio: create slab <bio-0> at 0
[    0.130000] SCSI subsystem initialized
[    0.140000] usbcore: registered new interface driver usbfs
[    0.140000] usbcore: registered new interface driver hub
[    0.140000] usbcore: registered new device driver usb
[    0.150000] Advanced Linux Sound Architecture Driver Version 1.0.25.
[    0.160000] cfg80211: Calling CRDA to update world regulatory domain
[    0.160000] Init eGon pin module V2.0
[    0.170000] Switching to clocksource ipipe_tsc
[    0.170000] FS-Cache: Loaded
[    0.170000] CacheFiles: Loaded
[    0.180000] timer0: Oneshot Mode
[    0.180000] [usb_manager]: CONFIG_USB_SW_SUN5I_USB0_HOST_ONLY
[    0.180000] [sw_hcd0]: usb host driver initialize........
[    0.180000] [sw_hcd0]: [sw_hcd_host0]: open_usb_clock
[    0.180000] [hcd0]: open, 0x60(0xc141), 0xcc(0x143)
[    0.180000] [sw_hcd0]: host_init_state = 0
[    0.180000] [sw_hcd0]: platform is usb host
[    0.180000] [sw_hcd0]: sw_hcd_host0: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx (X), HB-ISO Tx (X), SoftConn)
[    0.180000] [sw_hcd0]: sw_hcd_init_controller: sw_hcd_host0: USB Host mode controller at f1c13000 using PIO, IRQ 38
[    0.180000] sw_hcd_host0 sw_hcd_host0: sw_hcd host driver
[    0.180000] sw_hcd_host0 sw_hcd_host0: new USB bus registered, assigned bus number 1
[    0.180000] hub 1-0:1.0: USB hub found
[    0.180000] hub 1-0:1.0: 1 port detected
[    0.180000] [sw_hcd_host0]: Set USB Power ON
[    0.180000] axp driver uning configuration failed(562)
[    0.180000] axp driver uning configuration failed(574)
[    0.180000] NET: Registered protocol family 2
[    0.180000] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.180000] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
[    0.180000] TCP bind hash table entries: 16384 (order: 6, 327680 bytes)
[    0.180000] TCP: Hash tables configured (established 16384 bind 16384)
[    0.180000] TCP: reno registered
[    0.180000] UDP hash table entries: 256 (order: 1, 12288 bytes)
[    0.180000] UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)
[    0.180000] NET: Registered protocol family 1
[    0.180000] RPC: Registered named UNIX socket transport module.
[    0.180000] RPC: Registered udp transport module.
[    0.180000] RPC: Registered tcp transport module.
[    0.180000] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.180000] [pm]aw_pm_init!
[    0.180000] Initializing RT-Tester: OK
[    0.180000] audit: initializing netlink socket (disabled)
[    0.180000] type=2000 audit(0.170:1): initialized
[    0.190000] I-pipe: head domain Xenomai registered.
[    0.190000] Xenomai: hal/arm started.
[    0.190000] Xenomai: scheduling class idle registered.
[   21.610000] Xenomai: scheduling class rt registered.
[   21.610000] Xenomai: real-time nucleus v2.6.2.1 (Day At The Beach) loaded.
[   21.610000] Xenomai: debug mode enabled.
[   21.610000] Xenomai: starting native API services.
[   21.610000] Xenomai: starting POSIX services.
[   42.310000] Xenomai: starting RTDM services.
[   42.310000] VFS: Disk quotas dquot_6.5.2
[   42.310000] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[   42.310000] NTFS driver 2.1.30 [Flags: R/W].
[   42.310000] fuse init (API version 7.18)
[   42.310000] msgmni has been set to 707
[   42.310000] alg: No test for stdrng (krng)
[   42.310000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[   42.310000] io scheduler noop registered
[   42.310000] io scheduler deadline registered
[   42.310000] io scheduler cfq registered (default)
[   42.310000] start plist test
[   42.310000] end plist test
[   42.310000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[   42.310000] [uart]: failed to get uart2's used information
[   42.310000] [uart]: failed to get uart3's used information
[   42.310000] [uart]: used uart info.: 0x02
[   42.310000] [uart]: serial probe 1 irq 2 mapbase 0x01c28400
[   42.310000] sunxi-uart.1: ttyS0 at MMIO 0x1c28400 (irq = 2) is a U6_16550A
<6>console [ttyS0] enabled
[   42.310000] console [ttyS0] enabled
<6>brd: module loaded
[   42.310000] brd: module loaded
<6>loop: module loaded
[   42.310000] loop: module loaded
<6>'Low Performance USB Block' driver is deprecated. Please switch to usb-storage
[   42.310000] 'Low Performance USB Block' driver is deprecated. Please switch to usb-storage
<6>usbcore: registered new interface driver ub
[   42.310000] usbcore: registered new interface driver ub
<6>sun4i gpio driver init
[   42.310000] sun4i gpio driver init
[spi]: sw spi init !!
[   42.310000] [spi]: sw spi init !!
[spi]: sw spi init fetch spi0 uning configuration failed
[   42.310000] [spi]: sw spi init fetch spi0 uning configuration failed
[spi]: Get spi devices number failed
[   42.310000] [spi]: Get spi devices number failed
[spi]: register spi devices board info failed
[   42.310000] [spi]: register spi devices board info failed
[spi]: drivers/spi/spi_sunxi.c(L1872) [   42.310000] [spi]: drivers/spi/spi_sunxi.c(L1872) get spi 2 para failed, err code = -4
get spi 2 para failed, err code = -4
[spi]: source = sdram_pll_p, src_clk = 408000000, mclk 102000000
[   42.310000] [spi]: source = sdram_pll_p, src_clk = 408000000, mclk 102000000
<6>sun5i-spi sun5i-spi.2: master is unqueued, this is deprecated
[   42.310000] sun5i-spi sun5i-spi.2: master is unqueued, this is deprecated
[spi]: allwinners SoC SPI Driver loaded for Bus SPI-2 with 1 Slaves attached
[   42.310000] [spi]: allwinners SoC SPI Driver loaded for Bus SPI-2 with 1 Slaves attached
[spi]: [spi-2]: driver probe succeed, base f1c17000, irq 12, dma_id 2!
[   42.310000] [spi]: [spi-2]: driver probe succeed, base f1c17000, irq 12, dma_id 2!
<6>ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[   42.310000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
<6>ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[   42.310000] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[sw-ehci1]: open clock
[   42.310000] [sw-ehci1]: open clock
[sw-ehci1]: Set USB Power ON
[   42.310000] [sw-ehci1]: Set USB Power ON
<6>sw-ehci sw-ehci.1: SW USB2.0 'Enhanced' Host Controller (EHCI) Driver
[   42.310000] sw-ehci sw-ehci.1: SW USB2.0 'Enhanced' Host Controller (EHCI) Driver
<6>sw-ehci sw-ehci.1: new USB bus registered, assigned bus number 2
[   42.310000] sw-ehci sw-ehci.1: new USB bus registered, assigned bus number 2
<6>sw-ehci sw-ehci.1: irq 39, io mem 0xf1c14000
[   42.310000] sw-ehci sw-ehci.1: irq 39, io mem 0xf1c14000


Xenomai services has been started. But then later it freezes at sw-ehci. Hmmmm.

Hmm that is quite strange... I did not go anywhere near that subsystem.

Similar Bootlog (https://www.olimex.com/forum/index.php?topic=7.5;wap2)

You can see in that if you search for "sw-ehci1" that that IRQ and memory address is indeed correct so why it would freeze I have no idea.

crubille:

  Did you have any USB issues when it comes to booting? Can you post your 3.4.x config file?

Quote from: uMinded on February 20, 2013, 12:58:49 PM
Hmm that is quite strange...

Have to do it methodically. First we should compile a vanilla sunxi-3.2.24-r1 kernel with an A13_defconfig. If it runs then we can patch it with adeos-ipipe and high-res timer.

By the way, I have some doubts about this 3.2.24 kernel way. Because adeos ipipe patch was made for 3.2.21 kernel not for 3.2.24. If the patch runs without error (after modification) that is nice but it does not necessarily follow that is enough for the correct kernel patch. If you wanna be precise you have to compare 3.2.24 and 3.2.21 vanilla kernels, and then sunxi kernels in the aspect of ipipe patches. Otherwise you take some risk, you enter a twilight zone.

Im gonna try a vanilla sunxi-3.2.24-r1, then I come back to report.

EDIT:
I cant test that because it does not exist.
Maybe sunxi-3.4.24 patched with adeos ipipe 3.4.6
Hmmm.
EDIT2:
I cant do it for now. Sunxi gihub returns a server error 500. uMinded could you upload an unmodified sunxi-3.4.24-r1 onto your github please.

Quote from: Tele on February 20, 2013, 02:05:57 PM
Have to do it methodically. First we should compile a vanilla sunxi-3.2.24-r1 kernel with an A13_defconfig. If it runs then we can patch it with adeos-ipipe and high-res timer.

I agree, I will upload a vanilla kernel with just a defconfig.

Quote from: Tele on February 20, 2013, 02:05:57 PM
By the way, I have some doubts about this 3.4.24 kernel way. Because adeos ipipe patch was made for 3.2.21 kernel not for 3.2.24. If the patch runs without error (after modification) that is nice but it does not necessarily follow that is enough for the correct kernel patch. If you wanna be precise you have to compare 3.2.24 and 3.2.21 vanilla kernels, and then sunxi kernels in the aspect of ipipe patches. Otherwise you take some risk, you enter a twilight zone.

The I-Pipe patch really is not that much of a modification, I would say over half if it is just putting spinlocks in the appropriate places. And revisions between the minor version are exactly that, minor. CHANGELOGS (http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.4.6) Just put in the kernel version in the web address to bring up the commit log and 80% are bugfixes for specific hardware, 10% code tweeks (like a line or two), 10% are actual compile/module tweeks.

Kernel development has seriously accelerated in the past 5 years, I remember back when I was working on 2.6.x and now were on 3.8.x!

Quote from: Tele on February 20, 2013, 02:05:57 PM
I cant test that because it does not exist.
Maybe sunxi-3.4.24 patched with adeos ipipe 3.4.6
Hmmm.
EDIT2:
I cant do it for now. Sunxi gihub returns a server error 500. uMinded could you upload an unmodified sunxi-3.4.24-r1 onto your github please.

I just started using github last week, I am having huge problems pushing to remotes as I use two different computers for development and my branch pointers are not being stored properly, checkouts do not pull changes, etc. Finding a branch in the linux-sunxi kernel is painful at best as "git branch -a" only lists the ones one off master. the 3.4.24-r1 is in a remote node.


git clone git://github.com/linux-sunxi/linux-sunxi.git
git checkout sunxi-v3.4.24-r1

// If you do the following:

git log --all | grep "2.4."

// You will get a listing of the current working branches. Anything with a -rn appended seems to have full sunxi patches.


Quote from: Tele on February 20, 2013, 09:16:37 AM
Xenomai services has been started. But then later it freezes at sw-ehci. Hmmmm.

Yep. Just confirming, I get the same thing.

Quote from: uMinded on February 20, 2013, 03:27:06 PM

The I-Pipe patch really is not that much....

Its ok, I believe you. I was just thinking loudly. But Im a noobcake anyway, and thats a fact.

Quote from: uMinded on February 20, 2013, 03:27:06 PM

Code Select Expand


git clone git://github.com/linux-sunxi/linux-sunxi.git
git checkout sunxi-v3.4.24-r1

// If you do the following:

git log --all | grep "2.4."

// You will get a listing of the current working branches. Anything with a -rn appended seems to have full sunxi patches.


I hate 'git checkout'. It downloads about 1GB datas, althought sunxi-v3.4.24.r1.tar.gz is about 140MB. 'git checkout' is a peas of crab, but ok I will use it, if must.

Quote from: Tele on February 20, 2013, 04:50:05 PM
I hate 'git checkout'. It downloads about 1GB datas, althought sunxi-v3.4.24.r1.tar.gz is about 140MB. 'git checkout' is a peas of crab, but ok I will use it, if must.

Where the heck did you find sunxi-v3.4.24.r1.tar.gz?? I have not found a way to download the isolated commits and 3.4.24-r1 is not listed as a tracked branch.

Yes it does download about 1GB even though the kernel source is <300mb but thats because the 2.4.24-r1 is about 16 branches deep and a couple hundred thousand commits. I'm sure theirs a way to just checkout the thread of commits for your requested checkout but I am new to Git as well...


Here is a13-olinuxino_defconfig + the boot string:
Linux-3.4.24-r1-vanilla (https://docs.google.com/file/d/0B0HKuT2T-RfEMGNhZDF6YUFQOGc/edit?usp=sharing)

Quote from: uMinded on February 20, 2013, 06:02:04 PM
Where the heck did you find sunxi-v3.4.24.r1.tar.gz?? ...

Yes you can download gzipped tarballs as well.
https://github.com/linux-sunxi/linux-sunxi/tags

You will find a huge list (611) of tagged files. At the beginning and middle of the list you can see vanilla unmodified kernels, bases of forks. They look like v3.x.y or v2.x.y...all vanilla kernels, no sunxi stuffs inside. At the end of list(after many 'next page') you will see sunxi-3.x.y files, they are stable sunxi releases. They are about 140MB gzipped tarballs. At this moment it doesnt work, after few 'next page' it shows a server error 500. It worked before, and I used it instead of stupid 'github checkout':
Counting files...
Compressing files...
Getting files...
then you better go to take a lunch break, it wont be a quick one.
I reported this bug to github, I hope they fix it soon.

I never saw the 'zip' under the tag list before... I must be blind. Good to know though as if your not going to push changes theirs no need for the extra bloat.

I made a new github repo and made it properly this time, I forked the linux-sunxi/sunxi-3.4 and I have branched off the 3.4.24-r1 commit to add I-Pipe changes then the Xenomai patch. I am building kernels and saving logs and configs at each stage. This was we can properly merge our changes back into 2.4.24 and even pull from the linux-sunxi groups changes upstream.

Its not ready to go yet as my work computer does not compile like my 16 core workstation back home.

BTW - I have talked to digikey twice now and they say they do not know of the sd card issues and that they cant pull stock to test. I'm waiting to hear back now on if I can buy it and they test it so if it fails theirs not return shipping to deal with. If not I guess I will just order it and play roulette.

The SD card problems I know about are due to using cheap clone cards, the problem being the cards, and obviously they would be irrelevant to any board seller.  Which problem(s) do you mean?

John

Quote from: JohnS on February 20, 2013, 08:45:58 PM
The SD card problems I know about are due to using cheap clone cards, the problem being the cards, and obviously they would be irrelevant to any board seller.  Which problem(s) do you mean?

I bought two A13-Olinuxino-wifis from Digikey. The SD ports on both boards did not work, but otherwise the boards were fine. Olimex sent me two replacements directly and the SD ports worked fine on these. I was worried that Digikey may have received a batch of boards with bad SD ports and was hoping they had the means to test one before sending them out.

Oh.  Well, they probably could but it will also probably mean they sell the boards at a loss.  Just to connect them up and try a uSD card is going to wipe out their profit margin I expect, even if they have someone able to do it and equipped with the means (which they likely don't).

If the faults are an entire batch I expect they'd prefer to send the whole lot back to Olimex.  So if the faults were that kind then maybe argue it that way.

Or if they're faults that a visual inspection would reveal then maybe you could explain that to them.

John

I ended up just ordering it without any checks, I was running out of time to have it delivered by Friday so I had to buy in the next 3 hours.

It will be nice to be able to actually test my own builds lol, thanks so much you guys for testing things and dumping so many logs.

Anybody interested it getting commit access to my github (once its set up properly)?

Quote from: uMinded on February 20, 2013, 10:55:05 PM
Anybody interested it getting commit access to my github (once its set up properly)?

I would like to help out any way I can. So far I have pretty much been relegated to tester, but do not mind getting in and getting my hands dirty too. :)

Linux-3.4.24-r1-vanilla+ (https://docs.google.com/file/d/0B0HKuT2T-RfELVA5b1BKLTU4Rnc/edit?usp=sharing)

Me and crubille have ever so slightly different ipipe patches. If the above kernel boots I will know what I need to keep when changing over some spinlocks and some if/else statements.

Quote from: uMinded on February 20, 2013, 11:44:41 PM
Linux-3.4.24-r1-vanilla+ (https://docs.google.com/file/d/0B0HKuT2T-RfELVA5b1BKLTU4Rnc/edit?usp=sharing)

Me and crubille have ever so slightly different ipipe patches. If the above kernel boots I will know what I need to keep when changing over some spinlocks and some if/else statements.

Went a long way, but ended in a reboot loop. The boot log is here:
http://pastebin.com/yvrGxB6b (http://pastebin.com/yvrGxB6b)

Quote from: ehj666 on February 21, 2013, 01:13:35 AM
Went a long way, but ended in a reboot loop. The boot log is here:
http://pastebin.com/yvrGxB6b (http://pastebin.com/yvrGxB6b)

This is good. Pbobably it has nothing to do with Xenomai. I get these errors when I forgot to link the filesystem of rootfs (ext3 or ext4) statically, but they are compiled as module. They must be compiled statically into kernel. This is my guess.

I can test in 2-3 hours. Till then Im just a spectator but I keep cheering and supporting for you.

EDIT:
Of course it has nothing to do with Xenomai, it is vanilla sunxi kernel. Im idiot.

This is a working vanilla sunxi3.4.24-r1 config

http://pastebin.com/Y0QX3Bhn

Quote from: ehj666 on February 20, 2013, 11:34:42 PM

Quote from: uMinded on February 20, 2013, 10:55:05 PM
Anybody interested it getting commit access to my github (once its set up properly)?

I would like to help out any way I can. So far I have pretty much been relegated to tester, but do not mind getting in and getting my hands dirty too. :)

You can count on me also.

Quote from: Tele on February 21, 2013, 05:48:28 AM
I get these errors when I forgot to link the filesystem of rootfs (ext3 or ext4) statically, but they are compiled as module. They must be compiled statically into kernel.

I totally did not think of that but the only difference in regards to modules is I had the infrared one as a module (it shouldn't even be included). I did notice a few differences though as I had a different kernel compression and you had some more endianess options set. This is why having a working vanilla kernel is important as its so bloody finicky sometimes.

I will use your version as the base as it has usb networking enabled and we know it works. I am pushing working configs to the arch/arm/config/a13-olinuxino-xxx and will tag them when I do.

Quote from: ehj666
Went a long way, but ended in a reboot loop. The boot log is here:

It does look like it boots all the way but it does not automatically find the root filesystem which is my fault as its compiled with "CONFIG_CMDLINE_FORCE" which ignores what uBoot passes when I should of had " CONFIG_CMDLINE_EXTEND" to merge the two.

I will need a list of every ones github names to add as contributors to the repo. PM me if you want write access.

Quote from: uMinded on February 21, 2013, 05:09:52 PM
I will use your version as the base as it has usb networking...

Yes I forgot to say, but this is not a minimal config, USB keyboard, mouse, LCD7 framebuffer + resistive touch are working, plus RTL 8188USB->Wifi chip (I have Wifi board) + ASIX AX 88772 USB-ETH stick, (you can buy it in olimex shop), all set and working.

Quote from: Tele on February 21, 2013, 07:08:14 PM
Yes I forgot to say, but this is not a minimal config, USB keyboard, mouse, LCD7 framebuffer + resistive touch are working, plus RTL 8188USB->Wifi chip (I have Wifi board) + ASIX AX 88772 USB-ETH stick, (you can buy it in olimex shop), all set and working.

In the usual sense of the term a "vinilla" kernel is the bare minimum required to boot into a working system. As this is specific embedded hardware I classify this build vanilla. Would we rather have one _defcong for each build or a top level one with a readme on whats safe to remove?

Quote from: uMinded on February 21, 2013, 07:49:10 PM
...the term a "vanilla" kernel is the bare minimum required...

Yes you are right I skipped 1-2 step, because I trust in you and I think we are close, very close to the end. Of course I step back to the most naked minimum system if we will have any difficulties. We wont have.
(Relax ! Concentrate ! Be optimistic)

I live in UTC+1. You are in EST (or Pacific Time even worse). Im ahead of you at least six hours. I've seen your future. You have made it.

Quote from: uMinded on February 21, 2013, 07:49:10 PM
Would we rather have one _defcong for each build or a top level one with a readme on whats safe to remove?

Later we can decide that, if its stable its almost the same any solution, growing from minimum or shrinking from a generic full system.

So i test my patch for some hours without problems.

Running latency, worst case are not very low (100 us), but lower are a bit hight (11 us) and 25 average.
As i set options like ipipe/trace it can be a part of this delay.
In kernel mode, the delay are not a lot better, but in-kernel timer handler is around 4-5 us average and worst case around 40-50 us.

So, there is still things to do, but it is useable at least to play.
You can find the patch at this adress:

http://www.crubille.lautre.net/xenomai_sun5i/ipipe-core-3.4.6-sun5i.alpha.patch

The patch is for a sunxi 3.4.24, as the 3.4 kernel is not a stable version, if you get newer kernel, the patch would have some offset, which mostly dont care, but if it fail or you get problems, let me known.

There is nothing particular to do for installation, use the script as xenomai patch and apply the xenomai procedure.

I reread (part of) the post, as i am searching where you are with PLL6.

I read that uminded ask me where i found the procedure i apply to insert my code, here it is:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#Timer_issues


About PLL6, i do first attempt to use it, changing only that from a running kernel, and in a second time adapting ticks on the timer, then reducing rate at 100MHz.
In any case, the kernel hang before sending me anything.

Has anybody see it working?

So, as PLL6 look to be used only for SATA, it is not sure it is configured at boot for sun5i, but even it is not sure it is not a collateral casualty from removing sata to get A13.

I think the good way to check it is to configure it in a standart kernel (no xenomai), and just read timer2 to check it has anything to count.

AT this time, i rebuild a kernel removing the potential source of low perfs (i am not sure A13 don't go to various sleep mode).

Then, i want to check if it is possible to use PLL6/6 as i say in the previous message.

And i get now all the info (http://dl.linux-sunxi.org/A10/A10%20User%20Manual%20-%20v1.20%20%282012-04-09,%20DECRYPTED%29.pdf) to program priority irq, which is an interesting issue.

Thanks for all the work, my board will be here tomorrow morning so when I get home I can start doing some serious testing.

github.com/iceblu3710/linux-sunxi-xenomai (https://github.com/iceblu3710/linux-sunxi-xenomai/tree/a13-olinuxino)

The currently updated working branch is a13-olinuxino and it has the I-Pipe patch already applied. The current problem to work on is getting timer2 set up 100%

Hey i look at my script.fex:

PLL6 is defined at ... 720 ::) ???

So no chance to get a 200 MHz clock, PLL6/6 can be nothing else that 120 MHz!

PLL6 can be changed in the script, but it is used by MALI.


There is another point, but it is not only for this topic.

Quote from: crubille on February 22, 2013, 09:00:06 PM
Hey i look at my script.fex:

PLL6 is defined at ... 720 ::) ???

So no chance to get a 200 MHz clock, PLL6/6 can be nothing else that 120 MHz!

PLL6 can be changed in the script, but it is used by MALI.


There is another point, but it is not only for this topic.

Where did you find this out?

If you read the A10 clock diagrams (http://linux-sunxi.org/images/3/33/A10_Datasheet.pdf) (pages 53-55) it shows that PLL6 is only used things like ATA interface, and SPI, SD.

I am going to build a kernel that debugs what these timers are actually doing, I got my board but my card reader doesn't read SDHC cards so I need to wait until after work to grab a new one...

Well I finally have a day free to work on this after doing 22hrs of overtime at work this week... An after several computer issues and a dead card reader I have u-boot working.

I have the strangest problem though. I tried running several of my kernels and they all give the same error, I tried one of the pre-built ones with VGA support and it failed. I extracted its .config and built 3.4.24 based on it and it failed!

My kernel log (http://pastebin.com/At0mJ6ZK)


[    1.070000] registered taskstats version 1
[    1.080000] Unable to handle kernel NULL pointer dereference at virtual address 00000018


Have you guys seen this behaviour?

Quote from: uMinded on February 24, 2013, 06:11:20 AM

Code Select Expand


[    1.070000] registered taskstats version 1
[    1.080000] Unable to handle kernel NULL pointer dereference at virtual address 00000018

Have you guys seen this behaviour?

Yes I have. Im very sorry but I dont remember what was the reason and the solution. I just remember this line, because its strange. Dont get mad on me please. Did I mention I was a noobcake?

My current config is:
http://pastebin.com/eCW0M2PZ
This works for me.

Other things:
Differeneces in script.bin
I use a stock script.bin downloaded from somewhere, forum or Olimex, for LCD 800x480.

Differences in rootfs
I use buildroot to build kernel and a simple rootfs with busybox and qt. It works like charm. If you wanna make a try I can send the .config files.

Differences in toolchain and glibc/eglibc/uclibc
I use a selfmade crosstoolNG toolchain. Very stable and knows good switches, like:
-march=armv7-a -mtune=cortex-a8 -mthumb -mfpu=neon or vfp3  -mfloat-abi=hard or soft or softfp
I use glibc 2.13 with it, oldie but goldie.
I have had problems with Linaro toolchain, I dont trust on it. I know its an optimzed and fancy thing for arm, but it doesnt works good, it fails too many times, simply it cant compile files.
I can send crosstool-ng .config file if you want. Building toolchain takes about 20 min on a good pc, 10 min on your 20cores supermachine, 45 mins on a usual pc.

Btw, what kind of partition is your rootfs? I had problems with ext3 or ext4, I got "Kernel too old" error, then panic. I have changed to ext2, for now it works, later I will investigate that, because its nonsense if 3.4.24 is too old if rootfs is not on ext2. Maybe this was my "NULL pointer dereference at virtual address" error I donno. Change your filesystem. Sounds silly I know, but its worth a try because its only 3 minutes.

Hello,

about the PLL6, really nothing is clear:
- In the doc it is fixed at 1200 MHz. But, there is nothing fixed by hardware, there is div and mul factors to get it from the 24MHz. Fixed is for "decide so to FIX sata problems on a10".
- In the varions script.fex i saw for the A13, it is defined as 720 MHz.
- Printing a message from the kernel each time PLL6 rate change, i get one message:
"MY_MSG set PLL6 rate : 600000000"

But setting the clock at 100 MHz, it dont run ...

Perhaps, 24 MHz is a very good rate for a xenomai clock.

Quote from: crubille on February 24, 2013, 12:15:55 PM
Hello,

about the PLL6, really nothing is clear:
...
Perhaps, 24 MHz is a very good rate for a xenomai clock.

Why dont you make a try with 120MHz timer, if you think PLL6 goes with 720MHs -> PLL6/6=120MHz.
120 is still 5 times more than 24, isnt it ? Set your timer to 120MHz.
Its worth a try.

I check it 120, and now 100, and the same kernel that run fine with the 24 MHz clock, hang but not as soon as the clock is set on, at some time later when something do something (but the PLL6 rate is changed in the kernel before the ipipe clock start).

Quote from: Tele on February 24, 2013, 11:47:36 AM

Quote from: uMinded on February 24, 2013, 06:11:20 AM

Code Select Expand


[    1.070000] registered taskstats version 1
[    1.080000] Unable to handle kernel NULL pointer dereference at virtual address 00000018

Have you guys seen this behaviour?

Yes I have. Im very sorry but I dont remember what was the reason and the solution. I just remember this line, because its strange. Dont get mad on me please. Did I mention I was a noobcake?

My current config is:
http://pastebin.com/eCW0M2PZ
This works for me.

Other things:
Differeneces in script.bin
I use a stock script.bin downloaded from somewhere, forum or Olimex, for LCD 800x480.

Differences in rootfs
I use buildroot to build kernel and a simple rootfs with busybox and qt. It works like charm. If you wanna make a try I can send the .config files.

Differences in toolchain and glibc/eglibc/uclibc
I use a selfmade crosstoolNG toolchain. Very stable and knows good switches, like:
-march=armv7-a -mtune=cortex-a8 -mthumb -mfpu=neon or vfp3  -mfloat-abi=hard or soft or softfp
I use glibc 2.13 with it, oldie but goldie.
I have had problems with Linaro toolchain, I dont trust on it. I know its an optimzed and fancy thing for arm, but it doesnt works good, it fails too many times, simply it cant compile files.
I can send crosstool-ng .config file if you want. Building toolchain takes about 20 min on a good pc, 10 min on your 20cores supermachine, 45 mins on a usual pc.

Btw, what kind of partition is your rootfs? I had problems with ext3 or ext4, I got "Kernel too old" error, then panic. I have changed to ext2, for now it works, later I will investigate that, because its nonsense if 3.4.24 is too old if rootfs is not on ext2. Maybe this was my "NULL pointer dereference at virtual address" error I donno. Change your filesystem. Sounds silly I know, but its worth a try because its only 3 minutes.

I reformatted to ext2 and that didn't help. I downloaded Linux version 3.4.29-jwischka-3.4-video-20130214-R17+ from the forums and used dd to copy it and I get the same null pointer error. This is starting to feel like a hardware error....

Can you upload one of your kernels for me to try? That would completely eliminate my sources as a source of error. Thanks!

Quote from: uMinded on February 24, 2013, 07:27:59 PM
Can you upload one of your kernels for me to try? That would completely eliminate my sources as a source of error. Thanks!

Sorry to hear that. Of course I will, but only in about 12 hours, from my workplace. Now Im at home.

EDIT:
What kind of board do you have ? A13-OLinuXino, A13-OLinuXino-WIFI or A13-OLinuXino-MICRO ? You never mentioned.
What kind of video will you use ? VGA connector, LCD 4.3 ... 7", or nothing just a console via serial?

I found out what was wrong, the script.bin had some wrong settings and was somehow looking for the root filesystem on the second non existent SD card.

The script.bin has quite a few anomalies, not to mention none of the GPIO definitions. Where did this script on the olimex github come from anyways?? One major thing is be default it is set up for 512mb ram as on the WIFI so the smaller boards won't boot.

I have a micro via UART1. I pruned the whole script.bin but is their documentation on the files variables and what sunxi supports?

Sure I will take your configs. I haven't used buildroot in years, totally forgot about it

Quote from: uMinded on February 24, 2013, 10:09:27 PM
I have a micro via UART1. I pruned the whole script.bin but is their documentation on the files variables and what sunxi supports?

http://linux-sunxi.org/Fex_Guide

And tools to compile, decompile: fex <-> bin
https://github.com/linux-sunxi/sunxi-tools.git

jwischka's kernels are not for the micro

John

Quote from: JohnS on February 24, 2013, 10:39:22 PM
jwischka's kernels are not for the micro

John

They do boot without issues, their is just a serious lack of memory left over and the mali reserved block is wrong.

I found the fex documentation, that wiki is horribly laid out and is missing quite a few links. If you google

site:http://linux-sunxi.org/ SEARCH_STRING

Thats the only way I find anything...

I am working on making a useful userspace without all the "reeds to be root" errors during boot currently.

Actually they do NOT boot without issues on a micro.

E.g. you may only get about 38% the CPU speed you would hope for.  And USB is wrong.  Etc.

I think it'll be a wrong version of U-boot, too.

John

Quote from: JohnS on February 24, 2013, 11:11:58 PM
Actually they do NOT boot without issues on a micro.

E.g. you may only get about 38% the CPU speed you would hope for.  And USB is wrong.  Etc.

I think it'll be a wrong version of U-boot, too.

John

Fine. And why dont they talk about this on the olimex github? Can you see any useful info in the README of that script.bin ?
"Script.bin - Kernel parameters which are loaded at boot time"
Wow. For what card ? What kind of configuration ?

It must be uMinded's fault anyway.
uMinded, its your fault!

You lost me.  I posted about jwischka's kernels.  Why do you ask about github?  His kernels aren't there are they?

AFAIK he doesn't work for or represent Olimex.

BTW, there are other threads about the Micro's differences, and of course they are on the schematic, so I am puzzled why anyone would assume a non-Micro kernel (or uboot, for that matter) is OK on a Micro.

John

Quote from: JohnS on February 25, 2013, 12:39:53 AM
AFAIK he doesn't work for or represent Olimex.

Do you work for Olimex?
Will there be some better documented script.bin for all cards?? That was his problem.

You lost me too.
You do take notice of uMinded's fault, but you dont take notice of inadequate infos and softwares on Olimex's github. Although it wouldnt be long to fix them.

Over the last few days and the severa wiki/github pages I have viewed the common thread is "horribly out of date" or "we speakie grood engrish"

I recommend we talk Olimex into starting a PROPER wiki for their products. Their current wiki for the micro is a single post for the first ever debian boot image! If it was a proper wiki app at wiki.olimex.com then we could group keep it up to date and solve these simple issues like a repository being renamed but nobody telling anybody else.

For example HERE (https://github.com/linux-sunxi/sunxi-boards/tree/master/sys_config/a13) are the proper FEX files for our boards. Now how in the heck as I suppose to fuss out the VGA logic? I knew it was being derived from the LCD but not the specific settings.

For the time being I am going to start a Google Code page as I need some place to write everything we learn down and forums are a HORRIBLE way to document things. I dislike google codes wiki system and hope we can get Olimex to implement something more akin to MediaWiki.

https://code.google.com/p/a13-olinuxino/

Quote from: Tele on February 24, 2013, 11:47:36 AM
Differences in rootfs
I use buildroot to build kernel and a simple rootfs with busybox and qt. It works like charm. If you wanna make a try I can send the .config files.

Differences in toolchain and glibc/eglibc/uclibc
I use a selfmade crosstoolNG toolchain. Very stable and knows good switches, like:
-march=armv7-a -mtune=cortex-a8 -mthumb -mfpu=neon or vfp3  -mfloat-abi=hard or soft or softfp
I use glibc 2.13 with it, oldie but goldie.

This would be great information for me to dump in the wiki (or you can if you wish) as I agree that buildroot is the superior all in one build system. IF you wanted you can go down to as bare bones as a debootstrap but buildroot is very handy, once its set up that is.

I have the following toolchains:
arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.7-2013.01-20130125 - Linaro GCC 2013.01) 4.7.3 20130102 (prerelease)
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

As you can see most of the toolchains are based off Linaro so adding an alternative option would be great.

Quote from: uMinded on February 24, 2013, 06:11:20 AM

Code Select Expand


[    1.070000] registered taskstats version 1
[    1.080000] Unable to handle kernel NULL pointer dereference at virtual address 00000018


Have you guys seen this behaviour?

Sorry if this is already dated, but when you get that, if you try to boot to Android does it also lock up?

I would get that after a hard crash. It would then not boot to either the SD or Android. However if you let it sit for a while, it then will boot properly, at least to Android.

The difference is, I do not recall getting to a reboot loop when it happened.

Quote from: ehj666 on February 25, 2013, 06:51:39 PM
The difference is, I do not recall getting to a reboot loop when it happened.

The problem was the defined memory difference between the uboot enviroment and the linux kernel so when it handed all of the system memory over to the kernel to manage it freaked out.

See the fex's here (https://github.com/linux-sunxi/sunxi-boards/tree/master/sys_config/a13) for proper configs.

Hello, if there is anybody to test a running xenomai on A13 get

http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch

and apply the standart xenomai procedure.

PLEASE, let me know if you get it running or if it fail.

latency -t 2 -p 100
== Sampling period: 100 us
== Test mode: in-kernel timer handler
== All results in microseconds
RTT|  00:00:01  (in-kernel timer handler, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      5.583|      6.265|     11.167|       0|     0|      5.583|     11.167
RTD|      6.125|      6.258|     10.917|       0|     0|      5.583|     11.167
RTD|      5.500|      6.270|     12.000|       0|     0|      5.500|     12.000


"lat worst" is mostly under 20 us but can go up for 30 ns.

latency  -p 100
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|     11.999|     12.708|     21.333|       0|     0|     11.999|     21.333
RTD|     12.624|     12.791|     21.541|       0|     0|     11.999|     21.541
RTD|     12.458|     12.791|     26.458|       0|     0|     11.999|     26.458

"lat worst" is mostly under 40 us but can go up for 80 ns.


(To get these value, i tune the Olinuxino A13 setting the dram cas to 5).

Quote from: crubille on February 25, 2013, 10:48:46 PM
Hello, if there is anybody to test a running xenomai on A13 get ...

Hi Crubille,
I will do and then I will report.

Quote from: crubille on February 25, 2013, 10:48:46 PM
Hello, if there is anybody to test a running xenomai on A13 get

http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch

and apply the standart xenomai procedure.

Apparently I need some more clarification. I thought I successfully applied the patch and compiled the kernel. It booted properly, but there were no xenomai references in the boot log. Here is what I did:


cd kernel
git clone git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-3.4
wget http://download.gna.org/xenomai/stable/LATEST_IS-v2.6.2.1.tar.bz2
# Extract above file here
wget http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch
xenomai-2.6.2.1/scripts/prepare-kernel.sh --arch=arm \
--adeos=ipipe-linuxsun51-3.4.24.beta.patch --linux=linux-sunxi/
cd linux-sunxi
make ARCH=arm a13_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=out modules
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=out modules_install

Then copy arch/arm/boot/uImage to SD and boot.

Note: Base folder is kernel, xenomai is in xenomai-2.6.2.1 and the kernel source is in linux-sunxi.

Hello ehj666

The default config do not include the xenomai option and i am not sure it is well set for the olinuxino board.

In your linux main directory, recopy the default config:

boot on the standard olimex kernel for A13

get the .config file from here

zcat /proc/config.gz > .config
make ARCH=arm menuconfig

check xenomai is on in the real time part,
check anything like cpu-freq-scalling or agressive power management are disabled

Quote from: crubille on February 26, 2013, 09:58:46 AM
Hello ehj666

The default config do not include the xenomai option and i am not sure it is well set for the olinuxino board.

In your linux main directory, recopy the default config:

boot on the standard olimex kernel for A13

get the .config file from here

zcat /proc/config.gz > .config
make ARCH=arm menuconfig

check xenomai is on in the real time part,
check anything like cpu-freq-scalling or agressive power management are disabled

Sorry, I do not entirely follow. I copied a standard olimex .config, then ran menuconfig. I do not see a section for real time or xenomai, but with a stock .config I would not expect to. What am I missing?

Quote from: Tele on February 25, 2013, 11:36:36 PM

Quote from: crubille on February 25, 2013, 10:48:46 PM
Hello, if there is anybody to test a running xenomai on A13 get ...

Hi Crubille,
I will do and then I will report.

Hi Crubille,

this patch fails because of a missing file:


....
patching file arch/arm/xenomai/switch.S
patching file '#.config#'
patching file config-new
patching file drivers/cpuidle/Kconfig
patching file drivers/gpio/gpio-mxc.c
patching file drivers/gpio/gpio-omap.c
patching file drivers/gpio/gpio-pxa.c
patching file drivers/gpio/gpio-sa1100.c
can't find file to patch at input line 34865
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Naur linux-sunxi-sunxi-3.4/drivers/gpu/mali/mali/__malidrv_build_info.c linux-sunxi-sunxi-3.4-xenomai-beta/drivers/gpu/mali/mali/__malidrv_build_info.c
|--- linux-sunxi-sunxi-3.4/drivers/gpu/mali/mali/__malidrv_build_info.c 2013-02-21 19:49:00.000000000 +0000
|+++ linux-sunxi-sunxi-3.4-xenomai-beta/drivers/gpu/mali/mali/__malidrv_build_info.c 2013-02-25 17:58:26.000000000 +0000
--------------------------
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
patching file drivers/Makefile
patching file drivers/media/video/sun5i/sun5i_avs.c
patching file drivers/mfd/twl6030-irq.c
patching file drivers/misc/Kconfig
patching file drivers/misc/Kconfig.orig
patching file drivers/tty/serial/8250/8250.c
patching file drivers/tty/serial/8250/8250.c.orig
....
prepare-kernel.sh: Unable to patch kernel 3.4.24 with ipipe-linuxsun5i-3.4.24.beta.patch


It cant find a file
./linux-sunxi-sunxi-3.4/drivers/gpu/mali/mali/__malidrv_build_info.c

It can find hundreds of other files and patches them succesfully, except this one

And indeed, this file does not exist in the sunxi github, I checked.
You missed something, or I donno.

I was typing this as you replied.

That file is generated when you build the modules, and updates every time so its a useless change. As it is a .c file make mrproper would not have removed it and it got in the patch by accident.

Quote from: crubille on February 25, 2013, 10:48:46 PM
http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch

You must remove the following section from the patch:

diff -Naur linux-sunxi-sunxi-3.4/drivers/gpu/mali/mali/__malidrv_build_info.c linux-sunxi-sunxi-3.4-xenomai-beta/drivers/gpu/mali/mali/__malidrv_build_info.c
--- linux-sunxi-sunxi-3.4/drivers/gpu/mali/mali/__malidrv_build_info.c 2013-02-21 19:49:00.000000000 +0000
+++ linux-sunxi-sunxi-3.4-xenomai-beta/drivers/gpu/mali/mali/__malidrv_build_info.c 2013-02-25 17:58:26.000000000 +0000
@@ -1 +1 @@
-const char *__malidrv_build_info(void) { return "malidrv:  CONFIG=ca8-virtex820-m400-1 USING_OS_MEMORY=0 API_VERSION=14 REPO_URL= REVISION= CHANGED_REVISION= CHANGE_DATE= BUILD_DATE=Sat Feb 16 15:16:19 UTC 2013 BUILD=RELEASE CPU= USING_UMP=1 USING_MALI200=0 USING_MALI400=3 USING_MALI400_L2_CACHE=1 USING_GP2=0 KDIR= MALI_PLATFORM_FILE=platform/mali400-pmu/mali_platform.c OS_MEMORY_KERNEL_BUFFER_SIZE_IN_MB=6 USING_PROFILING=0 USING_INTERNAL_PROFILING=0 USING_GPU_UTILIZATION=";}
+const char *__malidrv_build_info(void) { return "malidrv:  CONFIG=ca8-virtex820-m400-1 USING_OS_MEMORY=0 API_VERSION=14 REPO_URL= REVISION= CHANGED_REVISION= CHANGE_DATE= BUILD_DATE=Sun Feb 17 22:20:05 UTC 2013 BUILD=RELEASE CPU= USING_UMP=1 USING_MALI200=0 USING_MALI400=3 USING_MALI400_L2_CACHE=1 USING_GP2=0 KDIR= MALI_PLATFORM_FILE=platform/mali400-pmu/mali_platform.c OS_MEMORY_KERNEL_BUFFER_SIZE_IN_MB=6 USING_PROFILING=1 USING_INTERNAL_PROFILING=0 USING_GPU_UTILIZATION=";}


It will always fail because their is a build date in that file that is updated on any call to make. It also does not set any different option besides USING_PROFILING=1 which shouldn't be necessary.

Also I recommend against using Xenomai's prepare-kernel.sh script as it applies the ipipe patch directly to the kernel tree and then symbolically links the xeno files in. If you remove the xenomai-2.6.2.1 directory at a later date you will break your kernel sources!

My recommended procedure:

wget https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.zip
wget http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch
gedit ipipe-linuxsun5i-3.4.24.beta.patch <<== REMOVE THE ABOVE __malidrv_build_info.c CHANGE
unzip sunxi-v3.4.24-r1.zip

cd linux-sunxi-sunxi-v3.4.24-r1
patch -p1 < ipipe-linuxsun5i-3.4.24.beta.patch
mv #.config# .config
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=out modules
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=out modules_install


Yes uminded is right.
The problem is not you don't get the patch, it is the prepare-kernel shell don't to the post patch job.

The simpler turn around is to create a null file with touch and rerun the prepare-patch.sh giving it this file as patch. So it do only what there is still to do.

I correct the patch now.

:P :P It is easier for me to patch a kernel than to generate a correct patch file.

ehj666, i think you got the same problem as tele.
Elsewhere, check you have an  ipipe topic in the menuconfig screen.

Paul

Another prospective change to your patch is: (Line 29449)


diff -Naur linux-sunxi-sunxi-3.4/#.config# linux-sunxi-sunxi-3.4-xenomai-beta/.config
--- linux-sunxi-sunxi-3.4/#.config# 1970-01-01 00:00:00.000000000 +0000
+++ linux-sunxi-sunxi-3.4-xenomai-beta/.config 2013-02-25 18:01:28.000000000 +0000


That way you don't need to rename #.config# to .config

Quote from: uMinded on February 26, 2013, 07:06:45 PM
I was typing this as you replied.

Thank you, I didnt check anything, I have just seen that file must exist because there are - and + lines in the patch, its a "modifier" patch not a "creator", -N switch would not work, so its buggy.

Quote from: uMinded on February 26, 2013, 07:06:45 PM
Also I recommend against using Xenomai's prepare-kernel.sh script...

I totally agree, I will use direct patch command from now, not the xenomai script.

Quote from: uMinded on February 26, 2013, 07:06:45 PM

My recommended procedure:

Code Select Expand


wget https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.zip
....
unzip sunxi-v3.4.24-r1.zip


Unzip is not good, it is bugged, it fails to extract symbolic links from github zips (and other big ones).
Usually you get an error "file name too long" or something like that, at the end of the progress list.

You can fix it if you are in that mood :
download the source of unzip60
http://sourceforge.net/projects/infozip/files/UnZip%206.x%20%28latest%29/UnZip%206.0/unzip60.tar.gz/download

then apply this patch on it:

--- ./process.c
+++ ./process.c
@@ -1751,6 +1751,12 @@
         = (G.crec.general_purpose_bit_flag & (1 << 11)) == (1 << 11);
#endif

+#ifdef SYMLINKS
+    /* Initialize the symlink flag, may be set by the platform-specific
+       mapattr function.  */
+    G.pInfo->symlink = 0;
+#endif
+
     return PK_COOL;

} /* end function process_cdir_file_hdr() */

then build it and install it.

Even better, if you dont bother poor .zip files but .tar.gz:

wget https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.tar.gz
....
tar -xf sunxi-v3.4.24-r1.tar.gz


Thx for the info, Im gonna make a new try with Crubille's patch.

Thanks for letting me know about that unzip bug, I had no idea! I have compiled many times with unziped sunxi kernels so who knows if some of my bugs where patch related at all!

Crubille: If you want I can add you as a comitter to the google code project. I have uploaded your patch and am writing a kernel compile howto. Just send me a PM with your gmail address and you'll have access.

Quote from: uMinded on February 26, 2013, 08:22:38 PM
Thanks for letting me know about that unzip bug, I had no idea! I have compiled many times with unziped sunxi kernels so who knows if some of my bugs where patch related at all!

You should check it. Unzip your kernel source and watch the end of progress list.

Big bunch of garbage then:
symlink error: File name too long

Thats not so good.

Quote from: uMinded on February 26, 2013, 08:22:38 PM
Crubille: If you want I can add you as a comitter...

I agree, Crubille is very clever guy, recruit him if you can.

I tried to boot Crubilles xeno patch and I got a <1>Unable to handle kernel paging request at virtual address da000008 right after <5>PC-MSG set PLL3 rate : 279000000


Kernel Log (http://pastebin.com/7M7tEC3N)

Hi Crubille,

I tried your beta patch and this is the result:

http://pastebin.com/J1VHFgxr

Its trying to load rootfs, buy it can not set MMC clock SDXC card for unknown reason. Of course nothing has changed on my hardware and this script.bin works good with another kernel.

I think we need your script.bin to see the mmc hardware configuration or something like that.

This is my current sript.bin:

http://pastebin.com/sXGNhGCi

Tell me something please.

Crubille:

What toolchain are you using to build your kernels? I do not get how we can build from the same patch on the same hardware (well Tele at least) and we have not had a successful boot.

Questions:

1 - What uboot version & repo are you using, did you compile it from unmodified code and with the standard make command?

2 - What does your partition table look like? (just paste the output of fdisk -l)

3 - Can you paste the output of your toolchains "--version -v" command

4 - What root filesystem image are you using? Custom built or extracted from one of the many cpio's in the forums?

If we know all that their should be no reason outside of hardware failures that should stop us from all being able to run to the same point as you.

Thanks!

Apply the following patch:

and just rerun
make uImage



diff -Naur linux-sunxi-sunxi-3.4-xenomai-bug/arch/arm/mach-sun5i/clock/clock.c linux-sunxi-sunxi-3.4-xenomai/arch/ar
m/mach-sun5i/clock/clock.c
--- linux-sunxi-sunxi-3.4-xenomai-bug/arch/arm/mach-sun5i/clock/clock.c 2013-02-27 21:54:52.000000000 +0100
+++ linux-sunxi-sunxi-3.4-xenomai/arch/arm/mach-sun5i/clock/clock.c     2013-02-27 22:24:38.000000000 +0100
@@ -168,7 +168,6 @@
     tmpSclk->clk->onoff = AW_CCU_CLK_ON;
     tmpSclk->set_clk(tmpSclk->clk);

-    /*
     tmpSclk = &ccu_sys_clk[AW_SYS_CLK_PLL6];
     tmpSclk->clk->rate  = 600000000;
     tmpSclk->set_clk(tmpSclk->clk);
@@ -184,7 +183,7 @@
     tmpSclk->set_clk(tmpSclk->clk);
     tmpSclk->clk->onoff = AW_CCU_CLK_ON;
     tmpSclk->set_clk(tmpSclk->clk);
-    */
+
     tmpSclk = &ccu_sys_clk[AW_SYS_CLK_PLL7];
     tmpSclk->clk->onoff = AW_CCU_CLK_ON;
     tmpSclk->set_clk(tmpSclk->clk);


Sorry for the mistake.

There is the same bug in the version i build to check irq priority and nothing work, and i dont understand what append ...


The patch is upgraded on my site.

Quote from: crubille on February 27, 2013, 10:48:33 PM


The patch is upgraded on my site.

I think I screwed up somewhere along the way, I am not getting a successful patch. I pulled the kernel from:
git clone git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-3.4

I pulled the latest xenomai: LATEST_IS-v2.6.2.1.tar.bz2
And the latest crubille patch as follows:
xenomai-2.6.2.1/scripts/prepare-kernel.sh --arch=arm --adeos=ipipe.patch --linux=linux-sunxi/
Where I renamed the patch file to ipipe.patch.

Here is the patch log:
http://pastebin.com/ni98Dvap (http://pastebin.com/ni98Dvap)

Any idea where I screwed up?

Quote from: ehj666 on February 28, 2013, 02:59:00 AM
I think I screwed up somewhere along the way, I am not getting a successful patch. I pulled the kernel from:
git clone git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-3.4

http://pastebin.com/ni98Dvap (http://pastebin.com/ni98Dvap)

Any idea where I screwed up?

git clone git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-v3.4.24-r1
wget http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.beta.patch

cd linux-sunxi-sunxi-v3.4.24-r1
patch -p1 < ../ipipe-linuxsun5i-3.4.24.beta.patch
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=out modules
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=out modules_install

While 3.4.24-r1 has been merged into 3.4 reference that all happened after we started this endeavor so their are around a dozen commits after that v3.4.24-r1 tag (I just checked, sunxi-3.4 => sunxi-3.4.29)

Hi Crubille,

I compiled your last patch, and its working now. Woooot !

Here is the bootlog:

http://pastebin.com/02ktYhZa

I start testing it, then I report.

Quote from: uMinded on February 28, 2013, 05:07:32 AM

git clone git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-v3.4.24-r1

I get an error to the effect "version sunxi-v3.4.24-r1 does not exist, reverting to trunk". Doing
"git tag -l" clearly shows a version sunxi-v3.4.24-r1. I do not think I made a typo.

Quote from: ehj666 on February 28, 2013, 01:04:21 PM

Quote from: uMinded on February 28, 2013, 05:07:32 AM

git clone git://github.com/linux-sunxi/linux-sunxi.git -b sunxi-v3.4.24-r1

I get an error to the effect "version sunxi-v3.4.24-r1 does not exist, reverting to trunk". Doing
"git tag -l" clearly shows a version sunxi-v3.4.24-r1. I do not think I made a typo.

Yes but -b switch is seeking for a branch not a tag.

I dont use github, Im not sure about this, but try it in 2 steps:

git clone git://github.com/linux-sunxi/linux-sunxi.git linux-sunxi
cd ./linux-sunxi
git checkout sunxi-v3.4.24-r1



Instead of the above, I download the specific kernel tarball directly, I dont need the whole 1GB sunxi repository.

wget https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.tar.gz
tar -xf sunxi-v3.4.24-r1.tar.gz


I have made my 1st tests with the brand new xenomai.

I skipped the "idle" tests, that test has no purpose for me. I loaded the Oli card with the stress application, I set 10 workers on processor test, other 10 workers on memory alloc/free. HTOP has shown 100% loaded procs, continously.


stress -m 10 --vm-bytes 5000 -c 10


Latency results:


root@sun5i># echo 10000 > /proc/xenomai/latency
root@sun5i># cat /proc/xenomai/latency
9999
root@sun5i># ./latency -p 100
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      2.499|      3.333|     20.416|       0|     0|      2.499|     20.416
RTD|      2.499|      3.208|     14.541|       0|     0|      2.499|     20.416
RTD|      2.499|      3.291|     16.541|       0|     0|      2.499|     20.416
RTD|      2.499|      3.249|     19.624|       0|     0|      2.499|     20.416
RTD|      2.499|      3.416|     17.666|       0|     0|      2.499|     20.416
RTD|      2.499|      3.249|     16.083|       0|     0|      2.499|     20.416
RTD|      2.541|      3.374|     21.749|       0|     0|      2.499|     21.749
RTD|      2.499|      3.166|     15.333|       0|     0|      2.499|     21.749
RTD|      2.499|      3.333|     16.291|       0|     0|      2.499|     21.749
RTD|      2.416|      3.291|     15.833|       0|     0|      2.416|     21.749
RTD|      2.249|      3.333|     18.416|       0|     0|      2.249|     21.749
RTD|      2.499|      3.249|     17.249|       0|     0|      2.249|     21.749
RTD|      2.499|      3.333|     15.541|       0|     0|      2.249|     21.749
RTD|      2.499|      3.166|     15.999|       0|     0|      2.249|     21.749
RTD|      2.416|      3.374|     15.541|       0|     0|      2.249|     21.749
RTD|      2.416|      3.249|     17.499|       0|     0|      2.249|     21.749
RTD|      2.416|      3.374|     18.499|       0|     0|      2.249|     21.749
RTD|      2.499|      3.208|     13.166|       0|     0|      2.249|     21.749
RTD|      2.499|      3.291|     19.999|       0|     0|      2.249|     21.749
RTD|      2.499|      3.249|     17.874|       0|     0|      2.249|     21.749
RTD|      2.499|      3.374|     17.083|       0|     0|      2.249|     21.749
RTT|  00:00:22  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      2.499|      3.249|     20.416|       0|     0|      2.249|     21.749
RTD|      2.499|      3.333|     15.833|       0|     0|      2.249|     21.749
RTD|      2.499|      3.166|     14.291|       0|     0|      2.249|     21.749
RTD|      2.499|      3.333|     16.833|       0|     0|      2.249|     21.749
RTD|      2.333|      3.333|     15.541|       0|     0|      2.249|     21.749
RTD|      2.499|      3.291|     17.833|       0|     0|      2.249|     21.749
RTD|      2.499|      3.291|     15.416|       0|     0|      2.249|     21.749
RTD|      2.499|      3.249|     16.416|       0|     0|      2.249|     21.749
RTD|      2.499|      3.249|     18.833|       0|     0|      2.249|     21.749
RTD|      2.541|      3.374|     18.416|       0|     0|      2.249|     21.749
RTD|      2.499|      3.249|     14.749|       0|     0|      2.249|     21.749
RTD|      2.416|      3.291|     17.749|       0|     0|      2.249|     21.749
RTD|      2.499|      3.333|     17.083|       0|     0|      2.249|     21.749
RTD|      2.333|      3.291|     16.083|       0|     0|      2.249|     21.749
RTD|      2.499|      3.208|     14.208|       0|     0|      2.249|     21.749
RTD|      2.499|      3.291|     16.916|       0|     0|      2.249|     21.749
RTD|      2.541|      3.333|     16.291|       0|     0|      2.249|     21.749
RTD|      2.416|      3.249|     14.666|       0|     0|      2.249|     21.749
RTD|      2.499|      3.333|     17.541|       0|     0|      2.249|     21.749
RTD|      2.499|      3.208|     14.083|       0|     0|      2.249|     21.749
RTD|      2.499|      3.333|     17.416|       0|     0|      2.249|     21.749
RTT|  00:00:43  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      2.499|      3.291|     17.083|       0|     0|      2.249|     21.749
RTD|      2.499|      3.333|     18.833|       0|     0|      2.249|     21.749
RTD|      2.499|      3.208|     17.291|       0|     0|      2.249|     21.749
RTD|      2.499|      3.291|     16.624|       0|     0|      2.249|     21.749
RTD|      2.499|      3.291|     16.333|       0|     0|      2.249|     21.749
RTD|      2.499|      3.333|     16.916|       0|     0|      2.249|     21.749
RTD|      2.499|      3.208|     19.999|       0|     0|      2.249|     21.749
RTD|      2.499|      3.374|     15.624|       0|     0|      2.249|     21.749
RTD|      2.499|      3.249|     16.499|       0|     0|      2.249|     21.749
RTD|      2.499|      3.374|     16.416|       0|     0|      2.249|     21.749
RTD|      2.499|      3.249|     17.666|       0|     0|      2.249|     21.749
RTD|      2.291|      3.291|     17.166|       0|     0|      2.249|     21.749
RTD|      2.499|      3.208|     18.208|       0|     0|      2.249|     21.749
RTD|      2.499|      3.374|     17.958|       0|     0|      2.249|     21.749
RTD|      2.083|      3.291|     16.874|       0|     0|      2.083|     21.749
RTD|      2.499|      3.333|     17.166|       0|     0|      2.083|     21.749
RTD|      2.499|      3.208|     18.499|       0|     0|      2.083|     21.749
RTD|      2.333|      3.291|     17.291|       0|     0|      2.083|     21.749
RTD|      2.416|      3.249|     17.416|       0|     0|      2.083|     21.749
RTD|      2.541|      3.374|     16.499|       0|     0|      2.083|     21.749
RTD|      2.499|      3.249|     18.541|       0|     0|      2.083|     21.749
RTT|  00:01:04  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      2.499|      3.333|     16.333|       0|     0|      2.083|     21.749
RTD|      2.499|      3.166|     15.916|       0|     0|      2.083|     21.749
RTD|      2.333|      3.374|     18.541|       0|     0|      2.083|     21.749
RTD|      2.416|      3.249|     21.833|       0|     0|      2.083|     21.833
RTD|      2.499|      3.291|     13.624|       0|     0|      2.083|     21.833
RTD|      2.499|      3.249|     18.874|       0|     0|      2.083|     21.833
RTD|      2.416|      3.291|     15.416|       0|     0|      2.083|     21.833
RTD|      2.499|      3.291|     19.583|       0|     0|      2.083|     21.833
RTD|      2.499|      3.374|     16.999|       0|     0|      2.083|     21.833
RTD|      2.541|      3.208|     16.208|       0|     0|      2.083|     21.833
RTD|      2.166|      3.291|     17.291|       0|     0|      2.083|     21.833
RTD|      2.416|      3.291|     22.624|       0|     0|      2.083|     22.624
RTD|      2.499|      3.416|     19.916|       0|     0|      2.083|     22.624
RTD|      2.499|      3.249|     16.416|       0|     0|      2.083|     22.624
RTD|      2.499|      3.291|     16.083|       0|     0|      2.083|     22.624
RTD|      2.499|      3.208|     17.291|       0|     0|      2.083|     22.624
RTD|      2.291|      3.333|     16.208|       0|     0|      2.083|     22.624
RTD|      2.416|      3.333|     17.333|       0|     0|      2.083|     22.624
RTD|      2.499|      3.333|     17.208|       0|     0|      2.083|     22.624
RTD|      2.499|      3.249|     14.833|       0|     0|      2.083|     22.624
RTD|      2.499|      3.208|     16.874|       0|     0|      2.083|     22.624
RTT|  00:01:25  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      2.499|      3.291|     16.833|       0|     0|      2.083|     22.624
RTD|      2.499|      3.291|     14.541|       0|     0|      2.083|     22.624
RTD|      2.499|      3.333|     17.208|       0|     0|      2.083|     22.624
RTD|      2.499|      3.333|     18.583|       0|     0|      2.083|     22.624
RTD|      2.499|      3.249|     15.249|       0|     0|      2.083|     22.624
RTD|      2.499|      3.249|     14.249|       0|     0|      2.083|     22.624
RTD|      2.416|      3.333|     15.833|       0|     0|      2.083|     22.624
RTD|      2.416|      3.249|     15.083|       0|     0|      2.083|     22.624
RTD|      2.541|      3.333|     17.874|       0|     0|      2.083|     22.624
RTD|      2.416|      3.249|     16.291|       0|     0|      2.083|     22.624
RTD|      2.499|      3.333|     15.333|       0|     0|      2.083|     22.624
RTD|      2.499|      3.333|     17.166|       0|     0|      2.083|     22.624
RTD|      2.499|      3.291|     17.208|       0|     0|      2.083|     22.624
RTD|      2.499|      3.249|     17.833|       0|     0|      2.083|     22.624
RTD|      2.499|      3.333|     17.166|       0|     0|      2.083|     22.624
RTD|      2.416|      3.333|     19.541|       0|     0|      2.083|     22.624
RTD|      2.499|      3.249|     17.999|       0|     0|      2.083|     22.624
RTD|      2.499|      3.249|     15.666|       0|     0|      2.083|     22.624
RTD|      2.499|      3.333|     15.416|       0|     0|      2.083|     22.624
RTD|      2.416|      3.333|     17.333|       0|     0|      2.083|     22.624
RTD|      2.499|      3.208|     12.208|       0|     0|      2.083|     22.624


And later, after 27 minutes:


RTT|  00:26:58  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      2.499|      3.249|     17.624|       0|     0|      1.749|     28.291
RTD|      2.499|      3.333|     17.499|       0|     0|      1.749|     28.291
RTD|      2.416|      3.249|     15.624|       0|     0|      1.749|     28.291
RTD|      2.499|      3.333|     16.874|       0|     0|      1.749|     28.291
RTD|      2.499|      3.208|     12.333|       0|     0|      1.749|     28.291
RTD|      2.083|      3.333|     17.666|       0|     0|      1.749|     28.291
RTD|      2.416|      3.291|     16.833|       0|     0|      1.749|     28.291
RTD|      2.499|      3.333|     17.291|       0|     0|      1.749|     28.291
RTD|      2.249|      3.208|     16.624|       0|     0|      1.749|     28.291
RTD|      2.499|      3.416|     17.291|       0|     0|      1.749|     28.291
RTD|      2.416|      3.208|     16.874|       0|     0|      1.749|     28.291
RTD|      2.499|      3.333|     16.208|       0|     0|      1.749|     28.291
RTD|      2.499|      3.249|     15.416|       0|     0|      1.749|     28.291
RTD|      2.499|      3.374|     15.749|       0|     0|      1.749|     28.291
RTD|      2.499|      3.249|     15.208|       0|     0|      1.749|     28.291
RTD|      2.333|      3.374|     17.333|       0|     0|      1.749|     28.291
RTD|      2.499|      3.208|     17.083|       0|     0|      1.749|     28.291
RTD|      2.499|      3.374|     20.583|       0|     0|      1.749|     28.291
RTD|      2.416|      3.208|     15.833|       0|     0|      1.749|     28.291
RTD|      2.499|      3.333|     14.958|       0|     0|      1.749|     28.291
---|-----------|-----------|-----------|--------|------|-------------------------
RTS|      1.749|      3.249|     28.291|       0|     0|    00:27:18/00:27:18
root@sun5i>#


Thats about 30usec worst case latency, it is promising and quite good, it is usable.
I have to find more evil and stressfull programs than stress, and test it longer than 30 minutes.
I will test Crubille's,  CAS settings for dram also, it can help a bit.

Thx Crubille this was a nice job :)

I am glad that you were able to compile and run my port of xenomai.

I get not so good values for long test with load, but i set /proc/xenomai/latency to 0, as the default is 9 us, it is a part of the difference.

Even with /proc/xenomai/lattency set to 0, I got a few negative values ​​for minimum lattences. I'll ask on the xenomai list about this.

I add irq priority and everything run, but not so much faster. I want to adapt some test to check if it is effective before releasing it.

Quote from: crubille on February 28, 2013, 11:40:00 PM
I get not so good values for long test with load, but I set /proc/xenomai/latency to 0, as the default is 9 us, it is a part of the difference.

This is the rule to set /proc/xenomai/latency, as I know it :

If /proc/xenomai/latency is less than the smallest "lat best" (best latency you get with the measuring) then you can set /proc/xenomai/latency to that value:   let /proc/xenomai/latency = "lat best"

If /proc/xenomai/latency is bigger than the smallest "lat best" then you can add that "lat best" to /proc/xenomai/latency :  let /proc/xenomai/latency = /proc/xenomai/latency + "lat best"

for example:
you set

echo 0 > /proc/xenomai/latency
./latency -p 100
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|     11.999|     12.708|     21.333|       0|     0|     11.999|     21.333
RTD|     12.624|     12.791|     21.541|       0|     0|     11.999|     21.541
RTD|     12.458|     12.791|     26.458|       0|     0|     11.999|     26.458


you can set /proc/xenomai/latency = lat best = 11999 :

echo 11999 > /proc/xenomai/latency

then make a new latency test, and repeat.

The other case, if you set /proc/xenomai/latency to 10000 and then you get:

echo 10000 > /proc/xenomai/latency
./latency -p 100
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      2.499|      3.249|     17.624|       0|     0|      1.749|     28.291
RTD|      2.499|      3.333|     17.499|       0|     0|      1.749|     28.291
RTD|      2.416|      3.249|     15.624|       0|     0|      1.749|     28.291

then you can set
/proc/xenomai/latency = /proc/xenomai/latency + lat best = 10000 + 1749 = 11749 :

echo 11749 > /proc/xenomai/latency


then run latency test again, and repeat.

The goal is to bring "lat min" to the minimum (of course that brings other values to minimum as well), but you cannot have any negative values, no where. When "lat min" is getting near to 0 ( 500...1000 is already very good value, its less than 1 microsec !), then you can stop it, you have completed setting of /proc/xenomai/latency

Some values are in nanoseconds some others are in microseconds, dont get confused about that.

When you set any rounded value with echo, you always get a 9-ending value back (just like in the shop, maybe xenomai was developed by a merchant), I donno the reason. You set 10000, it will be 9999.

This is what I know about /proc/xenomai/latency   , but I could be wrong.

Quote from: Tele on February 28, 2013, 05:22:33 PM

I dont use github, Im not sure about this, but try it in 2 steps:

Code Select Expand


git clone git://github.com/linux-sunxi/linux-sunxi.git linux-sunxi
cd ./linux-sunxi
git checkout sunxi-v3.4.24-r1


Instead of the above, I download the specific kernel tarball directly, I dont need the whole 1GB sunxi repository.

Code Select Expand


wget https://github.com/linux-sunxi/linux-sunxi/archive/sunxi-v3.4.24-r1.tar.gz
tar -xf sunxi-v3.4.24-r1.tar.gz


Ok, it looks like I have successfully built a xenomai kernel. The boot log indicates that xenomai is in fact running.

Now for testing. How does xeno or xeno-test get installed? It is not recognized as installed and the xenomai doc is not clear where this comes from.

Quote from: ehj666 on March 01, 2013, 04:36:55 AM
Now for testing. How does xeno or xeno-test get installed? It is not recognized as installed and the xenomai doc is not clear where this comes from.

if your xenomai directory <xenomai_dir>  (for example /work/xenomai-2.6.2.1)
if your compiler prefix is <toolchain-prefix> (for example arm-none-linux-gnueabi or arm-linux-gnueabihf or something like that)
then:


cd <xenomai dir>
mkdir install
./configure CC=<toolchain-prefix>-gcc AR=<toolchain-prefix>-ar LD=<toolchain-prefix>-ld CFLAGS="-march=armv7-a" LDFLAGS="-march=armv7-a" \
--host=arm-none-linux-gnueabi --prefix=<xenomai_dir>/install

CFLAGS could be armv7-a or armv7a , it depends on your gcc, it gives an error back, if doesnt like it.

if no error then:

make install



on your rootfs SD make a dir:
/usr/xenomai

then copy <xenomai_dir>/install/bin and <xenomai_dir>/install/sbin into it
then copy <xenomai_dir>/install/lib  onto your rootfs SD /usr/lib

You are done.
After booting you can go there and run any xeno tests.

cd /usr/xenomai/bin
./latency -p 100


Well I solved all my kernel virtual pointer issues. I will post more on that when I have everything sorted out and orginized. I must have tried a hundred things...

Do you guys have an arm rpm for stress or what string did you use to compile? make CROSS_COMPILE is ignored, and ./configure --host= as well? So I used this to load the system to 100%

cat /dev/zero > /dev/null


Here are my numbers:

RTT|  00:02:07  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      5.374|      5.791|     12.874|       0|     0|      5.291|     15.958
RTD|      5.458|      5.749|     15.624|       0|     0|      5.291|     15.958
RTD|      5.458|      5.749|     10.583|       0|     0|      5.291|     15.958
RTD|      5.458|      5.749|     11.708|       0|     0|      5.291|     15.958
RTD|      5.458|      5.833|     14.208|       0|     0|      5.291|     15.958
RTD|      5.374|      5.874|     11.374|       0|     0|      5.291|     15.958
RTD|      5.458|      5.791|     11.874|       0|     0|      5.291|     15.958
RTD|      5.291|      5.791|     12.958|       0|     0|      5.291|     15.958
RTD|      5.458|      5.749|     12.249|       0|     0|      5.291|     15.958
RTD|      5.458|      5.749|     11.999|       0|     0|      5.291|     15.958
RTD|      5.458|      5.749|     10.583|       0|     0|      5.291|     15.958
RTD|      5.333|      5.874|     11.708|       0|     0|      5.291|     15.958
RTD|      5.458|      5.833|     11.541|       0|     0|      5.291|     15.958
RTD|      5.458|      5.791|     12.749|       0|     0|      5.291|     15.958
RTD|      5.333|      5.791|     11.374|       0|     0|      5.291|     15.958
RTD|      5.458|      5.749|     12.041|       0|     0|      5.291|     15.958
RTD|      5.458|      5.749|     10.791|       0|     0|      5.291|     15.958
RTD|      5.458|      5.749|      9.624|       0|     0|      5.291|     15.958
RTD|      5.291|      5.916|     10.874|       0|     0|      5.291|     15.958
RTD|      5.458|      5.833|     12.541|       0|     0|      5.291|     15.958
RTD|      5.333|      5.791|     14.499|       0|     0|      5.291|     15.958



RTT|  00:01:25  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      0.249|      0.541|      5.083|       0|     0|      0.041|     11.833
RTD|      0.249|      0.541|      6.874|       0|     0|      0.041|     11.833
RTD|      0.124|      0.708|      6.458|       0|     0|      0.041|     11.833
RTD|      0.249|      0.583|      9.791|       0|     0|      0.041|     11.833
RTD|      0.124|      0.541|      7.374|       0|     0|      0.041|     11.833
RTD|      0.249|      0.541|      9.083|       0|     0|      0.041|     11.833
RTD|      0.249|      0.541|      5.583|       0|     0|      0.041|     11.833
RTD|      0.249|      0.541|      6.791|       0|     0|      0.041|     11.833
RTD|      0.249|      0.624|      7.624|       0|     0|      0.041|     11.833
RTD|      0.124|      0.666|      8.541|       0|     0|      0.041|     11.833
RTD|      0.249|      0.583|      8.624|       0|     0|      0.041|     11.833
RTD|      0.124|      0.541|      6.166|       0|     0|      0.041|     11.833
RTD|      0.208|      0.541|      7.208|       0|     0|      0.041|     11.833
RTD|      0.249|      0.499|      5.291|       0|     0|      0.041|     11.833
RTD|      0.208|      0.541|      5.124|       0|     0|      0.041|     11.833
RTD|      0.166|      0.666|      5.541|       0|     0|      0.041|     11.833
RTD|      0.249|      0.624|      7.999|       0|     0|      0.041|     11.833
RTD|      0.249|      0.541|      7.249|       0|     0|      0.041|     11.833
RTD|      0.124|      0.541|      9.416|       0|     0|      0.041|     11.833
RTD|      0.249|      0.499|      5.874|       0|     0|      0.041|     11.833
RTD|      0.249|      0.541|      5.208|       0|     0|      0.041|     11.833


If I test with /usr/xenomai/dohell 900 I get "Load average: 9.27 7.10 4.16" and:

# echo 5200 > /proc/xenomai/latency
# /usr/xenomai/bin/latency -p 100

RTT|  00:01:04  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      0.208|      3.874|     14.624|       0|     0|      0.000|     21.874
RTD|      0.416|      3.208|     16.499|       0|     0|      0.000|     21.874
RTD|      0.124|      3.708|     16.208|       0|     0|      0.000|     21.874
RTD|      0.499|      3.874|     16.166|       0|     0|      0.000|     21.874
RTD|      0.499|      3.791|     15.166|       0|     0|      0.000|     21.874
RTD|      0.499|      3.791|     14.541|       0|     0|      0.000|     21.874
RTD|      0.416|      3.791|     15.541|       0|     0|      0.000|     21.874
RTD|      0.208|      3.749|     15.124|       0|     0|      0.000|     21.874
RTD|      0.499|      3.916|     17.666|       0|     0|      0.000|     21.874
RTD|      0.124|      3.749|     18.958|       0|     0|      0.000|     21.874
RTD|      0.124|      3.624|     15.666|       0|     0|      0.000|     21.874
RTD|      0.124|      2.083|     14.833|       0|     0|      0.000|     21.874
RTD|      0.166|      3.749|     14.499|       0|     0|      0.000|     21.874
RTD|      0.458|      3.874|     18.083|       0|     0|      0.000|     21.874
RTD|      0.166|      3.874|     14.499|       0|     0|      0.000|     21.874
RTD|      0.416|      3.874|     16.249|       0|     0|      0.000|     21.874
RTD|      0.166|      3.458|     16.499|       0|     0|      0.000|     21.874
RTD|      0.499|      3.833|     14.499|       0|     0|      0.000|     21.874
RTD|      0.499|      3.791|     14.333|       0|     0|      0.000|     21.874
RTD|      0.499|      3.958|     17.208|       0|     0|      0.000|     21.874
RTD|      0.499|      3.916|     14.333|       0|     0|      0.000|     21.874


Quote from: uMinded on March 02, 2013, 03:31:19 AM
Do you guys have an arm rpm for stress or what string did you use to compile? make CROSS_COMPILE is ignored, and ./configure --host= as well? So I used this to load the system to 100%

In that case you have to specify the compiler explicitly. It will be a little bit long config line.

But 1st, if you use uclibc you have to patch stress sourcewith this file, (stress-001-remove-largefile.patch):

Remove largefile

Otherwise it doesn't compile in uClibc without largefile.

If the toolchain does support largefile, it will still work on large files
anyway.

Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
Upstream status: mail sent to apw@rossby.metr.ou.edu
---
diff -rup stress-1.0.4.orig/src/Makefile.am stress-1.0.4/src/Makefile.am
--- stress-1.0.4.orig/src/Makefile.am 2009-12-03 02:04:05.000000000 +0100
+++ stress-1.0.4/src/Makefile.am 2012-05-04 23:09:48.229842463 +0200
@@ -1,7 +1,5 @@
MAINTAINERCLEANFILES = Makefile.in

-AM_CFLAGS = -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-
bin_PROGRAMS = stress
stress_SOURCES = stress.c
stress_MANS = stress.1


now patch it with the above patch file:

patch -p1 < stress-001-remove-largefile.patch


Then you have to autoreconf the stress config files, (this is stress specific, not usual):

autoupdate
autoreconf -Wall


then make an install dir and call configure:

mkdir install
./configure CC=arm-cortex_a8-linux-gnueabi-gcc \
AS=arm-cortex_a8-linux-gnueabi-as \
LD=arm-cortex_a8-linux-gnueabi-ld \
CFLAGS="-pipe -g -fPIC -march=armv7-a -mtune=cortex-a8 -mthumb -mfpu=neon -mfloat-abi=hard" \
--host=armv7a-unknown-linux-gnueabihf \
--prefix=$PWD/install


of course, substitute the 'arm-cortex_a8-linux-gnueabi' compiler prefix with yours, and refine the compiler flags as you like it.
then just make it:

make install

and it will be installed in the ./install directory, you can copy that onto your SD card, rootfs /usr directory.

Quote from: Tele on March 01, 2013, 08:03:41 AM

if your xenomai directory <xenomai_dir>  (for example /work/xenomai-2.6.2.1)
if your compiler prefix is <toolchain-prefix> (for example arm-none-linux-gnueabi or arm-linux-gnueabihf or something like that)
then:

Code Select Expand


cd <xenomai dir>
mkdir install
./configure CC=<toolchain-prefix>-gcc AR=<toolchain-prefix>-ar LD=<toolchain-prefix>-ld CFLAGS="-march=armv7-a" LDFLAGS="-march=armv7-a" \
--host=arm-none-linux-gnueabi --prefix=<xenomai_dir>/install

CFLAGS could be armv7-a or armv7a , it depends on your gcc, it gives an error back, if doesnt like it.

if no error then:

Code Select Expand


make install


I am afraid I do not understand the appropriate substitutions. I am running in a cross compile environment from an Ubuntu 12.04 X86. I tried the following:


./configure CC=arm-linux-gnueabi-gcc AR=arm-linux-gnueabi-ar LD=arm-linux-gnueabi-ld CFLAGS="-march=arm7-a" \
LDFLAGS="-march=arm7-a" --host=arm-linux-gnueabi- --prefix=<fully qualified path>/install


The error I get is:

configure: WARNING: if you wanted to set the --build type, don't use --host
    if a cross compiler is detected the cross compile mode will be used
Invalid configuration 'arm-linux-gnueabi-': machine 'arm-linux-gnueabi' not recognized.


if I remove --host then I get:

checking build system type,,, i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking for gcc... arm-linux-gnueabi-gcc
checking whether the C compiler works... no
configure: error: in '...xenomai-2.6.2.1'
configure: error: C compiler cannot create executables


Thanks

Hello everybody,


good news and bad news ...

bad news first: in the user manual, there is no way to set PLL6 as entry for TIMER2. And it look like this one is right. The only way to get a 100 MHz clock is to go to timer0, timer1 or av_timer, but all of these are used in some way in the kernel linux.

good news:
    - i create an "preempt" test from the "latency" one: A xenomai task run for 1/4 of it's period, reading and reading the xenomai clock and, each time, it record the delta, computing min, max and avg.

    - from the previous, i know now that my priority-interrupt version do the job.

Here is an example testing preempt (NOT latencies) for this new version:

./preempt -h -p 100
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre best|--pre worst
RTD|      0.333|      0.374|      1.999|       0|     0|      0.333|      1.999
RTD|      0.333|      0.374|      0.833|       0|     0|      0.333|      1.999
RTD|      0.333|      0.374|      2.874|       0|     0|      0.333|      2.874
RTD|      0.333|      0.374|      0.874|       0|     0|      0.333|      2.874
RTD|      0.333|      0.374|      0.749|       0|     0|      0.333|      2.874
RTD|      0.333|      0.374|      0.708|       0|     0|      0.333|      2.874
RTD|      0.333|      0.374|      3.666|       0|     0|      0.333|      3.666
RTD|      0.333|      0.374|      0.833|       0|     0|      0.333|      3.666
RTD|      0.333|      0.374|      2.583|       0|     0|      0.333|      3.666
RTD|      0.333|      0.374|      1.958|       0|     0|      0.333|      3.666
RTD|      0.333|      0.374|      2.999|       0|     0|      0.333|      3.666
RTD|      0.333|      0.374|      3.374|       0|     0|      0.333|      3.666
RTD|      0.333|      0.374|      0.833|       0|     0|      0.333|      3.666
RTD|      0.333|      0.374|      0.749|       0|     0|      0.333|      3.666
RTD|      0.333|      0.374|      3.541|       0|     0|      0.333|      3.666
^C---|--param|----range-|--samples
HSD|    min|   0 -  1 |       15
---|--param|----range-|--samples
HSD|    avg|   0 -  1 |   154038
---|--param|----range-|--samples
HSD|    max|   0 -  1 |        7
HSD|    max|   1 -  2 |        2
HSD|    max|   2 -  3 |        3
HSD|    max|   3 -  4 |        3
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|        15|      0.000|      0.000
HSS|    avg|    154038|      0.000|      0.000
HSS|    max|        15|      1.133|      1.246


And for the previous version (without load):

./preempt -h -p 100
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT|  00:00:01  (periodic user-mode task, 100 us period, priority 99)
RTH|----pre min|----pre avg|----pre max|-overrun|---msw|---pre best|--lat worst
RTD|      0.333|      0.374|      7.458|       0|     0|      0.333|      7.458
RTD|      0.333|      0.374|     11.333|       0|     0|      0.333|     11.333
RTD|      0.333|      0.374|     11.999|       0|     0|      0.333|     11.999
RTD|      0.333|      0.374|     11.749|       0|     0|      0.333|     11.999
RTD|      0.333|      0.374|     11.499|       0|     0|      0.333|     11.999
RTD|      0.333|      0.374|     13.958|       0|     0|      0.333|     13.958
RTD|      0.333|      0.374|     12.083|       0|     0|      0.333|     13.958
RTD|      0.333|      0.374|     12.083|       0|     0|      0.333|     13.958
RTD|      0.333|      0.374|     12.291|       0|     0|      0.333|     13.958
RTD|      0.333|      0.374|     12.958|       0|     0|      0.333|     13.958
^C---|--param|----range-|--samples
HSD|    min|   0 -  1 |       10
---|--param|----range-|--samples
HSD|    avg|   0 -  1 |   106698
HSD|    avg|   6 -  7 |      153
HSD|    avg|   7 -  8 |      121
HSD|    avg|   8 -  9 |       27
HSD|    avg|   9 - 10 |        8
HSD|    avg|  10 - 11 |        4
HSD|    avg|  11 - 12 |        4
HSD|    avg|  12 - 13 |        1
---|--param|----range-|--samples
HSD|    max|   7 -  8 |        1
HSD|    max|  11 - 12 |        4
HSD|    max|  12 - 13 |        4
HSD|    max|  13 - 14 |        1
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|        10|      0.000|      0.000
HSS|    avg|    107016|      0.020|      0.372
HSS|    max|        10|     11.200|      1.619


Quote from: ehj666 on March 03, 2013, 06:42:07 PM
I am afraid I do not understand the appropriate substitutions. I am running in a cross compile environment from an Ubuntu 12.04 X86. I tried the following:

Code Select Expand


./configure CC=arm-linux-gnueabi-gcc AR=arm-linux-gnueabi-ar LD=arm-linux-gnueabi-ld CFLAGS="-march=arm7-a" \
LDFLAGS="-march=arm7-a" --host=arm-linux-gnueabi- --prefix=<fully qualified path>/install


I ran into this quite a bit when I started cross compiling, you give make arm-coretx_a8-linux-gnueabi- as make has macros inside like this CC = cpp so it compines into arm-coretx_a8-linux-gnueabi-cpp.

Automake however defines its macros as CC = -gcc so if you give it arm-coretx_a8-linux-gnueabi- then it will combine into arm-coretx_a8-linux-gnueabi--gcc which does not exist!

So when using a ./configure specify your toolchain WITHOUT the trailing -

EDIT:

Also make sure your toolchain is in your $PATH variable. If at the terminal you can type "arm" <tab><tab> your compile should list.

Quote from: crubille on March 03, 2013, 07:57:04 PM
good news and bad news ...

bad news first: in the user manual, there is no way to set PLL6 as entry for TIMER2. And it look like this one is right. The only way to get a 100 MHz clock is to go to timer0, timer1 or av_timer, but all of these are used in some way in the kernel linux.

good news:
    - i create an "preempt" test from the "latency" one: A xenomai task run for 1/4 of it's period, reading and reading the xenomai clock and, each time, it record the delta, computing min, max and avg.

I actually got a 100MHz kernel running about an hour ago! I mean I have my timers set to PLL6 and the timer is running without issues so I ASSUME its at 100 MHz... Do you know of a way to actually test the speed their counting at??

Also can you share your "preempt" program? I would love to see if my extra speed makes any difference.

My latency numbers:


stress -m 10 --vm-bytes 5000 -c 10 (Load avg:21.21 16.82 8.7)
echo 4720 > /proc/xenomai/latency
latency -p 100 -h

RTT|  00:01:04  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      0.050|      0.700|      9.130|       0|     0|      0.050|     14.880
RTD|      0.050|      0.700|      9.490|       0|     0|      0.050|     14.880
RTD|      0.050|      0.690|     10.720|       0|     0|      0.050|     14.880
RTD|      0.050|      0.690|     10.440|       0|     0|      0.050|     14.880
RTD|      0.080|      0.690|     11.600|       0|     0|      0.050|     14.880
RTD|      0.050|      0.700|     10.440|       0|     0|      0.050|     14.880
RTD|      0.050|      0.690|     10.640|       0|     0|      0.050|     14.880
RTD|      0.080|      0.690|     10.810|       0|     0|      0.050|     14.880
RTD|      0.050|      0.700|     11.440|       0|     0|      0.050|     14.880
RTD|      0.080|      0.690|      9.600|       0|     0|      0.050|     14.880
RTD|      0.080|      0.690|     10.600|       0|     0|      0.050|     14.880
RTD|      0.050|      0.700|     11.690|       0|     0|      0.050|     14.880
RTD|      0.050|      0.690|     12.050|       0|     0|      0.050|     14.880
RTD|      0.080|      0.690|     12.130|       0|     0|      0.050|     14.880
RTD|      0.080|      0.690|     10.960|       0|     0|      0.050|     14.880
RTD|      0.050|      0.700|     11.690|       0|     0|      0.050|     14.880
RTD|      0.080|      0.690|     11.560|       0|     0|      0.050|     14.880
RTD|      0.050|      0.700|     14.250|       0|     0|      0.050|     14.880
RTD|      0.050|      0.690|     11.690|       0|     0|      0.050|     14.880
RTD|      0.050|      0.690|      9.930|       0|     0|      0.050|     14.880
RTD|      0.080|      0.690|     10.440|       0|     0|      0.050|     14.880



dohell 900 (Load avg:21.21 16.82 8.7)
echo 4720 > /proc/xenomai/latency
latency -p 100 -h

RTT|  00:00:43  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      0.400|      3.740|     15.600|       0|     0|      0.000|     18.000
RTD|      0.570|      3.400|     16.690|       0|     0|      0.000|     18.000
RTD|      0.570|      3.040|     16.570|       0|     0|      0.000|     18.000
RTD|      0.440|      3.910|     14.640|       0|     0|      0.000|     18.000
RTD|      0.440|      3.940|     14.400|       0|     0|      0.000|     18.000
RTD|      0.370|      3.750|     13.760|       0|     0|      0.000|     18.000
RTD|      0.370|      3.880|     16.370|       0|     0|      0.000|     18.000
RTD|      0.640|      4.000|     13.930|       0|     0|      0.000|     18.000
RTD|      0.440|      3.790|     15.280|       0|     0|      0.000|     18.000
RTD|      0.640|      3.940|     15.040|       0|     0|      0.000|     18.000
RTD|      0.400|      3.930|     15.720|       0|     0|      0.000|     18.000
RTD|      0.400|      3.570|     13.130|       0|     0|      0.000|     18.000
RTD|      0.520|      3.900|     14.160|       0|     0|      0.000|     18.000
RTD|      0.490|      3.750|     16.520|       0|     0|      0.000|     18.000
RTD|      0.490|      3.660|     14.000|       0|     0|      0.000|     18.000
RTD|      0.640|      3.850|     15.280|       0|     0|      0.000|     18.000
RTD|      0.440|      3.760|     15.810|       0|     0|      0.000|     18.000
RTD|      0.400|      3.930|     17.370|       0|     0|      0.000|     18.000
RTD|      0.600|      3.900|     14.600|       0|     0|      0.000|     18.000
RTD|      0.440|      3.840|     14.570|       0|     0|      0.000|     18.000
RTD|      0.400|      3.830|     14.570|       0|     0|      0.000|     18.000


Hello uMinded,

What is the counter you use?

AMHA, the best way to be sure the timers use PLL/6 is to read their ctrl register! Then, my "preempt" code can be useful as the values are multiples of clock steps: In the examples i send, when the task is not preempted, the values are 8 (333ns) or 9 (374ns) clock steps (using the clock at 24MHz). If you get for example 350ns and 360ns, then your clock step is 10 ns.

I can send you the code if you send me your mail as private message.

Quote from: crubille on March 03, 2013, 11:13:50 PM
the best way to be sure the timers use PLL/6 is to read their ctrl register!

I can dump a memory location but not a hardware register location. How do you go about dumping say 0x01C20000 to 0x01C20158(physical address range of the CCM reg)

Do it in kernel code of course, somewhere it will not be done at hight rate, and late enough so you are sure everything is set.
Do not put it so it run in real time mode.



reg = readl( SW_TIMERx_CTL );
printk( KERN_NOTICE "UMINDED_MSG ... "0x%08.8X" \n, reg );


You can put it in the code you hack or in some convenient place, for example in the initialisation of some module so it is executed when you load it with modprobe (leds_gpio.c is very simple).

and get the result with dmesg:

dmesg | grep UMINDED_MSG


Quote from: ehj666 on March 03, 2013, 06:42:07 PM

Quote from: Tele on March 01, 2013, 08:03:41 AM

if your xenomai directory <xenomai_dir>  (for example /work/xenomai-2.6.2.1)
I am afraid I do not understand the appropriate substitutions. I am running in a cross compile environment from an Ubuntu 12.04 X86. I tried the following:

Code Select Expand


./configure CC=arm-linux-gnueabi-gcc AR=arm-linux-gnueabi-ar LD=arm-linux-gnueabi-ld CFLAGS="-march=arm7-a" \
LDFLAGS="-march=arm7-a" --host=arm-linux-gnueabi- --prefix=<fully qualified path>/install


The error I get is:

Code Select Expand


configure: WARNING: if you wanted to set the --build type, don't use --host
    if a cross compiler is detected the cross compile mode will be used
Invalid configuration 'arm-linux-gnueabi-': machine 'arm-linux-gnueabi' not recognized.


if I remove --host then I get:
...
Thanks

Dont remove --host=... it is mandatory, but write  --host=armv7a-unknown-linux-gnueabi

This is not the same as <toolchain-prefix> just it looks similar. Sorry if I was ambiguous.

Ok here is my conclusions of the weekend:

1 - So, I had to move all the kernels clocks around in order to get the two that have input from PLL6 to work. My kernel boots and runs normally and I have not seen any issues thus far.

2 - I got PLL6's control register set up so that it is either outputting 1800 MHz or 1200 MHz. How do I not know? Well if you check out the A10 Users Manual on page 43 you notice that PLL6_FACTOR_K and PLL6_FACTOR_M both say they add 1 to the register in hardware. Also see the snippit below:

Quote
Register Name: PLL6_CFG_REG
     For NC, the output =(24MHz*N*K)/M/6
     If the NC is on, the output should be equal to 100MHz
     For other module, the output = (24MHz*N*K)/2
     Note: the output 24MHz*N*K clock
     must be in the range of 240MHz~2GHz if the bypass is disabled.


<5>PLL6: 0xA1009922
N=25, K=2, M=2


So that means with my current setup with +1 added to K and M in hardware I have this range of speeds:

Quote
For NC, the output = (24MHz*25*3)/3/6 = 100 MHz
For other module, the output = (24MHz*25*3)/2 = 900 MHz
If the timers fed from "NC" that 100/6 = 16 MHz
If the timers fed from "other module" that 900/2/6 = 150 MHz
If the timers fed from "raw PLL6" that 1800/6 = 300 MHz

What if +1 is not added in hardware?

Quote
For NC, the output = (24MHz*25*2)/2/6 = 100 MHz
For other module, the output = (24MHz*25*3)/2 = 600 MHz
If the timers fed from "NC" that 100/6 = 16 MHz
If the timers fed from "other module" that 600/2/6 = 50 MHz
If the timers fed from "raw PLL6" that 1200/6 = 200 MHz

Now it is easy to modify the M, K & N values for PLL6 in code, you just need to get the balancing game right for whole numbers. The huge problem is WHAT ONE OF THOSE actually feeds the timer subsystem?!?! When I get Crubille's preempt program I can hopefully figure this out and then I can properly patch it together. Right now I have A LOT of file modifications as I have gone through some hundreds of interations...

Just some info:

<6>timer2: Periodic Mode
<6>I-pipe, 300.000 MHz clocksource
<6>sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 4294967286ms
<6>Calibrating delay loop... <c>1001.88 BogoMIPS (lpj=5009408)


Proof of timer setup:

<5>Timer0: 0x00000089
ONE_SHOT, PLL6/6, sun5i_itimer

<5>Timer1: 0x00000009
CONTINUOUS, PLL6/6, tsc_info

<5>Timer2: 0x00000045
CONTINUOUS, HOSC(25Mhz), DIV/16, sched_clock


My Results:

stress -m 10 --vm-bytes 5000 -c 10

RTT|  00:01:04  (periodic user-mode task, 100 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|      0.999|      1.633|      6.986|       0|     0|      0.963|     13.556
RTD|      1.009|      1.649|     11.949|       0|     0|      0.963|     13.556
RTD|      0.986|      1.643|     11.903|       0|     0|      0.963|     13.556
RTD|      0.999|      1.643|      9.653|       0|     0|      0.963|     13.556
RTD|      1.023|      1.646|      8.616|       0|     0|      0.963|     13.556
RTD|      0.999|      1.639|      8.223|       0|     0|      0.963|     13.556
RTD|      1.033|      1.643|      7.949|       0|     0|      0.963|     13.556
RTD|      1.009|      1.643|      8.473|       0|     0|      0.963|     13.556
RTD|      0.999|      1.636|      9.806|       0|     0|      0.963|     13.556
RTD|      0.986|      1.639|      7.236|       0|     0|      0.963|     13.556
RTD|      1.023|      1.646|      9.093|       0|     0|      0.963|     13.556
RTD|      1.023|      1.639|     10.949|       0|     0|      0.963|     13.556
RTD|      1.023|      1.636|     10.333|       0|     0|      0.963|     13.556
RTD|      1.023|      1.643|      9.473|       0|     0|      0.963|     13.556
RTD|      0.973|      1.643|      9.569|       0|     0|      0.963|     13.556
RTD|      1.009|      1.636|      8.879|       0|     0|      0.963|     13.556
RTD|      1.009|      1.639|      7.523|       0|     0|      0.963|     13.556
RTD|      0.999|      1.653|     10.533|       0|     0|      0.963|     13.556
RTD|      1.009|      1.639|      7.926|       0|     0|      0.963|     13.556
RTD|      1.009|      1.649|      8.139|       0|     0|      0.963|     13.556
RTD|      1.009|      1.646|      8.699|       0|     0|      0.963|     13.556

== Tested clock: 0 (CLOCK_REALTIME)
CPU      ToD offset [us] ToD drift [us/s]      warps max delta [us]
--- -------------------- ---------------- ---------- --------------
  0                  2.3            0.021          0            0.0


Quote from: Tele on March 04, 2013, 12:03:42 AM
Dont remove --host=... it is mandatory, but write  --host=armv7a-unknown-linux-gnueabi

This is not the same as <toolchain-prefix> just it looks similar. Sorry if I was ambiguous.

Ok, changed to


./configure CC=arm-linux-gnueabi-gcc AR=arm-linux-gnueabi-ar LD=arm-linux-gnueabi-ld CFLAGS="-march=arm7-a" \
LDFLAGS="-march=arm7-a" --host=armv7a-unknown-linux-gnueabi --prefix=<fully qualified path>/install


Which seemed to be correct, excluding the initial warning, down to where it checks whether the compiler works.

configure: WARNING: if you wanted to set the --build type, don't use --host.
    if a cross compiler is detected the cross compile mode will be used.
checking build system type... i686-pc-linux-gnu
checking host system type... armv7a-unknow-linux-gnueabi
checking for a BSD-compatible install... /usr/bin/install -c
checking for armv7a-unknown-linux-gnueabi-gcc... arm-linux-gnueabi-gcc
checking whether the C compiler works... no
configure: error: in... '<path>/xenomai-2.6.2.1':
configure: error: C compiler cannot create executables
See 'config.log' for more details


I did not see anything obvious in config.log as to why the compiler would not work.

ANy ideas?
Thanks

Quote from: ehj666 on March 04, 2013, 05:23:14 PM

Code Select Expand


checking for armv7a-unknown-linux-gnueabi-gcc... arm-linux-gnueabi-gcc
checking whether the C compiler works... no


Their is currently a bug in Autotools for cross compilers, I talked to a few maintainers about it on IRC yesterday. Their are two separate bugs:

1) Using the CC= macro with .config does not set the internal flag to tell the system its a cross compile so during the check it tries to run an a.out from armv7a-unknown-linux-gnueabi-gcc on your x86 system which obviously wont work. These bugs are known about but they are not high on anybodies priority list and we will run into issue #2 when building linuxcnc BTW.

2) Similarly their is a problem with --host= as it somehow breaks the AC_CHECK_HEADER macro into always returning a zero.

I was building stress yesterday and found the current version was able to build with the --host/--build features as well as the current xenomai-2.6.2.1 userspace programs.

From the xenomai-2.6.2.1 folder:

mkdir install
./configure --build=x86_64-linux-gnu --host=arm-linux-gnueabi CFLAGS=-march=armv7-a LDFLAGS=-march=armv7-a
--prefix=<FULL_PATH_TO_DIR>/install
make install


One thing to keep in mind if you build your own toolchain (such as arm-cortex_a8-linux-gnueabi) that different versions of the c libraries are not all equal. Xenomai requires a full version while the cortex_a8 chain above uses uClib so it will not work. If you use the command above it compiles (I verified it) alternatively download it from our wiki (https://code.google.com/p/a13-olinuxino/downloads/list).

NOTE: The arm-linux-gnueabi toolchain is from http://www.linaro.org/downloads/ (http://www.linaro.org/downloads/) under BINARIES

Quote from: ehj666 on March 04, 2013, 05:23:14 PM
I did not see anything obvious in config.log as to why the compiler would not work.

ANy ideas?
Thanks

I would like to take a look on that config.log. Would you upload it onto pastebin, if you dont mind.
Is 'arm-linux-gnueabi-gcc' in the path? It tries to use that as compiler, but for some kind of reason it cant compile a testfile. The exact reason is in that config.log. You can see the exact commandline as it calls the compiler and it returns an error. What is that error ?

Quote
I would like to take a look on that config.log. Would you upload it onto pastebin, if you dont mind.
Is 'arm-linux-gnueabi-gcc' in the path? It tries to use that as compiler, but for some kind of reason it cant compile a testfile. The exact reason is in that config.log. You can see the exact commandline as it calls the compiler and it returns an error. What is that error ?

Yes, arm-linux-gnueabi-gcc is in the path, it is what I used to compile the kernel and can be run manually from the local (Xenomai) folder. Config.log is not that big, so I have included it below:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by Xenomai configure 2.6.2.1, which was
generated by GNU Autoconf 2.67.  Invocation command line was

  $ ./configure CC=arm-linux-gnueabi-gcc AR=arm-linux-gnueabi-ar LD=arm-linux-gnueabi-ld CFLAGS=-march=arm7-a LDFLAGS=-march=arm7-a --host=armv7a-unknown-linux-gnueabi --prefix=/home/eric/Projects/olinuxino/kernel/xenomai-2.6.2.1/install

## --------- ##
## Platform. ##
## --------- ##

hostname = eric-HP-Probook
uname -m = i686
uname -r = 3.2.0-38-generic-pae
uname -s = Linux
uname -v = #61-Ubuntu SMP Tue Feb 19 12:39:51 UTC 2013

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /usr/lib/lightdm/lightdm
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2378: checking build system type
configure:2392: result: i686-pc-linux-gnu
configure:2412: checking host system type
configure:2425: result: armv7a-unknown-linux-gnueabi
configure:2459: checking for a BSD-compatible install
configure:2527: result: /usr/bin/install -c
configure:2560: checking for armv7a-unknown-linux-gnueabi-gcc
configure:2587: result: arm-linux-gnueabi-gcc
configure:2856: checking for C compiler version
configure:2865: arm-linux-gnueabi-gcc --version >&5
arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:2876: $? = 0
configure:2865: arm-linux-gnueabi-gcc -v >&5
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
configure:2876: $? = 0
configure:2865: arm-linux-gnueabi-gcc -V >&5
arm-linux-gnueabi-gcc: fatal error: no input files
compilation terminated.
configure:2876: $? = 4
configure:2865: arm-linux-gnueabi-gcc -qversion >&5
arm-linux-gnueabi-gcc: fatal error: no input files
compilation terminated.
configure:2876: $? = 4
configure:2896: checking whether the C compiler works
configure:2918: arm-linux-gnueabi-gcc -march=arm7-a  -march=arm7-a conftest.c  >&5
cc1: error: bad value (arm7-a) for -march switch
cc1: error: bad value (arm7-a) for -march switch
configure:2922: $? = 1
configure:2960: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "Xenomai"
| #define PACKAGE_TARNAME "xenomai"
| #define PACKAGE_VERSION "2.6.2.1"
| #define PACKAGE_STRING "Xenomai 2.6.2.1"
| #define PACKAGE_BUGREPORT "xenomai@xenomai.org"
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:2965: error: in `/home/eric/Projects/olinuxino/kernel/xenomai-2.6.2.1':
configure:2967: error: C compiler cannot create executables
See `config.log' for more details

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=i686-pc-linux-gnu
ac_cv_env_CCASFLAGS_set=
ac_cv_env_CCASFLAGS_value=
ac_cv_env_CCAS_set=
ac_cv_env_CCAS_value=
ac_cv_env_CC_set=set
ac_cv_env_CC_value=arm-linux-gnueabi-gcc
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value=-march=arm7-a
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=set
ac_cv_env_LDFLAGS_value=-march=arm7-a
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=armv7a-unknown-linux-gnueabi
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=armv7a-unknown-linux-gnueabi
ac_cv_path_install='/usr/bin/install -c'
ac_cv_prog_CC=arm-linux-gnueabi-gcc

## ----------------- ##
## Output variables. ##
## ----------------- ##

A2X=''
ACLOCAL=''
AMDEPBACKSLASH=''
AMDEP_FALSE=''
AMDEP_TRUE=''
AMTAR=''
AR='arm-linux-gnueabi-ar'
ASCIIDOC=''
AUTOCONF=''
AUTOHEADER=''
AUTOMAKE=''
AWK=''
BUILD_EXEEXT=''
BUILD_OBJEXT=''
CC='arm-linux-gnueabi-gcc'
CCAS=''
CCASDEPMODE=''
CCASFLAGS=''
CCDEPMODE=''
CC_FOR_BUILD=''
CFLAGS='-march=arm7-a'
CFLAGS_FOR_BUILD=''
CONFIG_STATUS_DEPENDENCIES=''
CONFIG_XENO_ASCIIDOC_FALSE=''
CONFIG_XENO_ASCIIDOC_TRUE=''
CONFIG_XENO_DOC_DOX_FALSE=''
CONFIG_XENO_DOC_DOX_TRUE=''
CONFIG_XENO_FASTSYNCH_FALSE=''
CONFIG_XENO_FASTSYNCH_TRUE=''
CONFIG_XENO_FAST_WRAP_FALSE=''
CONFIG_XENO_FAST_WRAP_TRUE=''
CONFIG_XENO_SHARED_FALSE=''
CONFIG_XENO_SHARED_TRUE=''
CPP=''
CPPFLAGS=''
CPPFLAGS_FOR_BUILD=''
CPP_FOR_BUILD=''
CYGPATH_W=''
DBX_ABS_SRCDIR_FALSE=''
DBX_ABS_SRCDIR_TRUE=''
DBX_DOC_FALSE=''
DBX_DOC_ROOT=''
DBX_DOC_TRUE=''
DBX_FOP=''
DBX_GEN_DOC_ROOT=''
DBX_LINT=''
DBX_MAYBE_NONET=''
DBX_ROOT=''
DBX_XSLTPROC=''
DBX_XSL_ROOT=''
DEFS=''
DEPDIR=''
DLLTOOL=''
DOXYGEN=''
DOXYGEN_HAVE_DOT=''
DOXYGEN_SHOW_INCLUDE_FILES=''
DSYMUTIL=''
DUMPBIN=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
EXEEXT=''
FGREP=''
GREP=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM=''
LATEX_BATCHMODE=''
LATEX_MODE=''
LD='arm-linux-gnueabi-ld'
LDFLAGS='-march=arm7-a'
LD_FILE_OPTION=''
LEX=''
LEXLIB=''
LEX_OUTPUT_ROOT=''
LIBOBJS=''
LIBS=''
LIBTOOL=''
LIPO=''
LN_S=''
LTLIBOBJS=''
MAINT=''
MAINTAINER_MODE_FALSE=''
MAINTAINER_MODE_TRUE=''
MAKEINFO=''
MANIFEST_TOOL=''
MKDIR_P=''
NM=''
NMEDIT=''
OBJDUMP=''
OBJEXT=''
OTOOL64=''
OTOOL=''
PACKAGE=''
PACKAGE_BUGREPORT='xenomai@xenomai.org'
PACKAGE_NAME='Xenomai'
PACKAGE_STRING='Xenomai 2.6.2.1'
PACKAGE_TARNAME='xenomai'
PACKAGE_URL=''
PACKAGE_VERSION='2.6.2.1'
PATH_SEPARATOR=':'
RANLIB=''
SED=''
SET_MAKE=''
SHELL='/bin/bash'
STRIP=''
VERSION=''
W3M=''
XENO_BUILD_STRING=''
XENO_DLOPEN_CONSTRAINT=''
XENO_HOST_STRING=''
XENO_LIB_CFLAGS=''
XENO_LIB_LDFLAGS=''
XENO_MAYBE_DOCDIR=''
XENO_POSIX_WRAPPERS=''
XENO_TARGET_ARCH=''
XENO_TARGET_ARCH_X86_FALSE=''
XENO_TARGET_ARCH_X86_TRUE=''
XENO_TEST_DIR=''
XENO_USER_APP_CFLAGS=''
XENO_USER_APP_LDFLAGS=''
XENO_USER_CFLAGS=''
XENO_USER_LDFLAGS=''
ac_ct_AR=''
ac_ct_CC=''
ac_ct_CC_FOR_BUILD=''
ac_ct_DUMPBIN=''
am__EXEEXT_FALSE=''
am__EXEEXT_TRUE=''
am__fastdepCCAS_FALSE=''
am__fastdepCCAS_TRUE=''
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__include=''
am__isrc=''
am__leading_dot=''
am__quote=''
am__tar=''
am__untar=''
bindir='${exec_prefix}/bin'
build='i686-pc-linux-gnu'
build_alias=''
build_cpu='i686'
build_os='linux-gnu'
build_vendor='pc'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='NONE'
host='armv7a-unknown-linux-gnueabi'
host_alias='armv7a-unknown-linux-gnueabi'
host_cpu='armv7a'
host_os='linux-gnueabi'
host_vendor='unknown'
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
install_sh=''
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
mkdir_p=''
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='/home/eric/Projects/olinuxino/kernel/xenomai-2.6.2.1/install'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target=''
target_alias=''
target_cpu=''
target_os=''
target_vendor=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

/* confdefs.h */
#define PACKAGE_NAME "Xenomai"
#define PACKAGE_TARNAME "xenomai"
#define PACKAGE_VERSION "2.6.2.1"
#define PACKAGE_STRING "Xenomai 2.6.2.1"
#define PACKAGE_BUGREPORT "xenomai@xenomai.org"
#define PACKAGE_URL ""

configure: exit 77


Here is my new version

http://www.crubille.lautre.net/xenomai_sun5i/ipipe-linuxsun5i-3.4.24.patch

it include priority based interrupt controller muting.

I adapt too the sun4i part, and it should work but i can't test it.

I have not tried to use the counters 0 and 1 because I fear it is more difficult to maintain the code.
Indeed, linuxsunxi3.4 version is not stable and we will port it to a future version integrated into the main branch of linux.

In fact, the use of PLL6 for the xenomai timer is of little interest, in contrast, PLL6 will be useful for the xenomai clock.

Quote from: uMinded on March 04, 2013, 07:51:00 PM

From the xenomai-2.6.2.1 folder:

Code Select Expand


mkdir install
./configure --build=x86_64-linux-gnu --host=arm-linux-gnueabi CFLAGS=-march=armv7-a LDFLAGS=-march=armv7-a
--prefix=<FULL_PATH_TO_DIR>/install
make install


Cool, that's better. The configure and the make seem to have worked, I have not tested anything as yet.

Quote from: ehj666 on March 04, 2013, 10:38:59 PM
...
Config.log is not that big, so I have included it below:
...

That was the error:
...
cc1: error: bad value (arm7-a) for -march switch
...

Its 'armv7-a' , a tiny v was missing :)

Quote from: Tele on March 01, 2013, 08:03:41 AM

on your rootfs SD make a dir:
/usr/xenomai

then copy <xenomai_dir>/install/bin and <xenomai_dir>/install/sbin into it
then copy <xenomai_dir>/install/lib  onto your rootfs SD /usr/lib

You are done.
After booting you can go there and run any xeno tests.

Code Select Expand


cd /usr/xenomai/bin
./latency -p 100


I must be missing something really simple. I copied everything as above and successfully boot the Olinuxino. If I try to run (from usr/xenomai/bin):
./latency -p 100

I get "no such file or directory".

The file attributes for "latency" are -rwxr-xr-x", the owner is root:root.
Running ./xeno latency gives "latency: not found/executable"

./xeno-config seems to run, but several others seem to have the path from the build computer.

Any ideas?

Thanks

Quote from: ehj666 on March 06, 2013, 05:26:49 PM
Any ideas?

Check if the xenomai libraries are in their place in <SD rootfs partition>:
cd /usr/lib
ls *.so


And you have to see these libs among many others:
libanalogy.so  libnative.so  libpsos.so  libpthread_rt.so  librtdm.so  libuitron.so  libvrtx.so  libvxworks.so  libxenomai.so


If you cant see them, you have to copy the lib files from
<xenomai_dir>/install/lib
directory to
<SD rootfs parttition>/usr/lib
directory

If they are in place, then maybe their attributes are wrong.(I donno, Im just guessing)
Try this on Olimex card:

cd /usr/lib
chmod 755 *.so


Tell me if still doesnt work, I have more ideas.

Quote from: uMinded on March 03, 2013, 11:17:41 PM

Quote from: crubille on March 03, 2013, 11:13:50 PM
the best way to be sure the timers use PLL/6 is to read their ctrl register!

I can dump a memory location but not a hardware register location. How do you go about dumping say 0x01C20000 to 0x01C20158(physical address range of the CCM reg)

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.

Quote from: Tele on March 06, 2013, 07:29:12 PM
And you have to see these libs among many others:

Code Select Expand

libanalogy.so  libnative.so  libpsos.so  libpthread_rt.so  librtdm.so  libuitron.so  libvrtx.so  libvxworks.so  libxenomai.so


They all exist as symlinks of the form
libanalogy.so -> libanalogy.so.1.0.0

The files to which the symlinks point all exist with file attributes -rwxr-xr-x, the symlinks have the file attributes lrwxrwxrwx.

Quote from: ehj666 on March 06, 2013, 10:50:36 PM
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:

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

it should answer:

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

but not:

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

If its ok then try:

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?

Quote from: Tele on March 07, 2013, 12:36:15 AM

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:

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


Quote from: Tele on March 07, 2013, 12:36:15 AM

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:

       not a dynamic executable


Quote from: ehj666 on March 07, 2013, 01:46:27 AM
Returns:

Code Select Expand


       not a dynamic executable


Oooops, there is something fishy about that.

2 more tests please:

strace ./latency

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

and at last

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.

Quote from: Tele on March 07, 2013, 03:42:40 AM
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:

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


Quote from: ehj666 on March 07, 2013, 06:08:38 AM

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.

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.

Quote from: Tele on March 07, 2013, 10:13:25 AM

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 (http://lcncolinuxino.blogspot.com/p/building.html)

Quote from: Tele on March 07, 2013, 10:13:25 AM
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.

Quote from: Tele on March 07, 2013, 10:13:25 AM
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.

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.

Quote from: Tele on March 06, 2013, 10:04:05 PM
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)

            //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 (http://pastebin.com/GggN5bDF)

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:

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)


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

Quote from: uMinded on March 09, 2013, 09:16:08 AM
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:

...
    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 (http://code.google.com/p/a13-olinuxino/downloads/list)) in an empty work directory.
Then:

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:

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


You can modify the configuration:

make ARCH=arm menuconfig


and then make the kernel in the usual way:

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.

Quote from: uMinded on March 09, 2013, 09:16:08 AM
...but I have a ton of other files I modified...

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

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.

Quote from: uMinded on March 09, 2013, 10:22:12 PM
...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)

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.

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


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


Quote from: uMinded on March 10, 2013, 02:08:38 AM

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 (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.

Quote from: ehj666 on March 10, 2013, 05:29:07 PM
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 (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 (https://code.google.com/p/a13-olinuxino/w/list) 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.

Quote from: uMinded on March 10, 2013, 07:17:13 PM
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
(http://www.linuxcnc.org/docs/2.5/html/gui/gladevcp.html)

Quote from: uMinded on March 10, 2013, 07:17:13 PM
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 (https://code.google.com/p/a13-olinuxino/w/list) 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.

Quote from: uMinded on March 10, 2013, 07:17:13 PM
If you want commit access to the wiki just PM me your gmail address and I will add you.

Will do.

Quote from: uMinded on March 10, 2013, 07:17:13 PM
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.

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.

Quote from: ehj666 on March 10, 2013, 09:49:43 PM
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.