tkaiser
-
Posts
5462 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
How come the hdparam -C wakes up the hard disk in the first case and doesn't wake it up in the second case?!?!
Seems like 'special logic' implemented in the drive's firmware. The drive differentiates between 'sleeping by idle timeout' (using 'hdparm -B') and a state where you sent the drive to sleep manually (no, I don't get the logic behind).
It does not work if you add 'hdparm -B255 -S60 /dev/disk/by-id/ata-ST9750420AS_5WS2FWKN' to /etc/rc.local?
Currently I can not test the behaviour of RPi-Monitor when reading empty files. IIRC it will be reported as 0 then (0°C as a sign that the disk is sleeping)
But you should keep in mind that the temperature of a sleeping disk is below an idle disk. The last disk I tested with had an internal temperature of approx. 4°C above the enclosure's internal temp when sleeping. When it was totally off the temperature reported was the same as the enclosure's internal. But this might differ from disk to disk (in the case of the Samsung I tested with the internal thermal sensor must be nearby electronic circuits otherwise I don't get it why there are 4°C difference between sleeping/standby and totally off. In both cases the disk's surface felt identical.)
-
What do you mean with 'vanilla'? There's legacy (3.4) or mainline (4.x). With the latter it might be an idea. But a much better idea would be avoiding writes at all (write commits only every x minutes, ramlog).
For results have a look at
http://forum.armbian.com/index.php/topic/243-debian-jessie-on-bananapi-logging-performance/?p=1455
http://forum.armbian.com/index.php/topic/120-f2fs-for-rootfs/
-
just a breadboard a 4.7K res on a base of a transistor (picture TKasier)
It's a DS18B20 (thermal sensor via 1-Wire). I had to learn it the hard way that in the SBC world all this thermal measurement stuff totally depends on ambient/surrounding temperature. You fire up the standard set of stress tests in the morning without heatsink applied and let RPi-Monitor measure the SoC's temperature. Being back from the office in the evening you mount the newly aquired heatsink and re-run the same set of tests. Big surprise: With applied heatsink the SoC's temperature is 4°C higher than without. In fact, the room's temperature increased by 5°-6°C and so the heatsink led to 1°-2°C less compared to the situation without. If you've not always an eye on surrounding temperature you easily draw wrong conclusions :-)
-
Just to give an idea how many information sources are available (forget about the cameras since these are Raspberry Pis that record video on the Lamobo):
The disk's temp can be read using S.M.A.R.T. (hddtemp package, already included by Igor), PMU using sysfs, SoC using a small binary included with my sunxi fixes, and I also used an internal thermal sensor to get an idea what's going on (since in the enclosure are 2 PSUs and 1 LCD with backlight and signal board)
In the statistics view RPi-Monitor provides graphs and there I differentiate between available voltage and used amperage for the power sources "USB OTG" and "power-in" (unfortunately not available for the LiPo connector when used together with a PSU). But this way you get a clue what sort of problem you're running into (most likely undervoltage due to bad USB cables and the most crappy connector in the world: Micro-USB).
-
Finally I tried the only other option I've read on the same forum here , injecting power to J12 connector
The whole idea is crap. The person supplying additional power used the wrong Micro-USB connector (USB OTG and not power-in).
You always have to keep in mind that this is not a Raspberry Pi (where you can insert power easily through GPIO pins since its power scheme is totally different) but an A20/AXP209 device. And the PMU (AXP209) decides on its own where to take power from if there is more than one source available.
In case you use kernel 3.4 I would suggest installing RPi-Monitor with the sunxi fixes since this immediately shows you thermal values for SoC and PMU and the power used from the three different available sources (power-in, USB-OTG and LiPo -- for the latter not exactly when you connect a PSU to the LiPo connector since the voltage can't be read out and my sunxi fixes then assume 5V).
I delivered one R1 recently to a customer. Runs vertical, no heat sinks (one on the SoC but a crappy one that doesn't help at all) but some sort of convection and a small fan that jumps in if the PSU's temperature exceeds 55°C. Uptime while being totally stable for 30+ days. Temperature was a problem a few weeks ago when ambient temperature exceeded 30°C (since inside the enclosure it were 7°-8° above and then the PMU's temperature exceeded 55° -- might be ok if it gets higher but I decided to let then a fan cool down both SoC and PMU since the fan is just a few cm above both)
-
Use a package hdparm.
Unfortunately there are a couple of drives that simply ignore "hdparm -B" settings. Then a daemon approach might help: http://pastebin.com/issrNdcP
-
In any case, what problems did it give on Jessie in addition to the init script to be ported to systemd?
As far as I understand it's about the order of started services (ramlog has to be the very first and the last daemon started/stopped so that all other daemon's output will be inside the ramdisk). The parallelisms introduced with systemd make this a bit hard to achieve.
Anyway: You can run jessie with SysV init instead of systemd. I tried to summarize the way Bananian does it here: https://olimex.wordpress.com/2015/08/26/devuan-jessie-for-olinuxino-images/#comments
-
My only remaining idea is to use both .dts/.dtsi from the kernel sources as well as the included dtc command: http://elinux.org/Device_Tree#Tools
-
What do the following commands return?
dpkg -s device-tree-compiler | grep Version dtc -v
-
The example above was rather old and I would suspect some stuff has changed in the meantime. I just had a short look into the .dts file from kernel 4.1.x and there sun4i-a10.dtsi is included.
Maybe it helps to add the definition there:
uart2_pins_a: uart2@0 { allwinner,pins = "PC18", "PC19"; allwinner,function = "uart2"; allwinner,drive = <SUN4I_PINCTRL_10_MA>; allwinner,pull = <SUN4I_PINCTRL_NO_PULL>; };And then reference it from the Lime's .dts as
uart2: { pinctrl-names = "default"; pinctrl-0 = <&uart2_pins_a>; status = "okay"; };?
-
Running hadoop on hardware lacking ECC RAM is simply insane (applies to every task that needs data integrity): http://web.archive.org/web/20080916092736/http://mail-archives.apache.org/mod_mbox/hadoop-core-dev/200705.mbox/%3C465C3065.9050501@dragonflymc.com%3E
-
i want to know about the additional requirements for cross-compiling armhf software on a X86 machine!
It's already answered. Over and out (since Igor made it so unbelievable easy to 'just do it' that any more words are just a waste of time)
-
The only thing I need to know, what addition packages from UBUNTU are required to compile your nicely prepared images on my on!
It's just git since all the other requirements get installed in the build process. It's that easy, just follow these steps somewhere with 20 GB free -- see https://github.com/igorpecovnik/lib
apt-get -y install git git clone https://github.com/igorpecovnik/lib cp lib/compile.sh . chmod +x compile.sh ./compile.sh
-
Ok, so now I would assume that you neither want bridging nor NAT but simple routing instead. Since the onboard Wi-Fi is crappy I wouldn't use it. Then you end up with something like:
auto lo iface lo inet loopback auto eth0.101 iface eth0.101 inet dhcp pre-up swconfig dev eth0 set reset 1 pre-up swconfig dev eth0 set enable_vlan 1 pre-up swconfig dev eth0 vlan 101 set ports '3 8t' pre-up swconfig dev eth0 set apply 1 auto eth0.102 iface eth0.102 inet manual pre-up swconfig dev eth0 vlan 102 set ports '0 1 2 4 8t' pre-up swconfig dev eth0 set apply 1 address 192.168.2.1 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.2.255You would've to add an IP configuration for the eth0.102 entry (different subnet as in your LAN! If you use there 192.168.1.0/24 for example then use 192.168.2.0/24 as in the example above) and then you install dnsmasq and configure it to be active only on eth0.102. If clients in both nets should be able to talk to each other (routing between WAN and LAN VLANs on the R1) then you do
sysctl net.ipv4.ip_forward=1 echo "net.ipv4.ip_forward=1" >>/etc/sysctl.conf
If the devices on R1's LAN ports should also be able to reach the internet then there's more to do. But I would configure dnsmasq as a simple DNS forwarder and that's it. Mosqitto running on the R1 is able to talk to all connected devices in any case.
-
Sorry, I only mentioned it in the topic title: It is Debian 8 / Jessie ...
Sorry, I've overseen that. If you're using the forking method to start FHEM I would uncomment/adjust $PIDFile in /etc/systemd/system/fhem.service as well set
attr global pidfilename /path/to/fhem.pid
in fhem.cfg. And let that point to a mountpoint not residing on a tmpfs. Or you add a simple
[ -d /var/run/fhem ] || mkdir -p /var/run/fhem
to the startscript or in your case systemd service (I assume you're using systemd and not SysV init -- it seems to be possible to use Jessie with the latter too)
-
A tmpfs is empty after reboot by design. So unless you populate it eg. from /etc/rc.local (which distro do you use? Wheezy, jessie, trusty?) or use daemons like tmpfs-populate another approach would be to let the PID file reside somewhere else (again: without details which distro you're using it's impossible to help).
-
I want to use the Bpi R1 as a DHCP-Server in a separate network bridged to my local network over the BPi's WAN-Port. [...] router setup
You're talking about two different things :-)
Routing is not bridging. In short words: Unless you get a clue what you really want to do you won't succeed.
If you want the R1 to act as a bridge between your LAN and the devices connected to the R1's so called "LAN ports" then all you've to do is to setup one VLAN connecting all 6 ports (SoC and the 5 external ports) and you're done (since then the R1 acts as a switch which is nothing more or less than a multi-port bridge). In this case it's a really bad idea to setup a DHCP server on the R1 unless it has absolutely the same config as the already present DHCP server in your LAN.
Igor ships already such a config, all you've to do is a "ln -sf /etc/network/interfaces.r1switch /etc/network/interfaces && reboot"
I suppose you want a NAT/router setup instead? In this case you use 2 different VLANs, one for the so called 'WAN port' that is connected to your LAN and another one connecting all the other ports together to work in switch mode. Again: Igor ships such a config already: https://github.com/igorpecovnik/lib/blob/next/config/interfaces.r1(should be the default)
And then you set up DHCP (I would prefer dnsmasq for this task) and in case the devices connected to the R1's LAN ports should be able to reach your LAN behind the 'WAN port' you would setup NAT also. If you do a google search for "debian nat dnsmasq" or something like that you get tons of tutorials. All you've take care of is that your external interface is eth0.101 and the 'internal' eth0.102 instead.
And if you don't want to use the R1's Wi-Fi you would've to remove the br0 definition in the interfaces file and adjust settings (static settings for eth0.102 and eth0.101 getting an address via the DHCP server in your real LAN for example)
-
-
It depends on the kernel you use. Igor currently provides both images with 3.4.x (fex/script.bin) and mainline (dts/dtb). Can you provide the ouput of
uname -a dmesg | egrep "serial|uart" sudo cat /proc/tty/driver/serial
-
Small addendum: I just tried this out with an externally connected LED that was defined in script.bin. Works the same way as with the board's internal LEDs so you could use the convenient timer trigger or BananaLEDd to show average load or disk activity also with external LEDs since these populate sysfs when defined in script.bin. I just added a small section to the linux-sunxi wiki: http://linux-sunxi.org/Fex_Guide#external_leds
-
Just a hint. You will need to write a mini application / script / daemon.
Not in any case. You could also do some redirect/filter magic and let the output of a specific command lead to different triggers that modify blink frequency based on load or something like that.
On page 4 of this thread there are many examples using iostat (one line in /etc/rc.local). Also the BananaLEDd project that has been started in the aforementioned thread should be usable starting with v1.2 on Cubietruck using the LED=cubietruck:orange:usr syntax.
A simple daemon approach would be something like this (saved as eg. /usr/local/bin/diskblink.sh and started from within /etc/rc.local):
#!/bin/bash export PATH=/usr/local/bin:/usr/bin:/bin MyLed="/sys/class/leds/green:ph24:led1" PartitionUUID=a7747356-feed-432a-81a3-7caea67c8cb8 PartitionDevice=$(ls -l /dev/disk/by-uuid/${PartitionUUID} | awk -F"/" '{print $7}') echo timer >${MyLed}/trigger while true ; do PartitionUseage=$(df -k | awk -F" " "/\/dev\/${PartitionDevice}/ {print \$5}" | tr -d '%') echo ${PartitionUseage} >${MyLed}/delay_on echo $(( ( 100 - ${PartitionUseage} ) * 100 )) >${MyLed}/delay_off # echo $(( 10000 - ${PartitionUseage} * ${PartitionUseage} )) >${MyLed}/delay_off sleep 10 doneSince LED blinking is rather annoying I would also adjust brightness in the loop by something like this (value is in the range 0-255, with the following formula you get 2 with 10%, 62 with 50%, 202 with 90% and 245 with 99% -- so you will notice the LED only when it gets critical):echo $(( ${PartitionUseage} * ${PartitionUseage} / 40 )) >${MyLed}/brightnessYou've to define $MyLed and of course $PartitionUUID (lookup with blkid). The script uses the timer trigger and adjust on/off cycles based on df's percentage output for the partition in question.
@Igor: Request for enhancement: please add BananaLEDd to /usr/local/bin for the A20 boards and ship with a disabled config for all supported boards :-)
-
Here is a thread regarding VoIP clients on Banana Pi and this is the output of "apt-cache show linphone-nogtk" running Armbian Wheezy:
Package: linphone-nogtk Source: linphone Version: 3.5.2-10 Installed-Size: 125 Maintainer: Debian VoIP Team <pkg-voip-maintainers@lists.alioth.debian.org> Architecture: armhf Depends: libc6 (>= 2.13-28), liblinphone4 (>= 3.5.2), libmediastreamer1 (>= 3.5.2), libncurses5 (>= 5.5-5~), libortp8 (>= 3.5.2), libosip2-7, libreadline6 (>= 6.0), libspeex1 (>= 1.2~beta3-1), libtinfo5, libx11-6, linphone-common (= 3.5.2-10), host Description-en: SIP softphone - console-only client Linphone is an audio and video internet phone using the SIP protocol. It has a GTK+ and console interface, includes a large variety of audio and video codecs, and provides IM features. . This package contains the console version of linphone, which saves space as it doesn't link to the gtk libraries. It does however still link to libx11 for video support. . Console Tools: . . linphonec is a command line interface that can use readline on Linux to get completion, history, such as bash. . linphonecsh is another command line tool to remotely control a linphonec daemon. Unlike linphonec, linphonecsh immediately exits once the command is executed. Homepage: http://www.linphone.org/ Description-md5: ea9dc85daac50c5af653e397210d4f6b Tag: uitoolkit::ncurses Section: sound Priority: optional Filename: pool/main/l/linphone/linphone-nogtk_3.5.2-10_armhf.deb Size: 50982 MD5sum: 968a6c149225e059c406aa0dd82f8beb SHA1: 86e3fa464b6e820b877f996789a6e5c755b72d9c SHA256: 44ee11f2fb6a3ced5d8cb103a1da05575e9a1b5228107efc5efbbdb518e4e938
-
can I export gpio pins for general purpose usage...
Since it seems you're using kernel 3.4 this might be a good starting point: http://linux-sunxi.org/GPIO#Accessing_the_GPIO_pins_through_sysfs_on_sunxi-3.4
-
Since you want to use a Banana Pro it should read CONFIG_SPI_SUN7I instead? It's not defined in Igor's config and maybe that's the reason: http://will-tm.com/spi-on-the-cubieboard2/
Regarding mainline kernel, SPI and device tree have a look at http://linux-sunxi.org/SPIdev
Freezing problem with Olimex A20 Lime 2
in Allwinner sunxi
Posted
You should be aware that if you power the 2.5" disk via the board then you might run into power supply troubles. You should first check the power scheme Olimex uses.
There are two alternatives:
In other words: You should check schematics of the board, you should get a second SD-card, use Igor's image with Kernel 3.4.x, install RPi-Monitor with sunxi additions and get a clue what's happening regarding power sources. You can search ages for software bugs if it's just an issue with your power supplies (two of them with a PMU in between that implements special logic on its own)