mmarks

Just a follow up to my problems with the nvme ssd. I found that the NVME SSD I was using - an ADATA 512GB SX6000 2280 PCIe SSD which was supposeldy PCIE 1.2 compatible just wanst recognized. I switched to the Samsung 256GB NVME SSD and it was recognized and works. So not all NVME SSDs work. Now I'd like to know how to fix the MAC address, which changes on every boot.

I see you are running kernel 4.4.150 while the debian stretch version for download is 4.4.148. Do I need to do an offline full build to pick up the latest changes?

I installed armbian stretch on my T4 and also got it installed in the eMMC with the nand install script. Good progress! It runs OK except for one thing. I installed a 512GB NVME SSD for bulk storage and it doesnt seem to be recognized at all. The FriendlyElec Wiki says to check /proc/partitions - and I see nothing for the nvme there. And also lspci shows nothing at all. Looking at dmesg I see some indications that pcie might be started but it has problems, maybe the device tree is not quite right?: ... [ 0.833210] phy phy-pcie-phy.5: Looking up phy-supply from device tree [ 0.833218] phy phy-pcie-phy.5: Looking up phy-supply property in node /pcie-phy failed [ 0.835200] rockchip-pcie f8000000.pcie: GPIO lookup for consumer ep [ 0.835211] rockchip-pcie f8000000.pcie: using device tree for GPIO lookup [ 0.835237] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0) [ 0.835458] rockchip-pcie f8000000.pcie: Looking up vpcie3v3-supply from device tree [ 0.835540] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply from device tree [ 0.835551] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply property in node /pcie@f8000000 failed [ 0.835563] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found [ 0.835570] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply from device tree [ 0.835578] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply property in node /pcie@f8000000 failed [ 0.835586] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found [ 0.855987] rockchip-pcie f8000000.pcie: invalid power supply [ 1.356010] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! [ 1.356204] rockchip-pcie: probe of f8000000.pcie failed with error -110 ... Any ideas what might be wrong? I noticed that there are some performance numbers for NVME speed - what kernel/device tree is being used for that data?

I'm still finding the H3 SPI to be too slow for driving LCD SPI displays. I'm using the vanilla 4.7.2 kernel, applying overlays for I2C and SPI. Using a C program to directly access the spi with ioctl calls the best speed I was able to achieve for single byte writes was <30 Kb/sec. This is with 8 MHZ SPI clock. The speed limiting problem is still long delays on CS assert and deassert: 5us from CS assert to SPI data start, 25 us from SPI data end to CS deassert. The actual data time is about 1us with 8 MHz clock so ~97% of the time is wasted in the hardware CS delays, not counting the delay between sending bytes This makes the H3 many times slower with displays than Arduino, and far, far slower than Teensy which I've used for many IOT projects. Legacy kernel experiments show the same sort of delays. I thought the more recent kernels might be better. But not yet. I'd really like to use the Neo for projects that use SPI for small displays, or interfacing a digital radio chip or ADC, etc, but the slow speed is holding me back at the moment. For example an IOT gateway. I know its not the H3 based hardware that's limiting the speed, just the driver and that can be fixed. I'm interested in any ideas or experimental results anyone has on this topic.

I had the same sort of problem. I have an Orangepi-pc-plus. I did the upgrade and then found it didn't complete the reboot. I connected a serial cable and watched the boot process. Here's a scrap showing the problem: ... Verifying Checksum ... OK ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree SCRIPT FAILED: continuing... switch to partitions #0, OK mmc1(part 0) is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 2444 bytes read in 173 ms (13.7 KiB/s) ## Executing script at 43100000 gpio: pin PL10 (gpio 298) value is 1 gpio: pin PG11 (gpio 203) value is 1 ** File not found /boot/.verbose ** 0 bytes read in 137 ms (0 Bytes/s) ** File not found /boot/dtb/sun8i-h3-orangepi-pc-plus.dtb ** ** Unrecognized filesystem type ** ** File not found /dtb/sun8i-h3-orangepi-pc-plus.dtb ** 4012265 bytes read in 410 ms (9.3 MiB/s) 5791992 bytes read in 595 ms (9.3 MiB/s) ## Loading init Ramdisk from Legacy Image at 42000000 ... Image Name: uInitrd ...... So it looks like in my case the .dtb for that particular board was missing. I know that the board is very similar to the OrangepiPC I just copied the /boot/dtb/sun8i-h3-orangepi-pc.dtb to /boot/dtb/sun8i-h3-orangepi-pc-plus.dtb and tried again. This time it booted without problems. Hope this is helpful.

Another bit of feedback on the mainline - vanilla Jessie. Only one of the three USB ports is active, USB0. USB1 and USB2 are disabled. For comparison I booted the FA Ubuntu core and the USB ports are OK. Perhaps this is another device tree issue?

Let me add that I did test the spidev0.0 with a logic analyzer and it works! I'm still exploring some aspects of it e.g. the CS control, but it doesn't seem to have the same huge delay between cs assertion and data that I saw previously.

By the way. A word of warning to anyone getting a Nanopi Neo bare board (without RJ45 and USB connectors). I bought a RJ435 Magjack from Sparkfun to provide the Ethernet connection. Although the dimensions and pinout match perfectly with the circuit board it simply doesnt work at all. A careful reading of the Neo schematics, and the circuit details of the Hanrun magjack FA used and the Sparkfun one I see that although they are not wired the same internally. The correct Magjack to use is a Hanrun HR911105A. They are hard to find in the US but $0.75 each from Aliexpress.

