Igor

Hello,
 
as i didn't found a perfect UI for my cubie and me and i always liked the look and feel of crunchbang, i developed a little script in the past to bring #! to my cubietruck.
It should also work on every other debian based image, but i mainly targeted igor's image since it seemed to be the best base to start from.
 
NOTICE: crunchbang has EOL-status, no updates coming from them!
I mainly use it even though, because its very fast and stable on my cubie.
 
This script could be injected into building process or can be run on a fresh 'install'. Just use the get_crunchy.sh script and relax or download the image from second post.
 
It's tested on debian jessie and wheezy, other releases may work too.
 
How-To (existing target, base image):
git clone https://github.com/Isotop7/crunchbang_UI.git && cd crunchbang_UI chmod u+x get_crunchy.sh sudo ./get_crunchy.sh sudo restart How-To (building igor's image):
 
Adjust the parameter AFTERINSTALL in igor's compile.sh to
AFTERINSTALL="wget -q https://github.com/Isotop7/crunchbang_UI/archive/master.zip&& unzip master.zip; cd crunchbang_UI-master; \ chmod u+x get_crunchy.sh;./get_crunchy.sh; cd .. && rm -rf crunchbang_UI-master" **NOTICE:** If you use it while building you have to wait in first boot and have to login in console mode the first time in order to change the root password.
 
Please let me know if this has worked for you.
 
 
 
UPDATE: Testing for build integration is done. Also i would like to announce that i will presume my little work and head over to getting a script working to deploy bunsenlabs (the community driven successor of #!) to our devices. This will happen when bunsenlabs Hydrogen is out of beta-status, which is likely to happen really soon. I'll keep you updated.

I found the answer for my question: http://www.lemaker.org/thread-15543-1-1.html
 
Thanks a lot.

Thank you again, this helped me a lot.

Excellent job Igor. 
Thank you very much and have a nice day.
Br,
Radek

I installed http://mirror.igorpecovnik.com/Cubietruck_Debian_4.0_jessie_3.4.108.zip, which looks like the version before the current one, and has U-Boot 2015.04.  The two cores are detected!
 
root@cubietruck:~# cat /proc/cpuinfo
Processor    : ARMv7 Processor rev 4 (v7l)
processor    : 0
BogoMIPS    : 957.05

processor    : 1
BogoMIPS    : 830.00
 
Thanks for your help, Igor.

Hi again,
 
to answer my own question:
 
a) It is more or less a duplicate of this one (sorry about that).
 
I do not know what excatly I was doing wrong before, but I must have gotten the combination of setting the op_mode for the module bcmdhd and running hostapd with that wrong somehow. Anyway, as Igor pointed out in the thread mentioned in a), we must load the module with the option a mentioned above. This must be done using an appropriate options file, e.g. doing
echo "options bcmdhd op_mode=2" | tee /etc/modprobe.d/bcmdhd.conf Doing that, everything is fine (even with the SSID hidden).
 
P.S.: I would like to mark this as "solved", but it seems I cannot change the title ...
 
Cheers,
 
chessplayer
 
P.P.S.: Obviously, someone managed to change the title ... 

It finally worked for me as well but setting flag FORCE at NO was not enough.
 
I had to comment the file patching.sh from line 128 to 132 to avoid the git command that was erasing my modified files...
 
I not sure it is the right way but it worked...

Hi there,
 
i just wanted to report my experience with Igor Pecovnik's debian 4.1.2 image - especially since he says that I2C is untested with Kernel 4.0 and above.
 
