Kernel for A64 git

[ak_hepcat]

All -

It's actually fairly easy to build longsleep's kernel for yourselves, and it only seems to take about 80 minutes from start to finish using all 4 cores.

I've slightly modified the way that /boot/ is laid out on my p64 so that it's easier to deal with (multiple) custom kernels. I haven't had any issues yet.

I've pushed my auto-build script here: https://github.com/akhepcat/build-pine64-kernel

i've added a couple of 'features' since i last tried it, but hopefully i haven't introduced any stupid errors - if so, just open an issue on the github page and i'll fix it up.


*** you should have a serial console available if you try this ***

because you don't want to be stuck booting an untested kernel without a back-door, right?

I've also attached my current 'config' to the github, which builds a number of wifi devices out of the box, as well
as support for network queuing.

(with qdisc enabled, I can get over 900mb/s transfer rate on the ethernet interface)

[insignia96]

So, the kernel has been working great so far, but I can't seem to get the update scripts to run properly. I am using Ubuntu 14.04.4 LTS aarch64 on a 64+ 1GB board with kernel 3.10.65-3-pine64-longsleep. The uboot update script (correctly) complains "Block device /dev/mmcblk0 not found." and the block device file is not present, but the root mount point is clearly mmcblk0 as seen when running lsblk:

Code:

$ sudo lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk0     179:0    0  14.9G  0 disk
|-mmcblk0p1 179:1    0    50M  0 part
`-mmcblk0p2 179:2    0  14.8G  0 part /

Any clues as to why this is? I tried to run the kernel update script as well, and it completed successfully (or rather without throwing any errors), but the kernel was the same version as before upon reboot.

[ak_hepcat]

you have pulled down the latest versions of those scripts, right?

In any case, you can run it in 'eXplain' mode, which will output the commands and show where the error is happening:

# bash -x pine64_update_kernel.sh

# bash -x pine64_update_uboot.sh

[longsleep]

Imported Kernel from BSP 2.0 to https://github.com/longsleep/linux-pine6....65-bsp2.0 for easy review of the changes. As there are lots of changes a overview is available at http://paste.ubuntu.com/16195299/

[longsleep]

I have looked at the Kernel changes from BSP 2.0 and found them insignificant and not worth the pain to do anything with it. If you feel otherwise, open up a issue at https://github.com/longsleep/linux-pine64/issues and explain why with code reference.

[tkaiser]

longsleep: Before releasing a new kernel please have a look at https://github.com/igorpecovnik/lib/tree...64-default

I sent one of my Pine64+ to Mikhail. Lost in transit for over 5 weeks but he received it few days ago and is now working on it like crazy. And in case you want to switch to BSP2.0 anytime soon please inform us immediately since rebasing all these patches to get to latest 3.10.y a second time would be a waste of efforts.

[longsleep]

Ah cool i can certainly pull those in. I have no plans to release any Kernels based on BSP 2.0 ever - promise.

[tkaiser]

Great. Answering IRC questions in a forum is somewhat moronic but currently I've only crippled network (http only). There's a problem breaking aufs compilation now but maybe he resolves that and increases 3.10.y version number to the max. Also this process is somewhat time consuming...

And regarding custom name: That's fine but since Armbian is an own 'ecosystem' removing it makes some sense.

Anyway, he's way more skilled than me, just have a look at the repo before you release something new. Being able to fix tons of issues by increasing the kernel version would be nice. And in the meantime I'm looking forward to use your sunxi-disp tool with a lot more than the current available HDMI resolutions on both A64 and H3

[janjwerner]

Damn,
This guy had too much time on his hands . I'm glad someone is doing this since I've been slacking with my CVE hunt...

[tkaiser]

Damn,
This guy had too much time on his hands . I'm glad someone is doing this since I've been slacking with my CVE hunt...

At Armbian we support a few more architectures and we take care that using legacy kernels is at least less insecure by applying available fixes where possible. So maybe patches already available for other SoC families have been re-used but testing them out is still a time consuming process and by looking through the commit log aufs compilation broke twice and hat to be fixed (now version at 3.10.100).

But he also reworked our debootstrap process and implemented FEL/NFS booting and just by these two 'tweaks' creating a whole full featured desktop/GUI OS image with the Armbian building system and starting to test it was a matter of 3-4 minutes (where I spent an hour minimum before and writing to SD card took longer than the whole process now avoiding the SD card at all).

@longsleep: Were you able to test higher resolutions than 1080p yesterday? And do you think about adding the two very popular 'DVI resolutions' 1024:768 and 1280x1024 (code existent but no one added them as additional modes so far)?