Orange Pi Plus 2E now available

[tkaiser]

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)

[theguyuk]

@tkaiser

 

How can these board makers add fast Sata, they all seem to use slow Sata solutions, do we know why?

 

Also as mad as it sounds would not a high speed USD to storage solution not be better than these slow on board Sata solutions?

[tkaiser]

How can these board makers add fast Sata, they all seem to use slow Sata solutions, do we know why?

 

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)

[Da Alchemist]

@tkaiser, do you already own a sample of the OpiPlus 2E?

[tkaiser]

Ah, forgot that before: Regarding software support everything's already in position (since I would suspect Steven/Xunlong is as smart as in the past and uses exactly the same pins for the same stuff). All we'll have to do get hardware working correctly (applies both to legacy and vanilla kernel) is to use fex/dts from Orange Pi PC and exchange network with the GbE network stuff from Orange Pi Plus.

 

Differences:

• DRAM: Xunlong uses the same type of Samsung DRAM on all 512MB/1GB variants and SK Hynix modules on Plus 2/2E. Since we didn't get reports about non-working OPi Plus 2 so far I would suspect DRAM initialization within u-boot for this different DRAM type works.
• WiFi: Xunlong said they replace 8189ETV used on the older OPi with 8189FTV on OPi Lite, PC Plus and Plus 2E. At least I have no idea whether both chips work with the same driver so unless someone holds a Lite or Plus 2E in his hands (and Igor managed to compile the new driver and include it into Armbian) we simply don't know what to expect

Both users of Orange Pi Plus 2 and Plus 2E are encouraged to start DRAM reliability testing using fel-boot-lima-memtester-on-orange-pi-pc-v3 as outlined here: http://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit (ssvb's package for OPi PC can be used since the only difference between Plus 2E and PC is a different Ethernet PHY used and this should not make a difference)

[tkaiser]

@tkaiser, do you already own a sample of the OpiPlus 2E?

 

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.

[hojnikb]

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)

 

 

What about pci-e or USB3 ? Are there cheapo chipsets that support that ?

 

My wish is still a cheap (<50$ shipped) board with gigabit ethernet and usb3 or sata (both works for me). I was really fed up of waiting for such board, so i went ahead grabbed a cheap ITX board (E1-2100 based).

For 40€ i got dual core x86, gigabit eth, usb3 and sata. But it's not ideal, since its quite big and draws more power (around 10-12W) than most arm boards.

[tkaiser]

What about pci-e or USB3 ? Are there cheapo chipsets that support that ?

 

Sure, i.MX6 for example has a single PCIe 2.x lane and Actions Semi's S500 for example (as used on Roseapple Pi) has USB3. And both suck regarding networking (i.MX6 negotiates GbE but maxes out at 400 Mbits/sec and S500 has only a Fast Ethernet MAC/PHY). Whether you can saturate bandwidth is another question and whether prices might drop in the region you're interested in another.

 

There are countless other SoCs with at least USB3 available and with some boards (ODROID XU4 for example) you might be able to exceed old boring A20 performance results using an external USB3 disk.

 

In the meantime I'm waiting patiently for A20E and am happy with A20/H3 yet

[Da Alchemist]

I have ordered one because i am still looking for a cheap and low power consumption Desktop replacement  . OPI Pc is running fine, but i think, running on Emmc is much faster. The Price for the OPiPlus 2E is the same as for the Odroid 8Gb Emmc Module.. Comparing the Odroid C2 to the Opi PC I must admit , that I have expected more from the Odroid...

[PoV]

Cool cool. I've just ordered a Plus 2E (and a $12 Plus). I'd still prefer they'd make it 4 USB ports, instead of adding the OTG port. I'm not sure what WiFi adds to cost ($2?), but I wish they could make some tweaks and bump it even more; Either with even more eMMC, or down to $30 instead of $35.

[lanefu]

my opi 2e arrived today.

 

so i should

* run and document dram test

* see if the untested wifi driver works

* make a dorky unboxing video

 

 

... anything else of value I can do in the name of armbian?

 

Sent from my SM-G920V using Tapatalk

[tkaiser]

* run and document dram test

* see if the untested wifi driver works

* make a dorky unboxing video

 

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.

[tkaiser]

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

[lanefu]

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

 

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

[tkaiser]

 

• 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)

 

WiFi is still a known issue. Jernej fixed the driver already and will add storage of the MAC address somewhere in the filesystem (will currently be created randomly on every boot which prevents authentication in many/most scenarios). Then Igor will adopt changes and new Armbian releases will contain the fixed driver.

 

Regarding the garbage you found on the eMMC: That's a whole Android 4.4 installation where wens extracted the new fex file from (see the commit log since it might help with further devices you get in your hands).

 

And thx a lot for testing DRAM reliability! If we get some 8 more testers all confirming that 744 or even above run stable we might increase official DRAM clock to 672MHz  

[Tido]

 

TK on sunxi:

exposes all 3 USB hosts ports as well as the USB OTG directly on USB receptacles without the need to share bandwidth.

USB 2.0 Hi-Speed    480Mbits/second

// 1 //

If you attach a fast SSD on the USB port how much through put do you get to the 1Gbit Ethernet ?

 

// 2 //

the opposite around from 1Gbit to SSD ?

[tkaiser]

USB 2.0 Hi-Speed    480Mbits/second

 

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):

 

 

 

Test commands used:

iozone -e -I -a -s 100M -r 4k -r 16k -r 32k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2
iozone -e -I -a -s 4096M -r 16384k -i 0 -i 1

Seagate Barracuda with bad alignment on USB OTG port through Micro USB adapter:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     6501     7461     7558     7384      960      982
          102400      16    16867    18950    19755    19943     3513     4478
          102400      32    22493    21499    22465    23680     6303     5507
          102400     512    30634    31994    34300    34859    23607    32550
          102400    1024    30794    30566    34580    35259    28039    24834
          102400   16384    34850    34041    36049    35784    36236    30910
         4194304   16384    33327    33262    34161    33883

Same Seagate Barracuda with bad alignment on upright USB host port:

                                                              random    random
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     7681     7740     5990     7653     1005      916
          102400      16    17141    20511    20863    19589     3702     3653
          102400      32    21073    25073    24726    25534     6513     8289
          102400     512    33839    33953    35282    34878    26454    28290
          102400    1024    34130    33389    35526    36232    30225    27337
          102400   16384    35598    35906    36876    37751    36337    35274
         4194304   16384    35598    35779    37028    36952 

 

 

 

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).

[Tido]

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?).

Oh yes you did the 8/10 thingy, but this site doesn't looks like fun to read, neither understandable to me.

 

 

I have asked now google for: usb 480mbits lie 

c't Magazin:

Warum schaffen selbst schnelle USB-Sticks und -Festplatten nur Transferraten um die 35 MByte/s? Ich dachte, USB 2.0 arbeitet mit 480 MBit/s.

 

Tatsächlich beträgt die Brutto-Bitrate im Highspeed-Modus von USB 2.0 480 MBit/s. Allerdings überträgt der Universal Serial Bus in festen Zeitabständen Datenpakete mit einer gewissen Maximalgröße: Pro Millisekunde acht Microframes mit höchstens je 13 Paketen, also 104.000 Stück pro Sekunde. Jedes kann im Bulk-Transfermodus maximal 512 Byte an Nutzdaten enthalten. Deshalb bleiben von 480 MBit/s nur 53,248 MByte/s als theoretisches Maximum der nutzbaren Datentransferrate übrig.

source: http://www.heise.de/ct/hotline/USB-2-0-ausgebremst-325842.html

 

Now I understand :-)

Well I understand, that it sucks with USB2.0

 

Uhhh, at the end something for you TK:

Hinweis: In einer früheren Version dieses Hotline-Tipps stand, dass Highspeed-USB eine 8-Bit-10-Bit-Kodierung verwendet, doch das stimmt nicht.

USB 3.0 Superspeed hingegen arbeitet tatsächlich mit 8b10b-Scrambling.

 

Bazinga

thank you for enlighten me

[wildcat_paris]

TK, Bazinga! well, TKKT is like TBBT

[tkaiser]

I posted my DRAM test results.

 

Bad news: There's a problem invalidating our both test results: http://irclog.whitequark.org/linux-sunxi/2016-05-31#16616909;

 

No 'spinning cube' --> no heat/load --> no results that matter. In case you're able to follow ssvb's suggestions it would be great if you can help narrowing the problem down.

[lanefu]

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

[tkaiser]

Just a small update on eMMC on Orange Pi Plus 2E (and also Orange Pi PC Plus since there it's the same). My goal was to get Armbian running from the eMMC. Igor had to provide a new mini release 5.14 yesterday since we forgot to add the necessary bits to u-boot the day before yesterday to be able to use both SD card and eMMC on Plus 2E and PC Plus.

 

So I took this new image, burned it to a small and slow SD card lying around, inserted the card into the board and booted. The usual procedure with one automated reboot, then I logged in, transferred the image on my SD card just to overwrite the eMMC contents in one single step:

sudo dd if=Armbian_5.14_Orangepiplus2e_Debian_jessie_3.4.112.raw of=/dev/mmcblk1 bs=10M

Partition table before and after:

 

 

root@orangepiplus2e:/home/tk# cat /proc/partitions 
major minor  #blocks  name

 179        0    3887104 mmcblk0
 179        1    3687424 mmcblk0p1
 179       16   15267840 mmcblk1
 179       17   12806144 mmcblk1p1
 179       18      16384 mmcblk1p2
 179       19          1 mmcblk1p3
 179       21      16384 mmcblk1p5
 179       22      16384 mmcblk1p6
 179       23     786432 mmcblk1p7
 179       24      16384 mmcblk1p8
 179       25      32768 mmcblk1p9
 179       26     786432 mmcblk1p10
 179       27      16384 mmcblk1p11
 179       28      16384 mmcblk1p12
 179       29      16384 mmcblk1p13
 179       30      32768 mmcblk1p14
 179       31      16384 mmcblk1p15
 259        0     655360 mmcblk1p16
 179       48       4096 mmcblk1boot1
 179       32       4096 mmcblk1boot0

root@orangepiplus2e:/home/tk# cat /proc/partitions 
major minor  #blocks  name

 179        0    3887104 mmcblk0
 179        1    3687424 mmcblk0p1
 179       16   15267840 mmcblk1
 179       17    1392640 mmcblk1p1
 179       48       4096 mmcblk1boot1
 179       32       4096 mmcblk1boot0 

 

 

 

Afterwards I ejected the SD card, rebooted and then Armbian started its usual 'firstrun' procedure now running from eMMC. There are more elegant ways to get Armbian on eMMC but I had to choose this way since I was in a hurry. As recommended I checked the eMMC for errors and performance using 'armbianmonitor -c':

 

 

 

 

  ___                               ____  _         ____  _____ 

 / _ \ _ __ __ _ _ __   __ _  ___  |  _ \(_)  _    |___ \| ____|

| | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | |_| |_    __) |  _|  

| |_| | | | (_| | | | | (_| |  __/ |  __/| |_   _|  / __/| |___ 

 \___/|_|  \__,_|_| |_|\__, |\___| |_|   |_| |_|   |_____|_____|

                       |___/                                    

 

Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.112-sun8i 

 

System load:   0.23            Up time:       54 sec

Memory usage:  3 % of 2013Mb IP:            192.168.83.119

CPU temp:      31°C           

Usage of /:    8% of 15G    

 

Last login: Wed Jun  1 12:07:37 2016 from macbookpro-tk.fritz.box

tk@orangepiplus2e:~$ armbianmonitor -c $HOME
Starting to fill /dev/mmcblk0p1 with test patterns, please be patient this might take a very long time
Free space: 13.23 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Creating file 5.h2w ... OK!
Creating file 6.h2w ... OK!
Creating file 7.h2w ... OK!
Creating file 8.h2w ... OK!
Creating file 9.h2w ... OK!
Creating file 10.h2w ... OK!
Creating file 11.h2w ... OK!
Creating file 12.h2w ... OK!
Creating file 13.h2w ... OK!
Creating file 14.h2w ... OK!
Free space: 162.20 MB
Average writing speed: 9.21 MB/s

Now verifying the written data:
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 2097152/        0/      0/      0
Validating file 5.h2w ... 2097152/        0/      0/      0
Validating file 6.h2w ... 2097152/        0/      0/      0
Validating file 7.h2w ... 2097152/        0/      0/      0
Validating file 8.h2w ... 2097152/        0/      0/      0
Validating file 9.h2w ... 2097152/        0/      0/      0
Validating file 10.h2w ... 2097152/        0/      0/      0
Validating file 11.h2w ... 2097152/        0/      0/      0
Validating file 12.h2w ... 2097152/        0/      0/      0
Validating file 13.h2w ... 2097152/        0/      0/      0
Validating file 14.h2w ...  156712/        0/      0/      0

  Data OK: 13.07 GB (27419688 sectors)
Data LOST: 0.00 Byte (0 sectors)
      Corrupted: 0.00 Byte (0 sectors)
Slightly changed: 0.00 Byte (0 sectors)
    Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 66.97 MB/s

Starting iozone tests. Be patient, this can take a very long time to complete:
Iozone: Performance Test of File I/O
        Version $Revision: 3.429 $
Compiled for 32 bit mode.
Build: linux 

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.

Run began: Thu Jun  2 12:43:26 2016

Include fsync in write timing
O_DIRECT feature enabled
Auto Mode
File size set to 102400 kB
Record Size 4 kB
Record Size 512 kB
Record Size 16384 kB
Command line used: iozone -e -I -a -s 100M -r 4k -r 512k -r 16M -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
              kB  reclen    write  rewrite    read    reread    read     write
          102400       4     4204     5685    16571    16518    13923     4367
          102400     512    36431    36541    63886    63812    63731    27479
          102400   16384    32262    31473    78170    78164    78198    27321

iozone test complete.

The results from testing /dev/mmcblk0p1 (ext4):
  Data OK: 13.07 GB (27419688 sectors)
Data LOST: 0.00 Byte (0 sectors)
Average writing speed: 9.21 MB/s
Average reading speed: 66.97 MB/s
                                            random    random
reclen    write  rewrite    read    reread    read     write
     4     4204     5685    16571    16518    13923     4367                                                          
   512    36431    36541    63886    63812    63731    27479                                                          
 16384    32262    31473    78170    78164    78198    27321                                                          

Health summary: OK

Performance summary:
Sequential reading speed: 66.97 MB/s 
 4K random reading speed: 13923 KB/s 
Sequential writing speed:  9.21 MB/s 
 4K random writing speed:  4367 KB/s 

To interpret the results above correctly or search for better storage
alternatives please refer to http://oss.digirati.com.br/f3/ and also
http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card
and http://thewirecutter.com/reviews/best-microsd-card/ 

 

Interesting observation: the f3write tool seems to use a rather small block size to write the test data patterns to 'disk' (so the 9.21 MB/s should be taken with a grain of salt since the eMMC is much faster with larger block sizes -- see here for a comparison of OPi Plus 2E and BPi M2+: http://pastebin.com/L1S7b3m7 )

 

Now the OPi Plus 2E is temporarely gone replacing a customer's 'server' (an aging Sun Fire 280 that died recently hosting an image archive for layout purposes. They allowed me to re-save all the images that were on a 8 disk RAID and with applied compression the TIFFs now fit on a 64 GB Samsung Pro SD card and are served by OPi Plus 2E which is also faster compared to the +1000W setup they used before).

[snowbody]

I would like to thank the "armbian team" for all the effort!

 

I tried the nand-sata-install script, but afterwards the 2E would not boot. (toggled a bootable flag, but that did not change a thing)

Your  "dd" method did the trick.  After a reboot I checked the free space. (was smaller than hoped for, so I executed resize2fs /dev/mmcblk0p1 ...)

[tkaiser]

Your "dd" method did the trick.  After a reboot I checked the free space. (was smaller than hoped for, so I executed resize2fs /dev/mmcblk0p1 ...)

 

Thx for providing this feedback! Since I experienced the same (no automatic fs resize -- the 1st partition got enlarged on /dev/mmcblk0 but the filesystem did not grow. I executed 'bin/bash -x /etc/init.d/firstrun' manually which did the trick (unfortunately since I tried to get a clue what went wrong).

 

So we know now that both firstrun and nand-sata-install need some attention/fixes. Unfortunately my OPi Plus 2E went productive yesterday :\

[Lope]

Hi Tkaiser, Thanks for your awesome work on these boards and wise suggestions to Xunlong to make this board. It's got some good ethernet, plenty of RAM and no silly slow SATA bridges or hubs restricting bandwidth.

 

Price - My opinions

Price may not be so important for users who only buy one. But some companies consider using products like this in their own products. And then price becomes important, when considering ordering many units. But OPi's software support is not as good as the RbPi. Making OPi more suitable for developers, and product developers. So I think Xunlong should consider my opinions, maybe they can agree.

 

Wifi: It's not worth including if it increases the selling price by more than $1.5.

If it only adds marginal cost then it adds convenience and can serve non-demanding applications when the software is working properly. (if it's a stable functional chip)

Price Vs the OPi PC: The 2E is $35. That's a $20 increase over the OPi PC @ $15. The only features it gained that are useful to me are an extra 1GB RAM and gigabit LAN. You linked the gigabit LAN chip in another thread, it was only about $1.50. I don't know what 2x 1GB RAM costs vs 2x 512MB RAM.

eMMC: Not worth including if it increases the selling price by more than $7.

To be really frank: There should be a version that only has gigabit LAN, 2GB RAM, all USB ports and nothing else.

Everyone needs different things. The best is to make a version that only provides a strong foundation and nothing else. People who need good Wifi & SATA, can buy the USB devices they need. It doesn't make sense that everyone should have to pay for features that only a fraction of people want.

I'd like a really bare bones version. Just CPU, 2G RAM, GBit PHY with no connectors, only solder pads.

2E makes the OPi lose it's price edge against the RbPi 2/3. At this price, price no longer becomes a reason to buy OPi instead of RbPi. But if my suggestions are implemented, maybe the OPi 2F could have better price AND better performance than the RbPi 2/3.

2E is near the price of BananaPi M2. (not referring to M2+) which is completely stable in Mainline and includes LVDS.

 

Software

I've been following the various threads about OPi One and OPi PC and their pages on armbian and the Mainlining progress etc.

But a few things were not clear to me, so if you or anyone else with knowledge on this could please clarify that would be awesome.

 

1.1 Since OPi+2E uses external PHY, (who's driver should be in mainline) will it work right now with Mainline kernel?

(I'm interested in using as a NAS so HDMI support does not matter to me)

1.2 What is the "common" kernel here? http://www.armbian.com/orange-pi-plus-2e/I watched the youtube vid, but the kernel version wasn't in there either.

 

2.1 You guys mention "Vanilla kernel". And I've seen "Kernel 4.x" mentioned nearby on some pages. Most of the Armbian Orange Pi pages seem to offer 2 images: "common" and "legacy kernel", but don't say what kernel version is in "common"?

 

I followed the "compiled from scratch link" and scratched around in the github.

I found this:

https://github.com/igorpecovnik/lib/blob/34770652d4e76a35cb1272632cc58bae7dac6f66/config/boards/orangepione.conf

Which uses family sun8i, which seems to refer to

Normal https://github.com/igorpecovnik/linux(empty)

Dev: https://github.com/wens/linux(looks like a 3.x kernel)

 

2.2 Is the above info deprecated? it doesn't seem capable of building a mainline kernel.

2.3 Is there a guide for compiling the kernel for Opi One/PC/Plus?

 

2.4 I saw you said the internal PHY of the orange Pi PC (and that should include OPi One as well) was working in (some?) 4.6 kernel? (and build info)

2.5 Who are the main people doing Kernel Dev on the H3?

 

I saw you posted a link to Igor's 4.6 kernel (with a warning that it's dangerous)

http://mirror.igorpecovnik.com/Armbian_5.10_Orangepih3_Debian_jessie_4.6.0-rc1.7z

I looked on the above URL root, but I don't see any info there on how it was built.

2.6 Does Igor have a build blog or something?

 

You said you'd be comfortable to use Mainline 4.7 on H3 once it has THS support. I searched linux 4.7 THS support and found:
http://www.gossamer-threads.com/lists/linux/kernel/2309350

2.7 What is THS? Is it relating to throttling down CPU usage when the core temp goes high? or volatage regulation? Where does the danger come in? If it's only related to voltage regulation, then there shouldn't be a problem on the Opi one since it's voltage "regulation" can't break anything. So in that case, it should be safe to use on Opi One? Which models are affected by the danger?

2.8 Is it ALL new kernels >=4.0 on ALL OPi One/PC/Plus that are affected by the danger or only some?

 

Thanks I hope you don't mind all the questions.

[zador.blood.stained]

Normal https://github.com/igorpecovnik/linux(empty)

Not exactly empty: https://github.com/igorpecovnik/linux/tree/sun8i

 

Dev: https://github.com/wens/linux(looks like a 3.x kernel)

More like 4.6.0-rc6: https://github.com/wens/linux/tree/h3-emac

 

Regarding some other questions: prebuilt images use kernel 3.4.112 (aka legacy, aka "default" branch) with extra patches, and this kernel is more or less suitable for everyday use. If you want to compile it yourself you can use official documentation: http://www.armbian.com/using-armbian-tools/

 

Mainline (4.x aka vanilla, "dev" branch) is missing different features - USB, Ethernet, THS, so it's not recommended to try it yet unless you want to help with development. Configured "dev" branch has experimental work-in-progress Ethernet driver, other than that it's not very useful at the moment.

[tkaiser]

In addition: I created an image for BPi M2+ with 4.6-rc1 a few weeks ago with working USB and Ethernet (external RTL8211E PHY -- this is only PHY and the MAC lives inside H3 so the driver has to be written for H3 since RTL8211 in 'PHY only' mode is just used as some sort of a passive component): http://linux-sunxi.org/Banana_Pi_M2%2B#OS_images

 

Since we now know how shitty BPi M2+ is behaving it's strongly recommended to not use this image on BPi M2+ unless megous' THS patches are sent upstream and hopefully accepted and we provide an official Armbian image. BPi M2+ is prone to horrible overheating and even reducing cpufreq to 816 MHz seems to be too dangerous for this lousy board.

 

But the very same image could be used without any problems on Orange Pi Plus 2E (unless you replace the .dtb contents you only 'loose' 1 USB port and one led) since OPi Plus 2E's PCB seems to perfectly spread the SoC's height and we limit cpufreq on this image to 816 MHz.

 

Apart from that we decided that until the THS stuff isn't working and montjoie's Ethernet patches were accepeted it's not worth the efforts to try to get H3 boards up and running with mainline kernel. So unless someone's willing to maintain this in Armbian's build system (me not) be prepared that you won't be able to generate fully working H3 Armbian images with kernel 4.x at the moment.

 

THS means working cpufreq and dynamic voltage frequency scaling (reducing the core voltage at lower clockspeeds on Oranges which helps with throttling a lot) and therefore 'thermal protection' of the SoC/board.

[Lope]

I see, thanks for the updates guys.

 

TKaiser: are the THS patches actually working? Have the THS patches been applied to your image or other mainline H3 Images?

 

You guys have said USB is not working in the mainline, but Tkaiser you said you've been running a NAS on mainline kernel with a USB ethernet adapter on OPi PC, and mentioned about using some USB device tree. So is the dev branch missing the drivers you used, or do they not work anymore in the new mainline kernel?

 

Is building a mainline kernel with the best USB and THS patches a very manual process each time?

[tkaiser]

Regarding 4.7: http://linux-sunxi.org/Mainlining_Effort#Planned_for_4.7 (no idea when this stuff will be ready. BTW: We will not wait until this is in the kernel but include patches when we feel the drivers are ready. So Armbian with all this stuff already working might be reality weeks/months before an official kernel is out).

 

Regarding THS I got the patches working but then the boards failed to boot and I got lost somewhere between u-boot and kernel. For the two guys who developed this stuff it obviously works and I fear that we're the 3 only people on this planet who paid attention to this 'H3 THS for mainline stuff'

[tkaiser]

Regarding state of the various H3 patches. Some of these patches (eg those for USB) are flying around for over half a year. Igor collected all available back in December and therefore we were able to get an OS image without SMP but working USB last christmas already.

 

Later SMP initialization has been added to u-boot and now montjoie sent his H3 Ethernet driver upstream for review. You might now be able to use montjoie's or wens' branch to get all this stuff working (since they integrated USB stuff also in their branches). For some additional info please check https://github.com/igorpecovnik/lib/issues/291 and https://github.com/wens/linux/tree/bpi-m2p-emac  (and then you would still need to adjust some patches to get this working as part of Armbian's build system. Since I see no benefit now I won't look into since without THS stuff being sent upstream and reviewed it's somewhat useless to provide OS images since we have to take care of our users unlike kernel devs that are already happy if Ethernet and USB work but you can easily kill the SoC due to overheating if anyone starts to do some serious stuff)

[Lope]

Thanks for the links.

 

We should try convince Xunlong to send a few complimentary boards to kernel devs who have the relevant experience.

 

Being 2014 28nm DDR2/3. Do you think the H3 chip has a future? Interesting that it's such a great chip at a great price, but not much interest in it...

 

The Banana Pi M3 Octa core A83T seems to have similar problems. No mainline kernel support. And it shares the same crappy design decisions as some of the previous Orange Pi boards. one USB port with a USB Hub chip. Crappy SATA chip. Etc. All that CPU performance but IO has been choked.

 

Tkaiser: Just a quick note about SMP/HYP. I think rather than SMP, uboot should be setup to bring the CPU online in HYP mode rather. These chips all support virtualization. KVM works on the RbPi2, and by default, the RPi2 bootloader starts their CPU in HYP mode. The linux kernel is setup such that if HYP support is not compiled into the kernel, the kernel switches back to SMP mode automatically; but the CPU MUST be started in HYP mode before the kernel is started for virtualization to function.

 

There's also the Odroid XU4 with the Samsung Octa-core SoC with USB3. Looks like a nice board. But again no Mainline kernel support.

 

There's one hope I just thought of

Xunlong seems to be open to your suggestions and prices their products competetively. What if Xunlong made a board with the A31S. Like the Banana Pi M2?

 

Ideal SBC:

Cost: Low
CPU: Quad or Octa core

SATA: Fast or nothing

Network: Gigabit

RAM: 1-4GB

Bootloader: Uboot HYP (virtualization enabled)

Kernel: Mainline
eMMC: None

Wifi: None

USB ports: All exposed

USB hub: Useful if SoC has less than 4 USB ports. But only pads should be exposed.

USB OTG: useful for development

CPU Voltage: High/low (user defined by trimpot within safe limits) or full range software controlled.

Power: DC barrel

Connectors: All unpopulated, sold separately. Most stuff like GPIO, USB, ethernet, audio is easy to solder in. I'd prefer solder pads for low profile and easier industrial integration.