wildcat_paris

Did you miss some lines in the scripts by chance? (latest lib, lime2, 3.4.112, jessie, with extras and desktop)
[ o.k. ] Applying common tweaks install: cannot stat '/[...]/lib/config/hostapd/hostapd.conf': No such file or directory install: cannot stat '/[...]/lib/config/hostapd/hostapd.realtek.conf': No such file or directory

Repository recreated, now also those errors should be gone @Wazou 
* [jessie-desktop]: Armbian desktop (packages: 41) * [jessie]: Armbian main repository (packages: 1403) * [trusty-desktop]: Armbian desktop (packages: 0) * [trusty]: Armbian main repository (packages: 1389) * [utils]: Armbian utilities (packages: 4) * [wheezy-desktop]: Armbian desktop (packages: 0) * [wheezy]: Armbian main repository (packages: 1357) * [xenial-desktop]: Armbian desktop (packages: 41) * [xenial]: Armbian main repository (packages: 1151) Next tomorrow.

Huh. I actually prepared this way, but forgot     and now I only merged utils into one.
 
Summary example:
 
[ o.k. ] List of local repos [ local ] * [jessie-desktop]: Armbian desktop (packages: 41) * [jessie]: Armbian main repository (packages: 36) * [trusty-desktop]: Armbian desktop (packages: 41) * [trusty]: Armbian main repository (packages: 36) * [utils]: Armbian utilities (packages: 7) * [wheezy-desktop]: Armbian desktop (packages: 0) * [wheezy]: Armbian main repository (packages: 36) * [xenial-desktop]: Armbian desktop (packages: 0) * [xenial]: Armbian main repository (packages: 36) I guess it should work now. Which issues are still regarding repo? 
 
dkms - agree it would be nice to do the proper way but I won't touch this at the moment.

wow you are one of the most active developer I ever seen. great work man.
thanks!
 
last question: where do i choose between legacy and vanilla kernel? i suspect that the image on armbian site (http://www.armbian.com/orange-pi-pc-plus/) is built with the legacy kernel but i would prefer the most updated vanilla kernel

So now it is working, thanks a lot.

I am using trusty on my Desktop and there is no reason for me to change to xenial at the moment.
 
Regards

I think this is the main "problem".
If you are using separate VM for working with Armbian, I would recommend upgrading to Xenial (or installing it from scratch) later, currently build script is tested only on Xenial.
Since these toolchains are not needed on Trusty AFAIK, they won't be downloaded on Trusty in the future.

First, make sure you know how to control your fan via GPIO: you will need either NPN or MOSFET transistor and a resistor (depending on transistor type), you can look here for example schematics: http://elinux.org/RPi_GPIO_Interface_Circuits
 
The most simple script for your task will look like this:
#!/bin/bash # see script.fex and board schematics for GPIO mappings # i.e.GPIO12 = PA07 = Pin 29 on 40-pin header GPIO=12 # "critical" temperature value, no hysteresis for simplicity TEMP=75 echo $GPIO > /sys/class/gpio/export echo out > /sys/class/gpio/gpio${GPIO}/direction while true; do if [[ $(cat /sys/class/thermal/thermal_zone0/temp) -gt $TEMP ]]; then echo 1 > /sys/class/gpio/gpio${GPIO}/value else echo 0 > /sys/class/gpio/gpio${GPIO}/value fi sleep 10 done You will need to assign correct GPIO number and "critical" temperature value to make this work

Hello guys, I am new to this forum and this is my first thread.
 
I bought a Nanopi M1 and try to play with the GPIO.
I follow all the official instruction and install MatrixGPIO-python
However, after the installing, I would like to test the GPIO with script that come with the Git Clone
The terminal shows me this response "Fail to set gpio direction"
 
Does anyone know how to solve this problem?
Thank you

/me = dumb.
 
I've had that already in another project, so it was/is just c'n'p for the variable definitions (which should be set in compile.sh IMHO), the rest is search-and-replace.
 
Compilation finished in the meantime: Inclusion of the conf worked as expected, and also the after-build hook!

You can't pass them as environment variables (BOARD=cubietruck ./compile.sh), but you can pass command-line arguments (./compile.sh BOARD=cubietruck), it is handled here in main.sh
 
"Keep it simple" and "function over fashion". This is a build script and not a christmas tree  , I don't want to spend time and resources on visual stuff while there are issues to work on. Especially in compile.sh where you need to define colors in place - I'm not against customizing diaplay_alert function later.

Currently I'm working only with one board, so for me it's not an issue. The idea is in case the Armbian script gets broken for a specific board only (I've had this some time ago for a BBB) you would be able to set LIB_TAG to the latest working one in the config-<thisboard>.conf file.
At the moment for me the actual master works fine, so no need here - I justed wanted to bring it to your attention in case you didn't consider this yet.
I just have changed my lib.conf to define the hook and now it's compiling.
 
Regarding my 2nd remark, there LIB_TAG was just an example, you also cannot pass BOARD and such as parameters, therefore my question. But the question is somewhat obsolete now as all of these can be set in the dedicated conf...
 
Anyway thanks for the really fast reply (and action!)
 
Do you dislike the idea of having the color definitions as variables instead of escape sequences at all or should I provide this once more later? But then over all scripts which use colored output...?

I know that this won't work for LIB_TAG and BUILD_ALL parameters, but BUILD_ALL is used mainly by Igor to produce images, and I don't see any use cases for dynamically changing LIB_TAG. In case you want to use your own fork of build script, you just create $SRC/.ignore_changes and use "wrapper" script that updates the code if needed and launches compile.sh afterwards.

Thanks for the hook, I think this will do very good!
 
But regarding the parameters and the inclusion script I have still some questions:
you placed the script AFTER Armbian self-update. This means one will not be able to provide a LIB_TAG by the additional script. maybe I'm not experienced enough in bash scripting, but to my knowledge parameters don't have priority over code. This means if compile.sh contains LIB_TAG="" this won't work:
LIB_TAG="v1.0" ./compile.sh ...or do I miss something? That's the main reason why I proposed the slightly more complex syntax in the patch.

forgot patch
compile_sh.patch.txt

No, this will work in any case, if first parameter is not name of the file but KEY=value pair (i.e. BOARD=cubietruck), it just won't do anything at this stage.
 
Anyway, I pushed some changes: this adds support for additional config files and adds a hook to run after building, so you can put something like this in userpatches/lib.config if you want to:
run_after_build() { [[ -n $SUDO_USER ]] && chown -R $SUDO_USER:$SUDO_USER $SRC }

Hm, the forum doesn't support nested quotes?
 
may be it's a little harder to read, but as the user doesn't have to change anything here I would not consider this a problem. The name of the variable and its standard value are visible and well documented in the comments, so if the user wants to have them changed he would do it in the separate conf (in standard syntax)... Oops, I have overlooked this one. This is better indeed, but it will work only as long as we don't expect more than 1 parameter, correct? good point, I never tried. $SUDO_USER was the only reference to the "real" logged-in user I was able to find. Do you know any better method? As long as it's unsafe this way, I'll put it in [[ -z ]]...

Yes, I know about this syntax, but IMO it's harder to read, this block should be as simpel as possible
 
This solution is more universal because it allows easy switching between several config files
 
And if you run this script while logged in as root user or from "sudo su -" shell ($SUDO_USER is not defined)?

I have done some changes to compile.sh:
Variables are now defined ONLY if not passed otherwise, so they can be set elsewhere without the need to make changes in this file (not necessary, just for readability of code) I have added the escape-sequences for the ANSI-coloring as variables, so they can be used anywhere later. This is just in case someone prefers other colors for output and doesn't want to change each line individually. At the moment it only works within compile.sh as I didn't touch other scripts yet, but I can easily do if I should! in case a file named "armbian_user.conf" is found in the same folder, it will be sourced just before Armbian self-update takes place. Within this file (which is absolutely not necessary to have) the user can set overrides to variables, call other scripts and so on. at the end of the script, all files in $SRC will be owned by the current user (instead of root) Please review the attached patch and apply if ok!
(in case something is missing/wrong also please tell so I can modify and create another patch)
 
[PS: I needed to change the extension to .txt to upload, .patch is not allowed...?]
  compile_sh.patch.txt

Yes, this can be a problem, but you can set
umask=002 in ~/.ccache/ccache.conf and set ~/.ccache owner group i.e.to "sudo" to fix this. Obviously you will need to clear your cache or change permissions manually to apply these changes to already existing files and directories in ccache.
 
You can check "SHARING A CACHE" section of ccache man page: http://manpages.ubuntu.com/manpages/xenial/man1/ccache.1.html
 
Edit: I forgot, you also need to set SGID bit on ~/.ccache directory ("chmod g+s ~/.ccache")

I don't have to remember anything, "smart" autocomplete from history in zsh does it for me automatically  , and persistent options are defined in userpatches/lib.config
 
If you want to keep config files in $SRC directory, I can add something like this at the end (I mean near the end) of compile.sh
[[ -n $1 && -f $SRC/config-$1.conf ]] && source $SRC/config-$1.conf so you can use something like 
./compile.sh lamobo-r1 #or ./compile.sh testconfig It shouldn't do that, I'll have to recheck things

Nope. These sorts of comparisons are only valid if you have a workload that scales linearly with count of CPU cores or you are running moronically silly benchmarks as it's done all the time eg on Phoronix.
 
Real-world workloads look different, most of the stuff is single threaded and therefore will run slower on a 4 x 600 MHz system than on one with 1 x 1200.
 
The reason why I'm thinking about limiting maximum consumption is since we're talking about low-power modes/settings and 'IoT' use cases. Imagine you use one 5V/2A PSU to power 3 boards and imagine a worst case scenario where something went really wrong and on all SBCs countless processes are running with 100% CPU utilization. In such a situation 5V/2A might not be enough and at least one board may freeze/crash, most probably all of them since underpowering is a pretty reliable method to freeze/crash any SBC.
 
That's the reason why I check idle and 'full load' consumption individually and also check the role of consumers (as the LAN9514 USB/Ethernet IC on Raspberries can be considered one) and what happens when an Ethernet cable is inserted or now. Since then you can calculate easily how much more consumption such a worst case scenario would mean and take counter-measures (such as limiting CPU cores or maximum cpufreq).
 
Just as an example how easy such worst case scenarios could be triggered: A few months ago we did a server migration at a customer and as some sort of a burn-in test I let a few thousand images be converted on the new virtual machine while we still tuned settings. Little mistake when setting up the cronjob and then the conversion did not start every hour but every minute instead. So the load was up to +300 pretty fast but since this was Solaris x86 it was even possible to login and to recover from the problem in a shell (while true ; do pkill $converter; sleep 1; done -- do the real work in another shell)
 
It should also be noted that most if not all recent SBC support dynamic voltage frequency scaling (lowering the voltage the CPU cores are fed with when at lower clockspeeds and increasing them with clockspeed -- not linearly bit somehow exponentially) so comparing full load at 600 MHz and 1200 MHz might double performance but consumption will be 2.x times more (maybe even 3.x times -- depends on the dvfs settings used). This has also to be taken into account when settings are defined and for a proper low-power operation the workload has to be analyzed or simply some long time consumption monitoring has to happen since too many factors are involved (dvfs, the specific workload, 'race to idle' concept and CPU cores sitting on low-power states and so on).

Well, if you compare the BOM of an RPi Zero and B+ it's obvious that the latter might add not even $5 to the production costs (this is mass production and all these components are dirt-cheap). So while they might not sell the Zero at a loss they simply don't make enough money with it so why should they try to cannibalize sales of B+ by making the Zero generally available?
 
Anyway back to consumption testing -- still with RPi. Today I wanted to explore the possibility to dynamically limit maximum power consumption of the multi-core RPi (2 and 3). To my surprise this is not possible, you can only limit the maximum CPU core count by editing /boot/cmdline.txt and add 'maxcpus=N' and every change needs a reboot: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=99372
  Even more a surprise: the consumption numbers:   RPi 3: nothing connected, doing nothing, just power led, maxcpus=1 (single core): echo 0 >/sys/devices/platform/soc/3f980000.usb/buspower --> 1120 mW echo 1 >/sys/devices/platform/soc/3f980000.usb/buspower --> 1520 mW Performance: sysbench took 486 seconds running on a single core (at 2640 mW, that's +1120mW compared to the baseline) and tinymembench looks like this in single-core mode:
  Weird to say the least, I disabled 3 CPU cores -- see below -- but obviously that led to some sort of background activity since idle consumption compared to 'quad core' mode increased by a whopping ~360mW while difference between idle and sysbench is 1120mW?   With 4 cores idle consumption was at 1165 mW and a 4-core sysbench run added 2385 mW. Based on this a single-core sysbench should add ~600mW so there clearly is something wrong. But it really looks like this: pi@raspberrypi:~ $ cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 38.40 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 Hardware : BCM2709 Revision : a02082 Serial : 00000000ee6200a5 pi@raspberrypi:~ $ cat /boot/cmdline.txt dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait maxcpus=1 To verify my measurements I simply removed 'maxcpus=1' from cmdline.txt and immediately rebooted: consumption back to normal values (1155mW with disabled LAN9514, 765mW with buspower=0):
 

 
So obviously the preferrable way to limit maximum consumption at least with RPi 3 is to rely on cpufreq scaling, limit max cpufreq for example to 600 MHz and leave count of active CPU cores as is.

One quick test on FriendlyARM NanoPi M3 (8core), stock Debian, kernel 3.4.39, current draw during test: 1.35A (0.5A in idle)

 

I am afraid (or not anymore) that RPI zero will be obsolete before being really available.