gnasch

I hope the screenshot helps you out.
 
Please refer to the screenshot. Note that this shows load during a http livestream to one of my computers (not recording, only streaming) and my opi+ is in a closed acrylic case without a fan (which I am going to install after this post). So the temperature is somewhat elevated.
 
CPU load is quite acceptable I guess... Off course during recording it's much higher, but the OPI+ is capable of handling recording also quite wel...
 
 
 

Me neither. Pine is a typical example. They had relatively good campaign - from marketing perspective, they raised solid money, but their relations with community is failing, like you already discovered. Similar case / attitude is with Sinovoip, while other makers do cooperate with community (not just with us) in a range from solid to very good. Xunlong is among those, even it's one of the smallest company. They are actively listening to our comments, adjust future hardware design, sent boards to developers no questions asked (all other makers too, from obvious reason) and they are the only board maker that actually made some donation in last 3 years since this project exits.
 
In general, all board vendors provide crappy software support. None is good enough for usage, but some at least work hard on it. I can put Solidrun here as an example. Since Linux is a community project per se, no company can fix their software on their own. No go. SDK, which comes from chip maker, is usually in a terrible state, unfinished, mainline support is usually mostly on community.
 
Well, at least we have a lot of fun 

Hi, thanks for the efforts making armbian very well and very stable for all the distributions, I'm running with a Cubieboard 1 and other arm devices..
 
I don't want to disturb,
but I'll be a headache to support or add in repository this old A10 device  Mele A1000/A2000? 
I know that is old chip, but I'm feel nostalgia, because was one of  firsts devices supported in linux-sunxi, and Tom Cubie worked at mele, and sell this litlle joys overseas in 2012, and there are a lot of people now that have  this devices too. a lot now sure in the dust and is in mainline kernel also.
 
Tom left Mele, and maked Cubieboard 1, this Mele A1000 I think that have the same configurations, and cubieboard was based on it, this board has no external 40/44 pins headers like cubieboads or other dev devices
 
I forked the library and maked a test,
https://github.com/calhemp/lib/
1) added the fex file (for 3.4.x compilations I think, kernel mainline don't needed right? )
https://github.com/calhemp/lib/blob/master/config/fex/mele_a1000.fex
from https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a10/mele_a1000.fex
2) added a conf file in boards section (i don't know if is correct, I  based from cubieboard.conf file)
https://github.com/calhemp/lib/blob/master/config/boards/mele-a1000.conf
 
Is the correct form to add a device to run compile.sh?
 
I run and maked the image and works like a charm, I think that can be polished but is out of my experience , but now works,
I know that I can compile a new kernel in every update of armbian lib, but I don't know if it can be added to baords list of armbian, and have a fresh compile every update of the libs.
 
and if is a problem I will do it as now of if can be a better configure option, I'm a all ears.
 
thanks in advance. Pere.

Fear not!
this temperature is actually quite moderate.
 
best, gnasch

Hi Igor, Hi Armbian team,
 
I wanted to give a short teaser of an upcoming board I have been developing. The board will be launched through a crowd-funding campaign in couple of weeks.
 
Codename : Helios-4
 

 
I'm sure the heatsink will give you some hint The board has been build around the Marvell Armada 388 SoC / SoM from SolidRun. So part of the design is inspired from the Clearfog dev board. Actually the SolidRun helped me on the PCB layout to make this little guy reality.
 
Here the main specs :
- dual core A9 @1.6 GHz (max 2Ghz) - 1GB DDR3 (2GB optional) - 4x SATA III - 2x USB 3.0 - 1x Gigabit Ethernet - Micro SD card - Built-in HDD power circuitry for 4 disks  - 2x Fan PWM headers - I2C, GPIO and extension pins - Micro USB to Serial - Dimension 100mm x 100mm   So clearly I have started this project with one main goal in mind : to finally bring to market the 1st ARM based board which has been designed specially for NAS purpose. I was frustrated to not find any affordable ARM board which has more than 1 SATA port.   Optionally the board will come along with a full kit, acrylic casing fitting 4x HDD (3.5'), 2x FAN, oled screen, cabling and power adaptor. Once assembled, it's the smallest 4x 3.5' disk NAS that you could find our there ;-) If people interested, I will post some pic.   Anyhow I stop my pitch here ;-)   Having used Armbian images and the build framework / toolchain for quite some times, it was logical for this project that the baseline image for Helios4 would be done via the Armbian project.   I recently started to dig into your repo to see how to contribute and squeeze my board in. I might need some guidance later, so I hope I can seek a bit of support from the team. I'm also super keen to donate aboard if it can help ;-)   Hope it was the right place to post this.   Cheers.

Designed a case for it. Available on thingiverse if anyone interested - http://www.thingiverse.com/thing:1918590
 

It is expected since the only way to keep out-of-tree modules during kernel upgrades is DKMS, and it doesn't work properly due to kernel upgrade scheme that is used in Armbian.

ROFL... Really, i can't stop laughing.
 
 
Ok, serious now, i will try to answer.
 
* CAM500B works only on FriendlyArm M1/Neo Air boards AFAIK, no need to change anything. CAM500A needs to change logic level to work on M1/Neo Air.
 
* Orange Pi PC/One needs the extention, and you need the pins reversed (OV5640), you can either get a Banana Pi sensor (no need to reverse the pins with this sensor) or use this FPC cable (this might work).
 
* If your board is Banana Pi M2+,M64 you just need their sensor (OV5640).
 
This thread ended with general information about how to use OV5640 on OPI, FA and Banana Pi boards .
 
Thanks for the FPC/FFC cable tip.
 
* Update: Not sure the FFC reversed cable will work since you have to reverse the pins on the output connector!

About armbian.com/download/:
pages for some boards have links to forum thread/section, i.e. https://www.armbian.com/pine64/
I guess these links will be added eventually for boards that have separate discussion thread or forum section
 
About chipsets and board threads:
not all boards have separate discussion threads dumping any board related question into one thread will create an unreadable mess, and some people will still create new topics even if you put large red blinking text telling them not to do that. and most boards on same SoC or SoC family will share the same SoC specific problems, so splitting forum per SoC and per board is not needed to IMO

The image was made for this contest ONLY!
 
Designed by: AntwanDesign
tronCube.zip

What about that?
 

Hi again,
 
I successfully made overlayroot work under Debian Jessie.
 
Ubuntu package
 
I installed overlayroot_0.27ubuntu1.2_all.deb package
wget http://fr.archive.ubuntu.com/ubuntu/pool/main/c/cloud-initramfs-tools/overlayroot_0.27ubuntu1.2_all.deb dpkg -i overlayroot_0.27ubuntu1.2_all.deb Correcting overlayfs module name
 
About the following error:
Failure: overlayroot: missing kernel module overlayfs I had to modify the /usr/share/initramfs-tools/scripts/init-bottom/overlayroot file:
Here is a diff:
diff --suppress-common-lines -r -y ./usr/share/initramfs-tools/scripts/init-bottom/overlayroot /usr/share/initramfs-tools/scripts/init-bottom/overlayroot VARIABLES="overlayroot overlayroot_cfgdisk"                   | VARIABLES="overlayroot overlayroot_cfgdisk overlayroot_driver         overlayfs)                                            |         overlayfs|overlay)                 mount_type="overlayfs"                        |                 mount_type="overlay"                 mount_opts="${mount_opts} overlayroot ${ROOTM |                 mount_opts="${mount_opts} overlay ${ROOTMNT}" mount --move "${ROOTMNT}" "${root_ro}" ||                     | mount -o move "${ROOTMNT}" "${root_ro}" ||         mount --move ${root_ro} ${ROOTMNT}                    |         mount -o move ${root_ro} ${ROOTMNT} mount --move ${root_ro} "${ROOTMNT}${root_ro}" ||             | mount -o move ${root_ro} "${ROOTMNT}${root_ro}" || mount --move "${root_rw}" "${ROOTMNT}${root_rw}" ||           | mount -o move "${root_rw}" "${ROOTMNT}${root_rw}" || As you can see, I added one variable to the VARIABLES list and made some changes to mount parameters.
 
Here is the complete file:
 
 
 
I modified the /usr/share/initramfs-tools/hooks/overlayroot:
diff --suppress-common-lines -r -y ./usr/share/initramfs-tools/hooks/overlayroot /usr/share/initramfs-tools/hooks/overlayroot manual_add_modules overlayfs                                  | manual_add_modules overlay Configuration
 
I added a file named /etc/overlayroot.local.conf (instead of modifying /etc/overlayroot.conf):
overlayroot_cfgdisk="disabled" overlayroot="tmpfs" overlayroot_driver="overlay" Chrooting to R/W
 
Last but not least, I had to modify the overlayroot-chroot executable
diff --suppress-common-lines -r -y ./usr/sbin/overlayroot-chroot /usr/sbin/overlayroot-chroot         overlay=$(grep -m1 "^overlayroot / overlayfs " /proc/ |         overlay=$(grep -m1 "^overlay / overlay " /proc/mounts  
 
 
Fast-forward
 
I attached an archive with the modifications.
 
Using
tar zxvf overlayroot-debian-lauhub.tar.gz -C / after package installation should do the trick
overlayroot-debian.tar.gz

Well, I eventually got it working :
 
- first I also forgot to signal I had change : "ControllerMode = bredr" in /etc/bluetooth/main.conf (not sure it is necessary)
- second in /etc/init.d/ap6212-bluetooth, in hciattach command the serial speed is at 115200 and fex/uboot param don't seem to be relevant. I had to put it at 1500000, otherwise the daemon drops furiously samples.
- and the major problem :
 
The sink is by default connected to the headset profile at 8KHz mono (and it seems it doesn't work). You need to change it :
 
- pactl set-card-profile <num> a2dp_sink
 
<num> has to be retrieve with : pactl list cards (and it changes constantly !)
 
But there is there also a bug : the next time the daemon will fail to reconnect the (recorded) profile and you will need to reset the "headset" profile, reconnect and reset a2dp : pactl set-card-profile <num> headset_head_unit + stop/start the device + pactl set-card-profile <num> a2dp_sink
 
(The web is full of advises on people that explain that in normal mode with graphical interface, they need to alternate between profiles and restart the device before they can connect a2dp)
 
I will now look if I manage to get the AVRCP profile connected threw uinput in order to read next/back commands.
 
I end my comments here as it seems nobody is interested in BT on armbian.
 
PS: second device, other problem ...
 
It seems this one does not have his audio profile automatically connected. So if the device fail to be recognized by pulse or if it refuses to switch profile (with set-card-profile), try a connect <addr> with bluetoothctl ...
 
PS2: workaround
 
It seems profile selection bug is well knows (but not corrected in pulseaudio 8). After many tests, I think that the better solution is to NOT load the "module-card-restore" module. Otherwise, this module will reset the ad2p profile and bluez module fall in bugs and race conditions. So the workaround become :
- disable module module-card-restore
- monitor dbus events
- on base [device] connection event, force connection by bluetoothctl connect, in order to connect audio profile (if device does not do that itself)
- on audio [media] connection event, switch profile to a2dp
- on [transport active] event start playback
 
There are other bug that may need to be handled, but with the method described above, I can get a fast clean working server.
 
Of course I think that this is only relevant for one version of (pulse, bluetooth, dbus)

How is blocking tivoization a bad thing? I've built commercial products on the OrangePi PC, the relevant project is on github with a nice little bash script to install & configure it all, but the thing is, if you design your business model well, having tivoized hardware is not useful or beneficial.
 
Red Hat and other giants have gotten this far without Tivoizing their offerings, and the only businesses intent on doing so are either doing it to protect a weak business model, or arcane reasons that generally do not make sense and will not generate extra revenue.

I managed to write H3 HDMI driver for mainline U-Boot. Source can be found here:
https://github.com/jernejsk/u-boot
 
You should also add CONFIG_VIDEO=y to defconfig for your board.
 
It should work nicely for standard resolutions (720p, 1080p). Other resolutions might work, but some additional work needs to be done. Currently, this can be used for working with U-Boot (instead of serial console) or splash screen.

Armbian Net

The python library from https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 is supporting I2C as well as SPI, along with plain GPIOs.

Hi,
 
I'am the new one. I'am German and bought last month an OrangePi PC+ from AliExpress without a clue what todo with it, but it was cheap ;-) And it was perfect for my new OMV.
 
Just installing OMV on top of Armbian / Jessie was not enough because of missing Quota Kernel Options. When setting up a development Enviroment, I found the excellent Build-Scripts of Armbian and thought, why not making an OMV-Image with the customize-image.sh.
 
And here is it (quick and dirty v0.1) Just copy it with a modified kernel.config under userpatches.
It should work with every supported Armbian Board as long as its working with Debian Jessie, because it installes OMV3.X
I compiled my Image with the legacy Kernel but it should also work with mainline.
 
If wanted I can build some Images for testing.
Please give some feedback or critics, I hope its helpfull for someone.
 
Sorry for attaching this as Code but I can't upload attachments?


#!/bin/bash

#################################################################################################################################
## customize-image.sh - for installing openmediavault 3
##
## installs omv, omv-extras, omv-flashmemory
## and making some changes to the System
## started in chroot from /tmp
##
## arguments: $RELEASE $FAMILY $BOARD $BUILD_DESKTOP
##
## Author : Benny St <Benny_Stark@live.de>
## Version : 0.1
##
## Version 0.1 - first Release
##
#################################################################################################################################
RELEASE=$1
FAMILY=$2
BOARD=$3
BUILD_DESKTOP=$4

#Modified display alert from lib/general.sh
display_alert()
#--------------------------------------------------------------------------------------------------------------------------------
# Let's have unique way of displaying alerts
#--------------------------------------------------------------------------------------------------------------------------------
{
# log function parameters to install.log
#[[ -n $DEST ]] && echo "Displaying message: $@" >> $DEST/debug/output.log

local tmp=""
[[ -n $2 ]] && tmp="[\e[0;33m $2 \x1B[0m]"

case $3 in
err)
echo -e "[\e[0;31m error \x1B[0m] $1 $tmp"
;;

wrn)
echo -e "[\e[0;35m warn \x1B[0m] $1 $tmp"
;;

ext)
echo -e "[\e[0;32m o.k. \x1B[0m] \e[1;32m$1\x1B[0m $tmp"
;;

info)
echo -e "[\e[0;32m o.k. \x1B[0m] $1 $tmp"
;;

*)
echo -e "[\e[0;32m .... \x1B[0m] $1 $tmp"
;;
esac
}


case $RELEASE in
wheezy)
# your code here
;;
jessie)
#change root passs first
#else we get some configure-errors
display_alert "Change Root PW" "custom-image.sh" "info"
echo root:openmediavault|chpasswd

display_alert "Change /etc/hostname" "custom-image.sh" "info"
echo "openmediavault" > /etc/hostname ## works after reboot

#generate locales
#they are not there
display_alert "Generate Locals and set them" "custom-image.sh" "info"
locale-gen "en_US.UTF-8"
locale-gen "C"
export LANG=C
export LC_ALL="en_US.UTF-8"

#Unattended apt-get
export DEBIAN_FRONTEND=noninteractive

#Add OMV source.list and Update System
display_alert "Adding OMV-Repo erasmus and update" "custom-image.sh" "info"
cat > /etc/apt/sources.list.d/openmediavault.list << EOF
deb http://packages.openmediavault.org/public erasmus main
## Uncomment the following line to add software from the proposed repository.
# deb http://packages.openmediavault.org/public erasmus-proposed main

## This software is not part of OpenMediaVault, but is offered by third-party
## developers as a service to OpenMediaVault users.
# deb http://packages.openmediavault.org/public erasmus partner
EOF
apt-get update

# OMV Key
display_alert "Install OMV Keys" "custom-image.sh" "info"
#wget -O - packages.openmediavault.org/public/archive.key | apt-key add -
apt-get --yes --force-yes --allow-unauthenticated install openmediavault-keyring
# OMV Plugin developer Key
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 7AA630A1EDEE7D73


#install debconf-utils for postfix configuration
display_alert "Install debconf-utils" "custom-image.sh" "info"
apt-get --yes --force-yes --allow-unauthenticated --fix-missing --no-install-recommends -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install debconf-utils

#install postfix
#Postfix configuration
display_alert "Install postfix and configure it - No configuration" "custom-image.sh" "info"
debconf-set-selections <<< "postfix postfix/main_mailer_type select No configuration"
apt-get --yes --force-yes --allow-unauthenticated --fix-missing --no-install-recommends -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install postfix

#install OMV
#--allow-unauthenticated because openmediavault-keyring doesn't contain all keys???
display_alert "Install OMV" "custom-image.sh" "info"
apt-get --yes --force-yes --allow-unauthenticated --fix-missing --no-install-recommends -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install openmediavault

#install OMV extras
display_alert "Download and install OMV Keys" "custom-image.sh" "info"
wget http://omv-extras.org/openmediavault-omvextrasorg_latest_all3.deb -O /tmp/omvextras3.deb
dpkg -i /tmp/omvextras3.deb
rm -f /tmp/omvextras3.deb
/usr/sbin/omv-update

#install openmediavault-flashmemory
display_alert "Install openmediavault-flashmemory" "custom-image.sh" "info"
apt-get --yes --force-yes --fix-missing --no-install-recommends install openmediavault-flashmemory
sed -i '/<flashmemory>/,/<\/flashmemory>/ s/<enable>0/<enable>1/' /etc/openmediavault/config.xml
/usr/sbin/omv-mkconf flashmemory

# Tidy up
display_alert "apt-get autoremove / autoclean" "custom-image.sh" "info"
apt-get autoremove
apt-get autoclean

#remove first-login Script
display_alert "Remove first-login Script" "custom-image.sh" "info"
rm /root/.not_logged_in_yet

#remove some services
#ändern auf systemctl enable dienstname.service
# /etc/systemd/system, /run/systemd/system, /usr/local/lib/systemd/system, and /usr/lib/systemd/system are four of those directories.
display_alert "Disable Services - tftpd-hpa, proftpd, nfs-common, smbd, snmpd, ssh"
#tftpd-hpa.service
systemctl disable tftpd-hpa
#proftpd.service
systemctl disable proftpd
#nfs-kernel-server.service
#nfs-common.service
systemctl disable nfs-kernel-server
systemctl disable nfs-common
#snmpd.service
systemctl disable snmpd
#samba.service
systemctl disable nmbd
systemctl disable samba-ad-dc
systemctl disable smbd
#ssh.service
#systemctl disable ssh
display_alert "SSH enable" "custom-image.sh" "info"
systemctl enable ssh
sed -i '/<ssh>/,/<\/ssh>/ s/<enable>0/<enable>1/' /etc/openmediavault/config.xml

#FIX TFTPD ipv4?
display_alert "tftpd-hpa ipv4 startup fix" "custom-image.sh" "info"
sed -i 's/--secure/--secure --ipv4/' /etc/default/tftpd-hpa

#adding omv-initsystem to firststart
display_alert "adding omv-initsystem to firstrun" "custom-image.sh" "info"
echo "/usr/sbin/omv-initsystem" >> /etc/init.d/firstrun


#debug shell
#/bin/bash
;;
trusty)
# your code here
;;
xenial)
# your code here
;;
esac

I am happy to report success when using native 1280x1024 resolution on an older Samsung 191T display using
h3disp -m33 -d on an Opi Pc updated to 5.20.
On the other hand the 8192cu driver delivered with 5.20 does not work, wireless only started to work after local
recompiling and installation of the module as described in the documentation.
Power to the device also had to be cut and reapplied.
 
Thanks for the nice work!
gnasch

Can you please provide the output from ' lpstat -t' and put the PPD that's now used in Wheezy and can be found below /etc/cups/ppd/ on pastebin.com or something similar?
 
Normally Linux 'drivers' for Brother printers are GPL licensed Perl wrappers around scripts that do this and that to work within every possible printing system (CUPS is not the only one). I'll never understand why Brother advertises printers capable of PCL or even PostScript 3 as GDI printers or provides .debs for i386 architecture only that do not contain any platform specific code and could be installed using 'dpkg -i --force-all '.
 
In case you've the Jessie installation around getting the "Generic CUPSwrapper printer driver (deb package)" from here http://support.brother.com/g/b/downloadlist.aspx?c=de〈=de∏=hl2130_all&os=128&flang=Englishand giving it a try with 'dpkg -i --force-all ' (after installing CUPS of course) would be an idea.

I am happy to report success when using native 1280x1024 resolution on an older Samsung 191T display using
h3disp -m33 -d on an Opi Pc updated to 5.20.
On the other hand the 8192cu driver delivered with 5.20 does not work, wireless only started to work after local
recompiling and installation of the module as described in the documentation.
Power to the device also had to be cut and reapplied.
 
Thanks for the nice work!
gnasch

*Update:
 
I commented out 30fps and enabled 90fps and the driver is now capable of 90~100 fps on 640x480. If we can fix the color/exposure this sensor looks very promising.

the nice thing with the Armbian tool is "this is all scripted"
 
so you can trace anything you want while you build your own image. So you can check yourself with your security team, if it is accurate for you.
 
Then if something is not right for you, you can fork the project and fix it as you need (making the whole community benefits from your changes if needed)

U-boot for the boards, there are no command "autosrc usb mmc emmc bootp" ?
 
The tester, who does not know that it is happening in the system (which carriers and why they are used) ?????
Better not to have such testing.
 
About the pros and cons of LABEL. Suppose such a scenario. Recorded image on the SD card of 16 GB . Checked. Works. Decided to move on the USB flash drive of size 8 GB. When using LABEL. Simply copy all the directories and files (as is) to a new medium. And assign a LABEL. Made changes to the system during testing. Created archive. Then deployed on any medium, even smaller (considering the size of the files). Can be easily transferred to testing by other users of the entire system "as is" for any media. I do not impose. I just share information. By the way, if the console UART, write and debug the script  - not difficult. When you work (if using) on other boards it is rarely necessary to edit (console UART is not needed). Enough to rule the working scripts, which defines all the features of the system startup (which you can change). This algorithm is already well established.

Repository is updated to latest version (jumped to 5.20) so it's possible to test upgrades.