Igor

Then it looks like your NAND is completely empty Booting is depended from "boot footprint". Technical background and solution which needs to be implemented withing the script. Fix for this was developed recently and has not been tested / implemented yet so there is only one thing you can do: 1. Install Lubuntu to NAND (or just any factory image) with Phoenix tools, (do one test run just to make sure it boots from NAND, to exclude hardware error) 2. Boot from my SD image and repeat the whole NAND install procedure. You will not need to apply any extra commands. You hit the worst install case scenario

1. You found a bug . If NAND was not used before the script got stuck ... here is a workaround which will create two partitions on your NAND: (echo y;) | nand-part -f a20 /dev/nand 32768 'bootloader 32768' 'rootfs 0' Run the install script again and it should work fine. It will ask to reboot once, than you need to start the script again ... it will take several minutes for copying. 2. This is normal. If you don't have your system on NAND you can't boot without SD card. Do you want to boot from NAND and have system on DD? Than you need to boot from NAND and run this install script again to transfer it to DD. I know it's a bit stupid way but it works. SD -> NAND -> DD

I had many troubles on the way to keep it clutter free & close to default Debian / Ubuntu way & knowing with their bugs too I am also looking forward to develop further and glue things together so that upgrade process could run fully automatic - if wanted.

You are probably referring to this: http://lists.denx.de/pipermail/u-boot/2014-September/190239.html This is done in uboot so you need to experiment with this parameter: CONFIG_GMAC_TX_DELAY= (try with numbers from 1-10) File is here: u-boot-sources/configs/A20-OLinuXino-Lime2_defconfig I don't know for any better way than this: 1. compile - DD to SD card - reboot 2. test 3. change parameter and try again

It looks like you are not using proper script.bin file? Where is your /boot/script.bin pointing to? It must be to the bananapro.bin script.bin -> /boot/bin/bananapipro.bin Just get the latest 3.4.107 and you will be fine. Get Wheezy if you don't want to find new problems.

No scripts, only download, unpack and dpkg -i at this point. The deb files has some post-install logic but nothing major. I only distinguish new / old kernel which is somehow important because of different loading process. The rest is more or less not done yet. The idea is to push to repository and that new versions are updated the standard way like on any other distribution via apt-get update It would be nice to retest updating on some real demo repository. To find and fix possible bugs. ... then added a switch UPDATE_REPOSITORY="YES" + sub script to do all this I was talking with a friend about this but we haven't made any progress yet so my Github lib section is script wise more or less up to date. Appreciate your help and open for ideas.

https://github.com/igorpecovnik/lib/blob/next/documentation/general-faq.md#how-to-install-to-nand-sata--usb If the install was successful you remove the card and it should boot from NAND. In minor cases you might need to fix boot record on NAND. Follow instructions under FAQ. You need to de-compile with: bin2fex script.bin script.fex You can edit the .fex file. Check this guide: http://linux-sunxi.org/Fex_Guide When you done. fex2bin script.fex script.bin Reboot.

Yes, building is failing within kernel 4.x ... If you need this, stay on older version and wait for fix / update ... or help us fixing , ping USB redirector support,... I'll do that eventually but currently it's not under my urgent nor important tasks.

It works interactive but not in non-interactive mode. Another Debian bug Working on walk-around.

http://www.incentivespro.com/support.html Try talking to their support. It was compiling well up to 3.19.x with this adjustments. # patch to work with newer kernels sed -e "s/f_dentry/f_path.dentry/g" -i usbdcdev.c

I finally get into this error Reset doesn't help. Power on/off and it boots o.k. Strange systemd / Jessie problem ?

I'll add this to the script and to the FAQ. Thanks. A quick solution: export CHARMAP=UTF-8 FONTFACE=8x16 DEBIAN_FRONTEND=noninteractive dpkg-reconfigure console-setup This is working for me - my locales are en_US.UTF-8. I guess this must be matched? Now the mc looks ok, some functional keys works but that's another story since my keyboard has only F1-F8

USB redirector fails to compile on 4.0.4 anyway, Debian Jessie is still problematic. If you want a full featured working system stick to Wheezy and kernel 3.4.107 p.s. I tested Jessie 4.0.4 installation many times and it works. I haven't try to first boot without a network but that shouldn't make any difference. Hardware wise there are two versions of Cubietruck A/B but that also should not affect on this level. No idea why it doesn't boot properly. Good power supply?

Most important part is missing - try to catch what's before that. If card content cannot be read u-boot seeks for network boot ... There is probably something wrong with the card or the writing process. But since I don't have CB2 I am not 100% sure. Cubietruck images are working and Cubieboard2 is almost the same. But strange errors are always possible

more /etc/hostapd.conf ssid=cubietruck interface=wlan0 hw_mode=g channel=5 driver=nl80211 bridge=br0 logger_syslog=0 logger_syslog_level=0 wmm_enabled=1 ieee80211n=1 wpa=2 preamble=1 wpa_psk=66eb31d2b48d19ba216f2e50c6831ee11be98e2fa3a8075e30b866f4a5ccda27 wpa_passphrase=12345678 wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP auth_algs=1 macaddr_acl=0 noscan=1 #ht_capab=[HT40-][SHORT-GI-40][SHORT-GI-40][DSSS_CCK-40] #country_code=SI #ieee80211d=1 Configuration for realtek: more /etc/hostapd.conf-rt interface=wlan0 ctrl_interface=/var/run/hostapd ssid=orangepi channel=5 noscan=1 wpa=2 wpa_passphrase=12345678 bridge=br0 wmm_enabled=1 driver=rtl871xdrv beacon_int=100 hw_mode=g ieee80211n=1 wme_enabled=1 ht_capab=[SHORT-GI-40][HT40+][HT40-][DSSS_CCK-40] wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP max_num_sta=8 wpa_group_rekey=86400

This is strange. I downloaded Jessie from my download site, v3.8 with kernel 4.0.4. boots fine. You need to wait until it reboots. It is doing ssh key creation and apt-update so it takes some time, up to few minutes this applies only to Jessie: during this time you can't login. BTW: wireless AP mode works out of the box - you only need to use /etc/network/interfaces.hostapd and run hostapd /etc/hostapd.conf

Check / add this: http://forum.armbian.com/index.php/topic/22-wlan-on-ct-not-working/?p=85 You can use the same module as on Cubietruck. Chips are almost identical, drivers too. Both shows some extra warning and errors but the work. Actually quite ok. On wheezy you need only to load module bcmdhd with op_mode=2 in: /etc/modules

I have one experience with Wheezy under kernel 3.4.x running 7" LVDS display on Banana Pi in portrait mode. Booted with extra kernel parameter, I think it was just fbcon=rotate:1 The console booted in portrait and also LXDE was started properly, only the touch screen controller was still in normal mode ... I haven't even try to fix that since it was only a test boot. X is not my home. I think you need to do some extra configuration to bring up rotation on the fly. Try first with 3.4.x since on 4.x might not be working at all.

There are many confusions which I am trying to merge. A lot has been done in this matter but still. If you are using Jessie and you want to establish AP you will need to create additional file in: /etc/modprobe.d nano local.conf options bcmdhd op_mode=2 And this is needed only on old 3.4 kernel This is how you check if your CT adapter is in proper mode - 0 is default: systool -m bcmdhd -v | grep op_mode

This is known problem for v3.7 ... I double checked the new compilation and I'll do it again during a day. Don't know exactly what was the problem but it was Debian problem. I only rebuild the root-fs and troubles gone away. If you were compiling by yourself make sure you delete output/rootfs/jessie-rootfs.tgz ... cached filesystem.

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

My default example configuration is meant to work with /etc/network/interfaces.hostap where wlan0 and eth0 are connected to a bridge so wlan0 AP clients are geting a dhcp from the main network - from your router.

Yes, it looks like this is not enabled in kernel. If you are in a rush try to compile yourself or wait for update. I hope it works. lsmod | grep -i seq Jessie 2.9 was broken - latest image is fixed. Thanks

Disable (commend out) eth0 and boot only with wlan0 and you should be fine. If you want to have so called backup or notebook mode - to work with any connection in "plug and play" mode - than you need to use bonding. There is one example configuration and I hope it works in kernel 4.x ... I was testing this only on 3.4.x

OK, some quick tips: v3.7 jessie image is broken due to some systemd changes. I saw too late. 3.8 is boots ok - at least with network attached. I haven't tested without for a while. On new kernel there is no output to serial console by default. loading with bcmdhd op_mode=2 works with wheezy and trusty but not jessie 4.0.4 different module brcmfmac. It should work ... I haven't tested with 4.0.4 but with 3.19.x and it was working w/o problems. If you want a proven configuration, stick to Wheezy with kernel 3.4.x Video resolution. I'll go down with default one or made some other solution. Waiting for 3min might not be enough. I am doing apt-get update at first boot.