Orange Pi R1

[guidol]

34 minutes ago, tkaiser said:

Thank you again for the support!

 

[before in your Msg]

But at least I would be interested in results from using nmtui only, configuring both eth interfaces with static or dynamic settings and also activate Wi-Fi (if possible). 

You're welcome! - if there is a thing in my possibilities i will try to help. 
But Iam glad that you and the others here could help me to get my different PIs running smoothly

 

Also to you: Thank you for your fast support! Many Users of the Orange Pi or H2(+)/H3 and H5 Boards will also thank you!

The only little catch with nmtui - I got sometimes is the subnet.

If you only insert a static IP in nmtui it will automatically add the subnet /32 ( 255.255.255.255 = LOCKUP  )

For a FAQ it would be nice to declare that the most users will have to add a /24 (255.255.255.0) after the IP to get the

communication working. (onlly IP-address of the Pi and not at the Gateway-/DNS-IP)

 

For my OPi R1 I had to ifconfig down the USB Ethernet (the port near the TTL-serial (RX,TX,GND) and wlan0

to get a a SSH-connect (or deactivate the connection via nmtui).

 

The real eth0-Ethernetport is near the WiFi-Chip 8189ETV and the 13-pin-row and named Wired Connection 2 (at install time)

 

PS: The OPi R1 Legacy Image is running much cooler on the R1 as the Opi Zero Image!

[guidol]

3 hours ago, tkaiser said:

Ok, no change to the stuff I looked into already in August. Preliminary support added, now building an image.

Thank you!

No wonder all their downloadable images are from August

[tkaiser]

7 minutes ago, guidol said:

For my OPi R1 I had to ifconfig down the USB Ethernet (the port near the TTL-serial (RX,TX,GND) and wlan0

to get a a SSH-connect (or deactivate the connection via nmtui).

Hmm... I don't think so. In situations with more than one NIC connected to the same subnet 'funny' things happen and I'm already curious how many many many new threads caused by this will flood the forum soon.

 

8 minutes ago, guidol said:

The OPi R1 Legacy Image is running much cooler on the R1 as the Opi Zero Image!

Hmm... I don't think so since they use more or less the same settings/software. Only difference between OPi Zero and R1 image is u-boot version (2017.05 vs. most recent now) and I would assume that somehow affects thermal calibration and the numbers the thermal sensor seems to spit out. Or do you measure real temperatures at chip surface?

 

1 minute ago, guidol said:

all their downloadable images are from August

Well, Xunlong (or the guy they pay/paid for software support) surprised us many times and I prefer to not monitor Orange Pi forum so I was waiting all the time for a confirmation that their most recent image running on the real hardware provides working Wi-Fi.

 

All the babbling in this thread the last months took way longer than doing the real work (especially in this case where mainline kernel device-tree stuff can be shared between Zero and R1)

[guidol]

34 minutes ago, tkaiser said:

I would assume that somehow affects thermal calibration and the numbers the thermal sensor seems to spit out.

Or do you measure real temperatures at chip surface?

Only with my finger at the surface on the heat-sink that I have installed.

With the OPi Zero legacy and the image from OrangePi I wouldnt held my finger for more than a pair of seconds to the heat-sink.

 

Now with your legacy image (or also with the next-kernel-image for the OPi Zero) there is no problem for me letting the finger on the heat-sink.

 

[tkaiser]

33 minutes ago, guidol said:

With the OPi Zero legacy and the image from OrangePi I wouldnt held my finger for more than a pair of seconds to the heat-sink.

 

Now with your legacy image (or also with the next-kernel-image for the OPi Zero) there is no problem for me letting the finger on the heat-sink.

 

Now it gets interesting!

 

But still the only real difference I can imagine is u-boot version. Can you give it a try with an older u-boot version on 'my' image?

 

Eg. http://apt.armbian.com/pool/main/l/linux-u-boot-orangepizero-default/linux-u-boot-orangepizero_5.30_armhf.deb that's »U-Boot SPL 2017.05-armbian (Jun 13 2017 - 15:38:19)«. Just download it, install it via 'dpkg -i', reboot and report back. There's a little chance that this bricks the image though so I hope that's ok on a test installation?

[guidol]

9 minutes ago, tkaiser said:

Just download it, install it via 'dpkg -i', reboot and report back. There's a little chance that this bricks the image though so I hope that's ok on a test installation?

gives only a install-error = conflicts with armbian-u-boot :

root@orangepi:~# cd /home/guido

root@orangepi:/home/guido# wget http://apt.armbian.com/pool/main/l/linux-u-boot-orangepizero-default/linux-u-boot-orangepizero_5.30_armhf.deb
--2017-11-04 19:26:52--  http://apt.armbian.com/pool/main/l/linux-u-boot-orangepizero-default/linux-u-boot-orangepizero_5.30_armhf.deb
Resolving apt.armbian.com (apt.armbian.com)... 185.158.177.155
Connecting to apt.armbian.com (apt.armbian.com)|185.158.177.155|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 163608 (160K) [application/octet-stream]
Saving to: âlinux-u-boot-orangepizero_5.30_armhf.debâ

linux-u-boot-orangepizero_5.30_ 100%[=====================================================>] 159.77K   248KB/s    in 0.6s

2017-11-04 19:26:53 (248 KB/s) - linux-u-boot-orangepizero_5.30_armhf.deb saved [163608/163608]

root@orangepi:/home/guido# dpkg -i ./linux-u-boot-orangepizero_5.30_armhf.deb
Selecting previously unselected package linux-u-boot-orangepizero-default.
dpkg: regarding .../linux-u-boot-orangepizero_5.30_armhf.deb containing linux-u-boot-orangepizero-default:
 linux-u-boot-orangepi-r1-default conflicts with armbian-u-boot
  linux-u-boot-orangepizero-default provides armbian-u-boot and is to be installed.

dpkg: error processing archive ./linux-u-boot-orangepizero_5.30_armhf.deb (--install):
 conflicting packages - not installing linux-u-boot-orangepizero-default
Errors were encountered while processing:
 ./linux-u-boot-orangepizero_5.30_armhf.deb

 

[tkaiser]

10 minutes ago, guidol said:

gives only a install-error = conflicts with armbian-u-boot

Adding '--force-all' most probably will 'fix' this  

[guidol]

51 minutes ago, tkaiser said:

There's a little chance that this bricks the image though so I hope that's ok on a test installation?

the force didnt seem to break it
was no problem, because it was my "old" 8GB Class6 uSD - and in the meantime I installed it on a 16GB Class 10 SanDisk uSD

 

But there is no big difference to the new u-boot which did idle at 57-59 degree (also Grad Celsius  ).

While running armbianmonitor -m I did press the finger at the heatsink....no problem.

But without the finger it raise again up:

root@orangepi:~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
20:02:21:  912MHz  0.00   1%   0%   0%   0%   0%   0%   57°C  0/7
20:02:26:  240MHz  0.00   1%   0%   0%   0%   0%   0%   58°C  0/7
20:02:31:  240MHz  0.00   1%   0%   0%   0%   0%   0%   57°C  0/7
20:02:36:  240MHz  0.00   1%   0%   0%   0%   0%   0%   57°C  0/7
20:02:42:  240MHz  0.00   1%   0%   0%   0%   0%   0%   56°C  0/7
20:02:47:  240MHz  0.00   1%   0%   0%   0%   0%   0%   56°C  0/7
20:02:52:  240MHz  0.00   1%   0%   0%   0%   0%   0%   56°C  0/7
20:02:57:  240MHz  0.08   1%   0%   0%   0%   0%   0%   57°C  0/7
20:03:03:  240MHz  0.07   1%   0%   0%   0%   0%   0%   57°C  0/7
20:03:08:  240MHz  0.06   1%   0%   0%   0%   0%   0%   56°C  0/7
20:03:13:  912MHz  0.06   1%   0%   0%   0%   0%   0%   55°C  0/7
20:03:18:  240MHz  0.05   1%   0%   0%   0%   0%   0%   54°C  0/7
20:03:24:  240MHz  0.05   1%   0%   0%   0%   0%   0%   53°C  0/7
20:03:29:  240MHz  0.05   1%   0%   0%   0%   0%   0%   53°C  0/7
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
20:03:34:  240MHz  0.04   1%   0%   0%   0%   0%   0%   51°C  0/7
20:03:39:  240MHz  0.04   1%   0%   0%   0%   0%   0%   52°C  0/7
20:03:45:  240MHz  0.04   1%   0%   0%   0%   0%   0%   51°C  0/7
20:03:50:  240MHz  0.03   1%   0%   0%   0%   0%   0%   51°C  0/7
20:03:55:  240MHz  0.03   1%   0%   0%   0%   0%   0%   50°C  0/7
20:04:01:  240MHz  0.03   1%   0%   0%   0%   0%   0%   51°C  0/7
20:04:06:  240MHz  0.03   1%   0%   0%   0%   0%   0%   52°C  0/7
20:04:11:  240MHz  0.02   1%   0%   0%   0%   0%   0%   52°C  0/7
20:04:16:  240MHz  0.02   1%   0%   0%   0%   0%   0%   54°C  0/7
20:04:22:  240MHz  0.02   1%   0%   0%   0%   0%   0%   53°C  0/7
20:04:27:  240MHz  0.02   1%   0%   0%   0%   0%   0%   54°C  0/7
20:04:32:  240MHz  0.02   1%   0%   0%   0%   0%   0%   52°C  0/7
20:04:37:  240MHz  0.02   1%   0%   0%   0%   0%   0%   54°C  0/7
20:04:43:  240MHz  0.09   1%   0%   0%   0%   0%   0%   53°C  0/7
20:04:48:  240MHz  0.08   1%   0%   0%   0%   0%   0%   54°C  0/7
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
20:04:53:  240MHz  0.07   1%   0%   0%   0%   0%   0%   53°C  0/7
20:04:59:  240MHz  0.07   1%   0%   0%   0%   0%   0%   54°C  0/7
20:05:04:  240MHz  0.06   1%   0%   0%   0%   0%   0%   53°C  0/7

 

[Piv Klit]

Just installed Next kernel to see the temps. Im running passive cooling on the CPU, and on the SD-card holder (yes that one actually gets damn hot on the Orange PI Zero, so a heatsink there works), and your temp is 20C above mine.

If I can help in any way since I got the board, do say so.
 

[guidol]

3 minutes ago, DEHN.IO said:

Im running passive cooling on the CPU, and on the SD-card holder, and your temp is 20C above mine.
If I can help in any way since I got the board, do say so.

I also got a little heatsink on top of the cpu of my OrangePi R1- but i would like to see a picture of your passive solution  

[Piv Klit]

[Icenowy]

P.S. my friend purchased an OPi R1 and I may help him to make it mainlined ;-)

[thanh_tan]

I tried the OpenWRT fw (openwrt_For_orangepiR1_V0_1) on OrangePi.org website, but it stuck here, any clues?

 

[   18.020570] Bridge firewalling registered
[   18.041116] 8021q: 802.1Q VLAN Support v1.8
[   18.069376] gre: GRE over IPv4 demultiplexor driver
[   18.083772] ip_gre: GRE over IPv4 tunneling driver
[   18.111895] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   18.341793] mmc1: new high speed SDIO card at address 0001
[   18.355564] *******************sdio init ok*******************
[   18.490985] ip_tables: (C) 2000-2006 Netfilter Core Team
[   18.510737] lib80211: common routines for IEEE802.11 drivers
[   18.584639] nf_conntrack version 0.5.0 (3869 buckets, 15476 max)
[   18.605293] PPTP driver version 0.8.5
[   18.621385] usbcore: registered new interface driver r8152
[   18.642345] r8712u: module is from the staging directory, the quality is unknown, you have been warned.
[   18.673827] usbcore: registered new interface driver r8712u
[   18.698095] usbcore: registered new interface driver rt73usb
[   18.713415] usbcore: registered new interface driver rtl8150
[   18.730414] usbcore: registered new interface driver rtl8187
[   18.770267] usb 2-1: reset high-speed USB device number 2 using sunxi-ehci
[   18.785018] xt_time: kernel timezone is -0000
[   18.806900] usbcore: registered new interface driver ath9k_htc
[   18.832616] usbcore: registered new interface driver brcmfmac
[   18.861165] usbcore: registered new interface driver rt2500usb
[   18.885324] usbcore: registered new interface driver rt2800usb
[   18.904284] usbcore: registered new interface driver rtl8192cu
[   19.013944] r8152 2-1:1.0: eth1: v2.07.0 (2016/06/14)
[   19.026381] r8152 2-1:1.0: eth1: This product is covered by one or more of the following patents:
[   19.026401]          US6,570,884, US6,115,776, and US6,327,625.
[   19.026413]
[   19.508027] wdt_restart, write reg 0xf1c20cb0
[   22.423917] gmac0: probed
[   22.434901] gmac0 gmac0: eth0: eth0: PHY ID 00441400 at 0 IRQ poll (gmac0-0:00)
[   23.243572] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   23.258068] ADDRCONF(NETDEV_UP): wlan1: link is not ready
[   23.307643] ADDRCONF(NETDEV_UP): eth1: link is not ready
[   23.344681] gmac0: probed
[   23.355789] gmac0 gmac0: eth0: eth0: PHY ID 00441400 at 0 IRQ poll (gmac0-0:00)
[   23.386328] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   23.400200] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[   23.414787] device eth0 entered promiscuous mode
[   23.431859] ADDRCONF(NETDEV_UP): br-lan: link is not ready

 

[Igor]

Update:

https://www.armbian.com/orange-pi-r1/

• Debian Jessie and Ubuntu Xenial with 3.4.113 (stable)
• Debian Stretch with 4.13.14 (nightly testing) 
  Bootlogs: http://sprunge.us/TZIQ
  Running AP:

  wlan0     IEEE 802.11bgn  ESSID:"ARMBIAN"  Nickname:"<WIFI@REALTEK>"
            Mode:Master  Frequency:2.432 GHz  Access Point: 08:EA:40:7C:02:B1   
            Bit Rate:150 Mb/s   Sensitivity:0/0  
            Retry:off   RTS thr:off   Fragment thr:off
            Encryption key:off
            Power Management:off
            Link Quality:0  Signal level:0  Noise level:0
            Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
            Tx excessive retries:0  Invalid misc:0   Missed beacon:0

   

 

[guidol]

13 hours ago, Igor said:

Update:

https://www.armbian.com/orange-pi-r1/

• Debian Stretch with 4.13.14 (nightly testing) 

Got it installed. After configuring wlan0 I got no network cable connected and the LEDs of the eth0 port stay on

When connecting a cable at eth0 the LEDs do work normally, but when disconnecting the cable the LEDs also stay on.

 

 

 

[Igor]

Networks work normally for me while I noticed that leds on USB based eth stays on but since this is a cosmetic issue I didn't even try to find out how to turn that down.

[guidol]

2 minutes ago, Igor said:

Networks work normally for me while I noticed that leds on USB based eth stays on but since this is a cosmetic issue I didn't even try to find out how to turn that down.

no problem - they do work booth  - just for imformation.
Is this right eth0 port the USB-based one and the other the onboard-SOC-ethernet-port?

[Igor]

If you look from rear, left is usb right internal. eth0 is the internal by naming.

Wrote on mobile

[guidol]

24 minutes ago, Igor said:

If you look from rear, left is usb right internal. eth0 is the internal by naming.

 

rear - from the uSD side? If you take a look at my picture above, then eth0 (at my R1) is near the 13-pin port an the other

( on mine = enxc0742bffe8ff) is the enx-USB-port - BUT the LEDs stayon at the eth0 port.

And you did wrote, normally the LEDs would stay on at the USB-Port.
[EDIT] found a picture with the description of the ports   

 

 

[Igor]

"Rear" could be understood both ways  Router rear are usually RJ45 sockets. In any case logical connections matters - both are 100M only and can be used in any WAN/LAN combination. Current armbian-config have a wizard for setting AP while for extended interfaces manipulating, creating bridges, firewall, ... is not yet done. Network config is anyway on your own/upon your needs and my goal is to provide some simple router functionality. If you need some serious stuff it's better to use (containerized) OpenWRT or similar.

