Jorge Ramirez-Ortiz wrote:

Just wondering if you are aware of the pending aarch64 port issue with Xenomai and if you found a a fix for it (we have been chasing it for a few weeks now) Basically fpu switching in realtime mode is not realiable (it can potentially trash any of the applications running..you would see level 2 translation faults in your console if you execute the latency tests).

you could also pull this commit http://git.xenomai.org/xenomai-3.git/commit/?h=arm64

and execute: $ smokey --verbose=2 --run=2 duration=0

you will see the fpu registers being trashed and not correctly saved/restored while cobalt context switches between the realtime and the non realtime threads.

Thank you for the heads up! I'm using a bit old linux-ipipe/xenomai trees and haven't experienced that issue. I'll try it with the updated trees.

Regards, kaz

Jorge Ramirez-Ortiz wrote:

Sorry I am a bit confused now (and interested since I am one of the xenomai maintainers :) )

As you know there is no aarch64 tree officially released for Xenomai (actually the aarch64 architecture patches were posted to us by the team at http://www.mperpetuo.com/ around July); I then did the initial ports for Hikey (kernel 3.18) and Dragon 410c (kernel 4.0) 96Boards on time for Linaro Connect in September. Since then Philippe and others have been amending my initial commits as well as hardening the architecture support trying to get a release out of the door. But we wont officially release it until we fix the FPU support (which is mandatory for aarch64)

And just to be clear so nobody gets alarmed, you can still develop your realtime apps on 96boards, it is just that you wont be able to launch a product just yet since it is not 100% reliable.

Now my ask to you is, if you already have aarch64 Xenomai and IPIPE ports that you/team might have done in the past, would you mind posting/sharing it with the xenomai mailing lists?

Sorry for my confusing message. We have no stable Xenomai/ipipe kernel and application. I shuold clarify our status. Currently we need only limited soft RT ability for a specific I/O. It doesn't require full Xenomai. Perhaps RTDM serial driver may be enough for us ATM. We've also tried Preempt RT patches and other things to find solution which is sufficient for us. It looks that Xenomai is most promising, though we simply do very limited tests.

Regards, kaz

On 10/29/2015 01:39 AM, Kazumoto Kojima wrote:

...

...

$ smokey --verbose=2 --run=2 duration=0

you will see the fpu registers being trashed and not correctly saved/restored while cobalt context switches between the realtime and the non realtime threads.

Thank you for the heads up! I'm using a bit old linux-ipipe/xenomai trees and haven't experienced that issue. I'll try it with the updated trees.

With the updated trees, I can see the suggested errors for xenomai smokey test. Although I'm afraid to do a stupid thing, with the change below, smokey test has been running ~50min successfully now.

Regards, kaz

I think this is exactly what we have been looking for (many thanks for sharing it) testing in UP mode I can see a negative impact on the minimum latency figures but it certainly addresses the fpu stress switch and seems to address the stalls as well. it might be a bit early to say this but this seems like good news :)

will run some tests now on SMP

Jorge Ramirez-Ortiz wrote:

having said that, the patch however doesnt seem to take into account the fpu activity of the regular kernel so there might be some other changes coming on top of this one.

Ah, I don't understand how linux/Xenomai contexts interact yet. Anyway hope my trial helps in some way.

Regards, kaz

loop zhongkaihua

On 2015/10/30 16:16, Guodong Xu wrote:

• Puck Chen, from Huawei.

---

...

From: kkojima@drone.co.jp To: dev@lists.96boards.org Date: Wed, 28 Oct 2015 07:52:31 +0900 Subject: [Dev] SPI on HiKey

Hi,

I've heard that the next release will include SPI support, so this might be already a bit old topic. I'm trying SPI on HiKey according to the thread https://www.96boards.org/forums/topic/hikey-board-spi/ with a .dsti hunk

