@lex Posted December 21, 2017 Posted December 21, 2017 I just received this sample sent by Nora Lee (Foxconn). I have put here the H3 and H5 side by side. I have been told it is pin to pin compatible so basically same pinctrl config would work, right? Let's find out, will try to build an Image with legacy and mainline and check out what we have here. Hey, don't expect a technical overview here.
tkaiser Posted December 21, 2017 Posted December 21, 2017 1 hour ago, @lex said: I have been told it is pin to pin compatible so basically same pinctrl config would work, right? Just look at Orange Pi Zero Plus 2: same PCB, one batch with H3 in the reel, the other batch H5. Due to software incompatibility use cases and usability of the two variants differ a lot (and I personally have not the slightest idea why 'we' started here to support the H5 variant at all since IMO no reasonable use case exists -- H3 variant with legacy kernel + Mali and video acceleration is something different) So here we're talking about the same: identical PCB, identical design flaw (SinoVoip 'forgot' voltage regulation) but different SoCs, different DRAM and AP6212 on early Bananas vs. AP6212A here, right? 1
@lex Posted December 21, 2017 Author Posted December 21, 2017 (edited) On 12/21/2017 at 7:19 PM, tkaiser said: So here we're talking about the same: identical PCB, identical design flaw (SinoVoip 'forgot' voltage regulation) but different SoCs, different DRAM and AP6212 on early Bananas vs. AP6212A here, right? Well, i think it is about use case too. We can draw some highlights / differences here (you can correct me if wrong or missed info) : * (m2+ h5) x (opiz2+h5) * Dram: 1 GB (m2+ h5) x 512 MB (opiz2+h5) * HDMI output x HDMI Output * Gbps + AP6212A1 x AP6212A1 * BT x BT * Reversed CSI pins x Reversed CSI pins (that means you need their sensor if you want a cheap camera or customize your sensor, more expensive) * eMMC: 8GB x 8GB * mali: ? x ? (i have read some where some user/developer got it working in fb, can't remember exactly) * price: ? x good * availability: ? x now If you ask me which one i prefer (H3 or H5) i don't hesitate to say: H5 (unless you need mali). And you need 1 GB of Dram to have a Browser experience. Regarding design flaw (voltage regulator) i can't comment, maybe it was a decision made due to BSP availability at the time, good or bad? who knows and they have the resources to "fix" the mistake if they want to. If we take for example the recent release of the BSP with kernel 4.4 that has no voltage regulator support we can infer this PCB (with H3) has some "advantages" and can run 4.4. Maybe AW release H5 BSP with missing voltage regulator support too (haha). Ok then, my first try with legacy (used u-boot and rootfs from OPIz2+H5 i had laying around here), was very promising but finally hit a wall, u-boot works and kernel boots fine but for whatever reasons SD card was not recognized when trying to mount /dev/mmcblk1p2 and i get freeze at this point (obviously). BT have some errors indicating it is really a AP6212A1. If I can't find a workaround for the SD card freeze will move on to kernel 4.14.y. If someone have any hint for the SD card issue, please let me know. Edited December 24, 2017 by @lex update info
tkaiser Posted December 21, 2017 Posted December 21, 2017 5 minutes ago, @lex said: (m2+ h5) x (opiz2+h5) Sorry, I was not talking about a comparison of those two boring boards but referenced the Xunlong board just as a starting point wrt software situation. For my use cases OPi Zero Plus 2 regardless which SoC is used is uninteresting anyway and it's more or less the same with M2+ since overpriced. Software situation with Allwinner is a constant mess and I gave up on them already. If Allwinner boards cost less than 15 bucks they're worth a look for IoT purposes or lowend NAS but for everything else (except camera maybe) there are better alternatives in the meantime. Disclaimer: only talking about my use cases. Final note: 'eMMC: 8GB x 8GB' -- at least on the OPi Zero Plus 2 I shortly tested with there was amazingly fast eMMC (40/80 MB/s write/read) and at least on my BPi M2+ is the slowest eMMC I've ever encountered (6.5 MB/s write, I forgot the read 'speed' already). So depending on the use case (eg. expecting 'class 10' performance which would require at least 10 MB/s sequential write) it's always necessary to look a bit closer since on the majority of Allwinner boards the eMMC is slow crap (Xunlong being the notable exception but even they replaced fast eMMC on some Orange Pi in the meantime with slow one which is somewhat understandable given the constant rise of BOM costs for flash memory)
@lex Posted December 22, 2017 Author Posted December 22, 2017 Disabling eMMC i was able to boot up to maintenance console but not without some tweaks, trial and error. U-boot needs some work and kernel too. eMMC definitely is not the same as of OpiZ2+H5. Will try 4.14.y when time permits as i see mainline can deal with eMMC...
@lex Posted December 23, 2017 Author Posted December 23, 2017 Little update, after revising eMMC pin config and fixing my mistakes i have now eMMC working. Some hiccups on hdmi output , Light Display Manager failed to start with some funny messages, possibly wrong configuration. Gbps is working but wifi still need some attention, i don't have any working Android fex file to base my findings so it is just trial and errors here. If you want me to run and test eMMC, put the command here and i try to grab the results.
@lex Posted December 24, 2017 Author Posted December 24, 2017 sudo ../iozone/iozone3_471/src/current/iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.471 $ Compiled for 64 bit mode. Build: linux-arm Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa, Alexey Skidanov. Run began: Sun Dec 24 17:58:38 2017 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: ../iozone/iozone3_471/src/current/iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 6361 6615 14036 14049 12156 6488 102400 16 19014 19470 30827 30886 28293 19009 102400 512 28949 29231 44031 44004 43835 28428 102400 1024 29138 29254 44116 44125 44007 28721 102400 16384 29878 29202 44358 44373 44386 29386 iozone test complete.
tkaiser Posted December 25, 2017 Posted December 25, 2017 8 hours ago, @lex said: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 It's a good idea to not rely on those iozone numbers made with just a test size of 100MB but to also test with at least twice the amount of DRAM. If numbers differ significantly you can throw above numbers away (at least that's what I'm doing regularly when benchmarking since 'benchmarking gone wrong' is rule and not exception ): iozone -e -I -a -s 3000M -r 16384k -i 0 -i 1 (if it's the same eMMC as on their other boards you'll end up with write 'performance' below 7 MB/s)
@lex Posted December 25, 2017 Author Posted December 25, 2017 5 hours ago, tkaiser said: It's a good idea to not rely on those iozone numbers made with just a test size of 100MB iozone -e -I -a -s 3000M -r 16384k -i 0 -i 1 Some Observations: governor: interactive and if governor is with performance the board runs all the time with 1008 Mhz and i get small (very small) increase. and running all the time with 1008 Mhz the Temp is around 63 C (no heatsink or active cooler) If Wifi and BT are in use the numbers differ a tidy bit for the worse. Used PSU 5v 2.0A. Iozone: Performance Test of File I/O Version $Revision: 3.471 $ Compiled for 64 bit mode. Build: linux-arm Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa, Alexey Skidanov. Run began: Mon Dec 25 07:33:15 2017 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 3072000 kB Record Size 16384 kB Command line used: ../iozone/iozone3_471/src/current/iozone -e -I -a -s 3000M -r 16384k -i 0 -i 1 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 3072000 16384 12962 12838 23028 23117 iozone test complete. The question: Benchmarking eMMC with frequency can shorten its life and/or reduce writing speed until it dies?
tkaiser Posted December 25, 2017 Posted December 25, 2017 15 minutes ago, @lex said: governor: interactive and if governor is with performance the board runs all the time with 1008 Mhz and i get small (very small) increase Usually we use 'ondemand' in Armbian (interactive is only useful on some sunxi legacy kernels) but apply the following tweaks: https://github.com/armbian/build/blob/751aa7194f77eabcb41b19b8d19f17f6ea23272a/packages/bsp/common/etc/init.d/armhwinfo#L82-L94 So the eMMC on this board is not that slow as on earlier board revisions (I had the opportunity to verify this recently since I let f3write/f3read run yesterday and the tool reported an average write speed of just 6.3MB/s on my BPi M2+). And what you observed is only some form of eMMC internal caching. As soon as the amount of data is small enough write speeds are high just to drop after some time. Easy to test for by combining two benchmark runs: iozone -e -I -a -s 3000M -r 16384k -i 0 ; iozone -e -I -a -s 100M -r 16384k -i 0 The 2nd iozone call will report the real write speed without any caching involved. And similar effects can be observed with small/cheap SSDs too (I've 5 small 120 / 128 GB here lying around just for testing, four show write performance of +300 MB/s but slow down to as low as low as 60 MB/s after a certain amount of data has been written, only my most recent one, a Transcend TS120GMTS420, is able to retain write performance of +500 MB/s regardless how much data will be written). And of course every write to flash media shorten its life but the FTL (flash translation layer) takes care of wear leveling to evenly spreads writes across flash cells so the most important thing to have in mind is 'write amplification'. And yes, on most flash media a performance degradation happens after total amount of data being written exceeding the storage capacity since now the FTL (controller) without TRIM has no clue which pages contain data and which not and starts to move around unused data as part of garbage collection and wear leveling (that's why quality SD cards can be considered the better choice than eMMC since with those SD cards you can use SD association's SD Formatter after some time and send an ERASE CMD38 to the device which restores factory performance -- see last 3 paragraphs here)
Recommended Posts