An alternative for isc-dhcp on Page 9,
written from Ashok Aiyar, I put it here because it is not just a fix but an instruction how to replace the isc-dhcp server with dnsmasq.
I find dnsmasq to be a better option to isc-dhcp-server, because it provides both DNS and DHCP servers in a single package and configuration file.
Also, dnsmasq supports caching, so with a large cache, it provides really fast name resolution after using it for a little while.
Here is a dnsmasq setup consistent with the rest of the Armbian BPi R1 configuration given in this very helpful guide.
a) Install dnsmasq (apt-get install dnsmasq)
b shutdown dnsmasq (service dnsmasq stop)
c) Edit "/etc/dnsmasq.d/dnsmasq.conf" with the contents shown below:
# interfaces
interface=br0
no-dhcp-interface=eth0.101
#
# DNS configuration
min-port=4096
cache-size=10000
local-ttl=3600
neg-ttl=3600
bogus-priv
domain-needed
expand-hosts
resolv-file=/etc/resolv.conf
#
# DHCP configuration
dhcp-authoritative
dhcp-leasefile=/var/lib/misc/dnsmasq.leases
dhcp-option=br0,1,255.255.255.0
dhcp-option=br0,3,192.168.9.2
dhcp-option=br0,6,192.168.9.2
dhcp-option=br0,28,192.168.9.255
dhcp-range=br0,192.168.9.150,192.168.9.250,255.255.255.0,72h
# explanation of options:
# option 1 = net mask
# option 3 = gateway
# option 6 = DNS
# option 28 = broadcast address
# assign address range = 150-250
# lease time = 3 day (72h)
Back in February '15 I have started to write an instruction about the setup of a BPi-R1 (Router).
In the threads of the Forum, the information is scattered and it takes so much time for each to get along.
So I thought such a document would help to become not only faster, but to achieve a better result as well, as you can faster spend time with the device and tweak it.
My know how is getting better, but things are still missing.
If you like to help the 'community' with your know how, please leave comments in the document if you find errors or you find something missing.
Back in February '15 I have started to write an instruction about the setup of a BPi-R1 (Router).
In the threads of the Forum, the information is scattered and it takes so much time for each to get along.
So I thought such a document would help to become not only faster, but to achieve a better result as well, as you can faster spend time with the device and tweak it.
My know how is getting better, but things are still missing.
If you like to help the 'community' with your know how, please leave comments in the document if you find errors or you find something missing.
Hi Wildcat, Tido sent me the link to the documents in a private message and now put it in his signature. Apparently I had the package already installed, not working for me I am afraid. I will try to get again the original hostap files from the package to test them out. I suggest also adding that disabling debug patch that I made, the first time my wifi went off, it was because all that garbage on the log file put it out, apparently.
For chester and Petr, I have managed to have my wifi up several days now. Yesterday updated my Mac and iPhone with a lot of concurrent updates all fine. Today, managed to get iperf to 10 concurrent connections and 80Mbps in a single machine from my Mac to my Lamobo (via wifi).
First steps with LeMaker's guitar:
These days a few SBC appear that are based on Actions Semi's S500 SoC (quad core Cortex A9r4 processor with 512KB L2 Cache and a PowerVR SGX544 GPU). Two competitors share the Raspberry's form factor (they both use Actions Semi's reference design):
Lemon Pi:
Roseapple Pi:
The Allo SPARKY is also compatible to RPi HATs
LeMaker's Guitar differs in size and shape(s) since the Guitar is the combination of one core board as SO-DIMM containing SoC, DRAM and the power management unit (PMU) and a few base boards featuring different hardware:
(yes, currently you won't see a product picture since the LeMaker guys seem to like broken links -- they also start every few weeks to destroy every working link between their support forum and their wiki but since noone cares... I don't care too)
All boards share the same common 40 pin GPIO header known from RPi A+/B+/2 and hardware characteristics due to using the same SoC/PMU: 2 USB 2.0 ports, 1 x USB 3.0, 1 or 2 GByte DRAM, up to 64 GByte Micro-SD-card, (optional) eMMC, HDMI output, MIPI DSI/CSI connectors for LCDs and cameras and a 'native' 10/100 MBit/sek Ethernet implementation. And they also share the same software limitations: Actions Semi provides only a weird 'SDK' containing a bunch of scripts and outdated heavily patched 3.10.37 kernel sources and there is zero efforts to get Actions Semi's SoCs supported by mainline kernel (which is really bad -- Amlogic/Hardkernel show with their kernel 3.10.y branch how it should work instead: you clone the official kernel tree, get a huge patchset from the SoC's manufacturer and can then merge all official patches in your customized kernel tree). Actions Semi now seems to be there where Allwinner was back in 2012 regarding 'openness'
How differs the Guitar from the other boards:
The coreboard/baseboard concept should theoretically help developing baseboards that suit ones needs. But since LeMaker hardware isn't Open-source hardware (OSH) I doubt we will anytime soon see baseboards from other manufacturers than LeMaker
They use a different power scheme. The base board can be fed with 5-12V @ 2A which will then be used to power USB peripherals (somehow proprietary and not acting as charging downstream ports (CDP) in conformance with the USB Battery Charging Specification) and also the voltage will be converted down to 4.28V to feed the PMU which then creates the different voltages the board's core components need. According to LeMaker they're able to supply additional 3.1A@5V on the USB ports. For details see below
USB 3: According to LeMaker they couldn't use the usual blue Type A port to easily connect peripherals like disks, Ethernet adapters or USB3 hubs but had chose the Micro-B port instead since this port can automagically determine whether to operate in host or device mode (obviously they believe people do flash way more often the onboard eMMC than trying to connect USB peripherals). For reasons yet unknown to me the Micro-B port LeMaker used is incompatible with certain (most?) USB3 cables. To sum it up: USB3 isn't useable unless you're lucky enough to find an adapter cable to interconnect the Guitar with normal USB peripherals. Update: These cables do not exist and you have to customize a cable to get USB3 support with LeMaker's Guitar. Unbelievable!
Since I'm neither interested in Android (should work flawlessly since Actions Semi's SoCs originate from this environment) nor in Linux as a desktop nor in GPIO stuff (should just work but unfortunately LeMaker chose wider spaces between the mounting holes which has consequences for HATs -- see below) I focused on the basics (getting any information about S500 and the board's hard- and software) and the area I'm interested in: low-power servers that act partially as a NAS. Therefore you won't find any words on GPU/VPU performance/acceleration or classical SBC/IoT stuff like interacting with sensors and stuff like that.
I did some tests regarding integer performance with the default 1.1 GHz and also with 1.3 GHz using an own kernel build (you have to adjust operating points in the kernel's cpufreq sources to define clock speeds and Vcore voltage accordingly). With 1.3 GHz the S500 is the fastest quad core SoC I tested so far. But unless you use a fan I wouldn't recommend running at this speed since both SoC and PMU get freaking hot and when thermal throttling jumps in after a few minutes the performance drops drastically. Without a fan you can operate the device only short periods of time with 1.3 GHz and then it either starts to overheat or to throttle down (for yet unknown reasons throttling sometimes failed in my tests and I managed to trigger emergency shutdowns at 125°C throttling is now fixed). Therefore I used the 1.1 GHz setting for the tests. The other 4 boards I compared with were also clocked at reasonable speeds:
Raspberry Pi 2, BroadCom BCM2836 quad core SoC, 1.0 GHz
Hardkernel ODROID-C1+, Amlogic S805 quad core SoC, 1.7 GHz
Wandboard Quad, Freescale i.MX6 quad core SoC, 1.0 GHz
not yet released SBC with Allwinner's A20 quad core successor, 1.1 GHz (tests done with Banana Pi @ 960 MHz and interpolated to 1.1 GHz and 4 CPU cores)
The board performs nicely in this area (same applies to sequential transfer speeds to/from SD card or eMMC) but for my use cases I/O and network performance are way more important. Due to LeMaker's choice to introduce mechanical incompabilities that prevent using USB 3.0 for this purpose I will stop at the moment. The USB 2.0 performance is bad (caused by the outdated 3.10.37 kernel we have to use with the S500 that doesn't feature UAS or btrfs support and does not contain USB/ext4 fixes and maybe also caused by Actions Semi's USB implementation) and WiFi or 10/100 Mbits/sec aren't worth to measure since other SoCs feature native GBit Ethernet.
Therefore I will stop testing the Guitar unless LeMaker designs a baseboard that makes USB3 useable (featuring the normal Type A port and ideally containing an USB hub and both an UAS capable USB-to-SATA bridge like JMicron's JMS567 and an Ethernet adapter like the ASIX AX88179) and wait for Allwinner's next quad core baby that features both native SATA and GBit Ethernet
It's too early to draw conclusions and my use case is obviously too specific for the Guitar. Unfortunately it was rather hard work to get/collect all the informations below and still many questions are open. Time will tell whether they'll be answered by LeMaker and Actions Semi and whether the software side evolves. With the current outdated 3.10.37 kernel the S500 is cut off from important stuff like mature kernel code for modern filesystems and tons of fixes inside the kernel (bug and/or security fixes)
Original Thread starting one week ago:
Today I received my Guitar (well done since it shipped at the end of last week in Shenzen and has been delivered an hour ago in Munich!). I connected it via HDMI to a display, via Ethernet to a network with DHCP server and via a simple 5V/2A PSU to wall power. The Guitar comes with 1 GByte DDR3 RAM and a quad core SoC. (Partially misleading/wrong) informations here: http://wiki.lemaker.org/LeMaker_Guitar
Boot time below 30 seconds. Consumption peak at 3.5W while booting and 2.7W when idling with X server running.
Both the SoC (thermal_zone1) as well as the ATC2603 PMU expose internal thermal sensors:
/sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-hwmon.0/ic_temperature: 49822 mCel
/sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-power.0/power_supply/battery/temp: 0
/sys/devices/virtual/thermal/thermal_zone1/temp: 60000
The PMU can be queried (and maybe its behaviour also modified) using I2C:
root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065# ls -al
total 0
drwxr-xr-x 29 root root 0 Jan 1 2011 .
drwxr-xr-x 4 root root 0 Jan 1 2011 ..
drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-adckeypad.0
drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-audio.0
drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-cap-gauge.0
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc1.1
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc2.2
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-dcdc3.3
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ext-pwm-dcdc1.1
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ext-pwm-dcdc2.2
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-gpio.0
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-hwmon.0
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-irkeypad.0
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo1.1
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo11.11
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo2.2
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo3.3
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo5.5
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo6.6
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo7.7
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-ldo8.8
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-onoff.0
drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-pm.0
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-power.0
drwxr-xr-x 3 root root 0 Jan 1 2011 atc2603c-pwm.0
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-rtc.0
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-sgpio.0
drwxr-xr-x 4 root root 0 Jan 1 2011 atc2603c-switch1.1
-r--r--r-- 1 root root 4096 Oct 5 14:26 auxadc_dbg
lrwxrwxrwx 1 root root 0 Jan 1 2011 driver -> ../../../../bus/i2c/drivers/atc260x_i2c
-r--r--r-- 1 root root 4096 Oct 5 14:26 modalias
-r--r--r-- 1 root root 4096 Jan 1 2011 name
drwxr-xr-x 2 root root 0 Oct 5 14:11 power
-r--r--r-- 1 root root 4096 Oct 5 14:26 pstore_dbg
-rw-r--r-- 1 root root 4096 Oct 5 14:26 reg_dbg
lrwxrwxrwx 1 root root 0 Jan 1 2011 subsystem -> ../../../../bus/i2c
-rw-r--r-- 1 root root 4096 Jan 1 2011 uevent
root@Lemuntu:/sys/devices/b0170000.i2c/i2c-0/0-0065/atc2603c-dcdc1.1/regulator/regulator.1# ls -al
total 0
drwxr-xr-x 3 root root 0 Jan 1 2011 .
drwxr-xr-x 3 root root 0 Jan 1 2011 ..
-r--r--r-- 1 root root 4096 Oct 5 14:27 bypass
lrwxrwxrwx 1 root root 0 Oct 5 14:27 cpu0-cpuvdd -> ../../../../../../system/cpu/cpu0
lrwxrwxrwx 1 root root 0 Oct 5 14:27 device -> ../../../atc2603c-dcdc1.1
-r--r--r-- 1 root root 4096 Oct 5 14:27 max_microvolts
-r--r--r-- 1 root root 4096 Oct 5 14:27 microvolts
-r--r--r-- 1 root root 4096 Oct 5 14:27 min_microvolts
-r--r--r-- 1 root root 4096 Oct 5 14:27 name
-r--r--r-- 1 root root 4096 Oct 5 14:27 num_users
drwxr-xr-x 2 root root 0 Oct 5 14:11 power
-r--r--r-- 1 root root 4096 Oct 5 14:27 state
-r--r--r-- 1 root root 4096 Oct 5 14:27 status
lrwxrwxrwx 1 root root 0 Oct 5 14:27 subsystem -> ../../../../../../../class/regulator
-r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_disk_state
-r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_mem_state
-r--r--r-- 1 root root 4096 Oct 5 14:27 suspend_standby_state
-r--r--r-- 1 root root 4096 Oct 5 14:27 type
-rw-r--r-- 1 root root 4096 Jan 1 2011 uevent
Kernel config: http://pastebin.com/9bUSA7Rr
For whatever reasons the device is not able to run at 1.3Ghz as advertised (UPDATE: I managed to clock it with 1.3 GHz by modifying kernel sources and building the kernel on my own -- see a few posts below):
root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_frequencies
408000 720000 900000 1104000
root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_available_governors
conservative ondemand userspace powersave interactive performance
root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq
408000
root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo performance >scaling_governor
root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# echo 1104000 >scaling_max_freq
root@Lemuntu:/sys/devices/system/cpu/cpu0/cpufreq# cat scaling_cur_freq
1104000
Clocked with 1.1Ghz it reaches 2338 7-zip benchmark points -- compare with https://s1.hoffart.de/7zip-bench/
"sysbench --test=cpu --cpu-max-prime=5000 run --num-threads=4" finishes in 19.5 seconds. Regarding integer/memory performance in these two short tests the Guitar is roughly 2.3 times faster at this clock speed compared to an A20 based device with the same clock speed: http://linux-sunxi.org/Category:A20_Boards
Disclaimer: It's not clear whether memory performance improves if one disables GPU stuff (like it's the case with slow Allwinner SoCs where high display resolution/colordepth/bandwidth decreases overall memory throughput) so this is just a rough estimate and not a benchmark at all.
While running the sysbench test on all CPU cores the consumption increases by 3W and the reported temperature rise up to 76°C SoC and 57°C PMU (when idle in my setup with the Guitar operated vertically with enough airflow around: 60°C SoC and 50°C PMU, when set to ondemand governor and idling at just 408 MHz the temperatures decrease to 56°C SoC and 47°C PMU). Warning: These are just values read out using sysfs and not any real measurements.
I collected some other informations at the link below (apply to Guitar Core Board v1.3 and Guitar Base Board Rev. B and "Lemuntu" V1509 (http://www.lemaker.org/article-64-1.html -- obviously LeMaker doesn't care about correct informations, the kernel version there is completely wrong)
http://pastebin.com/ZpMNkbU1
Complete boot log via debug UART: http://pastebin.com/X2ppDEwS
Device tree used: http://pastebin.com/QNb3i9F6
Contents of /boot/uEnv.txt:
uenvcmd=setenv ramdisk_addr_r -; setenv os_type linux;
bootargs=earlyprintk clk_ignore_unused selinux=0 scandelay root=/dev/mmcblk0p2 rw console=tty0 rootfstype=ext4 console=ttyS3 loglevel=4 rootwait
If sometimes in the future an "SDK" will be released I believe it would be a nice board to add to Armbian? Any comments on that?
UPDATE: In the meantime some docs/tools have been released and maybe a community evolves around Actions Semi's SoCs:
S500 manual v1.4: http://mirror.lemaker.org/Datasheet_For_S500_V1.4.pdf
ATC2603C manual v2.1: http://mirror.lemaker.org/Datasheet_For_ATC2603C_V2.1.pdf
image-create-tools (to combine bootloader+kernel with rootfs): https://github.com/LeMaker/image-create-tools-actions
bootloader+kernel (both not as source!) LeMaker uses: https://github.com/LeMaker/hwpack-s500
XApp-le community: http://wiki.linux-xapple.org/w/index.php/Main_Page
In my Banana 15.04 manual these steps are documented for a couple months now :-)
In Igor's armbian these steps were not necessary because he already delivers a driver and a fresh hostapd.
The only new thing is this, that I found lately and is mentioned in this thread from me as well.
neighbours to enable always 40MHz channels.
Hi,
just out of curiosity, did you run Step1, it is in my manual:
// Step 1 //
scan networks: iwlist wlan0 scan
show available channels: iwlist wlan0 channel
find least used channel: cat /proc/net/rtl819xC/wlan0/best_channel
// Step 2 //
Just configuring these didn't enable n-mode for my nix router. Turns out hostapd checks for neighboring SSID's.
If there are a lot of those, it won't activate the secondary n-channel.
A quick inSSIDer scan showed me my neighbours were in fact using the secondary channel.
Apparently many routers don't have this check (as described in RFC) built in.
I used the patch described in the url below to disable the neighborhood network check, and force hostapd to run in n-mode.
http://www.brunsware.de/blog/gentoo/hostapd-40mhz-disable-neighbor-check.html
source: stackoverflow
// Step 3 //
Some more interesting information on the bottom of page 5 of this doc HT40- and HT40+
Concerning the setup, on page 5 I wrote: connect the single WAN port to your current Router.
So the router is in this scenario not directly connected to the cablemodem /DSL.
If I think now, my comments in 'interfaces' lead to this assumption for eth0.101
I will have to review that and think /test changes.
I just wanted to support you in your move from ROM to Distro. Having up to date kernels, learning to make up to date kernels and absolutley great compile updates are what separate what you've been doing from other projects. I know quite well that it's not easy doing your own funky tech thing, and wish to congratulate you on seeing it through!