Igor

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.

I fixed kernel compilation process within legacy kernel. Try now.

I'll try to conduct NAND install on my CB1 as soon as possible. I guess it must be something else ...

https://github.com/igorpecovnik/lib/commit/ac1b23dade9330d37808d484962ed06f362686aa Will be present in next build.

It's a general notice. Yes, available is only in legacy kernel and this will be for some time. Audio is mainlined and it'll be soon in stable.

The kernel(s) which we are using are blob free but within distribution there are blobs for wireless chips. Feel free to remove the firmware package to be fully on the GNU side I can mention that we are also using a blob for NAND loading on some boards but this will be solved once. Most used kernel in Armbian are: github.com/linux-sunxi/linux-sunxi (slowly going out) www.kernel.org (now and future) Is this more or is this less open source than Debian stock kernel? Generally I can declare this as an 99% GNU project.

If you want to build into an image template, than you will need to alter a code here: https://github.com/igorpecovnik/lib/blob/second/deboostrap.sh I haven't prepare for such scenario but it's possible, yes.

It's possible that this is happening because of bad / missing sunxi tools. Check if you have a program called nand-part ? Recently they were failing to compile. We need those tools! Try to compile by yourself and try again or wait for update.

You need to convert the kernel to uImage this way: mkimage -A arm -O linux -T kernel -C none -a "0x40008000" -e "0x40008000" -n "Linux kernel" -d zImage uImage

Thanks! OK, that's an option too. But I need to fix script bugs in any case

I never saw this - I would say it's some HW failure within your network. Check router, cables, get another board. Low speed indicates troubles / low quality link. BTW: Do you have a clean image? Did you only upgrade kernel and not u-boot?

I noticed few weeks ago that those utilities failed to build so I fix the git pointer to specific commit. Since than it should work ... I'll check.

This bug / limitation should be fixed within U-boot. This is the case with Banana.

You are using self compiled image? What about fex2bin bin2fex utilities?

1. Yes, you are right. Fixed 2. I made few tests with old kernel and it does not break ... 3. Aha, so just my comment is deprecated? Let's see how things will go fuhter. I only made few runs.

Yes, you change it by adding a (proper) kernel parameter to /boot/boot.cmd - you need to recompile boot.cmd to boot.scr at any change. I am not aware how nonstandard resolutions parameters are defined (at the moment) and if this is possible without fidling with kernel source.

@wildcat_paris Yes, it's better this way. geekfaq removed http://www.armbian.com/documentation/ geekfaq added http://www.armbian.com/using-armbian-tools/