lanefu

I have installed Netatalk 3.1.11 and tried the Helios Lan Test. The storage used by netatalk is an SSD (OCZ Vertex 128G) attached to the SATA port of espressobin (see the test results below).
 
Additionally, I manually uploaded a 2260MB file via the macOS finder (afpd) to espressobin in 52s (43MB/s) and downloaded it again to a MacPro in 20s (113 MB/s).
I guess that the write speed is limited by the SSD - read speed of netatalk/espressobin is pretty impressive ...
 
I have used the latest Armbian image (Armbian_5.32.170626_Espressobin_Ubuntu_xenial_default_4.4.73.7z) - If you have a more recent image to test, please let me know.
 
 

Since I don't have one unit yet and the information related to this board is scarce, I'd like to ask if someone who owns one could test what the power budget for the board is. In Marvell's github wiki there is the following mention:
 
 
It would be really great if under load and with all the network ports connected to gigabit the board only took 1W@12V.
 
I found a script in github that would help to reduce power usage:
 
https://github.com/MarvellEmbeddedProcessors/main/wiki/Power-Saving-Script
 
Thanks for you help. Depending on the results I may have a solution for one project where I need to use a dual-lan board with low power consumption.

Patches are being pushed on patchwork for mainline support of Le Potato as promised on Kickstarter.  https://patchwork.kernel.org/patch/9845599/
 
At this rate it will have a better mainline device tree than the Tinker Board (Armbian's NEXT and DEV DTB's are my mashups using the 4.4 device tree from "ASUS" and the Rockchip Linux github)

I forgot to mention that you have to pass the mtd partitioning information via the kernel command line, e.g.
console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=UUID=99415e2c-d205-4dd4-84ba-6804c8e4bc79 rootwait rw fsck.repair=yes governor=ondemand no_console_suspend mtdparts=spi32766.0:1536k(uboot),64k(uboot-environment),-(reserved) net.ifnames=0 elevator=noop  

bonkers

I think paid/unpaid and branching is a fools errand. Anyone who expects to have full support for any rando board isn't going to know the reason for the difference (much less make the Redhat/Fedora association) because they didn't even bother to research into the board or it's kernel before purchase to really get a feel for it's abilities, limitations and current status.

Stable/Experimental, in my mind, is more than sufficient. Keep it as a single branch. Do think things can get a little heated especially with Tech support but no different than any other forum and especially no different than real life tech support, believe me. I have some stories.

I kinda zoomed through the past few comments but I liked the idea of offering a slightly tiered system in terms of payment. For instance, if I could donate towards Armbian dev on a specific board, that would be dope. I would throw several pretty pennies at NanoPiNeoAir. To be honest though, it probably wouldn't affect my donating habits, which is as much and as often as I can afford. W/e though, I'm a strange fruit ;D

Maybe a trend could become visable though if hundreds of cheapos buy OPi Zeros and never donate to the dev of it. Something can be said for the demand and visibility to Armbian by supporting it but something can also be said for the willingness and ability to support.
 
For instance:
~ "Donate here to support X feature of Y board" *Thermometer to goal*
~ Info graphic: Armbian on 9999 OPiZero boards. $50 donated. Armbian on 300 NanoPi Neo boards. $600 donated.

 

