On 10/27/2015 06:52 PM, Kazumoto Kojima wrote:
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.
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.
with respect to the SPI question, I'll let someone else from the team comment.