jobenvil

Really appreciated that you always share your observations.

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

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

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.

I found something weird: - 1. You are not using all cores: ### lscpu: Architecture: armv7l Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-3 Off-line CPU(s) list: 4-7 X! Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 X! Model name: ARMv7 Processor rev 3 (v7l) mine: root@hiperborea /etc/init.d # lscpu Architecture: armv7l Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 2 Model name: ARMv7 Processor rev 3 (v7l) CPU max MHz: 1300,0000 CPU min MHz: 200,0000 - 2. Compare your dmesg with mine:

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

Normal and don't worry, mi english is "broken" :-) 1) Yes, there is a mess with device drivers. You should use UUID to uniq identification of devices. So you are save if boot search for mmc0 or mmc1 2) Yes, only "next" was added = minor change 3.1) No, I tried to compile and build an image with ARMBIAN tools changing the "next" (see point 2). This compiled well, but the produced image doesn't boot because the boot.ini and fstab needs changes. After properly modifications, the u-boot is loading. 3.2) Yes, I prefer to compile directly on XU4. This takes less than 20 minutes. You get zImage, xu4-dtb and modules. Follow the guide from Uli Middelberg.

yes, this was working like it is mentioned. You should care about the /etc/fstab, wait... root@hiperborea /media/boot # cat /etc/fstab # <file system> < mount point> <type> <options> <dump> <pass> #/dev/mmcblk0p2 / ext4 noatime,barrier=0,commit=5,errors=remount-ro 0 1 UUID=e139ce78-9841-40fe-8823-96a304a09859 / ext4 defaults,noatime,nodiratime 0 1 UUID=1E66-94B1 /media/boot vfat defaults 0 0 #/dev/sda1 /media/sda ext4 defaults,noatime,nodiratime,data=writeback,commit=600,errors=remount-ro 0 2 # Seagate 500GB 7200RPM ST9500325AS #/dev/sda1 /media/sda ext4 noatime,barrier=0,errors=remount-ro 0 2 LABEL="data-7200" /media/sda ext4 defaults,noatime,nodiratime 0 2 # deleted barrier=0, para error tan largo en disco duro # Seagate 500GB 5400RPM #/dev/sdb1 /media/sdb ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 2 tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=512M 0 0 #tmpfs /var/tmp tmpfs defaults explanation: Verzeichnis /var/tmp sollte generell nicht auf diese Weise ausgelagert werden LABEL="swap-7200" none swap sw 0 0 /media/sda/album /var/www/Album none bind 0 0 UUID are mandatory

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

@wildcat_paris Answering your questions: 1) No, I have the original one based on HardKernel Ubuntu distro which is 2012.07 2) No idea what this is. Do you mean the tsz.bin /bl1/bl2? For what is this good or necessary? 3) Yes, /dev/mmcblk0p1 is starting at 4096. I didn't see any new mention on ODROID Forum regarding newer U-Boot to use with mainline kernel. I tested 4.6.X, 4.7.rc-2, rc-3. I build directly on XU4. It's quicker.

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

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

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

@wildcats_paris are you aware of this? http://forum.odroid.com/viewtopic.php?f=95&t=18034&start=150

Axel, ich bin Dir sehr dankbar! This did the trick. SATA is recogniced again and the patch considered the LEDs using Armbian_5.07 and Bananapro 4.5.2. Du solltest über die patches Igor benachrichtigen. Now I have wlan! (which I didn't use, but anyhow...) Thank you very much again!. BTW, I have short questions that you maybe could answer: - Do you have zram in use? if yes, how much and prio/swapiness? - Do you have tweaked rc.local? Possible to share? - Do you have tweaked sysctl.con? (maybe paste and bin?) Schöne Grüße Solution: Use the offered userpatches from Axel in earlier post to get recogniced SATA in Banana Pro; compile with them.

Thanks Igor. Do you mean to insert the mentioned ldo4 patch inside /userpatches/u-boot/u-boot-next/ and compile again? I have done this right now, but SATA is still not recogniced. Some other patch or idea? (I didn't cleaned last compilation, but I think it's OK)

I runned once again in same isssue. After compiling last image for bananapro and copying these to the sd card, the sata device not appears anymore. I changed the bananapro with the bananapi dtb file, but this doesn't help. root@bananapipro:~# dpkg -l | grep next ii linux-dtb-next-sunxi 5.07 armhf Linux DTB, version 4.5.1-sunxi ii linux-firmware-image-next-sunxi 5.07 armhf Linux kernel firmware, version 4.5.1-sunxi ii linux-headers-next-sunxi 5.07 armhf Linux kernel headers for 4.5.1-sunxi on armhf ii linux-image-next-sunxi 5.07 armhf Linux kernel, version 4.5.1-sunxi ii linux-jessie-root-next-bananapipro 5.07 armhf Root file system tweaks for bananapipro ii linux-u-boot-bananapipro-next 5.07 armhf Uboot loader 2016.01 root@bananapipro:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 14.9G 0 disk └─mmcblk0p1 179:1 0 14.9G 0 part / root@bananapipro:~# dmesg | grep ata [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] Memory: 1007252K/1046952K available (9236K kernel code, 664K rwdata, 2164K rodata, 636K init, 308K bss, 23316K reserved, 16384K cma-reserved, 244136K highmem) .data : 0xc0bca000 - 0xc0c702a4 ( 665 kB) [ 3.258555] libata version 3.00 loaded. [ 3.591733] ahci-sunxi 1c18000.sata: PHY power up failed. [ 3.591812] ahci-sunxi: probe of 1c18000.sata failed with error -5 [ 4.025162] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null) [ 4.952900] systemd[1]: Starting Increase datagram queue length... [ 5.064922] systemd[1]: Started Increase datagram queue length. [ 6.644417] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro Do you know what to do? Ideas? Thanks

Yes, this was what I mean in the earlier post. Thanks for the info because I thought that it was my build environment.

I think this could be succesfully catalogued like as solved. Summary: Errors(1) on SD-Card which lies to read-only filesystem on first boot and as a result new user an not be created. (1) Errors due to faulty compilation image.