Thanks! It wasn't quite so obvious but I did get it to work eventually. I found that building the default git mainline from pantoniou/dtc produced a dtc that would not accept the -@ option. However I noticed that there were several branches that were more recent - e.g dt-overlays8. When I built that branch it produced a dtc that although it gave a few warnings did produce a dtbo that could be copied into the configfs and suddenly the spidevs showed up in /dev. Here's exactly what I did: I found that the dtc build required flex and bison so I installed them: apt-get install flex bison I cloned the dtc git with the dt-overlays8 branch: git clone -b dt-overlays8 https://github.com/pantoniou/dtc I built that version ( DTC 1.4.1-gf7da040f) and used that to compile the dts: dtc -@ -O dtb -I dts -o spidev-enable.dtbo spidev-enable.dts There were a couple of warnings: Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /fragment@1 has a unit name, but no reg property Warning (unit_address_vs_reg): Node /fragment@2 has a unit name, but no reg property Then copied the result to the directory I created earlier: sudo cat spidev-enable.dtbo > /sys/kernel/config/device-tree/overlays/spi/dtbo Two spidevs then showed up in /dev! ls /dev/spi* /dev/spidev0.0 /dev/spidev1.0 Now I'll have to wire up something (maybe a logic analyzer) to test them. I hope I don't have the spi speed problem I saw earlier... Thanks again for your help. When it all works it is simply magical!

I wish it was that easy :-) If I use your overlay source directly and copy it to the overlay dtbo as you suggest I see the following errors in dmesg: ... [ 496.553300] Invalid device tree blob header [ 496.553371] create_overlay: failed to unflatten tree I thought I needed to compile the dts first into the dtbo with: dtc -O dtb -I dts -o spidev-enable.dtbo -b 0 spidev-enable.dts But that gives an error too: root@nanopineo:~# dtc -O dtb -I dts -o spidev-enable.dtbo -b 0 spidev-enable.dts Error: spidev-enable.dts:3.2-8 syntax error Of course it doesn't say what the syntax error is. I'm wondering it was something stupid like different line ending characters. That is sometimes as issue moving between windows and linux environments. I'll check that next. But my question is: do you need to compile it first or will it happen automatically when its copied to the configfs?

I've been looking at the missing spidev problem with the current mainline (4.7.2). I built armbian vanilla (mainline) Jessie on linux and noticed that although the correct spi device info has now been included in the device tree for h3 (sun8i-h3.dtsi) the changes martinayotte noted for the spidev driver have not been made. I tried adding his spidev patch file to the userpatches but it seems to be getting ignored or overwritten in the build script. Is there a way to rebuild without pulling in the git updates? I note that there is a spidev.ko but loading it with modprobe doesnt create any spi devices

A quick update on my software and hardware experiments. I received three Neo boards from FA yesterday. I ordered the FA heatsinks to go with them, but I thought I would try just using a RPI heatsink on the H3 to see if it was enough. The boards came without any USB and RJ45 hardware. Just the bare board, so I've ordered some MagJacks from Sparkfun. I'll hardwire the USB for now. I don't see an option on the FA website to buy the hardware so be warned you may get bare boards. I loaded Armbian 5.17 Jessie 4.6.7 on a 16GB uSD card and set up a serial debug port on the 5 pin header. Armbian booted and ran perfectly. Powered from the usb OTG port it draws about 250-400 mA depending on load. With just a small square RPI heatsink on the CPU it idles at 240 MHz at ~28C. Not much over ambient here in Texas. Loaded up it gets up to high 30s but I haven't run a real stress test yet. I'm not planning on running it too hard for my application. I'll switch to the bigger FA heatsink if I need to. The thermal pad looks too thick to be really effective but you never know. I tried using a powered OTG splitter dongle to see if I could use a USB Ethernet dongle on the OTG port but although the Ethernet dongle got power and the board powered up my ethernet device did not show up in lsusb. Not sure what the problem is there. Like others I need SPI, I2C and GPIO for my applications so I'll try playing with the device overlays once I get this board safely on the network. Once again THANKS for the great work on Armbian. I appreciate the hard work.

Hi Vancouver. I'm having the exact same problem on the H3 (Orangepi pc plus). I'm trying to drive a small tft display (2.2" ILI9225) from the spi pins on the header and found that the SPI transfers are so slow due to the delays that its almost unusable - it takes seconds to draw a text string. I optimized by code for a couple of days without improvement then got out the logic analyzer to look at the SPI transactions and saw exactly the same thing you did, which explains everything. The official armbian for opi pc plus is just using the legacy kernel. That generally works just fine, I've put it on the nand emmc. So I thought an updated (mainline) kernel might help but when I build the latest kernel with the armbian build system (which is a very nice piece of work by the way) the orange pi system wont boot; it just runs a boot loop trying to start up. There is something wrong and that's probably why Igor only provides the legacy kernel. So there are two paths to go - 1) patch the SPI driver in the legacy kernel to make it work properly - using hardware CS, the FIFO and hopefully DMA; or 2) figuring out why the mainline kernel won't boot and fixing it. The newer SPI code is probably optimized. Perhaps Igor has some thoughts on what would be the best approach?