Menion Posted August 25, 2017 Author Posted August 25, 2017 Hi 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?
zador.blood.stained Posted August 25, 2017 Posted August 25, 2017 12 minutes ago, Menion said: Is it going to come in some Armbian build option? Don't know. We probably could use some feedback regarding memory consumption and performance, preferably on boards with 512MB RAM: https://github.com/armbian/build/issues/645
Menion Posted August 25, 2017 Author Posted August 25, 2017 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!
Menion Posted August 25, 2017 Author Posted August 25, 2017 ... and my two cents on this topic is the 32bit userland for 64bit SoC shall be the default, leaving 64bit user space for special use
Menion Posted August 25, 2017 Author Posted August 25, 2017 I see that apt pretend to get kernel and uboot from orangepipc instead pc2. But the armbian apt source is the same. Where is the variable used by apt to select the board?
zador.blood.stained Posted August 25, 2017 Posted August 25, 2017 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.
Menion Posted August 25, 2017 Author Posted August 25, 2017 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 menion@orangepipc:~$ 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)
Menion Posted October 29, 2017 Author Posted October 29, 2017 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 MMC: SUNXI SD/MMC: 0 *** 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. Aborting! 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 root@menion-VirtualBox:/boot/dtb/allwinner# 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 Bye --edit-- Nevermind.... Never work on these things with two twins of 19 months old trolling you 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
Menion Posted November 1, 2017 Author Posted November 1, 2017 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?
zador.blood.stained Posted November 1, 2017 Posted November 1, 2017 Most build environments should have switches to override autodetected host architecture, toolchains, etc. Usually it can be changed during the configuration phase. https://github.com/FFmpeg/FFmpeg/blob/master/configure#L324
Menion Posted November 1, 2017 Author Posted November 1, 2017 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...
zador.blood.stained Posted November 1, 2017 Posted November 1, 2017 I don't use such mixed environment so I'm not sure I can provide much help, bit I would suggest to take a look at FFmpeg debian/rules file for your OS release, i.e. from here for Stretch. You may need to set more arch-specific options (cross-prefix, target-os, cc, cxx, ...)
Menion Posted November 1, 2017 Author Posted November 1, 2017 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
Menion Posted November 2, 2017 Author Posted November 2, 2017 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
Menion Posted November 2, 2017 Author Posted November 2, 2017 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
zador.blood.stained Posted November 2, 2017 Posted November 2, 2017 Isn't this void *reserved2; an even bigger problem due to the pointer size difference?
Menion Posted November 2, 2017 Author Posted November 2, 2017 I must be blind.... that is the problem I will write in the linuxtv mailing list, chance to get it fixed very little, but it is a quite big problem
zador.blood.stained Posted November 2, 2017 Posted November 2, 2017 11 minutes ago, Menion said: I will write in the linuxtv mailing list, chance to get it fixed very little, but it is a quite big problem But any attempt to fix the existing API may break currently working 32-32 and 64-64 kernel-userspace combinations.
Menion Posted November 2, 2017 Author Posted November 2, 2017 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...
Menion Posted November 2, 2017 Author Posted November 2, 2017 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)
Menion Posted November 2, 2017 Author Posted November 2, 2017 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
Menion Posted December 7, 2017 Author Posted December 7, 2017 @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? Bye
zador.blood.stained Posted December 9, 2017 Posted December 9, 2017 If I understand it correctly uInitrd arch depends on what u-boot is expected to see since it unpacks the image and passes its contents to the kernel.
Menion Posted December 9, 2017 Author Posted December 9, 2017 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
Recommended Posts