I have a PCTV DVB-C/T2 USB Stick (Triplestick 292e) and could make it work with my Cubietruck. I had to use Igor's compile script from the project website in my ubuntu virtual machine on Windows 7 to get the kernel sources and compile the kernel with the required options (the offered SD-Card image lacks support for I2C Multiplexing). To use this stick, you have to compile the kernel with I2C Multiplexing built in, and build the i2c mux modules for the chipset (I compiled all i2c_mux drivers as modules since i didn't figure out which was the right one). The USB Stick has a multiplexer to change between the DVB-C and DVB-T2 receiver. After that I checked the DVB-frontends and chipset driver to compile as modules (especially si2168, en28xx, si2157) and now the stick works just fine. So I can confirm that the 4.1.2 kernel from Igor's project website has working I2C and I2C Multiplexing support if you compile your own kernel. All you have to do additionally after building the SD-Card image (all included in the compile script) is get the firmware for the stick (see https://tvheadend.org/boards/4/topics/13782).
 
I use tvheadend as digital video recorder on the cubietruck, with XBMC / KODI Media Center on Windows PCs and android smartphones for programming and watching.
 
Next steps are SMB server for backups on 3.5" S-ATA harddrive (with Cubietruck 3.5" addon board) and whatever comes into my mind
 
I had a lot of trouble getting this TV stick to work on ARM since the old kernels (3.4.x) seem to have no option for i2c multiplexing or the chipset (at least i couldn't find it, but i'm not too familliar with linux kernel stuff), and i found a lot of forums where ppl have the same problems, so i thought this info might be useful for someone.
 
And thanks a lot to Igor Pecovnik for the debian images and the scripts on his project website
http://www.igorpecovnik.com/2013/12/24/cubietruck-debian-wheezy-sd-card-image/
 
Regards
 
Markus

No, you don't need to recompile kernel, u-boot or download anything. You need to de-compile device tree blob (/boot/imx6q-hummingboard.dtb or /boot/imx6dl-hummingboard.dtb), edit / add, compile back. DTC compiler is within the image.
 
@Moorviper
Patches are added to the source.

Hi Igor,
 
With these two lines in LSB-Tags of ramlog I don't get any Errors:
 
# X-Stop-After: $syslog
# X-Interactive: true
 
Source: https://debianforum.de/forum/viewtopic.php?f=27&t=131540
### BEGIN INIT INFO # Provides: ramlog # Required-Start: # Should-Start: $local_fs # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: moves /var/log into ramdisk # Description: ramlog daemon moves /var/log to ramdisk on startup and copies it back to harddrive on shutdown or restart # # X-Stop-After: $syslog # X-Interactive: true ### END INIT INFO Steffen

I have attached the corect micro.fex for Olinuxino A20 Micro.
 
On UEXT1:
/dev/spidev2.0
/dev/ttyS1
/dev/i2c_2
 
On UEXT2:
/dev/spidev1.0
/dev/ttyS2
/dev/i2c_1
 
 
micro.fex.tar.gz

You can do it this way:
 
First do a copy to larger image, than execute those commands manually to expand to whole space:
fdisk /dev/mmcblk0 d ENTER # delete 1 ENTER # partition 1 which is the only one n ENTER # create new p ENTER # primary ENTER # default number is 1 ENTER # default start ENTER # default end w ENTER # write to disk reboot # when system gets back resize2fs /dev/mmcblk0p1

You will loose your time only, when you are trying onboard wifi get running. I tested with all available drivers/kernels/systems and result is the same - nearly unusable.
Buy quality USB wifi, and you will have zero problems.

I looked through kernel config files and found than in config for Lime A10 image with kernel 3.4.108 and HW accelerated MATE desktop there are:
# CONFIG_ARCH_SUN4I is not set # CONFIG_ARCH_SUN5I is not set CONFIG_ARCH_SUN7I=y It is not good... Config file is here.

Just FYI: By simply exchanging U-Boot and the board's .dtb file Armbian is able to run on a Banana Pi M2 which is based on the A31s SoC: http://www.bananapi.com/index.php/forum/general-discussion-for-bpi-m2/995-working-wifi-on-modern-kernels-4-1-tested?start=6 (comprehensive instructions for Arch Linux on the M2 available there)

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 ?