Igor

Jessie with 4.0.4 / v3.8, v3.9 is reported to have problems but works for me. Odd. I just installed Jessie with 4.0.5 on Orange Pi and started with long term stress test. It's re-booting fine, hard drive is working, CPU freq scaling, battery charge / discharge, ... running some stress test periodically and running some services. Current uptime is only few days so it's a bit too soon to make conclusions but it looks it's stable. BTW. Distribution upgrades should work but they are not bullet proof.

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

FAQ - If I upgrade from older image / kernel. Are you upgrading from my installation or someone else?

Manual is in the FAQ but not sure if it's 100% valid for this older kernel. U-boot is not packed with kernel but separate. http://mirror.igorpecovnik.com/kernel/3.4.106-cubieboard-default.tar I can't find the exact u-boot, but try with this one. http://mirror.igorpecovnik.com/u-boot/linux-u-boot-3.4.107-cubietruck_3.6_armhf.deb

There is some problem with latest 3.4.107 build. Currently not sure where - it just hangs ... after days. I experience this first on Orange, than on Banana ... so I thing it affect all A20 boards. I suspect u-boot but am currently very tight with time for serious debugging. A good start would be to debug. We need to find out what's causing this. Try also with kernel 4.0.5 (u-boot is also a bit different).

Use this kernel. FTDI should work: http://mirror.igorpecovnik.com/kernel/4.0.5-lamobo-r1-next.tar Because you need to define this in the compilation process - make ARCH=arm or whatever target. Kernel compilation is / can be a nightmare ... I made a script to minimize risk, to simplify process, to save time but even if you fully stick to defaults, problems might occur. If you want do compile in any other but theoretically proper environment, native included, it might fail

In general: If you need some particular feature in kernel and you are not in a rush, propose changes directly to kernel config @Github: (Kernel) configurations: https://github.com/igorpecovnik/lib/blob/next/config/ kernel 4.0.5 config: linux-sunxi-next.config

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.

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.

Hmm, I am not sure that you will find anything in the log. At least not in default user mode. I am not a kernel debug expert, but I think looking trough this might be useful. http://elinux.org/Debugging_by_printing Regarding Ramlog. It's a bug which is safe to ignore.

You need to use one of the exiting tags. https://github.com/patrykk/linux-udoo Go to branch, select TAGS and you'll see what are possible tags. v3.18.3 does not exist, but v3.18.13, v4.0.0., .. If setting doesn't work trough my script, do it manually. I can check / fix later in the evening / tomorrow morning. Cheers.

Not at the moment. I have to check up on audio part. Maybe we only need to enable it? I just plug in my C-media USB and it's not recognized.

Image descriptions are only on-board hardware related. It will work with any supported USB DAC. You might need to install base sound utilities which is trivial. And yes, 3.4.x has much better hardware support, audio cards included.

Yes, I encounter this problem in recent build, but haven't got a solution yet. I thought it's related to hardware fail on some particular board. The problem could also be in U-boot. 100% working combination is kernel 3.4.106 with matched u-boot or older releases. I have zero problems with this, uptime several months. To disable ramlog: service ramlog disable reboot I am also working on to catch the bug, but it's a slow progress. Sometimes it works for weeks without a crash

Yes, working normally ... with some extra default kernel debugging in the log SD size you define in your initial call script. SDSIZE="2500" # SD image size in MB https://github.com/igorpecovnik/lib/blob/next/README.md This is the actual build script. You can build with old, not so recent, except in this scenario where is the latest kernel (and u-boot) hardencoded in / as an example. Some note should be there to clarify, I agree. No, it shouldn't. It should build properly regarding of the host LANG / locales settings. This needs to be fixed. I just build another image with Jessie. Runs o.k. - with XFCE desktop, installed manually ... need to fix that post auto install. Thanks for trying and finding problems I know that they are and I am doing my best to knock them down. If you haven alter anything in scripts under /lib than scripts are not updating anymore - at least your changes files. This is not yet under FORCE="yes" yet. Workaround - delete whole lib/ - save your customization elsewhere be4

Buggy development kernel with desktop on Jessie with some language customization is far worst possible scenario ... but I manage to build an image on first try with default language settings. Only desktop building failed for no apparent reason. I am going to fix that today if possible. Kernel 4.0.5 is latest stable, stick to this. I manage to build 4.1 RC Jessie has problems with or without my interventions. Desktop is here experimental - I don't deal with it. I hope I manage to find time and write a proper manual on this. I should Holidays are coming Enlarge default SD size a little bit, leave 4.0.5, leave default language, choose Wheezy / Trusty. Much better for start. Than tweak gradually. Most of things is cached, so build time is getting down to 2 minutes in best case.

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.

