tkaiser

Members
  • Content count

    4722
  • Joined

  • Last visited


Reputation Activity

  1. guidol liked a post in a topic by tkaiser in NanoPi K1 Plus to be released soon   

     
    http://wiki.friendlyarm.com/wiki/index.php/NanoPi_K1_Plus
     
    RPi 3 form factor like their K2, maximum DRAM (2GB), Gigabit Ethernet, Wi-Fi with onboard aerial provided by RTL8189ETV, still using their own/new eMMC socket. According to schematics and their Github repo a SY8106A voltage regulator is used which is great news since then it's possible to clock the H5 well above 1.3 GHz.
  2. JMCC liked a post in a topic by tkaiser in S905/X/W/D video acceleration/GPU hw + multi core processing support   
     
    Talking about 'not entirely honest' when it's about bold lies is funny
     
    It's some proprietary crap that controls DVFS on Amlogic SoCs (a bl31.bin BLOB or something like that loaded on the embedded Cortex-M or something like that) and Hardkernel is the only vendor that got this BLOB from Amlogic in a way where the installation does not cheat on you. In case the BLOB does also DRAM initialization (most likely) it should be hard to exchange it between boards.
     
    https://forum.armbian.com/topic/2138-armbian-for-amlogic-s912/?do=findComment&comment=43338 (S912 and S905X are both known to cheat on the Linux kernel. The cpufreq values are all faked. Most probably this does also apply to all S905 devices except ODROID-C2 since Hardkernel managed to get a fixed BLOB from Amlogic)
     
  3. Moklev liked a post in a topic by tkaiser in SD card performance   
    2018 SD card update
     
    It's 2018 now, SD Association's A1 'performance class' spec is out over a year now and in the meantime we can buy products trying to be compliant to this performance class. SD cards carrying the A1 logo must be able to perform at least 1500 random read input-output operations per second (IOPS) with 4KB block size, 500 random write IOPS and 10 MB/s sustained sequential performance (see here for more details and background info)
     
    Why is this important? Since what we do on SBC at least for the rootfs is mostly random IO and not sequential IO as it's common in cameras or video recorders (that's the stuff SD cards have been invented to be used with in the beginning). As an SBC (or Android) user we're mostly interested in high random IO performance with smaller blocksizes since this is how 'real world' IO patterns mostly look like. Prior to A1 and A2 performance classes there was no way to know how SD cards perform in this area prior to buying. Fortunately this has changed now.
     
    Last week arrived an ODROID N1 dev sample so I bought two SanDisk A1 cards with 32GB capacity each. An el cheapo 'Ultra A1' for 13€ (~$15) and an 'Extreme A1' for 23€. I wanted to buy a slightly more expensive 'Extreme Plus A1' (since even more performance and especially reliability/longevity) but ordered the wrong one  Please keep in mind that the 'Extreme Plus' numbers shown below are made with an older card missing the A1 logo.
     
    Let's look how these things perform, this time on a new platform: RK3399 with an SD card interface that supports higher speed modes (requires kernel support and switching between 3.3V to 1.8V at the hardware layer). So results aren't comparable with the numbers we generated the last two years in this and other threads but that's not important any more... see at the bottom.
     
    A1 conformance requires at least 10 MB/s sequential performance and 500/1500 (write/read) IOPS with 4K blocksize. I tested also with 1K and 16K blocksizes for the simple reason to get an idea whether 4K results are useful to determine performance with smaller or larger blocksizes (since we already know that the vast majority of cheap SD cards out there shows a severe 16K random write performance drop which is the real reason so many people consider all SD cards being crap from a performance point of view).
     
    I tested with 7 cards, 4 of them SanDisk, two Samsung and the 'Crappy card' being a results mixture of a 4GB Kingston I started to test with and old results from a 4GB Intenso from two years ago (see first post of this thread). The Kingston died when testing with 4K blocksize and the performance of all these crappy 'noname class' cards doesn't vary that much:
    1K w/r 4K w/r 16K w/r Crappy card 4GB 32 1854 35 1595 2 603 Samsung EVO+ 128GB 141 1549 160 1471 579 1161 Ultra A1 32GB 456 3171 843 2791 548 1777 Extreme A1 32GB 833 3289 1507 3281 1126 2113 Samsung Pro 64GB 1091 4786 1124 3898 478 2296 Extreme Plus 16GB 566 2998 731 2738 557 2037 Extreme Pro 8GB 304 2779 323 2754 221 1821 (All results in IOPS --> IO operations per second) For A1 compliance we only need to look at the middle column and have to expect at least 500/1500 IOPS minimum here. The 'Crappy card' fails as expected, the Samsung EVO+ too (but we already knew that for whatever reasons newer EVO+ or those with larger capacity perform worse than the 32GB and 64GB variants we tested two years ago), the Samsung Pro shows the best performance here while one of the 4 SanDisk also fails. But my Extreme Pro 8GB is now 3 years old, the other one I had showed signs of data corruption few months ago and when testing 2 years ago (see 1st post in this thread) random write performance was at 800. So most probably this card is about to die soon and the numbers above are partially irrelevant..
     
    What about sequential performance? Well, 'Crappy card' also not able to meet specs and all the better cards being 'bottlenecked' by ODROID N1 (some of these cards show 80 MB/s in my MacBook's card reader but Hardkernel chose to use some safety headroom for good reasons and limits the maximum speed for improved reliability)
    MB/s write MB/s read Crappy card 4GB 9 15 Samsung EVO+ 128GB 21 65 Ultra A1 32GB 20 66 Extreme A1 32GB 59 68 Samsung Pro 64GB 61 66 Extreme Plus 16GB 63 67 Extreme Pro 8GB 50 67 Well, sequential transfer speeds are close to irrelevant with single board computers or Android but it's good to know that boards that allow for higher SD card speed modes (e.g. almost all ODROIDs and the Tinkerboard) also show an improvement in random IO performance if the card is a good one. The ODROID N1 was limited to DDR50 (slowest SD card mode) until today when Hardkernel unlocked UHS capabilities so that my cards (except of 'Crappy card') could all use SDR104 mode. With DDR50 mode sequential performance is limited to 22.5/23.5MB/s (write/read) but more interestingly random IO performance also differs. See IOPS results with the two SanDisk A1 cards, one time limited to DDR50 and then with SDR104:
    1K w/r 4K w/r 16K w/r Ultra A1 DDR50 449 2966 678 2191 445 985 Ultra A1 SDR104 456 3171 843 2791 548 1777 1K w/r 4K w/r 16K w/r Extreme A1 DDR50 740 3049 1039 2408 747 1068 Extreme A1 SDR104 833 3289 1507 3281 1126 2113 We can clearly see that the larger the blocksize the more the interface speed influences also random IO performance (look especially at 16K random reads that double with SDR104)
     
    Some conclusions:
    When comparing results above the somewhat older Samsung Pro performs pretty similar to the Extreme A1. But great random IO performance is only guaranteed with cards carrying the A1 logo (or A2 soon) so it might happen to you that buying another Samsung Pro today results in way lower random IO performance (see Hardkernel's results with a Samsung Pro Plus showing 224/3023 4k IOPS which is way below the 1124/3898 my old Pro achieves with especially write performance 5 times worse and below A1 criteria) We still need to focus on the correct performance metrics. Sequential performance is more or less irrelevant ('Class 10', 'UHS' and so on), all that matters is random IO (A1 and A2 soon). Please keep in mind that you can buy a nice looking UHS card from 'reputable' brands like Kingston, Verbatim, PNY and the like that might achieve theoretical 80MB/s or even 100MB/s sequential performance (you're not able to benefit from anyway since your board's SD card interface will be the bottleneck) but simply sucks with random IO performance. We're talking about up to 500 times worse performance when trusting in 'renowned' brands and ignoring performance reality (see 16k random writes comparing 'Crappy card' and 'Extreme A1') Only a few vendors on this planet run NAND flash memory fabs, only a few companies produce flash memory controllers and have the necessary know-how in house. And only a few combine their own NAND flash with their own controllers to their own retail products. That's the simple reason why at least I only buy SD cards from these 4 brands: Samsung, SanDisk, Toshiba, Transcend The A1 performance speed class is a great and necessary improvement since now we can rely on getting covenant random IO performance. This also helps in fighting counterfeit flash memory products since even if fraudsters in the meantime produce fake SD cards that look real and show same capacity usually these fakes suck at random IO performance. So after testing new cards with either F3 or H2testw it's now another iozone or CrystalDiskMark test to check for overall performance including random IO (!) and if performance sucks you simply return the cards asking for a refund. TL;DR: If you buy new SD cards choose those carrying an A1 or A2 logo. Buy only good brands (their names start with either S or T). Don't trust in getting genuine products but always expect counterfeit stuff. That's why you should only buy at sellers with a 'no questions asked' return/refund policy and why you have to immediately check your cards directly after purchase. If you also care about reliability/resilience buy more expensive cards (e.g. the twice as expensive Extreme Plus A1 instead of Ultra A1) and choose larger capacities than needed.
     
    Finally: All detailed SD card test results can be found here: https://pastebin.com/2wxPWcWr As a comparison performance numbers made with same ODROID N1, same settings but vendor's orange eMMC modules based on Samsung eMMC and varying only in size: https://pastebin.com/ePUCXyg6
  4. tkaiser liked a post in a topic by TonyMac32 in Stability problem Tinker Board   
    Sorry, at the day job, now on lunch.  
     
    I never used the Tinker Board kernel, so the DVFS settings were always patched in using the Tinker and Rockchip references.  I will verify the settings 
     
    As far as power, there is no debate.  The 1.8 A is the minimum spec for current capability, I have information that says these are tested far beyond that, but again, multiple mate/unmate cycles would reduce that.  So, having dozens implemented with excellent supplies and top quality cables only plugged in a handful of times is not representative of a realistic situation for most users.  I applaud the quality of the deployment in this case, but consider it anecdotal evidence at best that Ohm and Kirchoff can be safely ignored.
     
     
    This is independent of Tinker.  While it's not uncommon to see in the field, "USB" and "industrial" are a bad combination.
  5. NicoD liked a post in a topic by tkaiser in Stability problem Tinker Board   
     
    Quite possible that different DVFS settings are used. IIRC @TonyMac32 switched with kernel/settings from Tinker sources to upstream Rockchip BSP a while ago. The individual DVFS OPP should be accessible from userspace (sysfs -- but don't know details. I skipped RK3288 entirely so far)
  6. TonyMac32 liked a post in a topic by tkaiser in Rock64 omv samba speed   
    Use /sbin/mount_cifs on your Linux box for SMB shares. If you mount them via GUI performance will be crappy (one of the many reasons why I hate 'Desktop Linux')
  7. lanefu liked a post in a topic by tkaiser in Espressobin support development efforts   
    https://www.cnx-software.com/2018/03/27/turris-mox-is-a-modular-router-with-wifi-ssd-lte-modem-ethernet-and-sfp-fiber-modules-crowdfunding/#comment-552639
  8. guidol liked a post in a topic by tkaiser in Distro-Download - Difference default, next   
     
    OMV is based on Debian. That's the simple reason it won't install on Ubuntu (dependency hell, different package versions). And if someone wants to run OMV I strongly recommend to check first whether there are available images at the download page or otherwise choose an Armbian Stretch next variant and then use armbian-config to install OMV.
     
    Even if someone interested in NAS does not want to rely on OMV/Debian looking into the various performance tweaks we did is worth the efforts: https://forum.armbian.com/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/?do=findComment&comment=44097
     
     
    And for any NAS usage next kernel is strongly recommended since better hardware support (especially UAS support for USB storage).
  9. guidol liked a post in a topic by tkaiser in Distro-Download - Difference default, next   
     
    OMV is based on Debian. That's the simple reason it won't install on Ubuntu (dependency hell, different package versions). And if someone wants to run OMV I strongly recommend to check first whether there are available images at the download page or otherwise choose an Armbian Stretch next variant and then use armbian-config to install OMV.
     
    Even if someone interested in NAS does not want to rely on OMV/Debian looking into the various performance tweaks we did is worth the efforts: https://forum.armbian.com/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/?do=findComment&comment=44097
     
     
    And for any NAS usage next kernel is strongly recommended since better hardware support (especially UAS support for USB storage).
  10. DiscoStewDeluxe liked a post in a topic by tkaiser in Armbian SD card backup   
    Well, I wrote the instructions above for a reason. When you don't provide the 'bs=' parameter then dd will use its defaults (1 block == 512 bytes) which slows down the cloning process like hell:
    bs=n Set both input and output block size to n bytes, superseding the ibs and obs operands. If no conversion values other than noerror, notrunc or sync are specified, then each input block is copied to the output as a single block without any aggregation of short blocks. Also it's somewhat weird to not compress the image on the fly. So now just as a reference and as preparation for a hopefully improved Armbian documentation soon.
     
    One way to do an offline clone from an Armbian installation with minimum size requirements would be to fill out all the unused space with zeros before (this really helps with compression afterwards if a lot of filesystem activity happened on the SD card before!) and then use a more efficient packer. So given the SD card is /dev/sdd you would do
    mkdir /mnt/clone mount /dev/sdd1 /mnt/clone dd if=/dev/zero of=/mnt/clone/empty.file bs=10M || rm /mnt/clone/empty.file umount /mnt/clone && rmdir /mnt/clone dd if=/dev/sdd bs=10M | gzip -c >/path/to/gzipped.img.gz dd if=/dev/sdd bs=10M | 7zr a -bd -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on -si /path/to/7zipped.img.7z I did this with a quite normal Armbian desktop image on an 8 GB SD card that looks like this
    /dev/sdd1 7,3G 2,1G 5,2G 29% /mnt/clone Instead of an uncompressed image that is 7.3GB in size the zeroed out 7z is 1.2GB in size and the gzip variant 1.7GB (please note that you could add '-9' then gzip would compress a little bit better).
     
    But here comes a more intelligent approach: Only outlined as a stub since others should do the job and try to earn a REWARD for this:
     
    When there's already a PC running Linux with a somewhat recent kernel where we can insert the SD card to create an offline clone then to combine the best of two worlds would be:
    Create a btrfs filesystem using maximum compression (compress=zlib) Configure keyless SSH authentication between your Linux host and the Armbian installation on the SBC to be able to run rsync later to copy filesystem's contents from the SBC to your Linux host Shut down your SBC, insert the SD card with the Armbian image into the PC, zero the unused space out and create an uncompressed dd image (the image will not be compressed internally since the filesystem does this job. So based on the aforementioned example the image we will create will show as being 7.3GB large but will only need approx. 1.3GB on disk since btrfs provides transparent file compression) Eject the SD card and start your SBC again Now setup a script on the Linux host that uses the btrfs command, losetup and rsync to
    create a snapshot of the btrfs filesystem where the uncompressed image is hosted mount the 1st partition of this image use rsync to incrementally update the OS image on your Linux host with the contents of / on the SBC (/dev/mmcblk0p1) through the network set up a cron job that does this automagically This way a whole bootable OS image only using the minimum amount of needed space will be stored on the Linux host and incrementally be updated. Since btrfs allows for transparent file compression and supports snapshots in case 100 MB have changed between two rsync runs (and given this data is compressable by 1:2) the whole storage requirements to store the new OS image variant will only be 50MB more. Yes, you have two independant OS images using this snapshot and compression technique that require not 8GB + 8 GB but just 1.3GB + 50MB.
     
    If such a script has been set up then we're starting to talk about backup and not stupid cloning any more. Since then we're talking about
    periodically saving the filesystem's contents to a different location implementing versioning (old/deleted/changed stuff remains on the Linux host in the form of older snapshots) allowing also for desaster recovery (since we created a bootable OS image in the first place) And the best news: The first step does also work through the network so in case we want to backup an internal eMMC then we boot the SBC with an SD card and transfer the dd image through the network to the Linux host. Also if you want to save a fleet of Armbian installations then simply also activate deduplication in btrfs and you'll end up with disk storage of below 2 GB to store eg. 8 Armbian desktop installation all being +2 GB in size
     
    Now it's time for someone to write this up as a nice tutorial and start to code this armbian-clone script. And please remember: If you do start contributing to community efforts there's something you'll get in return: http://forum.armbian.com/index.php/topic/1325-claim-a-task-and-do-it/
  11. MickMake liked a post in a topic by tkaiser in The mmBoard   
    Thank you for providing dev samples already weeks ago. We've been working 24/7 to support this awesome board from day one!
  12. MickMake liked a post in a topic by tkaiser in The mmBoard   
    Thank you for providing dev samples already weeks ago. We've been working 24/7 to support this awesome board from day one!
  13. tkaiser liked a post in a topic by MickMake in The mmBoard   
    Hi guys!
    Thought I'd let you know about a new board that I've just released - called the mmBoard.
    Has all the features that SBC hackers have been wanting, plus more.
     
    https://www.mickmake.com/post/announcing-the-mmboard-a-mickmake-sbc-with-all-the-goodies
     
    Let me know if there's any questions about it. Would be happy to answer them.
     


  14. manuti liked a post in a topic by tkaiser in Support of Raspberry Pi   
    Just for the record: This (using the OMV RPi image and removing the OMV parts) will not result in an Armbian installation (I'm aware that you've written about 'Armbian a like', just want to further clarify). It's just a Debian Jessie armhf rootfs generated by Armbian's build system that has been slightly adjusted and manually combined with RPi Foundation's kernel packages and the proprietary, closed sourced RPi stuff (ThreadX on the /boot partition and some proprietary userspace binaries to interact with VideoCore/ThreadX, most importantly to report/detect under-voltage).
     
    Armbian is about:
    bootloader and kernel optimizations (first not possible since closed source ThreadX, latter not reasonable/needed on Raspberries) optimized settings to improve performance, consumption and thermal behaviour (not possible on RPi since done entirely on the VideoCore by ThreadX) to improve security situation building an entire OS image from scratch so no one has fiddled around so far (if you use our build system and let it debootstrap a fresh Armbian image you know no one logged in so far and planted backdoors or stuff like that) So the OMV image is just a modified piece of data that was falling out of Armbian's build system (the rootfs) manually adjusted to be combined with the proprietary and closed source stuff that still makes up the whole 'RPi experience' (for the majority of RPi users I personally know the Pi is just a KODI and retrogaming box and without the proprietary video decoding and 3D acceleration stuff on the VideoCore they would have to throw it away)
     
    So all you get by using this OMV image is the illusion wrt 3) above (clean rootfs) but thinking this would enhance security or prevent you from being backdoored is just... an illusion. The main CPU of every RPi is still the outdated VideoCore from 2009 (this chip contains not only GPU, VPU and multiple QPU cores but also an ordinary dual core CPU inside running the closed source RTOS called ThreadX). The ARM cores running any secondary OS are just guests. Since Raspberries are popular for stuff like Tor end nodes or VPN gateways who knows whether GCHQ already ordered the Foundation to ship their ThreadX with an universal backdoor to allow agency access?)
     
    Anyway: maybe the OMV image's only real advantage is that it's Jessie based but still gets RPi Foundation's kernel updates (we do this via apt pinning since for whatever reasons someone at the Pi Foundation decided last year to cut off all their Jessie users from future kernel updates, weakening the security of all these installations). But if you're not running OMV (where OMV releases are bound to the underlying Debian release -- OMV 3 needs Jessie and OMV 4 simply wasn't ready last year) then why not using Stretch anyway? Raspbian isn't bad, it's just somewhat bloated.
     
    As usual the 2 most important things you can do to improve general RPi performance/responsiveness is
    Checking whether your powering is sufficient, you need to call perl -e "printf \"%19b\n\", $(vcgencmd get_throttled | -f2 -d=)" and have a look at the left whether there is a '1' (explanation). If you see there a 1 you're running 'frequency capped' at 600 MHz when performance would be needed. You must call vcgencmd since the usual ways to query CPU clockspeed are all fake (don't tell it over at the RPi forum -- for this you will get censored and banned  ) Throwing away your old and slow SD card and start with a new, genuine and A1 rated SD card of at least 16 GB in size (I would go with an A1 Extreme and not an A1 Ultra for the simple reason that most probably RPi folks with their next 'incremental Pi update' next year will finally implement SDR104 to speed up SD card access. This and better Wi-Fi is almost all they've left to once again sell their fanboys an 'improvement') Please note that both 'performance tweaks' are hardware and not software fixes.
  15. tkaiser liked a post in a topic by Xalius in RPi.GPIO port for Rock64 (R64.GPIO)   
    Leapo has started porting RPi.GPIO to Rock64 as R64.GPIO, you can find her work in progress at
     
    https://github.com/Leapo/Rock64-R64.GPIO
     
    Original thread with instructions/updates is here:
     
    https://forum.pine64.org/showthread.php?tid=5902
     
    She also made a more simple tool to work with GPIO:
     
    https://github.com/Leapo/Rock64-BashGPIO
  16. manuti liked a post in a topic by tkaiser in Armbian for OrangePi PC2, AllWinner H5   
     
    Which 'outsourcing'? Allwinner sells hardware. Cheap hardware for special markets. Android tablets back then, $something in between, now smart speakers, dashcams, retro gaming stuff, again tablets and TV boxes. Nintendo's NES Classic sold 2.3 million units in no time. Using a boring A33 SoC with technology from 5 years ago running a smelly 3.4.39 kernel from 5 years ago. Their customers (that's not us) do not care so why should Allwinner care so far?
     
    They enable device manufacturers to throw out cheap hardware with somewhat working software with ok-ish margins (their main market) or sometimes enable their customers like Nintendo to sell insanely overpriced/overhyped products where again no-one cares about kernel, software or anything else we would be interested in.
     
    For Allwinner there's still no 'Linux market'. Though things might change in the future. But unless there's an incentive to mainline their own hardware and submit code upstream (good luck given the BSP code quality) I doubt anything will change soon or at all. But of course I highly appreciate that they now contribute and react in a very responsive way. As @jernej pointed out in the meantime many requests will be answered positively (and I always chuckle seeing wink, the Allwinner guy, directly contributing to linux-sunxi wiki now -- I never thought this would happen)
  17. Slackstick liked a post in a topic by tkaiser in Support of Raspberry Pi   
     
    No. It's uninteresting for these reasons:
     
    RPi is a closed source platform, the main operating system bringing up and fully controlling the hardware (ThreadX running on the dual core VideoCore IV main CPU) can not be altered since... closed source and proprietary. All the relevant stuff happens completely there (DVFS for the ARM CPU cores, video decoding and so on) and the secondary OS running on the ARM cores has not even an idea what's going on (see for example all those RPi installations that constantly suffer from 'frequency capping'). All we as Armbians could do is to fiddle around with a secondary OS running on the 'guest' ARM CPU cores while everything interesting happens solely on the proprietary and closed source VideoCore. The community driven tries to replace ThreadX with something open sourced have stopped since the developers involved lost interest (some details)
     
    The new board is a power hog able to consume close to 1800mA by running some CPU intensive stuff alone (see at the bottom of this nice review). In the past due to poorly-designed power circuitry an RPi 3 was not able to exceed ~1.5A anyway (voltage drops then occured and under-voltage 'protection' kicked in). Now this has improved but unfortunately the Pi is still equipped with a Micro USB port to be powered (rated for 1800mA maximum!) so even more users will run into underpowering hassles.
     
    Headless RPi users are usually not even aware that they run under-volted (example, example, example, example) and if even under-voltage 'protection' (frequency capping turning the RPi into a 600 MHz board) doesn't help crashes, freezes, kernel panics occur that are usually considered 'software issues' (example). I believe the RPi people are well aware that powering with Micro USB is a shitty idea. But they do a great job masquerading the problem and try really hard to keep their users clueless (see this funny 'Micro USB powering' thread and how it ended -- archived version here, they love to censor over in their forum).
     
    TL;DR: it's not fun but simply boring to bring Armbian to the RPi and support situation for both users and us here will be a nightmare (users expecting everything Raspbian compatible while we would have to deal with the results of crappy Micro USB powering being reported as software bugs and users miseducated by RPi people not able to realize that under-voltage is the problem and their '3A PSU' won't help here anyway. RPi folks really try hard to let their users focus on BS amperage ratings instead of explaining the real problem.
     
    BTW: I know a bit what I'm talking about since having maintained an OS image for RPi 2, 3 and 3+ that gets downloaded +10,000 times each month.
  18. Tido liked a post in a topic by tkaiser in Pi-factor cases   
    Since we already trashed the whole thread with all this thermal babbling... Pi 3 B+ without heatspreader: https://youtu.be/4LtL9e7JqxE?t=3m10s
     
  19. joaofl liked a post in a topic by tkaiser in Android on H6 Boards   
     
    Replacing the .dtb file contents with the one for PineH64 works somewhat (at least the kernel uses the updated .dtb -- see the gmac-power0, gmac-power1 and gmac-power2 entries in serial console output). But then with the Xunlong image PineH64 panics: https://pastebin.com/h9G1kRQx
     
    Same modified image boots on an OPi Lite2 but... this Allwinner BSP crap is that horrible that it's really not worth a look (at least for the stuff I'm interested in). UAS is not supported, quick USB3 storage 'performance' test results in 40/45 MB/s read/write with an EVO840 SSD, no drivers included for any of the popular USB Ethernet dongles. I had the idea to do some tests with the BSP to get some baseline numbers but in this state this is all just a waste of time...
  20. manuti liked a post in a topic by tkaiser in Armbian for OrangePi PC2, AllWinner H5   
     
    Which 'outsourcing'? Allwinner sells hardware. Cheap hardware for special markets. Android tablets back then, $something in between, now smart speakers, dashcams, retro gaming stuff, again tablets and TV boxes. Nintendo's NES Classic sold 2.3 million units in no time. Using a boring A33 SoC with technology from 5 years ago running a smelly 3.4.39 kernel from 5 years ago. Their customers (that's not us) do not care so why should Allwinner care so far?
     
    They enable device manufacturers to throw out cheap hardware with somewhat working software with ok-ish margins (their main market) or sometimes enable their customers like Nintendo to sell insanely overpriced/overhyped products where again no-one cares about kernel, software or anything else we would be interested in.
     
    For Allwinner there's still no 'Linux market'. Though things might change in the future. But unless there's an incentive to mainline their own hardware and submit code upstream (good luck given the BSP code quality) I doubt anything will change soon or at all. But of course I highly appreciate that they now contribute and react in a very responsive way. As @jernej pointed out in the meantime many requests will be answered positively (and I always chuckle seeing wink, the Allwinner guy, directly contributing to linux-sunxi wiki now -- I never thought this would happen)
  21. manuti liked a post in a topic by tkaiser in Pi-factor cases   
     
    Sure, this is how it should work. Great that now even the RPi folks got it
     
    Yesterday I 'unboxed' Orange Pi Lite 2 (Allwinne H6). As small as the H3 Lite but extra thick PCB. After 10 minutes of idle operation the whole PCB including all receptacles is warm so the groundplane efficiently spreads the heat away from the SoC. I put 3 low performing heatsinks on SoC, PMIC and DRAM and reported SoC temperature went down from 49°C in idle to 46°C (after waiting the same 10 minutes or until temperature is stable).
     
    So still curious how efficient a 2mm thermal pad between PCB lower side and an aluminium enclosure would work (to transport heat out of an enclosure). To be clear: I'm talking about something like this (and am not willing to spend my own time on such tests any more since done with the low consumption/thermal stuff)
     
    Testing such stuff with enclosures that already exist seems impossible. The FLIRC is constructed wrongly and to buy the Wicked you must be mad.
  22. manuti liked a post in a topic by tkaiser in Pi-factor cases   
     
    Sure. Better results compared to the board lying flat on a pillow
     
    Since latest RPi 3+ from last week now also started to copy what those cheap Orange Pi do since years (using the PCB ground plane as massive heatsink) I suggested this test over at RPi forum: https://archive.fo/6kzg0 ... and (not so) surprisingly the post got censored: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=207863&start=225#p1286503 -- they really don't like it over there their users could get the idea that there grows more than Raspberries on this earth 
     
    BTW: really impressive how inefficient the old RPi 3 was and is from a thermal point of view:

     
    vs.

  23. TonyMac32 liked a post in a topic by tkaiser in Pi-factor cases   
     
    But since it's so inefficient (again: https://youtu.be/mBSfb6vlfKo?t=6m37s ) at least it will fit on the new RPi 3 B+. The FLIRC ruins the thermal efficiency of the enclosure material with a huge gap between chips and enclosure filled with thick thermal pads. Since the BCM2387B0 on the new Raspi is higher they'll start to put two thermal pads to the package soon. The old thick and inefficient one for BCM2387 (overheating SoC needing good heat transfer) and a much thinner one for the new board that doesn't need a heatsink anyway. Well done or... it's just a typical 'Rasperry Pi product'. Eye candy and a good feeling and real result inefficient.
     
  24. manuti liked a post in a topic by tkaiser in Some storage benchmarks on SBCs   
    Early 2018 update
     
    Time for another small update. It's 2018 now and since it seems Armbian will support a couple of RK3399 devices later this year let's have a closer look at the storage performance of them.
     
    RK3399 provides 2 individual USB3 ports which seem to share a bandwidth limitation (you get with a fast SSD close to 400MB/s on each USB3 port but with two SSDs accessed in parallel total bandwidth won't exceed 400MB/s). RK3399 also features a PCIe 2.1 implemenation with 4 lanes that should operate at Gen2 link speeds (that's 5GT/s so in total we would talk about 20GT/s if the SoC is able to cope with this high bandwidth). Rockchip changed their latest RK3399 TRM (technical reference manual) last year and downgraded specs from Gen2 to Gen1 (2.5GT/s or 10GT/s with 4 lanes). So there was some doubt whether there's an internal overall bandwidth limitation or something like that (see speculation and links here).
     
    Fortunately a Theobroma engineer did a test recently using Theobroma System's RK3399-Q7 with a pretty fast Samsung EVO 960 NVMe SSD: https://irclog.whitequark.org/linux-rockchip/2018-03-14 -- it seems RK3399 is able to deal with storage access at up to 1.6GB/s (yes, GB/s and not MB/s). This is not only important if you want ultra fast NVMe storage (directly attached via PCIe and using a way more modern and efficient protocol like ancient AHCI used by SATA) but also if RK3399 device vendors want to put PCIe attached SATA controllers on their boards. ODROID guys chose to go with an ASM1061 (single lane) on their upcoming N1 since they feared switching to a x2 (dual lane) chip would only increase costs while providing no benefits. But Theobroma's test results are an indication that even x4 attached controllers using all PCIe lanes could make reasonable use of the full PCIe bandwidth of 20GT/s.
     
    Below we'll now have a look at USB3/UAS performance and PCIe attached SATA using ASM1061 (both done on an ODROID N1 developer sample some weeks ago). Those tests still use my usual EVO840 SATA SSD so results are comparable. You see two ASM1061 numbers since one is made with active PCIe link state powermanagement and the other without (more or less only affecting access patterns with small block sizes).
     
    Then of course beeble's NVMe SSD tests are listed (here fio and there iozone -- numbers should also be valid for the other RK3399 devices where you can access all 4 PCIe lanes via M.2 key M or a normal PCIe slot: Rock960, NanoPC-T4 or RockPro64 (M.2 adapter needed then of course). And maybe later I'll add SATA and USB3 results from EspressoBin with latest bootloader/kernel.
     
    (for an explanation which boards represent which SoC and why please see my last post above)
    Random IO in IOPS Sequential IO in MB/sec 4K read/write 1M read/write RPi 2 under-volted 2033/2009 29 / 29 RPi 2 2525/2667 30 / 30 Pine64 (USB2/UAS) 2836/2913 42 / 41 Banana Pi Pro (SATA) 3943/3478 122 / 37 Wandboard Quad (SATA) 4141/5073 100 / 100 ODROID-XU4 (USB3/UAS) 4637/5126 262 / 282 ROCK64 (USB3/UAS) 4619/5972 311 / 297 Clearfog Pro (SATA) 10148/19184 507 / 448 RK3399 (USB3/UAS) 5994/6308 330 / 340 ASM1061 powersave 6010/7900 320 / 325 ASM1061 performance 9820/16230 330 / 330 RK3399-Q7 (NVMe) 11640/36900 1070 / 1150 As we can see RK3399 USB3 performance slightly improved compared to RK3328 (Rock64). It should also be obvious that 'USB SATA' as in this case using USB3/SuperSpeed combined with a great UAS capable USB-to-SATA bridge (JMicron JMS567 or JMS578, ASMedia ASM1153 or ASM1351) is not really that worse compared to either PCIe attached SATA or 'native SATA'. If it's about sequential performance then USB3 even outperforms PCIe attached SATA slightly. The 2 USB3 ports RK3399 provides when combined with great UAS capable bridges are really worth a look to attach storage to.
     
    NVMe obviously outperforms all SATA variants. And while combining an ultra fast and somewhat expensive NVMe SSD with a dev board is usually nothing that happens in the wild at least it's important to know how the limitations look like. As we've seen from the RK3399-Q7 tests with fio and larger blocksizes we get close to 1600 MB/s at the application layer which is kinda impressive for devices of this type. Another interesting thing is how NVMe helps with keeping performance up: This is /proc/interrupts after an iozone run bound to the 2 big cores (taskset -c 4-5): https://gist.github.com/kgoger/768e987eca09fdb9c02a85819e704122 -- the IRQ processing happens on the same cores automagically, no more IRQ affinity issues with all interrupts ending up on cpu0  
     
    Edit 1: Replaced Pine64 numbers made with EVO750 from last year with fresh ones done with a more recent mainline kernel and my usual EVO840
     
    Edit 2: Added Rasperry Pi 2 results from here.
     
  25. tkaiser liked a post in a topic by joaofl in Android on H6 Boards   
    @tkaiser I'll upload it and drop you the link asap