Menion

Hi all I am trying to build Armbian (Xenial Server) for H5 orangepipc2 I nee to customize kernel config to add some DVB drivers. The compilation starts but I get this error, but without any usefull information What I get is: CC [M] drivers/staging/rtl8723bs/os_dep/rtw_proc.o CC [M] drivers/staging/rtl8723bs/os_dep/sdio_intf.o CC [M] drivers/staging/rtl8723bs/os_dep/sdio_ops_linux.o CC [M] drivers/staging/rtl8723bs/os_dep/wifi_regd.o CC [M] drivers/staging/rtl8723bs/os_dep/xmit_linux.o LD [M] drivers/staging/rtl8723bs/r8723bs.o AR drivers/staging/built-in.o AR drivers/built-in.o [ error ] ERROR in function compile_kernel [ compilation.sh:338 ] [ error ] Kernel was not built [ @host ] [ o.k. ] Process terminated output.log in debug directory is not helping too much Displaying message: Compressing sources for the linux-source package Displaying message: Compiling dev kernel 4.13.0 info Displaying message: Compiler version aarch64-linux-gnu-gcc 7.1.1 info Displaying message: Using kernel config file lib/config/kernel/linux-sun50i-dev.config info Displaying message: Exporting new kernel config /home/menion/armbian/build/output/linux-sun50i-dev.config info Displaying message: ERROR in function compile_kernel compilation.sh:338 err Displaying message: Kernel was not built @host err Displaying message: Process terminated info (I would add timestamp in output.log anyhow) I am really lost, maybe some Armbian devs can help here Bye

This is the mainlining effort table In order to have a working, Mali driver, on top of a mainline kernel, something different is required, such a working DRM driver and the UPM module

Then we will use the Armbian patch I don't know if it could be related but with the H5 WIP kernel 4.11.10 the IPv6 has some problem, on my system I cannot get an IPv6 address from DHCP, which was working before (I think it was 4.11.4) Also, one or two time per day the ethernet connection stalls, in the dmesg I get: [204415.013774] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [204779.569976] sun8i-emac 1c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [205879.382799] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [206191.713237] sun8i-emac 1c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off [247047.620571] sun8i-emac 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [248221.164245] sun8i-emac 1c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off

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)

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?

... 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

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!

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?

Found the problem! This is the 99-uboot script in the Orange Pi PC image #!/bin/sh echo "update-initramfs: Converting to u-boot format" >&2 tempname="/boot/uInitrd-$1" mkimage -A arm -O linux -T ramdisk -C gzip -n uInitrd -d $2 $tempname > /dev/null ln -sf $(basename $tempname) /boot/uInitrd > /dev/null 2>&1 || mv $tempname /boot/uInitrd exit 0 modified to arm64 and going to test

Then there is something strange: root@menion-VirtualBox:/etc# cat armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=orangepipc BOARD_NAME="Orange Pi PC" VERSION=5.32.170629 LINUXFAMILY=sun8i BRANCH=dev ARCH=arm IMAGE_TYPE=nightly BOARD_TYPE=conf INITRD_ARCH=arm64 notice that the original armbian-release didn't have any INITRD_ARCH row root@menion-VirtualBox:/etc# update-initramfs -c -k all -v Available versions: 4.11.1-sun50iw2 Execute: /usr/sbin/update-initramfs -c -k "4.11.1-sun50iw2" -b /boot -v -t update-initramfs: Generating /boot/initrd.img-4.11.1-sun50iw2 Copying module directory kernel/drivers/hid ............................................. ............................................. Calling hook fixrtc Adding binary /bin/date Adding binary /sbin/hwclock Adding binary /sbin/dumpe2fs Building cpio /boot/initrd.img-4.11.1-sun50iw2.new initramfs update-initramfs: Converting to u-boot format but root@menion-VirtualBox:/etc# mkimage -l /boot/uInitrd Image Name: uInitrd Created: Fri Aug 25 17:56:33 2017 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4778579 Bytes = 4666.58 kB = 4.56 MB Load Address: 00000000 Entry Point: 00000000 So it is still 32 bit arm....

Tried, still the initramfs is detected as no aarch64. One thing worth to mention is that this hybrid image never ran on any target, it is just a downloaded image with uboot and kernel replaced, so I wonder if update-initramfs needs these info somewhere else, generated by the first run on target

I have the same identical problem with my OrangePi PC2 (AllWinner H5) The swap is just too slow so the kswapd0 kernel process get all the CPU power stalling everything in unser space. I don't know if it is just because the swap medium (SD or USB in my case) is too slow, or if there is some bugs (or wrong irq affinity)

Ok, then I will change only that row so it looks like: INITRD_ARCH=arm64

No, it does not work U-Boot 2017.01-rc1-g5df570f-dirty (Jun 13 2017 - 06:32:54 +0200) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: OrangePi PC 2 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment Setting up a 720x576i composite-pal console (overscan 32x20) Error: no valid bmp image at 66000000 In: serial Out: vga Err: vga Net: phy interface7 eth0: ethernet@1c30000 Hit any key to stop autoboot: 0 38518 bytes read in 115 ms (326.2 KiB/s) switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3362 bytes read in 129 ms (25.4 KiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 116 bytes read in 90 ms (1000 Bytes/s) 19253 bytes read in 527 ms (35.2 KiB/s) 4179 bytes read in 633 ms (5.9 KiB/s) Applying kernel provided DT fixup script (sun50i-h5-fixup.scr) ## Executing script at 44000000 4779271 bytes read in 620 ms (7.4 MiB/s) 11407368 bytes read in 919 ms (11.8 MiB/s) ## Loading init Ramdisk from Legacy Image at 4fe00000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 4779207 Bytes = 4.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK No Linux AArch64 Ramdisk Image Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing... starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 So, U-Boot looks for an aarch64 initramfs while the generated one in arm(hf)... I hadn't the time to check the uboot environment, but I am not sure how to move on, in the end now initramfs is an hybrid

Hi Actually both exist: -rwxr-xr-x 1 root root 743 dic 9 2016 klibc^i-t -rwxr-xr-x 1 root root 678 gen 26 2016 klibc-utils -rwxr-xr-x 1 root root 743 dic 9 2016 klibc^i-t -rwxr-xr-x 1 root root 678 gen 26 2016 klibc-utils and both does the same, actually some non sense to me root@menion-VirtualBox:/usr/share/initramfs-tools/hooks# ./klibc^i-t /bin/cp: '/lib/klibc-wBxlC8vEZykm9g94Kf1Dr2tj4ts.so' and '/lib/klibc-wBxlC8vEZykm9g94Kf1Dr2tj4ts.so' are the same file root@menion-VirtualBox:/usr/share/initramfs-tools/hooks# ./klibc-utils /bin/cp: '/lib/klibc-wBxlC8vEZykm9g94Kf1Dr2tj4ts.so' and '/lib/klibc-wBxlC8vEZykm9g94Kf1Dr2tj4ts.so' are the same file

Then it is possible it will cause problem, right?

No. It is a brand new LiPo battery of a decent brand also. I have anly the BananaPi and a WiFi USB dongle connected

Hi @zador.blood.stained maybe you can help me on one thing. I have connected a LiPo battery, it works, but when the AC is connected I get a battery voltage of about 4.11v which is full charged and the axp try to keep it around 95% with some charging On/Off But If I disconnect the AC, the battery voltages drop to 3.9v so about 55% of capacity Is it normal?

So, I have launched in chroot+qemu: root@menion-VirtualBox:/# update-initramfs -u -v but for some reason it pretends that the kernel is still the OrangePi PC one: Available versions: 4.11.7-sun8i update-initramfs: Generating /boot/initrd.img-4.11.7-sun8i WARNING: missing /lib/modules/4.11.7-sun8i but I have the OrangePi PC2 stuff, such: root@menion-VirtualBox:/lib/modules# ls 4.11.1-sun50iw2 root@menion-VirtualBox:/lib/modules# So, something else should be changed, but I cannot understand what/where. --edit-- Found, I have to generate a md5sum file with the kernel version as filename under /var/lib/initramfs-tools Or actually I could launch: update-initramfs -v -c -k all One thing: in the update-initramfs I get this two errors: /usr/share/initramfs-tools/hooks/klibc^i-t ignored: not alphanumeric or '_' file end Calling hook resume Unsupported ioctl: cmd=0x5331 Nothing to be worried of?

Yes I have replaced also armbianEnv.txt!!! So there are two things to do, update the UUID and update initrd One extra thing: on my running aarch64 image, this is the content of armbianEnv.txt verbosity=1 console=both overlay_prefix=sun50i-h5 rootdev=UUID=00f42023-d4d4-499b-9a57-e3c8d029e8e4 rootfstype=ext4 apart from the UUID, how should the rest look for this hybrid image? In particular I wonder about "overlay_prefix" Do you know if blkid can read UUID from a img file or from a loop mounted img?

mmmmm I am thinking about it What is this: Is it some script in initrd? Because this initrd image is taken straight direct from the Orange Pi PC2 image (I have replaced all the /boot content), so actually it does match the kernel.... Unless initrd call some executable in the root file system, in this case it is definitely required to update it, due to the rootfs being 32bit

Ok I will do that.

Hi I tried it but it cannot work, I suspect the problem is the uinitrd image that should be 32bit also But I don't know if I can just take it from Orange Pi PC image U-Boot SPL 2017.01-rc1-g5df570f-dirty (Jun 13 2017 - 06:32:47) DRAM: 1024 MiB Trying to boot from MMC1NOTICE: BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000) NOTICE: Configuring SPC Controller NOTICE: BL3-1: v1.0(debug):aa75c8d NOTICE: BL3-1: Built : 06:32:43, Jun 13 2017 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9 U-Boot 2017.01-rc1-g5df570f-dirty (Jun 13 2017 - 06:32:54 +0200) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: OrangePi PC 2 DRAM: 1 GiB MMC: SUNXI SD/MMC: 0 *** Warning - bad CRC, using default environment Setting up a 720x576i composite-pal console (overscan 32x20) Error: no valid bmp image at 66000000 In: serial Out: vga Err: vga Net: phy interface7 eth0: ethernet@1c30000 Hit any key to stop autoboot: 0 38518 bytes read in 116 ms (324.2 KiB/s) switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3362 bytes read in 132 ms (24.4 KiB/s) ## Executing script at 4fc00000 U-boot loaded from SD Boot script loaded from mmc 116 bytes read in 93 ms (1000 Bytes/s) 19253 bytes read in 533 ms (35.2 KiB/s) 4179 bytes read in 647 ms (5.9 KiB/s) Applying kernel provided DT fixup script (sun50i-h5-fixup.scr) ## Executing script at 44000000 4729916 bytes read in 587 ms (7.7 MiB/s) 11407368 bytes read in 843 ms (12.9 MiB/s) ## Loading init Ramdisk from Legacy Image at 4fe00000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 4729852 Bytes = 4.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4fa00000 Booting using the fdt blob at 0x4fa00000 reserving fdt memory region: addr=4fa00000 size=6b000 Loading Ramdisk to 49b7d000, end 49fffbfc ... OK Loading Device Tree to 0000000049b0f000, end 0000000049b7cfff ... OK Cannot setup simplefb: node not found Starting kernel ... Loading, please wait... starting version 229 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done. Begin: Running /scripts/local-block ... done.

Hi I have built and image, attaching the first 2Mb of OrangePi PC2 image to the Orange Pi PC image after having removed the first 1Mb (yes the partition start address is different) and I have replaced /boot, /lib/modules, /lib/firmware and /usr/include/linux with the content of OrangePi PC 2 image. I will try it this evening. One question: the libc binaries are coming from upstream or cross compiled? Bye

Same problem here, happened with some kernel upgrade on the 4.11.y branch, on Allwinner H5 The dhcpclient just don't get any IPv6 address. It was working few weeks ago, but unfortunately I cannot say when it stopped to work, since I didn't care of IPv6 at all the update I did