jobenvil

LOL, today I did some testing with NanoPi NEO, kernel 4.7.2 and the new schedutil cpufreq scheduler. I let the following run to check thermal readouts after allowing 1200 MHz max cpufreq:
sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo) To my surprise the result was just 117.5 seconds -- that's 'better' than RPi 3 with same settings and with Orange Pi PC while being clocked higher (1.3 GHz vs. 1.2 GHz) I got the following a few days ago: 'sysbench takes 142 seconds, H3 constantly running at 1296 MHz, SoC temperature reached 74°C but no throttling happening'
 
Wow!!! An increase in performance of ~30 percent just by using a new kernel! With a benchmark that should not be affected by the kernel version at all?! That's magic.
  So I immediately tried out our 3.4.112 Xenial image. Same thermal readouts, same result: 117.5 seconds! What did happen?   I tried out Xenial 16.04 LTS with both 4.7.2 and 3.4.112 kernel. And before I always used Debian Jessie. Ok, downloaded our Jessie image for NanoPi NEO, executed the same sysbench call and got 153.5 seconds (which is the correct value given that no throttling occured, max cpufreq was at 1200 MHz and OPi PC clocked at 1296 MHz finishes in 142 seconds!)   What can we learn from this? Sysbench is used nearly everywhere to 'get an idea about CPU performance' while it is horrible crap to compare different systems! You always have to ensure that you're using the very same sysbench binary. At least it has to be built with the exact same compiler settings and version! We get a whopping 30 percent performance increase just since the Ubuntu folks use other compiler switches/version compared to the Debian folks:   This is 2 times 'sysbench 0.4.12'   Ubuntu Xenial Xerus: root@nanopineo:~# file /usr/bin/sysbench /usr/bin/sysbench: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=2df715a7bcb84cb03205fa3a5bc8474c6be1eac2, stripped root@nanopineo:~# lsb_release -c Codename: xenial root@nanopineo:~# sysbench --version sysbench 0.4.12 Debian Jessie:
root@nanopineo:~# file /usr/bin/sysbench /usr/bin/sysbench: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, BuildID[sha1]=664005ab6bf45166f9882338db01b59750af0447, stripped root@nanopineo:~# lsb_release -c Codename: jessie root@nanopineo:~# sysbench --version sysbench 0.4.12 Just the same effect when comparing sysbench numbers on RPi 2 or 3 when running Raspbian or Ubuntu Mate -- see post #12 above (but there the difference is only 15 percent so it seems either the Raspbian people aren't using that conservative compiler switches compared to Jessie or Ubuntu Mate for Raspberries does not optimize that much as our 16.04 packages from Ubuntu repositories)
 
TL;DR: Never trust any sysbench numbers you find on the net if you don't know which compiler settings and version have been used. Sysbench is crap to compare different systems. You can use sysbench's cpu test only for a very limited set of tests: Creating identical CPU utilization situations (to compare throttling settings as I did before in this thread), running tests to estimate multi-threaded results when adding/removing CPU cores or test CPU performance without tampering results by memory bandwidth (sysbench is that primitive that all code runs inside the CPU caches!)
 
Everything else always requires to use the exact same sysbench binary on different systems to be able to compare. So no-cross platform comparisons possible, no comparisons between systems running different OS images, no comparisons between different CPU architectures possible. Using sysbench as a general purpose CPU benchmark is always just fooling yourself!

@goldfish_paris I posted some performance results on GitHub. It looks like that since kernel 4.8 the XU4 is very stable and USB3 works fine (but let's say not with all SATA-USB3 adapters)
 
I got new u-boot from here as well:
 
upgrade firmware  ================ https://github.com/c0d3z3r0/xu4-update An easier way to update the firmware of your Odroid-XU4. root@bananapi:/# lsblk NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT sda           8:0    1  7.4G  0 disk +-sda1        8:1    1  100M  0 part /media/boot +-sda2        8:2    1  7.3G  0 part /media/root mmcblk0     179:0    0  7.4G  0 disk +-mmcblk0p1 179:1    0  7.3G  0 part / root@bananapi:/# vi /usr/bin/xu4-update root@bananapi:/# ROOT_PATH=/media/root BOOT_PATH=/media/boot SD_DEV=/dev/sda xu4-update  *** Odroid-XU4 firmware updater by c0d3z3r0  *** based on rpi-update by Hexxeh, enhanced by AndrewS and Dom  *** Performing self-update  *** Relaunching after update  *** Odroid-XU4 firmware updater by c0d3z3r0  *** based on rpi-update by Hexxeh, enhanced by AndrewS and Dom  *** We're running for the first time  *** Backing up files (this will take a few minutes)  *** Backing up firmware  *** Backing up modules 4.6.3-sunxi  *** Downloading specific firmware revision (this will take a few minutes)   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                  Dload  Upload   Total   Spent    Left  Speed 100   168    0   168    0     0    118      0 --:--:--  0:00:01 --:--:--   118 100 25.8M    0 25.8M    0     0  1515k      0 --:--:--  0:00:17 --:--:-- 2154k  *** Updating firmware  *** Updating kernel modules  *** depmod 4.7.2+  *** Writing new bootloader to sd card 30+0 records in 30+0 records out 15360 bytes (15 kB, 15 KiB) copied, 0.00736964 s, 2.1 MB/s 28+1 records in 28+1 records out 14592 bytes (15 kB, 14 KiB) copied, 0.0105246 s, 1.4 MB/s 1070+1 records in 1070+1 records out 548191 bytes (548 kB, 535 KiB) copied, 0.207144 s, 2.6 MB/s 512+0 records in 512+0 records out 262144 bytes (262 kB, 256 KiB) copied, 0.272539 s, 962 kB/s  *** Running ldconfig  *** Storing current firmware revision  *** Deleting downloaded files  *** Syncing changes to disk  *** If no errors appeared, your firmware was successfully updated to 8bdbdebd6f60a1212e3d7b78835e9775f89bbc6d The foillowing example shows how to upgrade offline. I took my banana pi to upgrade the kernel offline, which it means that you insert your uSD-Card in the USB-Adapter on the Banana Pi and execute the upon described procedure. With this easy step we achieved a new kernel but the more important, the new U-Boot 2016.05-dirty
 
Take care because after that we have the boot.scr boot script 

@goldfish_paris I posted some performance results on GitHub. It looks like that since kernel 4.8 the XU4 is very stable and USB3 works fine (but let's say not with all SATA-USB3 adapters)
 
I got new u-boot from here as well:
 
upgrade firmware  ================ https://github.com/c0d3z3r0/xu4-update An easier way to update the firmware of your Odroid-XU4. root@bananapi:/# lsblk NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT sda           8:0    1  7.4G  0 disk +-sda1        8:1    1  100M  0 part /media/boot +-sda2        8:2    1  7.3G  0 part /media/root mmcblk0     179:0    0  7.4G  0 disk +-mmcblk0p1 179:1    0  7.3G  0 part / root@bananapi:/# vi /usr/bin/xu4-update root@bananapi:/# ROOT_PATH=/media/root BOOT_PATH=/media/boot SD_DEV=/dev/sda xu4-update  *** Odroid-XU4 firmware updater by c0d3z3r0  *** based on rpi-update by Hexxeh, enhanced by AndrewS and Dom  *** Performing self-update  *** Relaunching after update  *** Odroid-XU4 firmware updater by c0d3z3r0  *** based on rpi-update by Hexxeh, enhanced by AndrewS and Dom  *** We're running for the first time  *** Backing up files (this will take a few minutes)  *** Backing up firmware  *** Backing up modules 4.6.3-sunxi  *** Downloading specific firmware revision (this will take a few minutes)   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                  Dload  Upload   Total   Spent    Left  Speed 100   168    0   168    0     0    118      0 --:--:--  0:00:01 --:--:--   118 100 25.8M    0 25.8M    0     0  1515k      0 --:--:--  0:00:17 --:--:-- 2154k  *** Updating firmware  *** Updating kernel modules  *** depmod 4.7.2+  *** Writing new bootloader to sd card 30+0 records in 30+0 records out 15360 bytes (15 kB, 15 KiB) copied, 0.00736964 s, 2.1 MB/s 28+1 records in 28+1 records out 14592 bytes (15 kB, 14 KiB) copied, 0.0105246 s, 1.4 MB/s 1070+1 records in 1070+1 records out 548191 bytes (548 kB, 535 KiB) copied, 0.207144 s, 2.6 MB/s 512+0 records in 512+0 records out 262144 bytes (262 kB, 256 KiB) copied, 0.272539 s, 962 kB/s  *** Running ldconfig  *** Storing current firmware revision  *** Deleting downloaded files  *** Syncing changes to disk  *** If no errors appeared, your firmware was successfully updated to 8bdbdebd6f60a1212e3d7b78835e9775f89bbc6d The foillowing example shows how to upgrade offline. I took my banana pi to upgrade the kernel offline, which it means that you insert your uSD-Card in the USB-Adapter on the Banana Pi and execute the upon described procedure. With this easy step we achieved a new kernel but the more important, the new U-Boot 2016.05-dirty
 
Take care because after that we have the boot.scr boot script 

tobetter created a image based on 4.6.3. His Image will become auto upgradable since he created a odroidxu4 ppa repository. You can "watch" him on GitHub to get last comments, pull requests, etc.
I installed it yesterday (only the kernel, not image) and made some iozone tests (based on tkaiser uas wiki) to check performance. Not so good like 4.7-rc4, but not interesting to be published since I have old SATA II Hardware. I bought a Samsung EVO 850 500GB and will check again the tests. This time we could consider the results based on top components.

wow, you don't sleep 8-)
There is another patch for enable higher frequencies (A7@1,4GHz and A15@2,00GHz). Actually it is limited (in my case) to 1,3GHz and 1,8GHz.
Did you take the tobetter@4.6 branch? 

@wildcat_paris we were discussing some issues here, you may check it. The topic is: unable to boot new odroidxu4-v4.6 (but mine v.4.7-rc4 is up und running ;-)

I was playing around (Kernel 4.7-rc4) with menuconfig and comparing with older kernels where HDMI still worked. In mainline and next releases is not working my monitor, which is not HDMI native. I will receive in the next days a UART adapter and check where it hangs. Actually I use Kernel 4.7. which works somehow better with USB3.

post your .config in pastebin and I will git diff. Theoretically It should not differ to much. I don't remember well which branch/repo I took. My fan runs and runs... and no way to stop it. searching for solution.
Sorry for the spoiler. I will do this next time.

There are more changes than I expected. Here.
My OdroidXU4 .config

network is back
gr@odroidxu4:~$ dmesg  | grep 8152 [    0.754425] usbcore: registered new interface driver r8152 [    2.164556] r8152 5-1:1.0 eth0: v1.08.3 [    2.200154] r8152 5-1:1.0 enx001e06301503: renamed from eth0 I had to change /etc/network/interfaces
gr@odroidxu4:~$ cat /etc/network/interfaces auto enx001e06301503 iface enx001e06301503 inet dhcp # Wired adapter #1 ##allow-hotplug eth0 ##iface eth0 inet dhcp # Local loopback auto lo iface lo inet loopback the issue with the interface naming enx001e06301503, jessie deals with enx001e06301503, Armbian Xenial doesn't
 
so it is working!

awesome!. I was trying to put statical IP, changing DNS, etc. Something with the interfaces.d/ init scripts should be the problem, but no idea, time and will.

sorry to comment this so late. I can confirm I tried already last week this: xenial + odroidxu4 = not booting properly.  DHCP / Eth0 issue. I think this bug was fixed with jessie, not Xenial. I gave up trying to fix eth0.

next, next, next here
this is very promissing

@Igor
 
stuck at first boot... no way to login as root (as usual )with USB-UART and I don't see DHCP request (so no network). let's try keyboard and screen
 
 
 

I am trying to configure "next" with linux-vanilla (4.6.2) and built an Armbian image then booted from SDcard (removing my eMMC)
 
So far, Samsung OSG provided examples of vanilla kernel
@jobenvil tested 4.6 kernel but compiled on board WITH partition using UUID instead of /dev/mmc
 
I got 4 cores in the "basic" model (4 little => 4 BIG), network, HDD
 
issue: mixing uboot 2012.07 and vanilla kernel
 
it seems /dev/mmcblk0 doesn't exist for uboot 2012 only boot.ini works with root=/dev/mmcblk1p2
 
to quick fix the problem I put /dev/mmcblk1p2 for root partition in boot.ini
 
* I know how to manipulate UUID and partition
 
=> is it possible to put specific UUID on partitions before writing the image with Armbian
 
 
 
 

Actually, mi boot.ini looks like:
 
 
and /media/boot
 
 

@jobenvil
 
I haven't looked at "lib" code, only build an image for XU4
 
u-boot is 2012.07
the tsz/bl1/bl2 should be burned
 
maybe an update of boot.ini is need
 
the current Armbian boot.ini (kernel 3.x)
 
maybe an update has to be done to reference
dtb/exynos5422-odroidxu4.dtb and not dtb/exynos5422-odroidxu3.dtb
and making sure zImage is used
 
 
 
 

@wildcat_paris Thanks for your update. I'm reading very interesting your link and motivated @Shuah for share her progress with the XU4  community.
 
Update 13. Juni: I built the Kernel 4.7.0-rc2-next following the guides from @ummidelb  and @shuah
 
The main problem that I had is that the SD Card device numbering for mmcblk0 changed to mmcblk1 (probably NAND device is now mmclbk0?) and therefore it was necessary to use UUID in u-boot environment variables and in /etc/fstab. Moreover I had a Hardkernel Ubuntu Image wich had 3.10.84 updated by hardkernel scripts until 3.10.96 with Xenial. After that I put on the top the ARMBIAN Kernel 3.10.110. The u-boot environment variable had to be changed to the original one from Hardkernel:
setenv bootrootfs "console=tty1 console=ttySAC2,115200n8 root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro fsck.repair=yes" ... ... setenv bootcmd "fatload mmc 0:1 0x40008000 zImage_next; fatload mmc 0:1 0x42000000 uInitrd-4.7.0-rc2-next-20160609; fatload mmc 0:1 0x44000000 exynos5422-odroidxu4_next.dtb; bootz 0x40008000 0x42000000 0x44000000" But because the HDMI is broken and no serial UART available atm (german reseller has no more and I didn't want to order once again from Korea..) it was difficult to debug when it was not booting.
 
I enabled USB_CONFIG_UAS=y, but didn't work out the box. Probably patches are necessary, like other to fix the CPUs order, the ethernet which is attached to the USB2.0 instead of 5Gbps, etc.

@wildcat_paris Trying to compile next branch (4.2.X) with Armbian tools, I want to send this pull but I realized that even the compilation doesn't break, it doesn't work the created image out of the box and unfortunately, minor tunnings in boot.ini, etc/fstab are necessary to boot the image.

@jobenvil
 
ok, good to know,
 
another more complete recipee from SamsungOSG
https://blogs.s-osg.org/install-ubuntu-run-mainline-kernel-odroid-xu4/
 
I will backup my eMMC and give it a try

right, he uses bzImage instead zImage and he doesn't use initramfs. let's see...
 
update 4.Juni 2006: Didn't work like described by @Luisbg. If you try by yourself, try in .config with UAS activated.
CONFIG_USB_UAS=y

On my Banana Pro SATA works fine with the help of some userpatches. Take a look at the end of the thread http://forum.armbian.com/index.php/topic/836-bananapro-wifi-armbian-5-kernel-tracebacks/. I have attached my userpatches there.
 
Banana Pro uses a different DTS file, which is not as well maintained as those for  the Banana Pi. Therefore, I have made a patch for sun7i-a20-bananapro.dts which this updated and solves some problems with the power supply.
 
Viele Gruesse
Axel

Problem solved for wireless network setup with wicd. It works on my build  of Armbian_5.07_Bananapipro_Ubuntu_trusty_4.5.1_desktop with the current sources from the repository. By coincidence I have in the wicd settings "Preferences --> Advanced Settings" marked at "Wireless Interface" the checkbox "Use 0dBm to measure signal strengh". What a surprise, WLAN no longer breaks after 8 seconds.
 
Also for Armbian_5.07_Bananapipro_Debian_jessie_4.5.1 I have WLAN. I had only create "/etc/network/interfaces" with the usual Wi-Fi settings.
 
For the BananaPiPro I brought also SATA to run with some userpatches. See atached zip-file.
 
Viele Gruesse
Axel
build.next.zip

IIRC this was introduced when we changed the build process of the desktop image. We should either fix that or set /tmp back to 777 automatically when finished.
 
 
Yes, we also tried to introduce 'crash detection' with the next release (enable verbose messages automatically after a crash but unfortubately I messed it up )
 
But in your case you had troubles with loop devices on your build host that are currently ignored by our build system and let then to an image with fs errors.

About the build process, I've noticed that /tmp folder of my workstation is always becoming RO for other groups/users, so after "sudo ./compile.sh" finished, I always need to do a "sudo chmod a+rw /tmp"