willmore

I just updated two Orange Pi One boards and rebooted them to get to the new kernel only to have them boot loop. I know, development, not supported. I'm not asking for a solution, I'm just alerting people to the situation so they can avoid messing up their boxes. Console log attached if you're curious. orangepione.txt

Understood. I wasn't worried about the breakage as it's easily fixed and--as you said--this is an experimental build. But I did think it was a good time to improve my understanding of the boot process.

@zador.blood.stained Perfect, thank you, that's exactly what I was looking for!

Hello, all. My Orange Pi PC2 recently broke when doing an upgrade. So I hooked a serial cable to it and watched what it did. The error was that it couldn't find the dtb file. It was looking for "/boot/dtb/allwinner/allwinner/sun50i-h5-orangepi-pc2.dtb" and "/dtb/allwinner/allwinner/sun50i-h5-orangepi-pc2.dtb", but the former fails because the file is at "/boot/dtb/allwinner/sun50i-h5-orangepi-pc2.dtb". So, I put a simlink in dtb/allwinner called 'allwinner' and pointing to the parent directory. Now the device boots. I'm not sure if that's the proper fix, but it works for now and I'll fix it if I manage to break something with it later on. This brings me to the real questions which I discovered as I tried to debug this. While booting uboot says it loads something--it dosn't say what--and reports "6944 bytes read in 180 ms (37.1 KiB/s)" That looks like it was the boot.bmp file. Which--according to 'file'--is really a BMP file. But it looks like uboot wasn't expecting that because it says "Unknown command 'bmp' - try 'help'" That probably come from the 'BMP' magic entry at the beginning of the boot.bmp file. So, first question: Why are we loading a .bmp file? uboot clearly doesn't expect it and doesn't seem to know what to do with it. Where does uboot get the idea that it should even load that file? The next set of quesitons come from what uboot does next. It does "2253 bytes read in 191 ms (10.7 KiB/s)" which is the right size to be boot.scr. That file seems to start with some non-printable garbage which doesn't seem to upset uboot. It uses a bunch of predefined variables and I can't find where they are defined--the location of the dtb files in particular are what I was trying to determine the source of. Where does uboot get this? The armbianEnv.txt file doesn't have it. I'd like to know more about how the boot process works. If anyone could point me to a good source of information about this, I would appreciate it. The uboot documentation is very generic and doesn't deal with the specifics of how armbian handles things. Thank you!

@zador.blood.stained Yeah, I turned it off. Thanks, though.

Okay, so I let them bake for a few hours. The PC2 quickly climbed to 80C and then slowly up to 100C where it stayed. Performance did not change during the run. The C2 slowly climbed up to 49C and stayed there. It also had no performance changed during the test. I have no idea what the clock speed of the PC2 is. It's whatever current mainline armbian probides--which @tkaiser said was 815MHz. So, we could expect that one to come up a little, but not much--100C seems to be pretty toasty.

@tkaiser The C2 is at 1.752GHz, not the stock 1.5GHz. I'll start running the multi threaded burn in and see where it goes.

@tkaiser Nice summary. The Rock64 looks pretty good. Do you have XU4 results to add as context? Here are results for an i5-3220m (3.2GHz IVB core): type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 569283.29k 617659.88k 627125.93k 629601.96k 630164.14k aes-192-cbc 479330.65k 508491.20k 514591.74k 514747.05k 517674.33k aes-256-cbc 399388.34k 429790.57k 440986.54k 448194.56k 445876.91k

Okay, composited: root@orangepipc2 Doing aes-128-cbc for 3s on 16 size blocks: 19231577 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 12853395 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 5372534 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 1669698 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 224642 aes-128-cbc's in 3.00s Doing aes-192-cbc for 3s on 16 size blocks: 17959061 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 64 size blocks: 11051987 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 256 size blocks: 4292528 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 1024 size blocks: 1276599 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 8192 size blocks: 168931 aes-192-cbc's in 3.00s Doing aes-256-cbc for 3s on 16 size blocks: 17198520 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 9922363 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 3673052 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1063205 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 139337 aes-256-cbc's in 3.00s The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 102568.41k 274205.76k 458456.23k 569923.58k 613422.42k aes-192-cbc 95781.66k 235775.72k 366295.72k 435745.79k 461294.25k aes-256-cbc 91725.44k 211677.08k 313433.77k 362907.31k 380482.90k root@odroid64 Doing aes-128-cbc for 3s on 16 size blocks: 9702869 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 2781948 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 727164 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 183877 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 23058 aes-128-cbc's in 3.00s Doing aes-192-cbc for 3s on 16 size blocks: 8720919 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 64 size blocks: 2461310 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 256 size blocks: 639833 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 1024 size blocks: 161576 aes-192-cbc's in 3.00s Doing aes-192-cbc for 3s on 8192 size blocks: 20256 aes-192-cbc's in 3.00s Doing aes-256-cbc for 3s on 16 size blocks: 7892666 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 2170451 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 561814 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 141717 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 17766 aes-256-cbc's in 3.00s type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 51748.63k 59348.22k 62051.33k 62763.35k 62963.71k aes-192-cbc 46511.57k 52507.95k 54599.08k 55151.27k 55312.38k aes-256-cbc 42094.22k 46302.95k 47941.46k 48372.74k 48513.02k

@zador.blood.stained From OrangePiPC2: Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid root@orangepipc2:~# openssl speed -elapsed -evp aes-128-cbc aes-192-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-192 cbc for 3s on 16 size blocks: 4382225 aes-192 cbc's in 3.00s Doing aes-192 cbc for 3s on 64 size blocks: 1168568 aes-192 cbc's in 3.00s Doing aes-192 cbc for 3s on 256 size blocks: 299007 aes-192 cbc's in 3.00s Doing aes-192 cbc for 3s on 1024 size blocks: 75171 aes-192 cbc's in 3.00s Doing aes-192 cbc for 3s on 8192 size blocks: 9412 aes-192 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 3942328 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 1028331 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 262540 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 65973 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 8302 aes-256 cbc's in 3.00s Doing aes-128-cbc for 3s on 16 size blocks: 19229648 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 12855383 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 5371646 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 1669660 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 224669 aes-128-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-192 cbc 23371.87k 24929.45k 25515.26k 25658.37k 25701.03k aes-256 cbc 21025.75k 21937.73k 22403.41k 22518.78k 22669.99k aes-128-cbc 102558.12k 274248.17k 458380.46k 569910.61k 613496.15k root@odroid64:~# openssl speed -elapsed -evp aes-128-cbc aes-192-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-192 cbc for 3s on 16 size blocks: 9426226 aes-192 cbc's in 3.00s Doing aes-192 cbc for 3s on 64 size blocks: 2513241 aes-192 cbc's in 3.00s Doing aes-192 cbc for 3s on 256 size blocks: 642946 aes-192 cbc's in 3.00s Doing aes-192 cbc for 3s on 1024 size blocks: 161675 aes-192 cbc's in 3.00s Doing aes-192 cbc for 3s on 8192 size blocks: 20241 aes-192 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 8471996 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 2211530 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 564468 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 141815 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 17766 aes-256 cbc's in 3.00s Doing aes-128-cbc for 3s on 16 size blocks: 9706011 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 2782108 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 727117 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 183869 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 23058 aes-128-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-192 cbc 50273.21k 53615.81k 54864.73k 55185.07k 55271.42k aes-256 cbc 45183.98k 47179.31k 48167.94k 48406.19k 48513.02k aes-128-cbc 51765.39k 59351.64k 62047.32k 62760.62k 62963.71k Looks like openssl uses the AES instructions for the 128 bit keylength, but not 192 nor 256 which is a bit strange. Then again, it's an old version. The Odroid c2 is running xenal and the PC2 is running armbian current.

