Jump to content

Compile 32bit Armbian for aarch64 capable SoC

Recommended Posts


System booted and works just fine, I only have to check some network issue, apparently I cannot get any DNS from DHCP, strange...

I am using a nightly for Orange Pi PC, when the new 99-uboot has been implemented?
So to recap it is ok to use uboot kernel from the arm64 build and userspace in armhf.

Is it going to come in some Armbian build option? :)

Link to comment
Share on other sites

Donate your old hardware to community. Start a giveaway Raffle!

I will provide some feedbacks on IT (but I would need more time to reconstruct everything) 

As I have said with some, kind of normal for an enhanced NAS,  number of servers, you hit problems also with 1GB of RAM. 

Meanwhile, thanks for the support! 


Link to comment
Share on other sites

2 minutes ago, Menion said:

Where is the variable used by apt to select the board? 

apt uses list of installed packages to determine upgrades. apt data lives in /var/lib/dpkg, though I would recommend disabling the Armbian repository by removing /etc/apt/sources.list.d/armbian.list because things may break on upgrade, and they will certainly break if you upgrade the kernel and u-boot because their sources were switched recently and currently there are some breakages and regressions.

Link to comment
Share on other sites

Anyhow I need to do more tests, for example resolvconf does not work 


menion@orangepipc:~$ sudo resolvconf -u
trap: EXIT: bad trap
run-parts: /etc/resolvconf/update.d/libc exited with return code 1


But I get ipv6 ip that seems to be broken with latest orange pi pc2 code (not sure if because later kernels or some users pace tool) 

Link to comment
Share on other sites

So, sorry for the delay, but I have so few spare time these days.

I am trying to build my server on top of an armbian armhf with oprangepicp2 aarch64 kernel, to make some memory consumption comparision

So I built two armbian ubuntu xenial console image, based on next branch

I have swapped the uboot, chroot into the resulting image, and instead of manually moving kernel and modules around, I have removed the armhf ones and installed the aarch64 ones via dkpg (just to be cleaner and ready to some apt update)

The only think that I have manually taken from  the oprangepipc2 image are the boot script from the /boot directory (because I am not sure if they are included in any deb packages)

Then I have burned the image and tried

There is a problem with the dtb that I cannot REALLY understand

This is the Uboot log:


U-Boot 2017.09-armbian (Oct 29 2017 - 10:29:43 +0100) Allwinner Technology

CPU:   Allwinner H5 (SUN50I)
Model: OrangePi PC 2
DRAM:  1 GiB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c30000
230454 bytes read in 154 ms (1.4 MiB/s)
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
scanning bus 0 for devices... Device NOT ready
   Request Sense returned 02 04 01
2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3708 bytes read in 204 ms (17.6 KiB/s)
## Executing script at 4fc00000
Boot script loaded from mmc
152 bytes read in 173 ms (0 Bytes/s)
5698470 bytes read in 562 ms (9.7 MiB/s)
6853176 bytes read in 635 ms (10.3 MiB/s)
Found mainline kernel configuration
** File not found /boot/dtb/allwinner/sun50i-h5-orangepi-pc2.dtb **
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.

So it is complaining that it cannot find the dtb, but the dtb is there!!!

root@menion-VirtualBox:/boot/dtb/allwinner# ls -la
total 216
drwxr-xr-x 3 root root  4096 Oct 29 13:31 .
drwxr-xr-x 3 root root  4096 Oct 29 13:31 ..
drwxr-xr-x 2 root root  4096 Oct 29 13:31 overlay
-rw-r--r-- 1 root root 14406 Oct 29 09:44 sun50i-a64-bananapi-m64.dtb
-rw-r--r-- 1 root root 18556 Oct 29 09:44 sun50i-a64-orangepi-win.dtb
-rw-r--r-- 1 root root 14505 Oct 29 09:44 sun50i-a64-pine64-plus.dtb
-rw-r--r-- 1 root root 14431 Oct 29 09:44 sun50i-a64-pine64.dtb
-rw-r--r-- 1 root root 14377 Oct 29 09:44 sun50i-a64-sopine-baseboard.dtb
-rw-r--r-- 1 root root 28577 Oct 29 09:44 sun50i-h5-nanopi-neo2.dtb
-rw-r--r-- 1 root root 28999 Oct 29 09:44 sun50i-h5-orangepi-pc2.dtb
-rw-r--r-- 1 root root 29177 Oct 29 09:44 sun50i-h5-orangepi-prime.dtb
-rw-r--r-- 1 root root 28539 Oct 29 09:44 sun50i-h5-orangepi-zero-plus2.dtb

This is a live "ls" from the image, mounted via chroot that I have burned on the SD, the dtb is there, the path are correct, so I cannot really understand what is wrong here....

Probably something stupid, but in case it is not I can upload the image somewhere if anybody of you want give it a try






Never work on these things with two twins of 19 months old trolling you :D I just swapped the image I have worked on with the one I have flashed....

It boots fine, it will take some days to reinstall everything, then I can provide some figures


Link to comment
Share on other sites

Hello @zador.blood.stained I need some help here

The system works, but I have big troubles with the building environment. What happens is that variouse build systems, especially the ones using some arch specific ops (like ffmpeg) but also libtorrent bindings, get confused.

For ffmpeg/libx264 it fails to properly detect arch for embedded asm (ffmpeg goes for aarch64) or fpu (neon errors), libtorrent python bindings also detects aarch64 instead of armhf...

I have added arm64 architecture to the dpkg, but I don't think this is the problem, because in qemu at least it never goes for aarch64.

Do you know what can be the problem?

Link to comment
Share on other sites

Yes I know, but some don't, as for example the build python script.

In this case the only problem is "cosmetic", since a good armhf code is generated but in a wrong temp directory (aarch64)

For ffmpeg it is even more strange, I set --arch=armhf in configure, but it tries to compile some embedded arm64 asm in c files...

Link to comment
Share on other sites

There is nothing wrong in Armbian, it is lack of knowledge from my side, I just ask if anyone knows better the topic :)
For the moment I use chroot and qemu, I think this should work in anycase since as far as I know, it is the build system for the ubuntu/debian repositories

Link to comment
Share on other sites

I did some more test. I expected this: some drivers have problems, actually bug, with ioctl parameters. As example the DVB-T rtl2832 driver is affected: the ioctl return parameters are completely wrong and so the dongle is unusable. I will try to see if I can fix it, but it is a clue that this kind of setup, even if usefull (preliminary memory consumption show a 25% of memory saving), is difficult to maintain :(

Link to comment
Share on other sites

It seems to be really a problem with the ioctl structures definition in the dvb frontend kernel header file.

As example, even the DVB API read with FE_GET_PROPERTY ioctl is wrong

The API version is stored with a simple = in the data field of the structure:


struct dtv_property{

  __u32 cmd;

  __u32 reserved[3];

  union {

      __u32 data;

      struct dtv_fe_stats st;

      struct {

        __u8 data[32];

        __u32 len;

        __u32 reserved1[3];

        void *reserved2;

      } buffer; 

   } u;

  int result;

} __attribute__ ((packed));


in 32bit userspace this is just wrong, while it works in 64bit userspace (tested with w_scan)

One thing really bad in the structure is the fact that it contains a native type field "result" set to int. This should not be a problem, since it is 32bit in both 32 and 64bit, the problem here I think is the packed.

I am not sure if it is taken also by the internal structures and array.

I would check it but gdb fails to load the executable, it gets a SIGSEGV in ld :(

Link to comment
Share on other sites

Well, there must be a way, since this is the only problem I get now

After having digged a little bit more, the problem is this one:


struct dtv_properties {
    __u32 num;
    struct dtv_property *props;


the real ioctl interface is an array of this dtv_property struct (where there is of course the problem with the void*). But still, here there is a complete mismatch with the pointer size

As I said, there must be a way to properly implement portable ioctl structure, maybe it is just to completely avoid to put pointers into pointers...


Link to comment
Share on other sites

They should have implemented the structure this way (even if it is a little bit more memory hungry, but normally this is a temporary stack memory usage):


struct dtv_properties {
    __u32 num;
    struct dtv_property props[DTV_IOCTL_MAX_MSGS];


but there are two problem, the first one is that the structure is copied from user two time, the latter with the former pointer and it would not work with the array. The modifications are simple, but it would break the ioctl compatibility, it would require a new DVB API major.

I have written an email to the linux-tv mailing list, I think this is something definitely needed to be fixed.

Of course it is still possible tu run an arm64 bit version of the DVB app, which is what I am doing using a precompiled ppa (since otherwise I should cross-compile) and fixing some stupid dependencies problem in multi-arch (with package dtv-scan-tables)

Link to comment
Share on other sites

Ok, I have reinstalled all the services I had and make a mem usage check:


64bit userland

menion@orangepipc2:~$ egrep --color 'Mem|Cache|Swap' /proc/meminfo
MemTotal:        1018536 kB
MemFree:           33660 kB
MemAvailable:     235864 kB
Cached:           249024 kB
SwapCached:         9252 kB
SwapTotal:       2111484 kB
SwapFree:        1969148 kB

32 bit userland

menion@orangepipc2:~$  egrep --color 'Mem|Cache|Swap' /proc/meminfo
MemTotal:        1018572 kB
MemFree:          157292 kB
MemAvailable:     465496 kB
Cached:           346984 kB
SwapCached:            0 kB
SwapTotal:       2111484 kB
SwapFree:        2111484 kB

relevant services active,: apache2, amule, deluge, freeradius, php-fpm, mysql, 2xopenvpn server,  shellinabox, nfs sharing, samba, tvheadend (64bit)


I think the difference is important, and most important physical swap never run

Link to comment
Share on other sites

@zador.blood.stained It has been a while that I am running my "hybrid" image, the results are very very positive from both performances and most important memory footprint.

Also, adding the arm64 architecture and replacing the kernel dtb and uboot images, permits to ugprade everything directly by apt-get. But there is one little problem here: the package linux-xenial-root-next- must follow the userland version, so to say. In my case it is orangepi. But in this package there is also a new armbian-release file, that is set to generate initramfs for armhf instead of aarch64.

So, I don't know what are the plans for the 32 bit userland on 64 bit kernel official Armbian release, but maybe in the meawhile you may think to add a postinstall script that adapt the initrd architecture based on the kernel type?


Link to comment
Share on other sites

Yes, but the armbia-release under /etc is delivered with linux-xenial-root-next- that must follow the image userland arch. So if this is armhf and you install it on a aarch64 kernel, the uintrd image will be generated as armhf and the system will fail to boot. So, in very general case, the UINTRD variable in armbia-release shall be set according to kernel and/or uboot arch

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Create New...