Jump to content

tkaiser

Members
  • Posts

    5462
  • Joined

Reputation Activity

  1. Like
    tkaiser reacted to jernej in OPI LITE wireless device not working   
    You can't. Driver has some generic code but chip dependant code is only for 8189fs. AFAIK, 8189es driver, which you added today, is the latest one.
  2. Like
    tkaiser reacted to Igor in OPI ONE wireless success   
    Wifi is fixed on all H3 boards. I will push new update later in the evening where 8189fs and 8189es are updated. I made brief testing and AP mode also works on both chips.
  3. Like
    tkaiser reacted to lanefu in Orange Pi Plus 2E now available   
    sure ill take a look this evening. i was just using ttl serial.console last time. ill hook it up.to a monitor this time
     
    Sent from my SM-G920V using Tapatalk
  4. Like
    tkaiser reacted to rodolfo in OPI LITE wireless device not working   
    @tkaiser, @igor, @jernej
     
     
    AP (master) mode and monitor mode both work
     
    Working tested AP mode
     
    sudo nano /etc/default/hostapd
    --------------------------------
    DAEMON_CONF="/etc/hostapd.conf"
    --------------------------------
     
    sudo nano /etc/hostapd.conf
    -------------------------------------------------------
    ssid=xx_opilite1_xx
    interface=wlan0
    hw_mode=g
    channel=5
    driver=nl80211
    logger_syslog=0
    logger_syslog_level=0
    wmm_enabled=1
    ieee80211n=1
    wpa=3
    preamble=1
    #wpa_psk=66eb31d2b48d19ba216f2e50c6831ee11be98e2fa3a8075e30b866f4a5ccda27
    wpa_passphrase='12345678'
    wpa_key_mgmt=WPA-PSK
    wpa_pairwise=TKIP
    rsn_pairwise=CCMP
    auth_algs=1
    macaddr_acl=0
    noscan=1
    #ht_capab=[HT40-][sHORT-GI-40][sHORT-GI-40][DSSS_CCK-40]
    country_code=CH
    #ieee80211d=1
    --------------------------------
     
    sudo nano /etc/network/interfaces
    --------------------------------
    allow-hotplug wlan0
       iface wlan0 inet static
            address 192.168.4.171
            netmask 255.255.255.0
            network 192.168.4.0
    --------------------------------
     
     
    Testing monitor mode
     
    A new virtual interface needs to be created for monitor mode
     
    sudo iw phy phy0 interface add wlan1 type monitor
     
    sudo ifconfig wlan1 192.168.5.171
     
    sudo iwlist wlan1 scan
     
    ( ---> list of scanned SSIDs, just to show interface is up )
     
     
     
    enjoy
  5. Like
    tkaiser got a reaction from _r9 in Banana Pi M3   
    Overview
     
    (Disclaimer: The following is for techies only that like to dig a bit deeper. And if you're not interested in energy-efficient servers then probably this is just a waste of time  ) 
     
    EDIT: Half a year after this poorly designed SBC has been released just one of the many design flaws has been fixed: Micro USB for DC-IN has been replaced by the barrel jack that was present on the pre-production batches. If you were unfortunate to get a Micro USB equipped M3 please have a look here how to fix this. Apart from that check the Banana forums what to expect regarding software/support first since this is your only source)
     

     
    SinoVoip sent me a review sample of the recently shipped so called "Banana Pi M3" yesterday. It's a SBC sharing name and form factor of older "Banana Pi" models but is of course completely incompatible to them due to a different SoC, an A83T (octa-core Cortex-A7 combined with a PowerVR SGX544 GPU). For detailed and up-to-date informations please always refer to the linux-sunxi wiki.
     
    This new model distinguishes itself from the Banana Pi M2 with twice as much CPU cores and DRAM (LPDDR3), 8 GB eMMC onboard and BT4.0. And compared to the "M1" (the original Banana Pi) it features also 802.11 b/g/n Wi-Fi. Unlike the M2 the M3 is advertised as being SATA capable. But that's not true, it's just an onboard GL830 USB-to-SATA bridge responsible for horribly slow disk access. Unfortunately the GL830 and both externally available USB ports are behind an internal USB hub therefore all ports have to share bandwidth this way and use just one single USB connection to the SoC.
     
    Since my use cases for ARM boards are rather limited you won't find a single word about GPIO stuff (should work if pin mappings are defined correctly), GPU performance, BT, Wi-Fi or Android. Simply because I don't care 
     
    Getting Started:
     
    The board arrived without additional peripherals (no PSU) therefore you need an USB cable using a Micro-USB connector to power the board. Both DC-IN and USB-OTG feature an Micro-USB connector which is bad news since pre-production samples had a real DC-In connector (4.0mm/1.7mm barrel plug, centre positive like the M2). I suffered from several sudden shutdowns under slight load until I realized that I used a crappy cable. Many (most?) USB cables lead to voltage drops and when the board demands more power it gets in an undervoltage situation and the PMU shuts off.
     
    Same will happen to you unless you can verify that you've a good cable. I did not succeed querying the M3's powermanagement unit (PMU) regarding available voltage (/sys/devices/platform/axp81x_board/axp81x-supplyer.47/power_supply/ac/voltage_now shows always 0). This was a lot easier with the older Banana Pi M1: Here you can watch my cable being responsible for voltage drops under high load (I accidentally used this again with the M3).
     
    To avoid the crappy Micro-USB connector (limited to 1.8A maximum by specs and tiny contacts) you can desolder it and solder a cable or a barrel plug -- the PCB is already prepared for the latter. Or ask SinoVoip if they can fix this mistake with the next batch of PCBs. On the bottom side of the PCB there are also solder pads for a Li-Ion battery. It has to be confirmed whether the AXP813 PMU can also be fed with 5V through the Li-Ion connector since this is the preferred way to fix the faulty power design other SinoVoip products show.
     
    One final word regarding power: It seems currently something's wrong with power initialisation in the early boot stages (u-boot). With a connected bus-powered USB disk the board won't start or immediately shut down when the disk is connected within the first 10 seconds. I didn't verify when exactly because if you've a look at SinoVoip's commit log it seems they began to fix many obvious bugs just right now after they already started shipping the board (we've seen that with the M2 also).
     
    First Showstoppers:
     
    Since the board came with an unpopulated eMMC (why the heck?) I had to try out the available OS images from the banana-pi.org download site. Unlike everyone else on this planet they don't provide MD5/SHA1 checksums to be able to check integrity of downloads and even if you tell them that they've uploaded corrupted images they don't care. From 4 OS images 3 are corrupted (according to unzip) and all failed soon after boot with kernel panics. I tried the Android image to verify FEL mode works.
     
    But since Android is of zero use for me, I decided to build an own OS image from an Ubuntu distro running on the Orange Pi where I had the SD-card inserted. Since details are boring just as a reference. From then on I used this Ubuntu image and exchanged only the freshly built stuff from SinoVoip's BSP Github repo (3.4.39 kernel, modules, bootloader and also simple things like hardware initialisation since kernel/u-boot they prefer does NOT support script.bin)
     
    First Impressions:
     
    Heat (dissipation):
     
    The A83T needs a heatsink otherwise you won't be able to benefit from its performance. Allwinner's 3.4.39 kernel provides 'budget cooling' using 2 techniques: thermal throttling and shutting down CPU cores. You can define this 'thermal configuration' in sysconfig.fex and have to take care that you understand what you're doing since if throttling doesn't help your CPU cores will be deactivated and you have to can't bring them back online manually the usual way since Allwinner's kernel doesn't allow so:
    echo 1 >/sys/devices/system/cpu/cpuX/online Therefore it's better to stay with the thermal defaults to allow throttling and improve heat dissipation instead. I used a $0.5 heatsink that performs ok. Without heatsink when running CPU intensive jobs throttling limited clockspeed to 1.2 GHz but with the heatsink I was able to run most of the times at ~1.6Ghz under full load. With heatsink and an annoying fan I managed to let the SoC run constantly at 1.8GHz and achieved a 7-zip score close to 6000 and finished "sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=8" in less than 53 seconds.
     
    This is an example for wrong throttling values (too high) so that the kernel driver does not limit clockspeeds but starts to drop CPU cores instead:
     

     
    CPU performance:
     
    Since the H3 (used on the more recent Orange Pis) and the A83T seem to use much of the same kernel sources (especially the 'thermal stuff') I did a few short tests. When running with identical clockspeed and the same amount of cores they perform identical (that means they're slower than older Cortex-A7 SoCs like eg. the A20 when running at identical clockspeed -- a bit strange). Obviously the difference between H3 and A83T is the process. Both already made in 28nm but the A83T as 'tablet SoC' in the more energy efficient HPC process allowing less voltage and higher clockspeeds. According to sysconfig.fex the SoC should be able to clock above 2.1 GHz but since exceeding 1.6 Ghz already needs a fan this is pretty useless on a SBC (might be different inside a tablet where the back cover could be used as a large heatsink).
     
    Network throughput:
     
    I used my usual set of iperf testings and tried GBit Ethernet performance (with and without network tunables it remains the same -- reason below):
     
    BPi-M3 --> Client:
    [ 4] 0.0-10.0 sec 671 MBytes 563 Mbits/sec [ 4] 0.0-10.0 sec 673 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 870 MBytes 729 Mbits/sec [ 4] 0.0-10.0 sec 672 MBytes 564 Mbits/sec [ 4] 0.0-10.0 sec 675 MBytes 566 Mbits/sec Client --> BPi-M3: [ 4] 0.0-10.0 sec 714 MBytes 599 Mbits/sec [ 5] 0.0-10.0 sec 876 MBytes 734 Mbits/sec [ 4] 0.0-10.0 sec 598 MBytes 501 Mbits/sec [ 5] 0.0-10.0 sec 690 MBytes 578 Mbits/sec [ 4] 0.0-10.0 sec 604 MBytes 506 Mbits/sec When I used longer test periods (-t 120) then the "Client --> BPi-M3" performance increased up to the theoretical limit: 940 Mbits/s. Then a second iperf thread jumped in, both utilising a single CPU core fully. And that's the problem: Networking is CPU bound, a single client-server connection will not exceed 500-600 Mbits/sec as it was the case when I started with A20 based boards 2 years ago. Since all we have now with the A83T is an outdated 3.4.39 kernel and since I/O bandwidth on the M3 is so low, I stopped here since it's way too boring to try to improve network throughput and also useless (disk access is so slow that it simply doesn't matter when Ethernet is limited to half of the theoretical GBit Ethernet speed... at least for me  )
     
    Accessing disks:
     
    Since there's a SATA connector on the board I gave it a try.
     
    Important: the SATA-power connector uses the same polarity as older Banana Pis and Orange Pis (keep that in mind since combined SATA data/power cables from LinkSprite and Cubietech that share exactly the same connector use inverted polarity!).
     
    I started with the Samsung EVO I always use for tests (but due to the old 3.4 kernel using ext4 instead of btrfs) and was shocked: 13.5/23 MB/s is the worst result I ever measured. I then realised that I limited maximum cpufreq to 480 MHz and tried with 1800 MHz again. A bit better but far away from acceptable:
    GL830 USB-to-SATA performance: 480 MHz: kB reclen write rewrite read reread 4096000 4 13529 13466 22393 22516 4096000 1024 13588 13411 22717 26115 1.8 GHz: 4096000 4 15090 15082 30968 30316 4096000 1024 15174 15131 30858 29441 I disconnected the SSD from the 'SATA port' and put it in an enclosure with a JMicron JMS567 USB-to-SATA bridge and measured again: Now sequential transfer speeds @ 1800 MHz exceeded 35/34 MB/s. The GL830 is responsible for low throughput -- especially writes are slow as hell.
     
    I made then a RAID-1 through mdadm consisting of an external 3TB HDD (good news: the GL830 can deal with partitions larger than 2 TB) and the SSD. First test with the HDD connected to the M3's GL830 bridge (GL) and the SSD connected to the JMS567 (JM). Then I disconnected the HDD from the GL830 and put it in another external enclosure with an ASMedia 1053 (ASM). 
     
    Obviously SinoVoip's decision to use an internal USB hub and only one host port of the SoC leads in both situations to limited (shared) bandwidth. But in case the internal USB-to-SATA bridge is involved performance is even worse:
    GL/JM: kB reclen write rewrite read reread 4096000 4 17800 17140 14382 16807 4096000 1024 17741 17258 14493 14368 JM/ASM: 4096000 4 19307 18458 22855 26241 4096000 1024 19231 18518 21995 22362 If SinoVoip would've saved the GL830 USB-to-SATA bridge and wired both SoC's host ports to the 2 type-A USB ports directly without the internal hub in between overall performance would be twice as good. And obviously the M3's 'SATA port' is the worst choice to connect a disk to. Any dirt-cheap external USB enclosure will perform better.
     
    SD-card and eMMC:
     
    Just a quick check with the usual iozone settings running @ 1.8 GHz:
    kB reclen write rewrite read reread eMMC: 4096000 4 26572 27014 59187 59239 4096000 1024 25875 26614 56587 56667 SD-card: 4096000 4 20483 20855 22473 22892 4096000 1024 20526 19948 22285 22660 LOL, eMMC twice as fast as 'SATA'. The performance numbers of the SD-card (SanDisk "Extreme Pro") are irrelevant since I can not provide performance numbers from a known fast reference implementation. But since I might be able to provide this the next few days, I decided to give it a try. On older Allwinner SoCs there's a hard limitation regarding SDIO/SD-card speed. Maybe this applies here too.
     
    EDIT: Yes, it's a board/SoC limitation. When reading/writing the SD-card on a MacBook Pro I achieve ~80 MB/s. It seems SDIO on A83T is limited to ~20MB/s
     
    Other issues:
     
    If you want to try out the M3 you'll have to stay on the bleeding edge. Don't expect that any of the available OS images are close to useable. They just recently started to fix a lot of essential bugs in code and hardware initialisation. If you want to test the M3 be prepared to compile the BSP daily and exchange the bootloader/kernel/initialisation stuff on your SD-card/eMMC Currently average load is always 1 or above. When we started over 2 years ago with Cubieboards (and an outdated kernel 3.4.x) there was a similar issue. Maybe it's related. I just opened a Github issue Mainline kernel support in very early stage. Don't count on this that soon (situation with Banana Pi M2 was a bit different. All the OS images from SinoVoip based on kernel 3.3 weren't useable but the community provided working distros backed by the work of the linux-sunxi community and existing mainline kernel support for the M2's A31s) Always keep in mind that hardware without appropriate software is somewhat useless. SinoVoip has a long history of providing essential parts of software way too late or not at all (still applies to the M2 -- before you buy any SinoVoip product better have a look into their forums to get the idea which level of support you can expect: zero). Even worse: For the M2 and its A31s SoC there exists mainline kernel support (everything developed by the community while the vendor held back necessary informations). This does not apply to the A83T used on the M3. At the moment you're somewhat lost since you've to rely on the manufacturer's OS images (all of them currently being broken)  
    Conclusion:
     
    Still no idea what to do with such a device.
     
    Integer performance is great when you use a heatsink and even greater with an annoying fan. But where's the use case? If I would use the M3 with Android then everything that's relevant for performance does not depend on CPU (but instead CedarX for HW accelerated video decoding and GPU for 2D/3D acceleration -- BTW: the A83T is said to contain only a single core SGX544MP1 but the fex file's contents let me believe it's a faster MP2 instead).
     
    Due to limited I/O and network bandwidth the integer performance is also irrelevant for nearly all kinds of server tasks. If it's just about 'SBC stuff' why wasting so much money? Triggering GPIO pins works also with cheap H3 based boards like Orange Pi PC or Orange Pi One that also have 4 times more I/O bandwidth compared to the M3 (due to 4 available USB ports instead of one).
     
    And if I would really need a performant ARM SoC then I would buy such a thing and not an outdated Cortex-A7 design. I still have no idea what the M3 is made for. Except of selling something under the "Banana" brand to clueless people. Don't know. For my use cases the Banana Pi M1 outperforms the M3 easily -- both regarding price and performance (sufficient CPU power, 3 x USB and real SATA not 'worst USB-to-SATA implementation ever'). As usual: YMMV 
     
    Maybe the worst design decision (next to choosing the crappy Micro-USB connector for DC-IN) on the M3 is the 'SATA port'. If they would've saved both internal USB hub and GL830 and instead use the two available USB host ports then achievable I/O bandwidth would be way higher. Now both USB ports and the 'SATA port' have to share the bandwidth of a single USB 2.0 connection. Almost as bad as with the Raspberry Pis.
     
    But most importantly: Check software und support situation first and don't rely on 'hardware features'. Remember: SinoVoip shipped the M2 with OS images where not a single GPIO pin was defined and Ethernet worked only with 100Mb/s since they 'forgot' to define GMAC pins. They fixed that months later but still not for every OS image (the Android image they provide is corrupted since months but they don't care even if users complain several times). Visit their forums first to get an idea what to expect. It's important!
     
    Armbian support:
     
    Not to be expected soon. It's worthless when having to rely on Allwinner's old 3.4.39 kernel. I combined loboris' H3 Debian image with kernel/bootloader stuff for the A83T and it worked as expected (even my RPi-Monitor setup matched almost perfectly).
     
    Unless the linux-sunxi community improves mainline support for the A83T this situation won't change. But maybe someone interested in M3 (definitely not me) teaches SinoVoip how to escape from u-boot/kernel without support for script.bin in the meantime. Would be a first step.
  6. Like
    tkaiser got a reaction from Tido in Armbian taking a really long time to power up   
    This will be my last answer for now since you seem to ignore answers anyway.
     
    Please check your so called 'very high-quality SDCards' immediately and read through the 'SD card performance' thread I already recommended to you over there: http://forum.armbian.com/index.php/topic/1302-running-apt-get-dist-upgrade-installs-the-new-kernel-but-takes-the-orange-pi-pc-a-really-long-time/
     
    Regarding led behaviour it's that easy. All the OS images over at orangepi forums use Allwinner's oudated u-boot 2011.09 (where the led will be powered on immediately) while we use mainline u-boot where the led gets activated later (the time span already increased a lot since most recent mainline u-boot version scans all USB busses for peripherals).
     
    Anyway: if Armbian boots slow then your SD card is most probably the culprit. And no, after doing some very extensive testing I don't believe in any marketing claims any more. Counterfeit cards exist, most SD cards used are slow as hell when it's about random IO. Again: Read from here on: http://forum.armbian.com/index.php/topic/954-sd-card-performance/
  7. Like
    tkaiser got a reaction from wildcat_paris in Frequency scaling on Orange Pi One in Armbian   
    You are the very same person claiming he stops the upgrade process right in the middle (which might brick the board!), correct? http://forum.armbian.com/index.php/topic/1302-running-apt-get-dist-upgrade-installs-the-new-kernel-but-takes-the-orange-pi-pc-a-really-long-time/
     
    And if you read above another user said upgrading solved the issues for him. So if I were you I would slow down on complaining, get a fast SD card (see recommended thread already suggested to you) and enjoy Armbian from then on after upgrading to 5.11.
  8. Like
    tkaiser got a reaction from wildcat_paris in Armbian taking a really long time to power up   
    This will be my last answer for now since you seem to ignore answers anyway.
     
    Please check your so called 'very high-quality SDCards' immediately and read through the 'SD card performance' thread I already recommended to you over there: http://forum.armbian.com/index.php/topic/1302-running-apt-get-dist-upgrade-installs-the-new-kernel-but-takes-the-orange-pi-pc-a-really-long-time/
     
    Regarding led behaviour it's that easy. All the OS images over at orangepi forums use Allwinner's oudated u-boot 2011.09 (where the led will be powered on immediately) while we use mainline u-boot where the led gets activated later (the time span already increased a lot since most recent mainline u-boot version scans all USB busses for peripherals).
     
    Anyway: if Armbian boots slow then your SD card is most probably the culprit. And no, after doing some very extensive testing I don't believe in any marketing claims any more. Counterfeit cards exist, most SD cards used are slow as hell when it's about random IO. Again: Read from here on: http://forum.armbian.com/index.php/topic/954-sd-card-performance/
  9. Like
    tkaiser reacted to jernej in OPI LITE wireless device not working   
    Here is my solution for loading different wifi drivers on different boards. Basically it is just oneshot systemd service which runs a bash script. That script checks script.bin settings currently in use (there is read_fex.c source) and based on wifi settings loads appropriate wifi driver. In case of RTL8189FS it also checks for saved mac address and pass it as an argument or it creates a random one and saves it. Paths should be updated to be more appropriate for Debian.
     
    Latest RTL8189FS source is here.
  10. Like
    tkaiser got a reaction from wildcat_paris in Orange Pi Plus 2E now available   
    USB 2.0 means a rather inefficient encoding scheme called 8b/10b therefore you end up with sequential speeds of 40 MB/s max (didn't I already tried to explain that exactly to you? Twice?). Then sequential transfer speeds aren't everything since there's random I/O also that is for many use cases more important. Here SATA has an advantage as does UASP when compared to USB's BOT mode (see below).
     
    Regarding your questions simply rely on 'TK on sunxi' and then do the math (eg. thinking about using more than one disk attached to the board's USB ports): 
    http://linux-sunxi.org/Sunxi_devices_as_NAS#New_opportunities_with_mainline_kernel http://linux-sunxi.org/USB/UAS In the meantime I tested also the USB OTG port on H3 when changing the role to 'host mode' (running Armbian 5.11 with this kernel: Linux orangepiplus2e 3.4.112-sun8i #38 SMP PREEMPT Wed May 18 15:04:11 MSK 2016 armv7l GNU/Linux):
     
     
     
     
    In other words: OTG port almost as fast as normal host ports so you can use 4 USB disks with this device together with GbE. If I find the time I'll write an article explaining how to combine a bunch of disks with different size to a nice mixture between mdraid and btrfs' own RAID implementation (combining striping/mirroring to max out GbE Ethernet performance and provide full disk redundancy).
  11. Like
    tkaiser got a reaction from manuti 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.
  12. Like
    tkaiser got a reaction from gnasch in ORANGE PI PC PLUS support??   
    PC Plus support in Armbian (almost) done (Jernej fixed the WiFi driver already and will now add a fix for random MAC addresses within the next few days): https://github.com/igorpecovnik/lib/commits/13cc87639e958da00f30443b507c1565d19ca8af/config/fex/orangepipcplus.fex
     
    Added the necessary stuff to linux-sunxi wiki as well: http://linux-sunxi.org/Xunlong_Orange_Pi_PC#Orange_Pi_PC_Plus
  13. Like
    tkaiser reacted to lanefu in Orange Pi Plus 2E now available   
    Fired up and tested my Plus 2e
     
    I posted my DRAM test results.   Hopefully my comment makes sense.
     
    Other stuff
     
    I built latest Armbian 5.12 jessie for OPi PC from repo and booted without issue Once I symlinked my fex to /boot/bin/orangepiplus2e.bin, I was able to see the onboard eMMC, and the onboard ethernet. Ethernet was able link at gigabit.   I hit 700mbit on a quick iperf No luck with wifi with  using already included modules no luck with wifi following instructions described in this thread http://forum.armbian.com/index.php/topic/942-rebuild-rtl8189es-from-git-for-opi/page-2?hl=8189ftv#entry9574 There's a garbage Fat32 Filesystem with android stuff on the onboard flash (let me know if anybody really interested) I found this while poking around on the onboard flash
     
     

    root@orangepipc:/mnt/tmp# cat misc/wifi/wifi_hardware_info  realtek:rtl8189fs
  14. Like
    tkaiser got a reaction from gnasch in ORANGE PI PC PLUS support??   
    WiFi will be fixed within the next few days and the only other change are the 8 GB eMMC which do not need 'support'. In other words: Yes, the boards will be supported in a few days.
  15. Like
    tkaiser got a reaction from Igor in Orange Pi Plus 2E now available   
    Added device page to linux-sunxi wiki where also the DRAM reliability test results should be collected: http://linux-sunxi.org/Xunlong_Orange_Pi_Plus_2E#DRAM_clock_speed_limit
  16. Like
    tkaiser got a reaction from wildcat_paris in [NanoPi M3] Cheap 8 core (35$)   
    Strange. Since Orange Pi PC costs less (15$ + 3.50$) and is faster if you run heavy workloads (since throttling will happen later due to the better voltage regulator there). Further reading regarding NanoPI M1: http://forum.armbian.com/index.php/topic/1015-nanopi-m1/ and http://forum.armbian.com/index.php/topic/1213-ov5640-camera-with-orange-pi/  (camera stuff).
     
    Regarding NanoPi M3: Better avoid at all: http://www.cnx-software.com/2016/05/20/35-nanopi-m3-octa-core-64-bit-arm-development-board-is-powered-by-samsung-s5p6818-processor/
  17. Like
    tkaiser got a reaction from wildcat_paris in NanoPi M1   
    Then provide a stable power source and don't think about temperatures (throttling will jump in if load peaks make it necessary). Apart from that it might help with longevity if temperatures are lower (disclaimer: I'm no hardware guy) and in case you have an instable power source improving heat dissipation is always counterproductive since then throttling isn't that aggressive and since voltage drops occur under high loads chances increase that CPU gets clocked higher, is driven with a higher VDD_CPUX core voltage and then the critical supplied DC-IN voltage falls below a certain treshold.
     
    This is what seems to be hard to understand. The relationship between higher VDD_CPUX voltage (the SoC is fed with through a programmable voltage generator switching from eg. 1.1V to 1.3V which increases consumption) and dropping DC-IN voltage (eg. from 4.6V down to 4.3V which might already insufficient). The only relationship with temperatures is the aforementioned one: Improve heat dissipation only if you can provide a stable power source with stabilised 5V.
     
    On Banana Pi (A20/AXP209) it's easy to measure since drivers are available for the PMU: http://forum.lemaker.org/forum.php?mod=viewthread&tid=8312&extra=page%3D1  and the difference between a crappy USB cable with AWG 26 or 28 rating and good short one with only AWG 20 can be seen here: http://goughlui.com/2014/10/01/usb-cable-resistance-why-your-phonetablet-might-be-charging-slow/
     
    H3 has no PMU so you would need a multimeter to measure. And unfortunately the FriendlyARM folks chose the crappy Micro USB connector to power the board. In case you run into stability issues think about providing power through the GPIO header (pin 4: 5V, pin 6: GND)
  18. Like
    tkaiser got a reaction from wildcat_paris in NanoPi M1   
    Small update: The really friendly FriendlyARM people were the first to react on the Allwinner sun8i legacy kernel security alert we informed all affected vendors about. In the meantime they also tested our Armbian image and confirmed that it works.
     
    Unfortunately due to our still broken H3 board auto detection NanoPi M1 will currently be treated as either Orange Pi One or PC (depending on DRAM size). Major drawbacks until we fix auto detection (hopefully with next release):
    change /etc/hostname so that it reads nanopim1 fix dvfs settings manually in /boot/bin/nanopim1.bin as outlined here (I made a mistake when trying to improve dvfs settings prior to 5.10 release) then do as root a 'ln -sf /boot/bin/nanopim1.bin /boot/script.bin' -- this will lead to lower temperatures since appropriate voltage switching based on CPU clockspeed will be back again At least dvfs (settings dynamic voltage frequency scaling) will be fixed with next release and I hope also the board auto detection issues will be resolved then.
  19. Like
    tkaiser got a reaction from wildcat_paris in Orange Pi Plus 2E now available   
    Well, regarding the latter I'm not so sure whether this is the right target audience here
     
    But testing WiFi and DRAM reliability would ge great. I just prepared lima-memtester for Plus 2/2E (and OPi Lite/2 also): http://kaiser-edv.de/tmp/IXGNsR/
     
    Simply unpack the archive and use the contained fel-boot-lima-memtester-on-orange-pi-plus-2e script as outlined by ssvb: https://github.com/ssvb/lima-memtester/releases/tag/20151207-orange-pi-pc-fel-test
     
    BTW: To enter FEL mode you have to hold the button between microphone and serial console next to the Micro USB OTG jack.
  20. Like
    tkaiser got a reaction from wildcat_paris in Orange Pi Plus 2E now available   
    Sorry, I've overseen that. No I don't and am not that much interested in a sample since everything is already known (except of WiFi but that's absolutely useless for my use cases and most probably as crappy as on the other Oranges or on all SBC that use slow SDIO implementations only capable to use the 2.4Ghz band).
     
    Another linux-sunxi team member ordered one, I will prepare a fex file based on my above assumptions, he'll test and report back and then we will add OPi Plus 2E to Armbian.
  21. Like
    tkaiser got a reaction from wildcat_paris in Orange Pi Plus 2E now available   
    Depends on the SoC and its target market in question. Who needs SATA in a smartphone, tablet or an OTT box? Most probably no one so SoCs for these segments lack SATA.
     
    Allwinner added native SATA to A10/A20 more by accident than by design (which might explain the slow write performance) and it seems a faster dual core successor called A20E will be ready soon. If you need faster I/O choose the right board. Since repeating the same stuff over and over again is a bit boring, please read through http://linux-sunxi.org/Sunxi_devices_as_NAS#Differentiation_to_other_devices (just added Annapurna Labs a minute ago)
  22. Like
    tkaiser got a reaction from wildcat_paris in Orange Pi Plus 2E now available   
    Just FYI: Orange Pi Plus 2E is now available for $35 and shipping costs remain the same (pretty low compared to some competitors): 
     
    http://aliexpress.com/store/product/Orange-Pi-Plus-2-E-H3-Quad-Core-1-6GHZ-2GB-RAM-4K-Open-source-development/1553371_32665196281.html
     
    Please remember that this board was designed based on community requests (dropping the slow GL830 USB-to-SATA bridge and the internal USB hub and exposing all 4 USB ports physically to the outside) and should make up for a really nice server with 2 GB DRAM, Gbit Ethernet and 4 USB ports (3 real hosts ports and one Micro OTG).
     
    So now we have the following H3 boards with Gigabit Ethernet:
     
    Banana Pi M2+ for $33 (1 GB RAM, 8 GB eMMC, no USB hub / no shared bandwidth, only 2 USB host ports useable) OPi Plus 2E for $35 (2 GB RAM, 16 GB eMMC, no USB hub / no shared bandwidth, 3 USB host ports useable) OPi Plus for $39 (1 GB RAM, 8 GB eMMC, GL830 slow USB-to-SATA, internal USB hub / shared bandwidth) OPi Plus 2 for $49 (2 GB RAM, 16 GB eMMC, GL830 slow USB-to-SATA, internal USB hub / shared bandwidth)   SinoVoip said to release also a cost down version of M2+ without eMMC and WiFi that might be then the cheapest GbE equipped board. But since there you only get 1 GB DRAM (which might be totally ok for most use cases -- please compare with http://www.linuxatemyram.com if in doubt) and they don't use a programmable voltage regulator and always feed the SoC with 1.3V VDD_CPUX core voltage IMO spending a few bucks more to get OPi Plus 2E with twice the RAM/eMMC size, 1 more USB port, more performance and also lesser temperature/consumption is the better idea.   BTW: WiFi capabilities not mentioned intentionally since in my opinion those cheap SDIO 2.4 GHz implementations are all not worth a look (or time/efforts to get the crappy drivers running)
  23. Like
    tkaiser got a reaction from wildcat_paris in Hardware Mod BPi-R1   
    @badrianiulian/@pschasch: Can you please provide a few more pictures where one can see the hardware modifications clearly? And add them to http://linux-sunxi.org/Lamobo_R1#Pictures or allow me to do so?
     
    I would then summarize the 'Wi-Fi fix' there...
  24. Like
    tkaiser got a reaction from Rui Ribeiro in RPi-MonitorWatcher - Android App   
    An alternative would be to think about the whole approach first and then drop the whole idea.
     
    RPi-Monitor if adjusted to the data sources of the boards we play here with is a great tool to explore system behaviour (as part of a development/optimization process) since it's leightweight enough to not tamper the system's behaviour it should monitor.
     
    When you have a look what RPi-MonitorWatcher is doing then it's just plain 'fooling yourself' as usual: https://github.com/tobiasfiechter/RPi-MonitorWatcher/blob/master/app/src/main/java/io/hotkey/rpi_monitorwatcher/model/Raspberry.java#L16-L22
     
    Numbers without meaning displayed in nice colors. And the usual misunderstanding of 'average load' which is most of the times NOT CPU related on Linux SBCs (the author calls average load 'statusCPULoad' which is plain wrong). To understand what's wrong with such approaches please see http://forum.armbian.com/index.php/topic/1160-login-script-enhancement-for-load-average-color/?view=getlastpost
     
    But I doubt that this information will help since most people love numbers without meaning especially when nice colored graphs have been made of them.
  25. Like
    tkaiser got a reaction from rampage in [WiP / Orange Pi One] Support for the upcoming Orange Pi One?   
    Nope, what I've written to the wiki back then is outdated. I also made a mistake prior to 5.10 release so until 5.11 has been released (yesterday) a manual fix would've been required as outlined here: https://github.com/igorpecovnik/lib/issues/284#issuecomment-216655399
     
    Since 5.11 has been released all you've to do now is the usual
    sudo apt-get update && sudo apt-get upgrade
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines