lanefu

[Disclaimer on]
This is the try to play through some sort of an approval process contuining discussion from here and there -- maybe move @hmartin's last post to the latter thread? IMO we need a transparent process to decide whether to support new devices or not weighing pros/cons for both developers and users and estimate efforts especially if it's a new platform. Even if hardware vendors send out free dev samples we should not automatically start with new boards but discuss and evaluate first since we already deal with way too much boards with a crew just too small. I would believe @Igorhas now every new Olimex device and TL Lim said he sent out 3 ROCK64 boards to various Armbian devs me being amongst... I think that's an opportunity to start to establish such a process now?
 
Since I've thought about this issue for a few days and came to no conclusion (Github issue or not or discussion in forum and so on) I'm now just naively start with a new thread regarding this RK3328 device and maybe we find out collectively how to define a process based on this?
[Disclaimer off]
 
Let me introduce ROCK64:
 
RK3328 SoC: feature list ROCK64 schematic (preliminary since vendor promised to accept last minute changes/suggestions within the 2 next weeks) Board layout picture (same form factor as Raspberries, pre-production samples do not fit exactly in RPi enclosures, final design should fit) 1GB, 2GB or 4GB PC-18666 LPDDR3 eMMC has higher boot priority than SD card (but eMMC can be disabled via jumper) socketed eMMC modules are the same as on Pinebook and SoPine (and compatible to older ODROIDs and their SD card adapter) 128Mb SPI NOR flash (16MB) on future board revisions (to directly boot from USB[3] storage, network or whatever) RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth) Due to USB3, GbE and additional Fast Ethernet also interesting for NAS/server use cases (TBC, both USB3 and GbE performance needs to be checked) I2S exposed and compatible to some early RPi DACs, a lot more GPIOs exposed as usual (see picture above and this) Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks)  
Pros:
board vendor actively participates (listens to community, provides information including schematic and cares about correctness, tries to bridge developer community and chip vendor) board vendor provides dev samples and documents problems devs might run into (see below) chip vendor actively supports mainline Linux and u-boot chip vendor is said to focus on ROCK64 as currently best supported RK3328 device to spread market adoption (TBC) SDK/BSP not horribly outdated (RK relies currently on 4.4) almost all Armbian target audiences might benefit from RK3328 support (desktop replacement, NAS/server, audiophiles + IoT use cases due to exposed GPIOs/interfaces) No unreliable shitty Micro USB for DC-IN but sane 3.5/1.35mm barrel plug to be combined with 5V/3A PSU Pine Inc already sells together with Pinebook Icenowy already received a dev sample  
Cons:
 
new platform (Rockchip 64-bit) needing more initial work  
Did anyone of you received shipping confirmation with tracking number already? @jernej? Unfortunately I get a dev sample with unusable USB3 (some components need to be desoldered which is a pity since I'm not good in soldering at all)
 
My next steps planned:
 
Boot the board with what's provided within one week (TL Lim mentioned a 'Debian based 4.4 BSP, later Yocto' and said RK would be ready with a mainline variant within the next weeks) Test GbE speeds, memory throughput and the usual Armbian tunables (IRQ distribution) ask @Xaliusfor USB3 numbers (his dev sample was shipped out later and doesn't need soldering) Present results to continue discussion

Somewhat off-topic here but a great way to say thank you is to support Armbian in practical ways, eg. seeding Torrents: 
This is smallest OPi Zero seeding 24/7 our torrents since few weeks (33% of the 256MB used, consumption below 700mW running off a 128 GB Samsung EVO)
 
 

To secure top download speed around the globe, we need to have as many torrent seeders as possible. Currently we have dedicated seeders in: Estonia, Germany, Pakistan, Slovenia, Argentina, Singapore, USA, ... but we might be slower in China or Japan.
 
Prerequisite:
 
- Armbian or any Debian or Ubuntu based distribution (check instructions how to run armbian-config on a generic Debian/Ubuntu),
- 1TB of free space.

a) Installation with installing Transmission server
 
login and obtain superuser rights, execute armbian-config, select Software -> Softy, install Transmission server. (use space to confirm and enter to proceed with install)
   
Leave armbian-config and after a few minutes check your torrent server status with the following command:
transmission-remote -n 'transmission:transmission' -l and you should see some progress:
 

Note:
Torrent server installed this way is auto updating - it checks daily for new images, adds new and purge old ones.
 
 
 
b.) Installation to the existing Transmission server
 
You only need to install a cron job script that your client serve only most recent files.

Create file:
sudo nano /etc/cron.daily/seed-armbian-torrent with this content:
 
 
Change username(transmission) and password(transmission) if have something else than stock, save and exit, then run:
sudo chmod +x /etc/cron.daily/seed-armbian-torrent sudo /etc/cron.daily/seed-armbian-torrent Optional:
 
If you use GUI, you can install desktop front end for simple torrent server monitoring.
 
apt install transmission-remote-gtk Host: localhost
Username: transmission
Password: transmission

Confirm and click connect.
 
 
How to stop seeding torrents?
Remove cron job: sudo rm /etc/cron.daily/seed-armbian-torrent  
Remove torrents:  transmission-remote -n transmission:transmission -t all --remove-and-delete This command will remove all files on your torrent server! If you seed other stuff do a cherry pick.
 

ya ill try to tidy things up and send a PR.

theres a few weird things like the interface is literally called wan from the device tree perspective rather than eth0... perhaps because of the topaz switch being in the middle of it. i have a few other questions i need to post. Should i start a more topic appropriate thread elsewhere?

Sent from my SM-G920V using Tapatalk