IMO no! Make it easier for people who aren't able/willing to read could not be the ambition of armbian.  I think it would be better if we try to explain what WIP means (also explain that WIP doesn't mean that this is finished in the next months), what the difference between mainline and legacy is. Not only in one or two sentences about mainline is for *random application* and legacy is for *other random application*. Bring examples so that people can imagine that legacy/mainline is the better choice for their use cases (showing performance of multimedia application in mainline/legacy, or a serverapplication moved from legacy to mainline). Explain why mainline needs so much time to implement. 
If there are two "brands" you have to decide what's needed to call it armbian or 'WIPian'. A propper definiton of 'stable' 'testing' 'experimental'  is IMO way to go. 
Something like: stable means network works, usb works, gpio works (e.g. onewire, i2s, i2c), wifi works etc.  testing means: we think that all these things should work but aren't sure, experimental means: not recommended for end users, use this images only when you're able to solve problems by yourself or you're able to improve the support status (I like tkaisers link about smart questions, maybe this should be a 'must read' bevor asking questions about experimental builds).
For example: Asus Tinker is claimed to be stable (mainline) but:
Known issues: Ethernet driver needs some fixing (Downloadpage) Bluetooth seems to be still WIP (Forum) Camera on CSI seems only work with a 'questionable' move  Display on DSI Don't understand me wrong, especially @TonyMac32 does a really good job on the thinker board, he spends a lot of time explain the current status, give support (for sure the most activ supporter in the rockchip subforum). But, as long as these things aren't solved it's not stable for me (thinkting as a user not as a dev). Especially for a SBC which is claimed to be a 'RPi with more power' (it's not armbians faults that average joe thinks this is a overpowered RPi) but this is a board where a lot of former RPi users will join armbian with an atitute like 'my VW golf has now a ferrari engine! so why does the gear not working anymore?'. When I started with my first RPi (Model B ), nobody asked for CSI or DSI cause there weren't any cameras and displays on the market. But this changed and an average SBC user thinks this should work (especially cause the tinker looks like a nice colored RPi).  Just flag it as 'testing' could help that people understand that not everything is working at the moment. For sure, there will be still stupid questions why *random function* does not work but it's easier to understand when your armbian is flaged yellow or red that something doesn't work than if it's green. 

It's simple guide, presenting how to setup LCD (ili9431) with integrated touchscreen (tsc2046) on mainline kernel (4.11). It may be not fully "armbian way", since I'm pretty new in armbian
 
In case that somebody is interested, I recently bought couple those displays from here
 
Few basic informations:
 
1. OrangePiZero has two SPI buses. First one is usually occupied by build in memory. So we can only use bus1
2. tsc2046 chip is fully compatible with ads7846, and we have drivers for it since years now
3. Maximum clock frequency for ads7846 is 3.25Mhz, but don't expect that it will work with that.  Reasonable value is something beetween 0.5-2Mhz. Lower frequency, if you observing misbehavior.
4. Probably most important information  ili9431 and tsc2046 poorly cooperate on shared bus. I don't know exactly why, because I don't have access to logic analyzer,  but it's proven fact (at least on my equipment). You have to lower bus frequency to 2MHz (highest common value), and even then it work very unstable.  My educated guess is that, missed interrupt from touchscreen (when SPI is busy with sending data to LCD) makes it stop making further attempts to communicate. Or maybe there is some incompatibility on electrical level, I really don't know.
5. My electrical setup (keep in mind it's 3.3V)
 
OPIZ - LCD (ili9431)
PA13 - CS
PA14 - SCK
PA16 - SDO
PA15 - SDI
PA03 - DC
PA00 - RESET
PA06 - controls transistor which is driving current to LCD pin. You may also connect LCD pin to VCC, and leave PA06 floating.
 
And here is part for touchscreen. We are going to use emulated spi bus with bitbang. At this point bitbang isn't compiled in armbian kernel - we will take care of this later.
 
OPIZ - LCD (tsc2046)
PA10 - T_CS
PA18 - T_IRQ
PA19 - T_CLK
PA11 - T_DIN
PA12 - T_DO
 
Configuration for the first spi bus:
 
Configuration for touchscreen driver:
 
Compile and add those DTS with "armbian-add-overlay" command.
Next, download armbian sources and cross compile kernel - without any modifications, just to make sure that everything is compiling without issues:
# mkdir armbian # cd armbian # git clone https://github.com/armbian/build.git # git clone https://github.com/igorpecovnik/lib # cp lib/compile.sh . # ./compile.sh BRANCH=dev BOARD=orangepizero KERNEL_ONLY=yes PROGRESS_DISPLAY=plain RELEASE=jessie Enable required modules :
echo "CONFIG_SPI_BITBANG=m" >> lib/config/kernel/linux-sun8i-dev.config echo "CONFIG_SPI_GPIO=m" >> lib/config/kernel/linux-sun8i-dev.config ... and recompile kernel, then install deb packages from output directory. You may also copy drivers, it may be faster for testing but it's not advised for "serious" deployment.
Loading modules at startup:
# cat > /etc/modprobe.d/fb_ili9341.conf << _EOF_ options fbtft_device custom name=fb_ili9341 gpios=dc:3,reset:0,led:6 speed=16000000 busnum=1 _EOF_ # echo fbtft_device >> /etc/modules # echo ads7846 >> /etc/modules If you connected LED pin to VCC, then you should omit that ",led:6" in configuration above. 
 
I hope that this will help anyone who want to connect LCD display and build simple touchscreen based Orange Pi Zero terminal

 
 

The rk3288's H.265 support is supposedly a bit buggy and is considered "legacy" hardware by Rockchip.  I've not tested it to be honest, as I've been working on the peripherals/etc. 
 
@chwe I doubt my reply meets Heinrich's quality standard for freely provided information, sadly.

@default0
 
Sorry HDMI is only external.   Allegedly there is an analog video in if you can find the test points and make a connection, but as far as I'm aware the analog video capture doesn't work either.

Here are the steps to get a legacy H5 kernel running with Mali r5p0:
* Linux kernel from: https://github.com/OrangePiLibra/OrangePi_H5SDK
* Here is my legacy kernel generation script: https://pastebin.com/w1b4exzW
* Mali kernel module: DX910-SW-99002-r5p0-01rel0 from here: https://developer.arm.com/products/software/mali-drivers/utgard-kernel
* Mali kernel patch:  https://pastebin.com/VnJgZWZJ (name: DX910-SW-99002-r5p0-01rel0.patch)
* Blob: mali450r5p001rel0linux1fbdevarm64v8a
* Good benchmark/test utility: glmark2-es2-fb. The blob is a aarch64 one, so we must use a aarch64 linux environment to compile and run glmark2-es2-fb.
 
#script template:
#orangepi_h5sdk_dir link to repository: https://github.com/OrangePiLibra/OrangePi_H5SDK
yourkernelorangepih5sdkfullpath="<>"
f="DX910-SW-99002-r5p0-01rel0";rm -Rf mali_r5p0/;tar xf $f.tgz;(cd $f/;cat $f.patch|patch -p1);mv "$f/" mali_r5p0/; #mali450r5p001rel0linux1fbdevarm64v8a
mkdir -p mali_r5p0/driver/src/devicedrv/mali/include/linux/aw/sun50i/;
cp orangepi_h5sdk_dir/kernel/modules/gpu/mali450/kernel_mode/driver/src/devicedrv/mali/linux/mali_platform.c mali_r5p0/driver/src/devicedrv/mali/linux/mali_platform.c
cp -dpR orangepi_h5sdk_dir/kernel/modules/gpu/mali450/kernel_mode/driver/src/devicedrv/mali/include/linux/aw/platform.h mali_r5p0/driver/src/devicedrv/mali/include/linux/aw/
cp -dpR orangepi_h5sdk_dir/kernel/modules/gpu/mali450/kernel_mode/driver/src/devicedrv/mali/include/linux/aw/config.h mali_r5p0/driver/src/devicedrv/mali/include/linux/aw/
cp -dpR orangepi_h5sdk_dir/kernel/modules/gpu/mali450/kernel_mode/driver/src/devicedrv/mali/include/linux/aw/sun50i/sun50iw2p1.h mali_r5p0/driver/src/devicedrv/mali/include/linux/aw/sun50i/
sed -r -i "s/^(int mali_fb_start = )0(;)$/\10x7f040000\2/; s/^(int mali_fb_size = )0(;)$/\17372800\2/" mali_r5p0/driver/src/devicedrv/mali/common/mali_kernel_core.c; #from: fbset -i
#(cd mali_r5p0/driver/src/devicedrv/ump;(make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnueabihf- -j 8 KDIR=${yourkernelorangepih5sdkfullpath} V=1 BUILD=release))
(cd mali_r5p0/driver/src/devicedrv/mali;make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnueabihf- -j 8 KDIR=${yourkernelorangepih5sdkfullpath} V=1 USING_UMP=0 USING_DT=1 BUILD=release)
 

Hi Guys,
 
That's nice to see the effervescence around Helios4. We have a pretty good start for the first 48hours, we are very optimistic.
 
Thanks @tkaiser for being so proactive and already answering most people questions. I saw you were very active on CNX ;-) I have so many question to reply through KS, it's hard to catch-up.
 
