manuti reacted to LycanthroLabs in OPI LITE wireless device not working
What an amazing team! Thank all of you so much for all the work... I did a fresh install on one of my OPi Lites and wireless is up and running in no time - and it works pretty damn good, much better than a RPi3 sitting in the exact same spot on my bench!
manuti reacted to aegrotatio in Orange Pi One - adding USB, analog audio out, TV out, mic and IR receiver
Well, your work is wonderful, and I really think you're doing a great job. I think there's similar attitude problems at Banana Pi communities.
I want you to continue supporting Orange Pi H3 boards, for sure. They are the most powerful working implementation I have found so far.
manuti reacted to tkaiser in Orange Pi One - adding USB, analog audio out, TV out, mic and IR receiver
Wow! Guess who made the original picture: http://linux-sunxi.org/File:Orange_Pi_One_Top.jpg#filehistory
Someone sent me two pictures from Orange Pi forums (which I've not visited since 5 months), I combined those two images in Photoshop so that the image alone should be significant enough to get the idea and forgot to mention "@GUTEK@ the greatest artist on planet" since I didn't even know that the great @GUTEK@ was responsible for creating this masterpiece of art (combining a screenshot from schematic with someone else's photo). I truly apologyze for my mistake. Will correct that immediately!
OMFG! It was such a mistake starting to support Orange Pi H3 boards.
manuti reacted to lanefu in OPI ONE wireless success
I had to blacklist the standard realtek module in order to get things to behave with the patched one that comes with the distro
lane@orangepione-2:~$ cat /etc/modprobe.d/wifi-blacklist.conf blacklist rtl8192cu Prior to blacklisting, it would just crash and reboot as soon as the wifi module loaded.
This was using one of the little rt8192 dongles from adafruit running an armbian image I built from the repo yesterday.
manuti reacted to rodolfo in Torrent client & mount point changes
Welcome on board.
USB-dongles are usually auto-mounted on a newly created mount point in /media. This is how you force it to be mounted at a predefined
1. Create a new mount point for your USB-dongle
sudo mkdir /mnt/mydrive
2. Plug in your USB-drive and check the partition name ( e.g. /dev/sda1 ) Your drive is most likely formatted as vfat.
/dev/mmcblk0p1: UUID="56a9eae3-fd35-47d4-a01c-00251c2d6a8d" TYPE="ext4" PARTUUID="00003286-01"
/dev/mmcblk0: PTUUID="00003286" PTTYPE="dos"
/dev/sda1: UUID="4732-9959" TYPE="vfat"
3. Use the unique identifier (UUID) of the filesystem on your USB-drive and add an entry to your /etc/fstab
sudo nano /etc/fstab
#----sample fstab-entry to mount specific USB-drive
# the unique identifier UUID can be queried with
UUID="4732-9959" /mnt/mydrive vfat defaults,noatime 0 2
4. When you reboot, the USB-drive will be automatically mounted at /mnt/mydrive. Adjust permissions if needed.
manuti reacted to RagnerBG in Orange Pi One's Second Booting Failed
There is a huge overscan on this boards and your login screen is hidden bellow. Just enter default login and pass and change resolution later, or adjust screen position with your monitor controls. If you use Desktop version of image, it will boot after you change your root pass, create new account and reboot. I was confused too at the beginning, but there is nothing wrong with the OS.
manuti reacted to tkaiser in Breaking News: Choosing Armbian speeds up your Orange Pi multiple times!
It's important to believe blindly in numbers! At least when you try to be mislead as much as possible!
Yesterday Michael Larabel from Phoronix fired up his usual set of passive benchmarking tests for the new Raspberry Pi 3 and he still uses rather questionable results for other boards to compare with (he claims that it would be sufficient to use a board with 'factory settings', run a set of synthetic benchmarks, don't analyse the results or even think about whether they could be wrong and treat the results as the truth)
RPi 3 is 4 times faster than OPi PC and 6 times faster than OPi Plus? Really?
If you just try to think about these graphs for a second it's obvious that there must be something wrong: Testing Orange Pi PC and Plus individually already makes no sense at all (same SoC, same settings --> same performance results to be expected) and publishing results that vary that much is alarming: either your benchmark must be wrong or the conditions or the tester. If you just think a second it's obvious that Orange Pi PC and Plus have to be faster than Banana Pi M2 (also an Allwinner ARMv7 SoC clocked a bit slower) and that you should drop any results if you experience a difference of more than 10% between both boards that must perform identical.
So I took our Armbian 5.05 release candidate and tested 2 of Phoronix' benchmarks on an H3 based Orange Pi (and then stopped this waste of time):
C-Ray: 340 with Armbian vs. 1425 according to Phoronix. Using Armbian increased the performance by over 400% (if you're dumb enough to rely on 'benchmarking gone wrong')
John the Ripper: 558 with Armbian vs. 315 according to Phoronix. Using Armbian increased the performance by 77% (if you're dumb enough to rely on 'benchmarking gone wrong')
Confusing! Why is Armbian way faster?! And why does choosing Armbian speeds up your Orange Pi in one case over 4 times and in the other case just by 77%? Let's have a closer look:
How does Armbian differ:
We are able to use 1.3GHz as CPU clockspeed (might speed things up) For reliability reasons we clock the DRAM lower (might slow things down) Most importantly: We don't use braindead thermal throttling settings (and I used a heatsink/fan) And the latter is the most important issue that Michael Larabel seems to miss at all when he uses the 'benchmark' results he collected sometimes ago to compare between different hardware. It's 2016 now! Each and every more recent SoC is a throttling candidate. This has to be taken into account if you want to benchmark a SoC or a board. If you ignore this your results are plain bullshit (just like Michael's).
When he tried to 'benchmark' Orange Pi PC and Plus he obviously ran into the problem that the vendor's budget cooling settings favoured killing CPU cores instead of thermal throttling so he obviously ended up with just one active CPU core left after some time of testing. And while this was an important finding (OS images for Orange Pis all crap more or less back then and negatively influencing performance) it's also important that this is nothing the hardware has to be blamed for.
The very same board running with Armbian performs more than four times faster! Think about. So obviously the benchmarks Phoronix recommends do not test the hardware but something else instead.
To be clear: the Phoronix test suite is fantastic when used correctly. That means ACTIVE BENCHMARKING and not collecting meaningless numbers and then relying on these worthless numbers to draw the wrong conclusions. When using the Phoronix test suite correctly you can identify performance bottlenecks and boundary conditions that affect performance easily (wrong cpufreq governor, killed CPU cores, thermal throttling, wrong settings, whatever). And also what to do to increase performance (tweaking compiler/scheduler settings, constantly trying out to optimise things until it works better).
The worst thing you could do with the Phoronix test suite is to collect numbers without meaning (passive benchmarking) and then use them to draw the wrong conclusions (that's what most of Phoronix' users including the author of the test suite do all the times).
Back to the origin again: We started with the Raspberry Pi 3 and 'benchmarking gone wrong' the Phoronix way. You really should take the numbers Michael/Phoronix published with a grain of salt since he neither mentioned whether throttling happened nor he commented on the consequences for the RPi 3 if the RPi foundation understands that it's necessary to provide a Raspbian version that is ARMv8 optimised.
The RPi foundation claimed the new RPi 3 would outperform the RPi 2 by 50% using questionable sysbench results. If they would've optimised their Raspbian code base for ARMv8 they could claim the RPi 3 would be at least 15 times faster. Why? Because benchmarks are always wrong and using sysbench (that calculates prime numbers) can't be used any more to compare between different ARM architectures (or architectures in general): http://forum.odroid.com/viewtopic.php?f=136&t=19158(I'm really curious whether Phoronix gets that when 'benchmarking' ODROID C2)
TL;DR: Benchmarking is fine as long as you use it to optimise software and to rule out insufficient hardware. When used wrong it's misleading (unfortunately that happens most of the time)
manuti reacted to rodolfo in Breaking News: Choosing Armbian speeds up your Orange Pi multiple times!
Yes - that is exactly what I mean. Real people doing real stuff for real. RK was progressing nicely and then unfortunately stumbled over their own greed. Actually, I would prefer a stripped OrangePi (ONE/LITE without LAN, WIFI, OTG) with 3xUSB2 and solder pads for the rest, power-optimized with a LiIon-battery-circuit for < $10. The next interesting board would be ARM64-based, exposing USB3 and featuring HW-accelerated graphics for <$20. LAN/WIFI/SATA are no problem with properly exposed USB at highspeed/superspeed, avoiding crappy components on the boards.
manuti got a reaction from rodolfo in Breaking News: Choosing Armbian speeds up your Orange Pi multiple times!
Maybe my UG802 (RK3066 dual core) with Picuntu running several days a week as torrent downloader since 2012 and update from Ubuntu 12.10 to 14.04 and I hope in next months go to 16.04 is a good example of benchmark. And also chinese people lost an opportunity to have a PiZero killer 4 years ago.
manuti reacted to tkaiser in Breaking News: Choosing Armbian speeds up your Orange Pi multiple times!
Nice try but still insufficient.
Using passive benchmarking is only great if you want to collect meaningless numbers. When you use those tests for active benchmarking purposes then it will be way more time consuming and the one thing you will do most often will be... throwing results away since they're completely irrelevant.
Regarding 'sysbench --cpu' and trying to compare ARMv7 and ARMv8 (applies to RPi 3 also if RPi foundation will sometimes in the future switch Raspbian's codebase to ARMv8) everything is outlined here already: http://forum.odroid.com/viewtopic.php?f=136&t=19158#p127223
Running sysbench storage tests on an SD card... c'mon what are yout trying to achieve? Producing numbers without meaning or just the insight that if you want to run anything storage intensive then you should avoid using SD cards at all (using eMMC when available or moving both rootfs and database storage location to USB or SATA where available).
This is the only lesson you can learn from any storage bench when used on SBCs! And what do people do instead? Create graphs that are based on meaningless numbers.
Please don't get me wrong. Synthetic benchmarks can be very useful. A storage benchmark that is done correctly might provide the insight that on an Orange Pi Plus (eMMC and an ultra slow USB-to-SATA bridge onboard) it's braindead to move the rootfs to USB (some people still call it SATA for reasons unknown to me) but instead use the eMMC since it's faster. But measuring SD card speeds on an Orange Pi Plus is just a waste of time.
manuti got a reaction from Igor in Authentication token manipulation error on Banana Pro jessie 4.0.4
Thanks a lot Igor.
With Bananapi Debian 3.1 jessie 4.0.5. on a Banana PRO
first run OK intrnal Wi-Fi - OK after copy in /boot/dtb/ the file sun7..bananapro.dtb over sun7...bananapi.dtb and reboot thanks