spi_0: spi@f7106000 { compatible = "arm,pl022", "arm,primecell"; reg = <0x0 0xf7106000 0x0 0x1000>; #address-cells = <1>; #size-cells = <0>; interrupts = <0 50 4>; reset-controller-reg = <0x330 0x334 0x338 9>; clocks = <&clock_sys HI6220_SPI_CLK>; clock-names = "apb_pclk"; pinctrl-names = "default"; pinctrl-0 = <&spi0_pmx_func &spi0_cfg_func>; status = "ok"; };

on linux-xenomai kernel. Now it looks OK at least for the loop test on the spidev which is added as a sub-node

spidev@0 { compatible = "linux,spidev"; spi-max-frequency = <500000>; reg = <0>; };

and I can test sensors via spidev. BTW, I've found that a few pl022 dt entries for other SoCs describe two clocks and the first clock looks to be the one for SSPCLK. I'm curious about how SSPCLK of amba pl022 is handled on HiKey.

Regards, kaz

---

Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev

Zhong Kaihua wrote:

Clock_sys 21,which is divided from syspll, is used for both work clock and bus clock on hi6220. If you refer to the docs at Documentation/devicetree/bindings/spi/, you may find that some other SOCs also work like that.

Thanks for your explanations!

BTW, we are interested in how you test SPI on Hikey board. Can you share your test methods and test case to us? We are evaluating if we should upsteam our DTSI patch to the mainline branch, and we do not have related test environment.

I've heard that the SPI suport is in testing with linaro folks already. Anyway, here is a step-by-step trial with the tiny patch attatched. I'm using uefi with the recent edk2 that enables SPI0:

commit 04ba756e8996b1bdcd10ff484779cc95352a8e4a Author: Haojian Zhuang <haojian.zhuang at outlook.com> Date: Fri Oct 9 20:12:11 2015 +0800

Merge pull request #51 from hzhuang1/unreset_spi

HiKeyPkg: unreset SPI0

which is on hikey branch of https://github.com/96boards/edk2.git.

[On host:] git clone https://github.com/96boards/linux.git cd linux git checkout hikey git branch working-hikey cat $SOMEWHERE/hikey-spi.patch | patch -p1 wget http://builds.96boards.org/snapshots/hikey/community/hikey/latest/kernel.con... cp kernel.conf .config make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig #Check spidev support # Device Drivers->SPI support->[*] User mode SPI device driver support make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image modules dtbs #Install it

#Get latest spidev test, for example # https://github.com/torvalds/linux/blob/master/Documentation/spi/spidev_test.... #and send it to the target. [On target with the new kernel:] [Confirm that there is f7106000.spi under /sys/devices/smb] [Compile spidev_test.c] $gcc -O2 -o spidev_test spidev_test.c

[Target root:] [Loop test where connecting SDO to SDI on HiKey] #./spidev_test -D /dev/spidev0.0 spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@....�..................�.

[Send two bytes to some device. This is the result from gyroscope of ST LSM9DS0.] #./spidev_test -D /dev/spidev0.0 -p "\x8f\x00" spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) RX | 00 D4 __ __ __ __ __ __ | .�

Regards, kaz

Hi guodong,

Most parts of the patch are the same to mine. But There is some tiny difference in which I need to acknowledge.

Hi kaz,

Thanks for your sharing. But I am curious about your configuration for cs-gpios,

cs-gpios = <&gpio2 0 0>, <&gpio2 1 0>;

According to the configuration in arch/arm64/boot/dts/hi6220-gpio.dtsi ,these two gpios seem to have no relation to SPI.

/* LCB: GPIO2_0, J2 */ gpio_j2_2_0:gpio_j2_2_0 { gpios = <&gpio2 0 0>; }; /* LCB: GPIO2_1, J2 */ gpio_j2_2_1:gpio_j2_2_1 { gpios = <&gpio2 1 0>; };

My configuration is bus-id = <0>; enable-dma = <1>; dmas = <&dma0 12 &dma0 13>; dma-names = "rx", "tx";

num-cs = <4>; cs-gpios = <&gpio6 2 0>, <&gpio6 3 0>, <&gpio6 4 0>, <&gpio6 5 0>;

I am trying to test my configuration according to your trail today. Not finished yet due to network failure in our lab.

On 2015/11/10 9:42, Guodong Xu wrote:

Thanks Kazumoto. Kaihua, Please have a review of attached patch. Are you OK with that? If yes, I would like to integrate this into hikey (https://github.com/96boards/linux.git) -Guodong Xu

From: kkojima@drone.co.jp To: zhongkaihua@huawei.com Date: Tue, 10 Nov 2015 09:52:13 +0900 CC: dev@lists.96boards.org Subject: Re: [Dev] SPI on HiKey

Zhong Kaihua wrote:

...

Clock_sys 21,which is divided from syspll, is used for both work clock and bus clock on hi6220. If you refer to the docs at Documentation/devicetree/bindings/spi/, you may find that some other SOCs also work like that.

Thanks for your explanations!

...

BTW, we are interested in how you test SPI on Hikey board. Can you share your test methods and test case to us? We are evaluating if we should upsteam our DTSI patch to the mainline branch, and we do not have related test environment.

I've heard that the SPI suport is in testing with linaro folks already. Anyway, here is a step-by-step trial with the tiny patch attatched. I'm using uefi with the recent edk2 that enables SPI0: commit 04ba756e8996b1bdcd10ff484779cc95352a8e4a Author: Haojian Zhuang <haojian.zhuang at outlook.com> Date: Fri Oct 9 20:12:11 2015 +0800 Merge pull request #51 from hzhuang1/unreset_spi HiKeyPkg: unreset SPI0 which is on hikey branch of https://github.com/96boards/edk2.git. [On host:] git clone https://github.com/96boards/linux.git cd linux git checkout hikey git branch working-hikey cat $SOMEWHERE/hikey-spi.patch | patch -p1 wget http://builds.96boards.org/snapshots/hikey/community/hikey/latest/kernel.con... cp kernel.conf .config make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- menuconfig #Check spidev support # Device Drivers->SPI support->[*] User mode SPI device driver support make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image modules dtbs #Install it #Get latest spidev test, for example # https://github.com/torvalds/linux/blob/master/Documentation/spi/spidev_test.... #and send it to the target. [On target with the new kernel:] [Confirm that there is f7106000.spi under /sys/devices/smb] [Compile spidev_test.c] $gcc -O2 -o spidev_test spidev_test.c [Target root:] [Loop test where connecting SDO to SDI on HiKey] #./spidev_test -D /dev/spidev0.0 spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@....�..................�. [Send two bytes to some device. This is the result from gyroscope of ST LSM9DS0.] #./spidev_test -D /dev/spidev0.0 -p "\x8f\x00" spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) RX | 00 D4 __ __ __ __ __ __ | .� Regards, kaz

---

Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev