Menion

Can you point me where the cross compiler for userland is selected in the build script for the specific target? So I can try to swith to the 32bit version

Hi Yes the problem is the memory footprint I have an Orange Pi PC2 running some services, in particular amule, deluge, apache, freeradius, tvheadend, minidlna (plus the default Armbian userland services) This board has 1Gb of RAM. The problem is that I often run out of physical memory especially when the apt update package list run., or when I compile onboard some cpp stuff I do have swap set on the external USB HD, but I don't know if this is a bug or what, when the swap happen, all the user space application hang, since kswapd0 (kernel thread) run 100% of all the 4 cores. The result is that I can ping the board (ping is terminated in the kernel IP stack) but all the application services, including ssh are unresponsive. The behaviour is strange, it could also be a bug, or some irq affinity problem, don't know, but this is not the point The point is that for this kind of application (which are 99.99% of the application of this board, since it is hard that someone does some heavy computing with this SoC), there is no good reason to run 64bit. Consider that the Raspberry PI consortium basically does not eve provide an official 64bit distribution for the same reason. I think that with the current uboot and kernel makefile it is enough to select ARCH=arm and point to an armhf toolchain for CROSS_COMPILE in order to compile everything in 32bit The defconf (and the config) for kernel, should be a no issue, since it should get all the proper settings from the ARCH variable, you just need to select the proper SoC Are you sure? I think that the 32bit libc must be compiled against the 64 bit kernel (syscall parameters are different). I remember years ago, with the first ubuntu64 bit experiment, if you wanted to upgrade an existing 32 bit userland to 64bit kernel also the libc got updated

Hi I have managed to patch and compile the LEDE Snapshot (based on the 4.4.x kernel) I would like to issue a pull request, if you don't mind (of course I will give credit to you) But I need to understand one thing: as far as I see this patch is not included in mainline, right? Is it in the queue or not? Also, just for your information, the axp20x-calibrate-battery needs a modification to compile against musl libc, because lack of error() function Bye

Yeah, this is definitely something I can work on, thank you!

It is possible to swap kernel with some tricks, but Lede develops and use several network patches for their architecture. Anyhow I will look into that. About the apx: is it full functional in mainline, including battery monitor, or there are some armbian patches required?

Hi I am actually trying to do the same on my BananaPi with LEDE running kernel 4.4.79 I don't have /sys/power/axp_pmu, checking the sunxi mainlining effort in 4.4.x there is support for axp209_usb (that I have in /sys) but "axp" drivers have been merged in 4.9.x. Is this the kernel version I need (if I don't want to use i2c access)?

Actually I think you got a wrong impression of my (old) DVFS questions. First in 4.12 branch there is no DVFS support for H5. In the 4.12 branch, compared to the 4.11.y WIP used for the H5, as written, what I think it could be very useful to test, use and provide feedbacks to the community, is the USB OTG, which has always been a problem on Allwinner SoC, on A20 for example is still far from being perfect (if you try to connect a DVB-T to it you will understand why...) As always, my are just questions, I don't want to push anything, anyone. Unfortunately I miss most of the understanding of the internal Armbian branching policy, so I cannot even try to be of any help for you (for the moment) There is no need to be harsh Bye

Hi Is there any problem on bringing 4.12 kernel for H5 in Armbian? It should get rid of most of the patches implemented so far, plus it add support for USB OTG Bye

Hi all Is it possible to compile a full 32bit Armbian (32bit Kernel and 32bit userland) for targets that run aarch64 SoC (H5, A64, etc....)? Bye

I think that the best approach would be to chroot+qemu the img that is actually running on your armbian device and compile within it. The performances are really good, considering it is an x86->aarch64 emulation. I have used it to compile libraries that run out of memory (and swap on SD/USB is so slow that it is basically useless) on my OrangePi PC2 1Gb RAM

Hi, I have just updated uboot and kernel from Armbian build. Kernel is now 4.11.10-sun50iw2 on my OrangePiPC2 I see DVFS+THS patch added to kernel, but no dts bindings, so no cpufreq support and no throttling Also, the USB OTG does not work, even if the WIP code already exist Just as a point of discussion: I think that H3 and H5 shall share the same WIP branch, rather then use the same for H5 and A64. H5 and A64 have a completely different target products and very different architecture, they just share the CPU core. Instead H3 and H5 are much more similar, only cores differs Using https://github.com/megous/linux for H3 and H5 should get rid of most, if not all, the patches currently applied for H5 on Kernel, delivering at the same time a good level of WIP features for proper testing (and the fork itself is tested...) I would be happy to do it on my own to contribute, but I am very bad in bash and I am lost in the Armbian build scripts

Well Actually also the branch used by Armbian so far use the old sun8i-emac and it does not have the DVFS THS at all. Anyhow I am too far from having a full understanding of all the Armbian internals and dependencies, so I cannot really tell you more than just a suggestion Bye

Hi But would not be better to use this repo: https://github.com/megous/linux For the H5 (and possibly H3) build? It contains all the latest and greatest for H3/H5 that will come into mainline sooner or later Bye

DVFS for H5 has been "lost" by the developers, even if it exist in various form. I think it is mainly due to confusion about the PLL divider bug, which was stalling the CPU during frequency transition. The problem has been fixed in uboot. If you check the http://linux-sunxi.org/Linux_mainlining_effort you can see that the DVFS and THS for H5 is not even scheduled But I have posted on the sunxi newsgroup and if you check the post "DT based cpufreq scaling for H5" Icenowy Zheng (the principal sunxi dev) promised to give a look at it But, as I have said, the code is there, and the main, all including, experimental, repo for H5: https://github.com/megous/linux includes it. In this repo, there is the latest and greatest stuff (with decent testing) for H5. I would suggest the Armbian devs to used this repo for building kernel for H5 Bye

Could you share the patches? Some users, like me, need to tweak the default armbian configuration, i.e. DVB and VLAN support

I have filled a github issue and started a thread in development forum I see that one mandatory patch is not applied to uboot and the DVFS and THS patch for H5 have been moved to "unresolved" directory I think that user reported boot lockup due to the missing patch in uboot and Armbian devs removed the kernel patches... But so far none of the devs replied, I guess it is vacation time

Hi all I am working on having a working cpufreq support for Allwinner H5 SoC According to the mainline plan, it won't happen anytime soon (it is not even scheduled for 4.13) However some (working) patches already exist, there is a quite updated fork at: https://github.com/megous/linux Reading the provided information, there is also an absolutely required patch for u-boot that fix a PLL1 configuration Apparently this patch is already included in Armbian, it is the patch: But for some reason I really don't understand, this is not applied to the u-boot source, the file doesn't contain the patch. Other patches in u-boot-sun50i-dev are applied correctly, so I am wondering why (and how) this particular one is out. I don't have any userpatches override I have also noticed that the DVFS and THS patches for H5 have been moved to the "unresolved" directoryCan it be due to kernel lookup caused by the missing u-boot patch above? I have also adapted the dwmac-sun8i patch for 4.11.y. It is quite straightforward except for a conflict in PineA64 DTS and it requires some fuzzy (-F) to work However I don't fully understand the build system in Armbian. I have applied the path in the kernel downloaded under sources, the files are patched but if I re-run ./compile.sh I don't even get the new dwmac-sun8i driver in kernel config... Shall I clean something? Bye

Hi, EXPERT=yes, if used with KERNEL_ONLY=yes and KERNEL_CONFIGURE=yes doesn't work You have to specify the board, via BOARD= option Bye

Hi all I have updated the armbian repo today and all the H5 boards disappeared... Some new option to add maybe?

Hi all Is it possible (and if so how) to use the toolchain and the first kernel compilation output from armbian to recompile a single kernel module? Bye

libvdpau-sunxi1 is an experimental vdpau backend that in conjunction with an kernel driver has demonstraded hardware decoding of MPEG2 MPEG4, see: http://free-electrons.com/blog/support-for-the-allwinner-vpu-in-the-mainline-linux-kernel/ Unfortunately it seems that no one is actively working on it. Apart of the lack of support for H264/H265, the kernel driver is out of tree, so as usual, it doesn't compile anymore. In summary we are far away from having a RPi OMX like VPU support

Check here: http://linux-sunxi.org/1-Wire You may have to change the gpio you want to use to match your need If you are unfamiliar with overlay, you can decompile dtb in dts, make the changes and then compile to dtb again Bye

You have to clone the armbian repo: https://github.com/armbian/build Then recompile a kernel (use ./compile.sh KERNEL_CONFIGURE=yes KERNEL_ONLY=yes) and enable under drivers/multimedia/platform the v4l webcam support you need The out of tree linuxtv will never compile unless if matched with exactly the kernel version supported. It is a long story, and sadly one of the biggest limitation in Linux, that I believe no one is really willing to solve, such implement a stable framework for out of tree drivers implementation.

Apparently it has something to do with the specific DVB-T driver. I have tested a Terratec based on em28xx plus xc3028 tuner. Even if this key require much more current, it works perfectly with OPiPc2

I managed to get the kernel fault log: