Christos

Also got a OPiPC+, so far everything works ok here. Did you notice the "MMC: no card present"? There might be an issue in the SD card used, or in the SD receptor itself (broken pins?) You could have an inspection in the SD receptor hardware for any damage or contacts issue and of course try to use a very good SD..

nand-sata-install -> https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-nand-sata-usb

Obviously Orange/Xunlong failed hard here in design -> http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread&tid=2227 hopefully in their next versions of the boards (H2+, H5) they will rectify that.

Try to use the utility named 'h3disp', it sets the display resolution, running it without arguments it will show you the available options, then you choose what to set as resolution with its command line parameter. This will be a permanent setting and needs a reboot to be applied.

Well Thomas, that 'structure' as you mention sounds pretty vague. Is there any other H5 image, from you or longsleep or anyone from the community that can be used from us as it is right now?

From what I understand, @tkaiser the issue in Buddy's repo is with BSP blobs, right? In longsleep's repo, there are also blobs used. Is there any other blob than initrd.img in buddy's repo to be released, in order to match the level of open sources released in longsleep's repo? Is there anything else than initrd.img that needs to be released?

Well, the interesting part is that the guy there actually reads comments and issues. The more interesting part is that he also tries to respond.. Seen way different behavior from others and in many eastern companies so at least that, this time, is interesting. So, now you understand why I say interesting

Interesting, looks like H5 u-boot source & build is released -> https://github.com/OrangePiLibra/OrangePi_H5SDK/commit/d9fcbd33ef61143bbc2e27cc9480686489905d00

When I did the patch for H3 I2S from tina, I patched only the daudio0 driver, iirc daudio2 is hdmi but didnt patched that, did just a daudio0 patching in sun8i sources and it worked ok.

At least his repos are forked from Xunlong in their own repository.

Just seen a few new commits (a bit interesting) in Buddy's repository -> https://github.com/OrangePiLibra/OrangePi_H5SDK/commit/fa3a871e03640dae3ee13d45194e762749c460aa Gonna check them this evening, hopefully they are some response to -> https://github.com/OrangePiLibra/OrangePi_H5SDK/issues/7 Interestingly enough, seen a more than welcome comment from @tkaiser there "To be honest: I don't plan to run this BSP stuff ever again on a H5 device since for my use cases mainline u-boot/kernel will be sufficient pretty soon."