I take note of all your feedback. Regarding the HDD vibration absorbers and the filter screen, it's something I had already in mind but haven't found yet the right solution. Take note that the thickness of the acrylic plate is much ticker than usual PC metal case, so standard absorber won't fit. If I can find the right solution we might put these as part of the kit by default.
 
Haha i see someone really wants its ECC RAM, but yes agree It would be a great stretch goal.
We were also planning in the stretch goal list to include a OLED i2c screen.
 
But well, first we need to see how the campaign progress in the next few days before dreaming too big.
 
Cheers.

I must admit it looks very nice and it's truly first properly NAS oriented board. I hope you will manage to keep the price low enough to keep wide interest. Since it's backed by Armada 388 and co-developed by Solidrun, things should be fine and Armbian must work on it ... I assume with some minor adjustments due too slightly different configuration.
 
Currently we are changing configurations for clearfog and clearfog pro from armada so this is related.
Generally, config goes here:
https://github.com/igorpecovnik/lib/tree/master/config/boards
Sources if different here:
https://github.com/igorpecovnik/lib/tree/master/config/sources
and patch if needed here:
https://github.com/igorpecovnik/lib/tree/master/patch
 
I assume diff to Clearfog is minor so, you only need to add board config and a patch under u-boot.
 
BTW. Lately, I saw other commercial project made with Armbian so I am also glad that our work finds the way in. Send us a box of beer, when you get rich 

Hi sniffyjaay
 
i have several opipcplus working in a "lean desktop" mode. They run armbian 5.25 jessie with the legacy kernel. I have tried to cut back on the insane writing of cache and state data by firefox, have installed qpdfview, the complete libreoffice, xfce4-power-manager and lightdm instead of nodm.
They are always on and run reliably over ethernet or wlan connected by the user's mount to a samba server with the data.
As surfing station and Office PC they run reasonably fast, especially when you consider that you don't have to wait for endless windows starts and -updates. When a user is logged in but not active, the OpiPcPlus falls asleep after selected half hour, and stays ready consuming only a few mA until the button is pressed, then it is back within a second. I did not bother with cases, but mounted the pi's vertically with 5mm distance on a little wood plate fixed to the desk. This plate also holds the wifi antenna on its top. The natural airflow before and behind the board is easily sufficient for cooling with a simple Al heat-spreader.
 
Until now I failed to have them fall asleep when unused without user login, although I edited logind.conf.
I would like to achieve this not only to save the little energy, but also to save writing to the SD card and to stop burning an image into the monitor.
 
hth,
gnasch
 
 

Okay.... I built a new OMV image last night... Frequency Scaling is working.. sweet
 
So I need some helio tests to smb. Using my MBP w/ Thunderbolt gig NIC . to cheap SANDisk X300... I did onboard sata.. and another testing with my add-on sata card.
 
no bad at all.   Writes seem to be thread bound by samba.   This was traversing accross my 48port POE switch, not point to point.. same vlan.
 
@tkaiser OMV is promising.
 
I had tested some raid 5 stuff, but turns out i had a bad sata cable causing my woes
 

