Igor

I found a problem. Fix is coming within next commit.

Nice to hear that! I need to work further on the script to be more resilient - that it will done the job in absolutely all situations.

Just a note that I also had no success.

I don't understand what problems do you have. The manual procedure is written here. Here goes a copy / paste for your particular case: 1. You need to add repository if you don't already have it and update packages. echo "deb http://apt.armbian.com $(lsb_release -cs) main" > /etc/apt/sources.list.d/armbian.list apt-key adv --keyserver keys.gnupg.net --recv-keys 0x93D6889F9F0E78D5 apt-get update 2. Create boot script cd /boot rm boot.cmd wget https://raw.githubusercontent.com/igorpecovnik/lib/second/config/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr 3. Install packages apt-get install linux-u-boot-lime2 apt-get install linux-image-sun4i apt-get install linux-headers-sun4i apt-get install linux-firmware-image-sun4i apt-get install linux-$(lsb_release -cs)-root-lime2 If some package say some duplicate error or something, remove that package and install that one again. 4. Reboot

O.K. I believe you It's working here but yes it's possible that something is not quite right. I am doing code inspection ...

Hey. Take a look on threads where we discuss about R1 troubles to see why the most obvious solution might not be the right one. Than if you want to have a good wireless coverage no onboard solution is perfect. Perhaps the best / most stable one is Cubietruck / BananaPRO. But since you are going to use this in a bar, you need to have in mind the limitation of wireless users. All clients (i think max is 5) need to share 56Mbit network speed which will be very bad in peek hours. Bottom line. Perhaps a decent dual band gigabit wireless router + any A20 based banana / cubie / olimex will be much better / realistic solution.

Is your system working normal? Which modules are you using beside defaults? What you get from: lsmod

Than xorg.conf is somewhere else ... do a search.

Hmm, update while installed on /dev/sda seems to cause troubles. Other scenarios works. If you haven't rebooted, I think you will need to install kernel+uboot+dtbs+roots via apt-get metod I am working on this solution.

I suppose it should work within this manual. I am not doing much different except I use mainline u-boot / kernel source and automate some things ... but those sources doesn't fully support your board. I guess first try some alternative sources and linux sunxi should be the first to try out. If you succeed ... Inside armbian documentation you will find "how to add a board" ... If it's working we can add the board to the script.

1. Use a supplied call script: https://github.com/igorpecovnik/lib/blob/second/compile.sh It looks like kernel was not download properly. Manually remove sources/linux-mainline and rerun the script. 2. That's ok 3. Also.

No, my scripts are not designed for such use but you can extract certain commands. You can install desktop standard way ... just fix the xorg configuration afterwards. The part which I pointed out is critical - you need to disable DPMS, perhaps not all are needed ... Section "Monitor" Identifier "Monitor0" Option "DPMS" "false" EndSection Section "ServerFlags" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection

Proper way is to build: u-boot with hackberry configuration. In this case you don't need to touch boot scripts since your target DTB is chosen auto. Than if things doesn't work properly is most likely that something is missing from DT ... or is not done yet. Basic thing should work. This is A10 or A20 version?

Safe to ignore.

Strangely, locales on Jessie are somehow corrupted. It could be my fault ... I am going to rebuild images soon, so I won't fix this one. Solution: locale-gen logout / login

You have to wait until first reboot. Than you can login. This so only with Jessie.

I hope you'll find any of this helpful: 1. Within image you don't have kernel source but headers. 2. I don't compile native since is damn slow but however it's possible. I saw people done it. 3. Rather use some x86 comp and cross compile. https://github.com/igorpecovnik/lib 4. If you compile anything do it with declaring proper architecture: make ARCH=arm 5. If you are not in a rush, propose configuration changes and support is built into our kernel within next build cycle

Not enabled OTG within DT is not a single issue ... I love extra patching Thanks for pointing out.

If you don't have boot scripts and you are coming from some old kernel or different distribution, rather use this tools to upgrade: wget -q -O - http://upgrade.armbian.com | bash Make sure to make a backup if anything goes wrong. For manual procedure check this ... Boot script is here. Place to /boot/boot.cmd ... than recompile.

I assume your USB doesn't work since it's not defined or not properly defined in DT. Similar situation is within legacy kernel. You need to have proper board configuration that things works properly. You already had a luck that you could boot the board without changing anything. To fix vanilla kernel, you will need to look into the difference / manual or check around for a proper DTB. First check here: https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-next

This difference is probably due to U-boot fine tuning. The rest doesn't have that much impact. Except governor, everything is as stated in wiki but nevertheless kernel is different. I don't do detail testing for each build but I'll check within next build. There are also two different legacy kernels now: sun7i and sunxi ... they differ in GMAC driver.

It's a known bug. Check my desktop build script to resolve the issue; https://github.com/igorpecovnik/lib/blob/second/desktop.sh#L123

Here is my "secret" workaround 1. Rebuild inside chroot and repack. https://github.com/igorpecovnik/lib/blob/second/boards.sh#L224 2. Before packing this patch is also needed - I do it within buildeb process: https://github.com/igorpecovnik/lib/blob/second/patch/misc/headers-debian-byteshift.patch I also needed few moments to recall how I solved this issue. Since kernel 4.3 has some changes within packaging process this workaround might stop working ...

Remember to update u-boot. That can produce such issues especially if you are still using some very old one.

OK, thank you for this! I have to pull back those 99% if we look from this perspective. None of those is cleaned to such degree at least not by me or not by my knowing. Why do we need blobs? I was speaking generally - for all boards. I added for Cubox wifi, Intel mPci that I use and some popular Realteks which come on USB. First question is - what do we loose by moving to cleaned / libre kernel? My primary goal within Armbian is to maintain a base system / kernel and that already become a hard job. I support and like the idea of blob free kernel but am currently supporting 6 different kernels. I would need a help to change this.