willmore

I did a loopback test with a 200mm+ jumper wire from MISO to MOSI and transfered a 4KB block of random data error free. That makes me think that a short well laid out PCB trace should do better. Maybe we can get 100MHz at DIO for a whopping 25MB/s! Feel the power!

@martinayotte, thanks! That's the eventual use. I have two Zero's. One with the stock 16Mb chip and the other with a custom 128Mb chip for just that kind of testing. Before that, I want to test out the DMA SPI code and help tune where the buffer thresholds need to be. I also want to see about getting DIO working in the kernel. Then it'll be time to move on to learning uboot and the SPI boot code.

Cool, works from 12.5KHz to 100MHz. The top end is a bit crampt, but signals look as good as my poor 100MHz BW scope can see. The granularity of the clock is poor. It's just 100MHz/N where N is a natural number. @martinayotte, is the clock for SPI that simple or is there a more complex clock chain that can feed the SPI unit? It looks like the largest transfers I can do are 4K. Does that sound correct? Does something else need to be done to do larger transfers? 4K is, I'm guessing, page size?

Note to self, don't be stupid. On the plus side, both of my Orange Pi One boards now have working SPI0. Want to guess why? Let's use my previous post to show how to do it right as that worked perfectly. One might just make a note to remember to perform all of those actions *on the same board*. I'm going to go enjoy my working SPI and my stupidity. Thanks for all of the help, @zador.blood.stainedand @martinayotte. Also, sorry for the grief.

I jumpered 19 to 21 and ran the test and I don't see anything. looks like something still isn't right. To summarize: 1> installed the new boot.cmd (@zador) 2> did the mkimage 3> edited /boot/armbianEnv.txt to add: overlay_prefix=sun8i-h3 overlays=spi-spidev param_spidev_spi_bus=0 param_spidev_max_freq=100000000 4>rebooted and found /dev/spidev0.0 crw------- 1 root root 153, 0 Mar 19 20:42 /dev/spidev0.0 5>I see the spidev kernel module installed. 6>Compiled the spidev_test.c program from the mainline kernel 7>Hooked a scope to Orange Pi One pins 19, 21, 23, 24 8>ran the spidev_test program with several sets of options 9>observed no changed on the scope. Well, I did see the line that should be CS go and stay high--I think that happened during the first 'cat' into /sys when followerd @martinayotte's procedure. It's stayed that way through several reboots. I think I'll power cycle and see when it goes high.

Okay, @zador.blood.stained, that made the device persistant. the spidev-test program doesn't do anything that I can see, so I'll have to poke around in user land as it seems things are good in kernel land now. I'm monitoring pins 19, 21, 23, 24 and not seeing anything with: ./spidev_test -D /dev/spidev0.0 -s 10000 -b 8 I was expecting to see some activity on CS or CLK, but nothing at this time. Probably just pilot error on my part. I'll keep at it and see if I can get movement on something. Thank you again for all of your help. Same to you, @martinayotte.

@martinayotteThat seems to have produced a /dev/sdidev0.0! I'll see if I can get it to speak, too. @zador.blood.stained Not "overlays=sun8i-h3-spi-spidev"?

@martinayotte Yes, sir, I did. I'm following the advice of the thread How to enable hardware SPI. I've cloned the current dtb code mentioned in that thread as well and I'm making my own .dtbo. I've also tried the one in /boot/dtb/overlay/ Neither shows any reaction by the kernel.

Okay, got an Opi One on the beta repository booting a new kernel. I tried both the armbianEnv.txt method and the "cat /boot/dtb/overlay/sun8i-h3-spi-spidev.dtbo > /sys/kernel/config/device-tree/overlays/spi/dtbo" methods and had no luck. No response from dmesg nor any /dev/spi* files. I seem to be getting further away from a working system.

I've never intentionally used the beta repository. I do notice that my Zero's, PC's, and PC2's all get regular kenel update, but my One doesn't. I guess that's probably the difference. I'll go look at the other boards repo setup and see what's different--and bring the One over to the beta feed. Thanks for all of the help, Zador!

Okay, I'll try it with overlays from the testing repo that you mentined in your call for testers. Thanks for the help!

