Xenomai for A13 - A10

[Tele]

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:

Code Select Expand


....
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.

[uMinded]

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.

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

You must remove the following section from the patch:

Code Select Expand


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:

Code Select Expand


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


[crubille]

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.

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

[crubille]

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

Paul

[uMinded]

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

Code Select Expand


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

[Tele]

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.

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.

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:

Code Select Expand


--- ./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:

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


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

[uMinded]

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.

[Tele]

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.

Crubille: If you want I can add you as a comitter...

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

[uMinded]

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

[Tele]

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.

[uMinded]

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!

[crubille]

Apply the following patch:

and just rerun
make uImage

Code Select Expand


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);


[crubille]

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.

[ehj666]

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

Any idea where I screwed up?

[uMinded]

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

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)