[guidol]

On 15.8.2017 at 11:25 AM, tkaiser said:

• Possibility to combine this Zero (R1) with available Expansion boards (eg. NAS Expansion board or the $2 thing with exposes the two other USB2 ports and other interfaces)

 

I dont know how good the R1 is set up for the small Non-NAS-Expansionboard (2x USB, Audio/Composite Video), BUT the NAS-Board doenst seem to be made with the R1 in Mind.

I ordered the NAS-Board for the Zero for using ist wit the R1. But it came without the metall spacer and screws
Just putting it together without the spacers did show that a electric component will collide with one of the ethernet ports

(see the red arrow in the picture)

 

So I had to get some distance between the Orange Pi Zero R1 and the NAS-Expansionboard..

 

Lucky me - I had some spare parts from 2 Acrylic OPi Zero cases laying around with some higher spacers and matching screws.

To get more distance I used connector-extensions from/for an Arduino. Normally the Arduino has 8 pins + 6 pins - but I had to cut the 6 pin extension so fit the 5 pin width and I had to shorten the pins of the Arduino-Extensions to fit the hight of the spacers from the Acrylic case.

 

For the bottom I also did use one of the Acrylic plates as foot-stand

 

So this may be the first (and may be at this time the only) Orange Pi R1 with the NAS-Expansionboard "on the world"

 