@jernej Thanks for the hints. Lost a few more hours ..again. The booting process loads the .dtb (as it says) Examined the environment with printenv, looks fine, tried running myself manually all uboot macro commands, fine too. Tried manually via uboot using another new .dtb and it did load it (again as it says) yet nothing changes in the booted system. Tried to delete the .dtb and during boot system reported that it cannot find the dtb, it obviously fall back to a known dtb and booted ok with devices as always. It looks that uboot is loading the /boot/orangepi/*.dtb but for some reason kernel or whoever should do it later on does not execute it. Before I start to sound like tkaiser raging myself too, I'll throw the board back in the drawer, a bit deeper this time.. Thanks anyway. update dtb dram start update dtb dram end serial is: 44005035c1202c2f038c [ 2.666]inter uboot shell Hit any key to stop autoboot: 0 Loading orangepi uEnv.txt from 40000000 ... reading uEnv.txt [mmc]: blkcnt should not be 0 140 bytes read in 5 ms (27.3 KiB/s) Loading boot environment ... Loading orangepi bootscript ... reading boot.scr ** Unable to read file boot.scr ** Booting with defaults ... Loading orangepi orangepi/OrangePiH5orangepi.dtb from 44000000 ... reading orangepi/OrangePiH5orangepi.dtb 73320 bytes read in 8 ms (8.7 MiB/s) Loading orangepi orangepi/uImage from 4007ffc0 ... reading orangepi/uImage 12200584 bytes read in 523 ms (22.2 MiB/s) reading initrd.img 1090786 bytes read in 49 ms (21.2 MiB/s) Loading orangepi initrd.img from 44300000 ... bootm kernel:4007ffc0 initrd:44300000 ... bootm initd_size:10a4e2 fdt_addr:44000000 ... ## Booting kernel from Legacy Image at 4007ffc0 ... Image Name: OrangePiH5 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 12200520 Bytes = 11.6 MiB Load Address: 40080000 Entry Point: 40080000 Verifying Checksum ... OK XIP Kernel Image ... OK reserving fdt memory region: addr=40020000 size=800 reserving fdt memory region: addr=48000000 size=1000000 reserving fdt memory region: addr=48100000 size=4000 reserving fdt memory region: addr=48104000 size=1000 reserving fdt memory region: addr=48105000 size=1000 Loading Ramdisk to 76d85000, end 76e8f4e2 ... OK Using Device Tree in place at 44000000, end 44015dbf Starting kernel ...

@zador.blood.stained Well, that is the same text output as when we do dtc on current /boot/orangepi/OrangePiH5orangepi.dtb to get its dts. To be honest, tried to see how I can put back a modified dtb by reading this -> https://github.com/longsleep/build-pine64-image/blob/master/u-boot-postprocess/u-boot-postprocess.sh but couldnt make it happen, I'm not that experienced with plain binary file modifications..

Indeed. As it is right now, based on today's functionality, in the current kernel of the given SDK, it became evident to me quite early (at least for the purposes of my project) that it can be of no use, thus it found a place in the drawer. And I couldnt agree more that many of the pending stuff are responsibility of the vendor to have them ready together with the board offering.

Well, I have given up on this board for some days now. (It got in the drawer after two days of heavy trouble and frustration..) Yet, if I understand it correctly, for some reason the OrangePiH5orangepi.dtb in /boot/orangepi folder is not being used at all? its there just for ..cosmetic reasons? instead the device tree is initialized only from the dtb copy that is included in uboot bin generation, right? If that is so, then ..wow, things are really messed up.

Arm64 firefox package is broken, you could try this though -> https://forum.armbian.com/index.php/topic/2793-odroid-c2-31479-kernel-videomode-screwed-up/?p=19397

Nope, tested it by changing only this parameter and didnt do anything different.. Have to wait on this for the real gurus (I'm not.. lol)

So you mean to use dtc to generate the text dts, then change that parameter, use dtc again to build the modified dtb, put it in its place, reboot and it will work?

Get another OPi..

Using the same mode here, with OPi, but with latest self build image, Armbian 5.24 Jessie 3.4.113 desktop, it works just fine. Can you build an image with these instructions? -> https://github.com/igorpecovnik/lib

Today received my PC2, eager to see now Armbian on it. (first sysbench impression with Xunlong image is good!!) @Igor , @tkaiser , any news on this?

Just today, received my OPi PC2. Unpacked and used the "OrangePiPC2_Debian_Desktop_jessie_xfce4.img" provided by Xunlong. No networks was setup there so modified the net config files to get net access and after loading of sysbench, got this.. root@Orangepi:~# root@Orangepi:~# root@Orangepi:~# uname -a Linux Orangepi 3.10.65 #3 SMP PREEMPT Tue Nov 15 09:46:50 CST 2016 aarch64 GNU/Linux root@Orangepi:~# root@Orangepi:~# root@Orangepi:~# sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run sysbench 0.4.12: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 4 Doing CPU performance benchmark Threads started! Done. Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 9.0978s total number of events: 10000 total time taken by event execution: 36.3762 per-request statistics: min: 3.63ms avg: 3.64ms max: 5.87ms approx. 95 percentile: 3.65ms Threads fairness: events (avg/stddev): 2500.0000/2.35 execution time (avg/stddev): 9.0940/0.00 root@Orangepi:~# @tkaiser , guys , should I believe it? The relevant tests with other H3 boards are not even close.. I cannot justify the abyssmal difference, according to ARM, Cortex-A7 has 1.9 DMips/MHz/Core and A53 has 2.3 DMips/MHz/Core so what is going on here? Can anyone explain?

Hopefully now that the actual informative H5 manual arrived, things could get some speed.. -> https://github.com/OrangePiLibra/OrangePi_H5SDK/commit/a77742c665e508b9126a7e783a3f2de4feb92a28

FYI, I build image with -> https://github.com/igorpecovnik/lib for my PCPlus. Thus having Armbian 5.24, legacy jesse 3.4.113 with desktop and it works flawlessly, nand-sata-install takes quite some time but finishes successfully dont know if you're willing to build from source though..

lol .. I was deliberately monitoring the perfomance of my DSP application and looking at an about 75 degrees temp before, now with a newly build kernel got about 67.. and its not from the Thumb2.. ok, whatever it is, is welcome though