Searching elsewhere on the forum, I found How to enable hardware SPI which covers the 'dynamic dtb overlay' support. The summary is to: mkdir /sys/kernel/config/device-tree/overlays/spi cat spidev-enable.dtbo > /sys/kernel/config/device-tree/overlays/spi/dtbo Where 'spidev-enable.dtbo' could be any file from /boot/dtb/overlay. I got a big kernel bug from that. I'll try it again from a clean boot without modprobing the spidev module. That gives the same error. Oh, you responded...

I've read the documentation you linked to. I think the problem start around Overlay Parameters. They mention a set of README.* files that should be in /boot/dtb/overlay or in /boot/dtb/allwinner/overlay, but no such files exist. Following the general--and maybe outdated--advice from the documentation, I added "param_spidev_spi_bus=0" and rebooted. Nothing changed. I guess the next step is to hook a serial line up to it and see what's happening.

How about for the mainline kernel? I've tried: Editing /boot/armbinaEnv.txt and adding "overlays=sun8i-h3-spi0-spidev" and rebooting. modprobing spi-dev I don't see anything in /dev/spi* Clearly I've missed something. Can you advise, please?

May I ask for a slight modification to this policy? Since we've already made a small exception for UART headers, could we go so far as to include: 1) Included in design but not populated parts like CIR receivers? 2) Dedicated use headers--I'm thinking specifically of the 1x13 header on the Orange Pi Zero(s). It's looking to become a standard. or, do we want to do these via overlays as well? I truely don't understand the pro's and con's of going one way or the other on this decision. If this has been discussed before, please ignore my comments and refer me to the other posts and I'll go get educated on the issue.

Okay, you want me to do a custom (from source) build of xhpl. Then you want me to instrument a recently purchased Orange Pi Zero with a meter on the CPU voltage line and a bench power supply. Then you want me to run xhpl at a series of fixed clock speeds and measure the voltages/temperatures/currents? I'm good on all of that but I may need some hand holding on how to do the fixed clock speed and on how to tell if there is throttling occuring.

@zador.blood.stained, are you refering to running StabilityTester on a large number of boards at a series of fixed clock speeds and voltages? I'd like to do this for the boards I have. Would the Sunxi-linux wiki be a good place to collect the results?

Okay, I will test tomorrow. Thank you for all of your work!

I just did an apt-get update on the mainline version of armbian and now the machine won't boot. I'l looking at the uboot output and it appears not to load the full kernel in and boot it. The strange thing is it seems to hang, but when I unplug the power, the kernel load info shows up on the serial output. U-Boot SPL 2017.03-armbian (Mar 15 2017 - 06:57) DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2017.03-armbian (Mar 15 2017 - 06:571 +0100) Allwinner Technology CPU: Allwier H3 (SUN8I 1680) Model: Xunlong Orange Pi Zero DRAM: 512 MiB MMC: SUNXI SD/MMC0 *** Warning - bad CRC, usig default environment r serialial Net: phy interface0 eth0: ethernet@1c30000 Hit any key to stop autoboot: 0 switch to partitions #0, OK.1 KiB/s) mmc0 is current device Scanning mmc 0 After I unplug the power I also get: ... Found U-Boot script /boot/boot.scr 2092 bytes read in 216 ms (8.8 KiB/s) ## Executing script at 43100000 Booting from SD 114 bytes read in 185 ms (0 Bytes/s) 5084171 bytes read in 535 ms (9.1 MiB/s) 5720128 bytes read in 579 ms (9.4 MiB/s) 0 byt Any suggestions? I can always reimage the uSD card with a new version. But it might be useful to know what went wrong.

I found my SMD clips! ITT Pomona Model 5514. They were even where I thought they would be! Too bad it was at the bottom of a drawer that I don't think I've touched since we moved last. Nine years ago......

They consider "openssl --speed" to be a good torture test? Oh, my.

http://sprunge.us/cZOb is the first half. If you point me to a specific image you want me to run, I'll DL and burn it and get the data. I've never used any of their images, so I'm unfamiliar with their site.

Okay, let me dig out my SMT clip/probes!

I have a scope that does SPI decode as well as a cheap 24MHz logic analyzer. I haven't done a ton of high speed serial work since the early 90's, but I'm ready to try.

I can confirm that you can feed power in over the 13 pin connector. The NAS board will do that if you power the NAS board with 5V. I have a Z running that way rigth now.