Where have you seen cryptsetup benchmark results for the rock64? I searched this thread and didn't find any. It's just an A53 with the AES extensions, right? So, we'd expect something like the H5 +/- some for clock speed differences? Orange Pi PC2 (AllWinner H5) root@orangepipc2:~# cryptsetup benchmark # Tests are approximate using memory only (no storage IO). PBKDF2-sha1 129262 iterations per second PBKDF2-sha256 76293 iterations per second PBKDF2-sha512 70773 iterations per second PBKDF2-ripemd160 109409 iterations per second PBKDF2-whirlpool 24435 iterations per second # Algorithm | Key | Encryption | Decryption aes-cbc 128b 238.4 MiB/s 296.1 MiB/s serpent-cbc 128b 17.0 MiB/s 19.2 MiB/s twofish-cbc 128b 25.9 MiB/s 28.2 MiB/s aes-cbc 256b 204.6 MiB/s 267.8 MiB/s serpent-cbc 256b 17.2 MiB/s 19.1 MiB/s twofish-cbc 256b 26.1 MiB/s 28.2 MiB/s aes-xts 256b 259.8 MiB/s 261.3 MiB/s serpent-xts 256b 17.7 MiB/s 19.5 MiB/s twofish-xts 256b 27.7 MiB/s 28.7 MiB/s aes-xts 512b 240.3 MiB/s 239.8 MiB/s serpent-xts 512b 18.1 MiB/s 19.5 MiB/s twofish-xts 512b 28.2 MiB/s 28.6 MiB/s By way of comparison, a faster clocked A53 without AES (Odroid-C2 Amlogic S905): root@odroid64:~# cryptsetup benchmark # Tests are approximate using memory only (no storage IO). PBKDF2-sha1 275941 iterations per second PBKDF2-sha256 165913 iterations per second PBKDF2-sha512 152409 iterations per second PBKDF2-ripemd160 238312 iterations per second PBKDF2-whirlpool 52851 iterations per second # Algorithm | Key | Encryption | Decryption aes-cbc 128b 42.4 MiB/s 44.2 MiB/s serpent-cbc 128b 34.5 MiB/s 37.7 MiB/s twofish-cbc 128b 42.6 MiB/s 42.2 MiB/s aes-cbc 256b 32.7 MiB/s 33.0 MiB/s serpent-cbc 256b 35.2 MiB/s 37.7 MiB/s twofish-cbc 256b 43.5 MiB/s 42.2 MiB/s aes-xts 256b 45.2 MiB/s 44.7 MiB/s serpent-xts 256b 36.5 MiB/s 38.1 MiB/s twofish-xts 256b 45.5 MiB/s 42.7 MiB/s aes-xts 512b 34.1 MiB/s 33.3 MiB/s serpent-xts 512b 36.9 MiB/s 38.1 MiB/s twofish-xts 512b 45.9 MiB/s 42.7 MiB/s

@tkaiser, while all of that is correct, there is another use case that you didn't consider. What about using this for a NAS/router? One interface towards the internal network and the other to the outside. Not all of the traffic has to terminate on the Rock64.

Thank you for the warning! I'll hold off on doing any testing that I expect to be meaningful for now. In the mean time I will take the card out and put it in a faster machine so that I can get a baseline performance estimate for the SSD itself. A quick and dirty read test with dd shows some 37MB/s which isn't bad for USB2--it's safe to say the drive isn't the limiting factor in that test. Also, I'll finish getting the power connector for the 2.5" SATA drive finished so I can try that as well.

Do I need to do anything special before doing some iozone benchmarks? I'm running the current mainline armbian: root@orangepizero:~# uname -a Linux orangepizero 4.11.5-sun8i #4 SMP Sat Aug 12 14:21:20 CEST 2017 armv7l armv7l armv7l GNU/Linux

To clarify, I'm not plugging any USB devices into the NAS board as I understand they are parallel to the jmicron USB<>SATA converters. I only have an mSATA card in the proper slot. But, the problem is that I don't even have the busses enabled. Here's the output of uboot: ** File not found boot/dtb/overlay/usbhost0.dtbo ** ** File not found dtb/overlay/usbhost0.dtbo ** ** File not found boot/dtb/overlay/usbhost2.dtbo ** ** File not found dtb/overlay/usbhost2.dtbo ** ** File not found boot/dtb/overlay/usbhost3.dtbo ** ** File not found dtb/overlay/usbhost3.dtbo ** Which is odd as I have the prefix set and the instructions said to leave those out. Let me add them back in and see if that works--though I tried it before.... Okay, that works. Guess something else changed? I hope this doesn't get broken some point in the future when the prefix starts to be respected. And I can see the drive. Yay! Thanks everyone.

Okay, I'll go grab a serial adapter and get it hooked up. I don't think the dtb that I have (Armbian current) has them enabled. All I have is: Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Which I believe are the OTG port and the one on board USB port. There should be four more lines like that for the ones on the NAS board. I have an msata SSD plugged in there and was using lsblk to look for it and then gave up and looked at lsusb. That's when I realized I was missing the ports. Boy, I'm so glad we didn't include them in the kernel DTB file.

