Igor

Wait that first run finish the job, than login - it takes few minutes. Wrote on mobile phone

You mentioned: 7 LEDs triggered by the system events So I thought you are using GPIO header. The numbers are different . Regarding power supply. There are some topic on this forum and else where this problem is worked into details. R1 has a design fail regarding power supply. If you want to use board in full scale than you need to fix powering. Micro USB has it's own power limits and they are less then what's needed for everything.

Added that to, thanks Horst. https://github.com/igorpecovnik/lib/commit/282fac50d704a02621f04471cc46c69f2612dc10

Yes and no. I do many compilation and sometimes it does not build up, than in few days - when things are fixed - everything is fine. Is this a problem of debootstrap, packets, ... I don't explore. Jessie is the problem winner, than Trusty and Wheezy which is somehow logical. I am among those few % who notice such things. Yes, Jessie become stable. With minor, probably irrelevant, glitches. But if you can't boot the system due to bug which is most likely from os ?

There is a hardware walk around for powering SATA. GPIOs. On new kernel you will need recalculate: http://linux-sunxi.org/GPIO

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

GPT is supported, that's not a problem. What do you have if you type:

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?