For all I did there, I would say I can't represent the whole MediatTek, the contributions mostly comes from those passionates in MediaTek internally
and the core member in LEDE/Openwrt.  Many people still don't recognize importance gained from open source I admit.  I don't blame them because
everyone has different experiences for defining what success is for them although I still have a little complaining on them as @tkaiser did it for sinovoip
why let me do the unnecessary and repetitive thing again wasting so much time and energy if they are done well in the initial.
 
Instead, I would like to change their mindset as much as possible through upstreaming activity to help to link irrelevant groups among MediaTek internal,
various communities, existing developers, potential users and so on to produce more chemical changes getting more attention on the importance of open source
and prove commercial product still can be done well with combining appropriate open source project and finally allow us all together walking on the right path.
 
Maybe there'll  a lot blames/questions/suggestions on coming bpi-r2, but I will be glad to listen to and reflect them into the MediaTek internal, and even
welcome delivering patches to me making more robust to BSP

Even if you 'open source code on github' this happens:
You 'open' what the Soc vendor gave you (sometimes with minor modifications), eg. https://github.com/BPI-SINOVOIP/BPI-M2U-bsp Since you, Lion Wang, are a chip head obviously not able to understand what software is I try to explain to you one last time: This is a 3.10.65 kernel now 2.5 years old containing a lot of security vulnerabilities. No one right in his mind wants to use this with Linux. 'The community' you think should help you in fact still tries to help you all the time as they did the last 2.5 years already. They do your work, invest many many hours to patch this smelly old kernel up to most recent 3.10 LTS version 3.10.106: https://github.com/dan-and/BPI-M2U-bsp (you ignore this now since over half a year, Daniel started to fix your failures on 15 Dec 2016) Since your level of ignorance is that insanely high (it would take you maybe 10 minutes to merge Daniel's patches into your repo to save your users at least from most severe security vulnerabilities), Daniel decided to send you all his work as a pull request. N° 1 sent on May 17 got ignored for over 5 weeks, now N° 2 containing another fix gets ignored since 4 days. (you have to click a button on github, takes 1 second max) Your level of ignorance is that high that you're able to ignore someone wasting hours of his life trying to fix your failures while at the same time cherry picking this. In other words: you are aware that there's an open source community member wasting his time to provide you with fixes for your smelly kernel release, you ignore all of his work but choose one single improvement to be merged into your sources. I miss words for that. At the same time a lot of people experience instabilities with the same device. Users are on their own since you simply ignore this. Users in your forum are discussing DRAM settings being the issue, several users all on their own at least try out some improvements and this is what happens: https://github.com/facat/BPI-M2U-bsp/commit/dff5ffe35dc22b2904993b0441c6cf6dd54efd0f#commitcomment-22739082  
Please tell me how 'community' should be able to help you? You're behind a wall of ignorance stronger than anything at least I could imagine. What about exploring how to fix this?
 
@sean.wangwish you good luck when hell breaks loose as soon as R2 starts selling.
 
 

haha.. My dad was a reporter so he used his TRS-80 model 100 until like 1999 or 2000.   He'd always go back to it for writing his final copy.    "6 hours of battery life on 4 AA rechargeables" 

Well, if the under-powered hardware is the talking point, I used my TRS-80 model 100 portable as a linux terminal just to prove it could be done...

The CHIP is a cool little board.   Ive got a pocketCHIP which is always surprisingly fun to use as a SSH remote control.
 
i gotta give nextthing credit for completeness.

i always have to dig my electronic stuff out sadly.   I need more workbenches

https://sites.google.com/site/zberrysbc/
 
Is it worth it?  Assuredly not, but you can't help but smile if you have any sense of nostalgia.  It also doesn't help that the entire thing can be implemented in an FPGA, although that may actually turn out to be more expensive...

A kernel layer (subsystem) for accessing raw NAND and NOR flash based storage.

Most of us probably do some electronics along with the small computers, I've been part of "what does you desktop look like?" threads (terrible, by the way), thought I'd put up (the electronics part of) my workbench:
I wasn't about to lie and clean it up before hand...
 

Sure, but they need to get better!
 
Off-topic 2: that's what I do for a living sometimes: