Igor

It's one of the known problems of this board: http://linux-sunxi.org/Lamobo_R1#Available_enclosures_and_thermal_issues
 
Try to operate it vertically since then convection jumps in 
 

I came out with this: 
###################################################################################### # # Battery info # i2cset -y -f 0 0x34 0x82 0xC3 # read power OPERATING MODE register @01h POWER_OP_MODE=$(i2cget -y -f 0 0x34 0x01) BAT_EXIST=$(($(($POWER_OP_MODE&0x20))/32)) # divide by 32 is like shifting rigth 5 times CHARG_IND=$(($(($POWER_OP_MODE&0x40))/64)) # divide by 64 is like shifting rigth 6 times ######################################################################################## #read battery voltage 79h, 78h 0 mV -> 000h, 1.1 mV/bit FFFh -> 4.5045 V BAT_VOLT_LSB=$(i2cget -y -f 0 0x34 0x79) BAT_VOLT_MSB=$(i2cget -y -f 0 0x34 0x78) BAT_BIN=$(( $(($BAT_VOLT_MSB << 4)) | $(($(($BAT_VOLT_LSB & 0xF0)) >> 4)) )) BAT_VOLT=$(echo "($BAT_BIN*1.1)"|bc) # store maximum battery voltage to compare to if [ -f "/etc/default/battery" ]; then source "/etc/default/battery" else echo "MAX=$BAT_VOLT" > /etc/default/battery echo "MIN=3484" >> /etc/default/battery fi # integer is enough, cut down the decimals MAX=${MAX%.*} BAT_VOLT=${BAT_VOLT%.*} # mainline kernel shows battery existence even if not exists. this is walkaround if [ "$BAT_VOLT" -ge "3200" ]; then # if we have new max value, alter defaults if [ "$BAT_VOLT" -gt "$MAX" ]; then MAX=$BAT_VOLT sed -e 's/MAX=.*/MAX='$BAT_VOLT'/g' -i /etc/default/battery fi # if we have new min value, alter defaults if [ "$BAT_VOLT" -lt "$MIN" ]; then MIN=$BAT_VOLT #sed -e 's/MIN=.*/MIN='$BAT_VOLT'/g' -i /etc/default/battery fi # calculate percentage percent=$(echo "($BAT_VOLT-$MIN)*100/($MAX-$MIN)"|bc) # colorize output under certain percentage if [ $percent -le 15 ] then color="31" fi if [ "$BAT_EXIST" == "1" ]; then BATT=" - Batt: " # dispay charging / percentage if [ "$CHARG_IND" == "1" ]; then BATT=$BATT"charging $percent%" else BATT=$BATT"\e["$color"m$percent%\x1B[0m" fi fi fi OUT="${OUT}${BATT}" echo "" echo -e ${OUT} echo "" Load: 1.64, 1.14, 1.00 - Board: 36.2°C - Ambient: 27.0°C - Drive: 43°C / 2.5Tb - Memory: 934Mb - Batt: 7%
 
Working on both kernels.

Hi,
 
my LEDs are working already, I will describe shortly, howto: (for example two leds connected to GPIO PI03 and PI19)
 
Install DTC, device tree compiler. Take your DTB file and convert to DTS. Output DTS is little bit more human readable than examples I posted before.
 
Find section "pinctrl@01c20800" and to the end of this section add two LED subsection:
led_pins@0 { allwinner,pins = "PI"; allwinner,function = "gpio_out"; allwinner,drive = <0x1>; allwinner,pull = <0x0>; linux,phandle = <0x38>; phandle = <0x38>; }; led_pins@1 { allwinner,pins = "PI"; allwinner,function = "gpio_out"; allwinner,drive = <0x1>; allwinner,pull = <0x0>; linux,phandle = <0x3A>; phandle = <0x3A>; "allwinner,pins" must be "PI", beacause both of my leds are connected to the PI ports(PI03 and PI19). "linux,phandle" I simply find unused interrupt numbers and used them for my leds.
 
In main section of DTS file add:
led1 { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <0x38>; blue1 { label = "lamobo:blue1:usr"; gpios = <0x19 0x8 0x03 0x0>; default-state = "on"; }; }; led2 { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <0x3A>; blue2 { label = "lamobo:blue2:usr"; gpios = <0x19 0x8 0x13 0x0>; default-state = "on"; }; }; Where pinctrl-0 is phandle from first section and gpios parameters: 0x19 - i dont know; Second parameter is GPIO port group, for P>I< ports is 8 (A=0, B=1 ...), third parameter is port number.
Then use device tree compiler and convert your DTS->DTB. Take your DTB file, replace original in boot folder or where you have it. Reboot!
 
Enjoy!
 

It worked!
Thank you!!!

yes, exactly that helped.
 
Thanks

GOT IT !!!
  It was the f***ed-up rtc indeed! Let me explain:   I simplified my experiment from above:   - installed debian-3.8-wheezy-3.4.107 --> ok (eth0 is ok, ping heise.de works) - survives reboot / halt and power-on / halt and dis-/reconnect power --> everything ok   Then upgrade to kernel 4.0.5 as described in your faq and then: - reboot    --> System boots till login screen (!!!) but eth0 isn't set up! No ping possible! dmesg | grep rtc 2085-06-25 (NOT ok) date Fr 20. Mai 13:37:52 CET 1949 (NOT ok)
hwclock --show hwclock: The Hardware Clock registers contain values that are either invalid (e.g. 50th day of month) or beyond the range we can handle (e.g. Year 2095).
  So, all date/time and clocks are wrong! Now I've set the correct date manually: date -s "25 JUN 2015 21:00:10" date ok!
 
But hwclock / rtc is still going wrong:
hwclock --show (NOT ok)
 
So, I've now set hwclock to system date via:
hwclock --systohc --localtime And voilà:
hwclock --show  --> ok (!)   reboot --> eth0 comes up !!!! ping ok! date --> ok hwclock --show --> ok   halt and power on date : ok ping ok   halt power dis-reconmnect --> ok   Then I removed sdcard, copied debian-4.0-wheezy-4.1 on it, put it back in and reset   And.................. Tatataaaaaaa, it doesn't complain about rtc, it recognizes eth0 and boots normally!   Repeated that with new installation of  debian 3.9-jessie-4.0.5, also works like a charm!     I'm happy!   Hope, that this is helpful for you other guys, too!!!

H3 is in the same position.
 
There is no community support (yet) for kernel 3.4.x which means you need to use previously mentioned (Official) Allwinner SDK. Current result is poor so I don't want to build images using that kernel. Way too much bugs for a single person or a small group to fix and support.
 
For mainline kernel (kernel.org) there are some patches for basic functionality but haven't got time to test.
https://patchwork.ozlabs.org/project/devicetree-bindings/list/?submitter=65627

Mainline doesn't have script.bin any more but Device Tree which has similar role but completely different structure.
 
Sources are located in /arch/arm/boot/dts/ ... compiled under /boot/dtb
 
Documentation:
http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf

Short version of answer is: to avoid questions -  "why do we have a high load without running anything?" 
 
More specific:
http://www.cubieforums.com/index.php/topic,1084.0.html

@dear Igior and others
 
 
My R1 fw1 run fine past 2 month with the 3.19.3. now its time to move to 4.0.x

Igor - many thanks for KERNEL_CONFIGURE at your scripting implementing .
This shortcut my work with automated rebuild kernel  an bit  -- but not fully.
 
I have the need to been able to push my own kernel .config into your https://github.com/igorpecovnik/lib in an automated way.

But how about to push an custom .config into that?
welll ... My suggestion are here top add i.e at your compile.sh : KERNEL_CUSTOM_CONFIG="/path/file"
 
 
if file env set , use it instead from default patched kernel .config

How you think about this Idea ?

That was a bug on one version back. On latest build this should be fixed. I'll check again asap.
 
Wrote on mobile phone

Where it stops? Do you have a serial console, VGA, HDMI? Do you get an IP - check router ...
 
Last images are double checked. Cubietruck, rev. A.

Never done this so not sure.  Check this configuration.
/etc/network/interfaces.bonding You probably need to create a bond between ppp0 with and eth0.101 but than you need configure a dialer to dial if eth0.101 fails ... not sure.

Yes, but I meant the increment in 48MHz steps. So I just tried it out myself (with kernel 4.0.4 and ready to overclock up to 1.2 GHz):
root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 144000 312000 528000 720000 864000 912000 960000 1008000 1056000 1104000 1152000 1200000 root@bananapi:/# echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor root@bananapi:/# echo 1000000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 960000 root@bananapi:/# echo 1008000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1008000 root@bananapi:/# echo 1009000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1008000 root@bananapi:/# echo 1056000 >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq root@bananapi:/# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 1056000 Same behaviour as with kernel 3.4. So the operating points available in kernel 4.0 or above are the equivalent to the former dvfs_table entries. They define a relationship between core voltage and clock speed but the actual cpufreq settings are still only possible in steps of 48 MHz. But what's different: Starting with kernel 4.0 thermal throttling is implemented on sun7i (A10/A20). If the temperature that will be read out from the thermal sensor inside the A20's touchpad controller exceeds defined values then the cpufreq driver will start to throttle. The temperature can be read out using the following code starting with 4.0:
awk '{printf ("%0.1f",$1/1000); }' </sys/devices/virtual/thermal/thermal_zone0/temp

Thanks a lot Igor.
With Bananapi Debian 3.1 jessie 4.0.5. on a Banana PRO
first run OK intrnal Wi-Fi - OK after copy in /boot/dtb/ the file sun7..bananapro.dtb over sun7...bananapi.dtb and reboot thanks

I tested yesterday, it's working normally. Are you using a proper network configuration?
 
If you made only kernel upgrade, you might need to remove:
 
/etc/udev/rules.d/70-persistent-net.rules

For the record, I got the nand boot working. Was way simpler than I expected.
 
Got a Nand Lubuntu image from here http://dl.cubieboard.org/software/a20-cubieboard/lubuntu/cb-a20-lubuntu-12.10-v1.06/
Used PhoenixCard to send it to a spare SD card.
Booted from this card and it installed itself to Nand (yaay !)
Booted from my first SD Card and ran nand install script.
Everything went as expected, it booted form nand a minute ago !
 
I'm currently loged in, wirelessly, without any SD card.
 
Thanks again for the images and forum. I found a lot of information and I wouldn't be that far without it.


Little google keywords for anyone looking for some help with this box  :  TXCZ_A20_V3.0  TXCZ_A20 V3  debian linux nand img firmware 

FAQ on that URL is working now.
 
And thank you for that URL to general-faq, I will contribute there with few interesting things after exams.
 
Thank you.

Since December 2013, when I started to deal with CLI Debian images and support them, things become ... bigger. My prime motivation was only to build an working Linux image for some amateur based services.
 
Project brought a lot of fun, a lot of new toys on my desk but also tears and frustrations. I hope and wish that public use our work to the greatest degree.
 
Blog comments - your questions and (not only my) answers - become large and valuable knowledge base for ARM single board computers and general Debian / Ubuntu problems. I already manage to pack some of the into the FAQ but I'll need your help and patience within summarizing this into General FAQ. You only need to login into Github to add to file.
 
I am slowly slowly closing comments on my personal website www.igorpecovnik.com and when most useful stuff will be in the FAQ they will be re-moved.
 
We are going further - projects are moving to www.armbian.com, forum.armbian.com and we are slowly getting an dedicated repository deb.armbian.com
 
Thank you!
 
 

You need to use rt-patched hostapd:
hostapd-rt /etc/hostapd.conf-rt

I agree. I also dumped BTSync from usage some time ago but haven't adjust the build script yet. Currently I am developing the backup / restore part which hanged somewhere in the middle.
 
All general services are open / free to change. I don't prefer any - it must work / suit the purpose. 

FIRST OF THX iGOR FOR YOUR GREAT WORK AND HANDS-ON WORKING IMAGES
 
Sata powering, no nonsense, just inject the power 5 Volt into the LiPo battery connector and your ready to go.
Its idd poorly designed, and there are different solutions about, this 1 suits me fine.
 
I found the solution on a forum, if i find it again ill post the 1 who came with this solution. Credits due to that person who experimented, without risking his/your warranty.
The battery charger will shut off above 4,2 volts, and i was not using it anyway.
 
Because of another design flaw, watch the temperature of your hard-disk, its 40+ because it sits on top of something hot.
Especially if your using the closed acrylic case that comes with it.
 
Besides the hardware/design flaws in this board it will make a kick-ass router.
 
Edit: after injecting the 5 Volt to the LiPo socket press power on button
 
Greetz form Holland

I know this way is a bit odd for such simple case but yes.
 
1. When you click edit the whole source is forked to your account automatically
2. Now it's your copy which you can edit
3. When you are satisfied you can send a modified code back to me (create pull request) and I decide to merge it, propose changes, reject, ...
 
This is Github way. It's meant for code and then those steps become logical. 

Mastering Github is useful 

Your solution works...i disabled eth0 and everything is fine. thank you!
 
i dont need AP mode..i am just confused that exactly the same config with enabled eth0 works on kernel 3.4.x wheezy.
 
4.0.4 jessie doesnt allow me to run both adapters at the same time (without bonding).

Here is my take on printerserver using cups with google cloudprint / airprint support and a little system monitor called mintr incase you wanna improve on yours 
 
https://gitlab.com/swe_toast/Printerserver