With the armbian-image I used before the USB-Ports on the Expansionboard do work (didnt checked by now the other ports):

 

Linux opi-zero-r1 4.13.14-sunxi #12 SMP Sun Nov 19 10:35:41 CET 2017 armv7l GNU/Linux

root@opi-zero-r1:~# lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 002: ID 058f:9380 Alcor Micro Corp. Flash Drive
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 03f0:5307 Hewlett-Packard v165w Stick
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 0bda:8152 Realtek Semiconductor Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

 

[tkaiser]

1 minute ago, guidol said:

BUT the NAS-Board doenst seem to be made with the R1 in Mind.

 

Which is perfectly understandable since no one right in his mind wants to combine the router role with the NAS role on the same device without at least containerization/virtualization. OPi R1 has 16MB (128Mb) SPI NOR flash, that's where OpenWrt should be installed into.

 

Two Fast Ethernet ports for the NAS role? Stupid, better use Orange Pi Zero Plus instead.  

[Piv Klit]

Oh well, we are all mad in here

Here is my expandable IoT backend with 4 Zeros, 1 R1 and a C.H.I.P.
Going to be expanded with some new ZeroPlus. Why ? For fun . 

 

And yes openwrt is in the planing with the R1 so I can run them all away from my "private" network.


 

[tkaiser]

Today something called 'zeroshell updated:2017-11-23' appeared on Orange Pi R1 download page: http://www.orangepi.org/downloadresources/

 

Curious I downloaded the image and had a look (still keen on either correct schematics or a correct hardware description. There's an additional led on this board next to the USB Ethernet MagJack and I still hope we can use a GPIO to toggle powering of the RTL8152 Ethernet chip in case it hangs).

 

Guess what a surprise seeing that they use our work and rely on legacy kernel (IMO 'a bit' challenging for something with security in mind):

root@orangepizero:/mnt/sda1# lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT | grep sda
sda                 14.9G 
├─sda4      ext4     2.1G /mnt/sda4
├─sda2      iso9660  640M /mnt/sda2
├─sda3      iso9660  640M /mnt/sda3
└─sda1      vfat     319M /mnt/sda1

root@orangepizero:/mnt/sda1# bin2fex OPIZERO.bin | grep corekeep
fexc-bin: OPIZERO.bin: version: 1.2
fexc-bin: OPIZERO.bin: size: 35384 (84 sections), header value: 35384
[corekeeper]
corekeeper_enabled = 1

root@orangepizero:/mnt/sda1# cat boot-slot.cmd 
setenv machid 1029
setenv bootm_boot_mode sec
fatload mmc 0:1 0x500 slot.scr
source 0x500
setenv bootargs ${CONSOLE} root=HD=${HD} rootwait panic=10  panic=10 loglevel=0 ${PARAMETERS}
fatload mmc 0:1 0x43000000 OPIZERO.bin 
fatload mmc 0:1 0x48000000 ${SLOT}/${KERNEL}/vmlinuz-OPIZERO
bootz 0x48000000

root@orangepizero:/mnt/sda1# cat slot
setenv SLOT 1
setenv HD ZS-7D1C9C63_3.8.1A_1
setenv KERNEL 3.4.113-ARM-ZS
setenv CONSOLE console=ttyS0,115200n8
setenv PARAMETERS quiet

root@orangepizero:/mnt/sda4/_DB.001/LOG/2017/Nov/16/zeroshell# cat Administration 
Nov 16 20:50:12 zeroshell Administration: SUCCESS: System successfully started with Linux kernel 3.4.113-ARM-ZS and ZeroShell 3.8.1A

 

[Piv Klit]

The old kernel is the reason I didn't use the pulpstone image, it do work on the R1 (wifi doesn't)  but the old kernel is a no go. and looking around it seems that openwrt and the mainline kernel is not an option yet. 
 

[guidol]

2 hours ago, tkaiser said:

 

Which is perfectly understandable since no one right in his mind wants to combine the router role with the NAS role on the same device without at least containerization/virtualization.

OPi R1 has 16MB (128Mb) SPI NOR flash, that's where OpenWrt should be installed into.

Two Fast Ethernet ports for the NAS role? Stupid, better use Orange Pi Zero Plus instead.  

But the R1 has the same form-factor for the mounting holes and the 13 pin connector is also the same at the same place 

I personally dont like OpenQRT - so I would like more to have a Boot-Loader in the SPI which enables the R1 to boot from USB.

The Orange Pi Zero Plus ( not the -2- only the Zero Plus H5) is ordered, but will came in the end of 2017 or January 2018

but will also be placed in a small hot black Cube

 

As NAS I got my 2 NanoPi Neo2 (and the Synology and a Realtime-OS IcyBox-NAS).

 

The R1 has did get the NAS-Board for the USB and SATA Ports because he didnt got a case - so its a open working system

Its for Fun and testing - and because it was directly buyable her in turkey

 

[guidol]

Audio enabled and Internetradio does also work
 

armbian-config:
Toogle hardware config
Choose what you want to enable or disable
[*] analog-codec

root@opi-zero-r1:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 []
  Subdevices: 0/1
  Subdevice #0: subdevice #0

root@opi-zero-r1:~# lsmod
Module                  Size  Used by
sun4i_codec            32768  3
sun8i_codec_analog     24576  1
snd_soc_core          118784  2 sun4i_codec,sun8i_codec_analog
snd_pcm_dmaengine      16384  1 snd_soc_core
snd_pcm                69632  3 snd_pcm_dmaengine,snd_soc_core
sun4i_gpadc_iio        16384  0
snd_timer              24576  1 snd_pcm
snd                    45056  4 snd_timer,snd_soc_core,snd_pcm
soundcore              16384  1 snd

 

[Piv Klit]

1 hour ago, tkaiser said:

Today something called 'zeroshell updated:2017-11-23' appeared on Orange Pi R1 download page: http://www.orangepi.org/downloadresources/

 

 

The image is actually on Zeroshells homepage

http://www.zeroshell.org/download/

[guidol]

4 hours ago, tkaiser said:

 

Which is perfectly understandable since no one right in his mind wants to combine the router role with the NAS role

Something that you normally "like": the R1 isnt a device anymore that is MicroUSB-powered.
Now he get his 5V via the 13 Pin Header from the external 5V/3A Power-Supply of the Expansion-Board

[tkaiser]

15 minutes ago, DEHN.IO said:

http://www.zeroshell.org/download/

 

This whole stuff looks interesting. My only concern is the rather outdated kernels they use (for Raspberry Pi it's 4.4.50 and for the Oranges 3.4.113 -- at least I don't like to run stuff that matters with that outdated kernels)

 

8 minutes ago, guidol said:

Something that you normally "like": the R1 isnt a device anymore that is MicroUSB-powered.

 

Sorry, but when this OPi R1 is used correctly (as a little routing device without peripherals attached) it should be almost impossible to underpower this thing even with crappy USB cables and crappy phone chargers. I tested 2 years ago with undervolting an Orange Pi PC: still booted at 4.4V but then of course both HDMI and USB peripherals got in trouble (since way below the specs: HDMI allows for 4.8V – 5.3V and USB for 4.75V - 5.25V) while the camera was still working.

 

On the R1 without HDMI and USB consumers that need 4.8V minimum (without USB peripherals also minimal consumption which helps with voltage drops) and most if not all components on board 3.3V max it shouldn't really matter how crappy you power the board. We got OPi Zero with reasonable settings below 700mW (mW and not mA) so depending on how much the RTL8152 consumes I would still assume that we're talking here about less than 2.5W peak consumption (too lazy and uninterested to measure myself)