I am having the exact same hw configuration as described here. I am using latest (stable) mainline kernel 4.0.5, SPI is enabled in DTB like this: spi0: spi@01c05000 { pinctrl-names = "default"; pinctrl-0 = <&spi0_pins_a>; status = "okay"; spi0_0 { #address-cells = <1>; #size-cells = <0>; compatible = "spidev"; reg = <0>; spi-max-frequency = <50000000>; }; }; I am loading the driver like this and the displays back light goes on - so far is o.k. modprobe fbtft_device name=adafruit22a rotate=90 speed=4800000 fps=30 gpios=reset:272,led:226,dc:245 busnum=32766 This way, with different GPIOS numbers and without busnum parameter works perfectly well on kernel 3.4.x Kernel output when loading the driver on 4.0.5 [27880.540870] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [27880.549004] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [27880.551333] fbtft_device: SPI devices registered: [27880.551386] fbtft_device: spidev spi32766.0 50000kHz 8 bits mode=0x00 [27880.551406] fbtft_device: 'fb' Platform devices registered: [27880.551570] fbtft_device: Deleting spi32766.0 [27880.553696] fbtft_device: GPIOS used by 'adafruit22a': [27880.553735] fbtft_device: 'reset' = GPIO272 [27880.553756] fbtft_device: 'led' = GPIO226 [27880.553775] fbtft_device: 'dc' = GPIO245 [27880.553793] fbtft_device: SPI devices registered: [27880.553820] fbtft_device: fb_ili9340 spi32766.0 4800kHz 8 bits mode=0x00 [27880.575688] fb_ili9340: module is from the staging directory, the quality is unknown, you have been warned. [27880.819789] fb_ili9340 spi32766.0: SPI transfer failed: -22 [27880.819830] spi_master spi32766: failed to transfer one message from queue [27880.819850] fb_ili9340 spi32766.0: fbtft_update_display: write_vmem failed to update display buffer [27880.821093] graphics fb1: fb_ili9340 frame buffer, 320x240, 150 KiB video memory, 4 KiB DMA buffer memory, fps=33, spi32766.0 at 4 MHz When I write some picture to the display I got this: [28727.125092] fb_ili9340 spi32766.0: SPI transfer failed: -22 [28727.125141] spi_master spi32766: failed to transfer one message from queue [28727.125162] fb_ili9340 spi32766.0: fbtft_update_display: write_vmem failed to update display buffer [28727.154895] fb_ili9340 spi32766.0: SPI transfer failed: -22 [28727.154937] spi_master spi32766: failed to transfer one message from queue [28727.154957] fb_ili9340 spi32766.0: fbtft_update_display: write_vmem failed to update display buffer I haven't done the famous spi_test.c test and I also doesn't have any equipment to debug further. Is there any stupid thing that I am doing wrong or is this simply not done yet? Anyone got further on this?

I already add few other things which might be useful in this area. I think this kernel should help in that case too.

Try the kernel from http://forum.armbian.com/index.php/topic/74-bpi-r1-umts-e220-usb-problems/?p=341 CONFIG_USB_SERIAL_FTDI_SIO=m I enabled this while building and some other general serial com stuff.

You used my stock 3.4.107 image? http://mirror.igorpecovnik.com/kernel/4.0.5-lamobo-r1-next.tar Try this one ... recompiled with what was missing.

Mainline, currently (4.0.5) we have: available frequency steps: 144 MHz, 312 MHz, 528 MHz, 720 MHz, 864 MHz, 912 MHz, 960 MHz

My version of kernel 3.4 is not that much different (at least in this part) from the one in Bananian so I think this feature works equal. I am not 100% sure since I don't pay much attention - I pay attention to the main community Linux: https://github.com/linux-sunxi/linux-sunxi 2 & 3 Status of mainline: http://linux-sunxi.org/Linux_mainlining_effort I don't use any extra configuration script except NAND / SATA / USB installer. The rest is either Debian/Ubuntu stock (keyboard, timezone, ...) or automatic (partition resize, SWAP) or done via .deb install (kernel switching, upgrade). I tend to have images as clean as possible.

This part needs to be fixed ... since new u-boot auto detect HDMI / VGA and set output accordingly. I do detecting in first boot script and if you haven't plug HDMI at first boot, than it fix output to VGA. Now you need to enable HDMI for kernel manually. bin2fex /boot/script.bin /boot/script.fex nano /boot/script.fex # screen0_output_type = 3 fex2bin /boot/script.fex /boot/script.bin reboot

Do you have them? And how is working under Bananian? Kernel source is very similar, configuration looks o.k. ... BTW. Try with kernel 3.4.107 ... 4.x has issues.