Yeah I realize now I should have just purchased an 32GB SATA SSD instead of goofing around with m.2 and converters and such, however, at this point I figured it cheaper to cut my losses by buying the m.2 to sata adapter than still buying another drive.  Hopefully this adapter arrives and everything works (and I don't find my issues were caused by a bad SSD module).
 
As far as testing on the ESPRESSOBin:
 
Unfortunately the first one I ordered is already in production -- One of the reasons I wanted the SSD was to provide a little bit of high speed swap without chancing killing off an SDcard.  The board its self runs like a champ and it is easily my favorite headless board I own.   While some of their documentation is lacking. it does seem like they actually spent some time thinking about the board and creating docs which actually teach(force) you to compile your own kernel and use the USB to serial console and some things other board vendors don't really make you do.  I have enjoyed the experience of setting it up, learning the in and outs and working with it in general, so far (other than this issue with m.2).
 
Now, I have another ESPRESSOBin I had ordered, which they said would start shipping 'soon' so as soon as the second one arrives, I will make OMV my first test with it.  Sorry I can't be more helpful right now.
 
Maybe if I can afford some downtime of the appliance its running this weekend I will see if I can test, but I won't make any promises at this time.
 
@tkaiser  thanks again for taking time out to answer my questions as well as all the time and hard work you put in to keep Armbian the awesome distro it is!  
 
Cheers!

Good for you but I'm looking for help.

I don't think so. You can simply 'blacklist' interfaces you don't want NM to deal with and even if you allow NM to handle allNICs it should be possible to do bridging, routing and so on with NM: https://github.com/armbian/build/commit/e6c47e0b33278cf2735ce111c28a2b30b26c2137#commitcomment-21877390
 
I think it just needs some time to understand/adopt new/better concepts (applies especially to DSA which I'm still not familiar at all)...

SPI flash would be exposed as MTD device, not as block device. And for it you need some options in the kernel config and bindings in DT.
Assuming it's not really "hidden" by making it a secure access only device.

Aha!  the console wasn't in /etc/securetty   (/dev/ttyMV0)
 
victory!
 
I'll kick off a WIP thread soon--once I get things a little more dialed in...
 
armbian monitor seemed to work out of the box too
 

Aha!  the console wasn't in /etc/securetty   (/dev/ttyMV0)
 
victory!
 
I'll kick off a WIP thread soon--once I get things a little more dialed in...
 
armbian monitor seemed to work out of the box too
 

sweet the patch for mvebu you all linked to worked fine on mvebu64....  Image FS wasn't showing as valid. so gonna clean image caches etc.
 
  I'm building u-boot,but it's really a placebo for now.   the espressobin comes with it's own u-boot fork installed on NOR

MOSI - 19, MISO - 21, SCK (SPI_CLK) - 23, CS - 24, RESET, DC and LED - 11, 13, 15. power supply and ground as usual
sudo modprobe fbtft_device custom name=fb_ili9341 gpios=reset:1,dc:0,led:3 speed=48000000 fps=25 rotate=90 bgr=1 txbuflen=65536

You need to add a kernel patch i.e. based on this: https://github.com/igorpecovnik/lib/blob/master/patch/kernel/mvebu-default/packaging-4.x-with-postinstall-scripts.patch
You may need to adjust it i.e. to use Image instead of zImage for the kernel file name. Also please keep in mind that you'll have to add a new boot script since boot-marvell.cmd is for 32-bit systems, and arm64 most likeky will use booti instead of bootm bootz and Image instead of zImage.

You need something like this https://github.com/igorpecovnik/lib/blob/master/patch/kernel/mvebu-default/packaging-4.x-with-postinstall-scripts.patch

First Rockchip RK3399 based board from Orangepi maker - under development, not much news except what can be scrapped from pictures. Chip: http://rockchip.wikidot.com/rk3399
 
 

Orange Pi Win Plus with 2GB RAM and black PCB color is available:
https://www.aliexpress.com/item/Orange-Pi-Win-Plus-Development-Board-A64-Quad-core-Support-linux-and-android-Beyond-Raspberry-Pi/32803012893.html
 
Looks to be an Orange Pi Plus 2e and Orange Pi Prime form factor.

You need to buy an Eltechs license I think this type: Eltechs ExaGear Desktop for ARMv7 devices and after installing ExaGear intall inside WINE and inside of Wine the Windows software.
I do some test https://raspberryparatorpes.net/instalacion/probando-exagear-emulador-x86-sobre-arm/
but for me is only usable under ODROID-U3 quad core 2GB RAM and eMMC memory.

Requirements
Fresh enough nighly or manually built image Latest kernel and dtb packages (26.03.2017 or newer)  
Limitations
As stated in other PWM related threads, hardware PWM output is supported only on pin PA5 which is also UART0 ("debug" serial console) RX pin, so enabling PWM will disable this console.
 
Activation
Add "pwm" to "overlays" line in /boot/armbianEnv.txt
Example:
overlays=pwm Reboot is required to apply the changes
Armbian overlays documentation: https://docs.armbian.com/User-Guide_Allwinner_overlays/
 
PWM sysfs interface
Official documentation: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/ABI/testing/sysfs-class-pwm?h=v4.10
Please note that this ABI is considered "testing" so it may change in the future.
 
Sysfs interface example
# activate the PWM. On H3 only 1 PWM is supported, so exporting PWM 0 echo 0 > /sys/class/pwm/pwmchip0/export # set period to 10ms echo 10000000 > /sys/class/pwm/pwmchip0/pwm0/period # set normal polarity. needs to be reset explicitly. Bug? echo "inversed" > /sys/class/pwm/pwmchip0/pwm0/polarity echo "normal" > /sys/class/pwm/pwmchip0/pwm0/polarity # enable the PWM echo 1 > /sys/class/pwm/pwmchip0/pwm0/enable # set duty cycle to 1ms echo 1000000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle Result:
# set duty cycle to 2ms echo 2000000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle Result:
 
# set duty cycle to 1us, period to 2us echo 1000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle echo 2000 > /sys/class/pwm/pwmchip0/pwm0/period Result:
 
Please note that some settings needs to be changed in a correct sequence, i.e. you can't set duty cycle higher than period
root@orangepiplus2e:~# echo 1000 > /sys/class/pwm/pwmchip0/pwm0/duty_cycle root@orangepiplus2e:~# echo 500 > /sys/class/pwm/pwmchip0/pwm0/period -bash: echo: write error: Invalid argument root@orangepiplus2e:~#  

When adding any thing in /etc/rc.local, you need to make sure it done as a subprocess, not block /etc/rc.local from exiting.
So, you should call your script similar to :
 
nohup /usr/bin/python /root/hw_shutdown.py &  

Hello from Armbian!  4K output is configured by default, however my monitor was not behaving properly.  Otherwise USB, ethernet, etc are working, And it is smoother than the ASUS tinkerOS 1.4
 
It could be that the MiQi is more robust bootloader wise, it might be able to overlook some formatting differences on the SD card where the Tinker Board cannot, my net crawling did uncover some comments to that effect concerning the Tinker Board being "inflexible".

Thank you, but I am not sure I need another board / new costs. Recently I denied two board donations, from board makers, with this (simplified) explanation: "We can't accept more boards, since we are small amateur group, overwhelmed with work / boards.". If they still want the board here, project is open - they can add it ... or try to make a deal.

I think this
means that he most likely used a prebuilt nightly image and upgraded it from the repository.
 
Anyway missing characters in the logs don't look good. Maybe voltage regulator or CPU frequency limits were lost during u-boot patches upgrade and now the board is undervolted/overclocked. I'll check the commits later.
 
Edit: CPU frequency limit and CVBS output settings was lost, I'll add a patch to fix this.

I upgraded to nightly beta.
 
I added to /etc/network/interfaces:
auto eth0
allow-hotplug eth0
iface eth0 inet manual
pre-up /sbin/ifconfig eth0 down
pre-up /sbin/ifconfig eth0 up
pre-up /sbin/ifconfig eth0 down
 
 
With this extra "pre-up" config I get full duplex connection (without only half duplex).
 
A: Macbook, Samsung TV: 100Mb/s full duplex
B: Old laptop Asus F5R, it is equipped with 10/100Lan card, but for some reason it is advertising itself 10Mb/s only (Live Ubuntu + Acronis True Image CD). Doesn't matter.
 
 
I use this little board for wlan0 to eth0 bridging and it's really good.
 

I'd like to add another method which I found "cleaner" and "easier".
Debian provides an easy way to set sysfs values after reboot via the /etc/sysfs.conf file and the /etc/sysfs.d/ directory.
(This is basically the same as the relation between the /proc/sys and sysctl.conf and sysctl.d.)
 
My use-case:
I wanted to set the red light on my OpiPC to the heartbeat effect.
This can be set manually with:
# echo heartbeat > /sys/class/leds/orangepi\:red\:status/trigger The sysfs files format is really simple:
# the path omits the /sys/ path/to/the/settings = value So all I had to do was:
# echo "class/leds/orangepi\:red\:status/trigger = heartbeat" > /etc/sysfs.d/red_led.conf One can modify the sysfs.conf itself, but it's more pluggable/manageable via .conf files under the sysfs.d directory.

Small update: Tried two more locations within the same building with OPi Lite and the other board with RTL8192CU MIMO dongle:
 
Location 1: 4 meters away, 2 walls in between, wall angle approx. 30°
 
Orange Pi Lite: 33 Mbits/sec on average
 
ODROID-C2 with MIMO USB dongle: 51 Mbits/sec on average
 
 
Location 2: 5 meters away, 2 walls in between, different direction compared to prior location.
 
Orange Pi Lite: 23,5 Mbits/sec on average:
 
 
ODROID-C2 with MIMO USB dongle: 31.4 Mbits/sec on average