Okay, I'm using a rubber band to hold the drive on, but now I notice that the USB ports aren't active to the NAS board. I think I have set up the overlays properly, but they busses don't show up. Does this look okay for a /boot/armbianEnv.txt? verbosity=7 console=both disp_mode=1920x1080p60 rootdev=UUID=c592dd4c-b0c2-4644-b627-bc3cbd3dc180 rootfstype=ext4 overlay_prefix=sun8i-h3 overlays=usbhost0 usbhost2 usbhost3 I added the two lines starting with 'overlay'. In /boot/dtb/overlay/, there are "sun8i-h3-usbhost0.dtbo" and ones for host2 and 3. Am I missing a step?

FWIW, here are results from an Odroid-C2 (s905 at 1.752 GHz) root@odroid64:~# openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128 cbc for 3s on 16 size blocks: 10626464 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 64 size blocks: 2854954 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 732698 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 184400 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 23091 aes-128 cbc's in 3.00s Doing aes-256 cbc for 3s on 16 size blocks: 8492125 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 64 size blocks: 2213547 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 256 size blocks: 564986 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 1024 size blocks: 141955 aes-256 cbc's in 3.00s Doing aes-256 cbc for 3s on 8192 size blocks: 17779 aes-256 cbc's in 3.00s Doing bf-cbc for 3s on 16 size blocks: 8588780 bf-cbc's in 2.99s Doing bf-cbc for 3s on 64 size blocks: 2551326 bf-cbc's in 3.00s Doing bf-cbc for 3s on 256 size blocks: 668702 bf-cbc's in 3.00s Doing bf-cbc for 3s on 1024 size blocks: 169460 bf-cbc's in 3.00s Doing bf-cbc for 3s on 8192 size blocks: 21263 bf-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 56674.47k 60905.69k 62523.56k 62941.87k 63053.82k aes-256 cbc 45291.33k 47222.34k 48212.14k 48453.97k 48548.52k bf-cbc 45960.03k 54428.29k 57062.57k 57842.35k 58062.17k I'm new to reporting this, so if there was more info you need, let me know and I'll do my best to get it to you.

Okay, I finally got all the hardware I need to test with this. But, now that I have the msata drive, I notice there are no mounting standoffs on the Orange Pi NAS board. Does anyone know the spec for the standoffs? One more thing I need to go get to finish this project..... Thanks!

@martinayotteI don't think there is a problem. As @zador.blood.stainedpoints out, there are other consumers of the SPI drivers in the kernel which don't share the 4K limitation that the user space facing spidev codes does. When I looked over her code, I didn't assume the 4K limitation. My only concern is that I didn't see any of the normal 'is this page proper for DMA on this architecture' kind of checks. But, I'm well out of practice for reviewing kernel patches. It's been a very long time.

Fair enough. On the plus side, it looks like 4K transfers are sufficient to drain the buffer with the existing driver. I need to annotate the captures I've done so far. I'll also need to do them again at slower speeds--100MHz is, by definition, an extreme test.

Thank goodness I answered that in the very message you quote.

Thanks for that! Okay, then the DMA patches from MoeIcenowy are a bit overkill when they limit their transfer length to 2^24-1. sun6i-dma-patch "#define SUN6I_MAX_XFER_SIZE 0xffffff" Seeing that, I was assuming that the rest of the SPIDEV infrastructure supported larger transfers. Maybe that's there for kernel drivers which may do larger than page sized transfers. That would make sense as it would be hard to get DMA memory allocated from a user space transfer, while a kernel module wouldn't have the same issue.

Hmm, okay, I'm seeing 4K transfers accepted by the test program, but not 8K. That's well past the size of the FIFO. It may not use DMA, but something is feeding the FIFO. I think it's time to me to make my own test program so that I know exactly what it does and what the error messages are.

@zador.blood.stained, Am I correct in believing that the current beta channel kernels for the Orange Pi One have the DMA patch in them and the FIFO set to 'fifo_size - 1'? MoeIcenowy was saying that on the IRC. I put a command to do 4K transfers in a loop which should exit if there is an error. I'm letting it run overnight. Okay, looking closer at the scope, I can see it. It's pretty interesting. I need to get the protocol analysis tools running on the scope to see how many bytes are transfered between the gaps. Looks like I can do 48 4K transfers/sec using the spidev_test program. So, that's got a ton of overhead. I need to write a program that cuts that out.