Armbian for OrangePi PC2, AllWinner H5

[zador.blood.stained]

Extracted and converted to .dts:

extracted.dts.txt

 

Please don't ask how to modify it and put back to u-boot.bin

[tkaiser]

As for DVFS; is this a script issue or is the driver in the kernel actually not working ? Looking at the dtb file, it seems that frequency points are set, but they all have the same voltage.

 

Same with the images for OPi Zero from Xunlong's download locations. I really don't know why these settings are as they are but they're also clearly wrong. Since I have no H5 device anymore (sent it to jemk who looks into mainline u-boot and video engine support) I can't test and I really really really hoped that some of those guys waiting so eagerly for improved H5 support start to do some work on their own.

 

Anyway: https://github.com/OrangePiLibra/OrangePi_H5SDK/issues/6

[zador.blood.stained]

So unless someone fixes allwinner kernel, stuff like mali will never work for mainline kernel. Is this correct or is there a way to get mali working under mainline as well ?

I'm sure most of you guys hate it (tkaiser sure does ) but it's pretty useful for emulation stuff. Given how mali450 is like 3 times better in h5, this would help a lot.

Mali hype again 

 

As I said somewhere in another topic, once we have fully operational DRM display driver in mainline kernel for this particular board, Mali platform configuration (clocks and interrupts, info available in user manual should be enough) and assuming that xf86-video-armsoc driver will work fine in this setup, it should be possible to run Mali on mainline kernel.

 

And again, this may give you hardware assisted rendering in Chromium or Firefox, but it's not related in any way to hardware accelerated video decoding.

[tkaiser]

I'm sure most of you guys hate it (tkaiser sure does ) but it's pretty useful for emulation stuff.

 

I know, retro gaming in 64 bit. I don't care about that stuff and most probably that applies to the other Armbian distro people as well and the vast majority of linux-sunxi devs too.

 

But some are clearly interested and already started to investigate how to combine Mali kernel drivers with useable binary blobs. Simply continue to ask every day here and there how far things evolved to ensure everyone who is able and willing to do the work gets so much annoyed that he stops working on this. It's really important to constantly push others doing some work in their spare time so it's not fun for them any more but they understand that they're doing unpaid work for others! That's the key to success. Push harder!

[Christos]

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.

[tkaiser]

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?

 

Well, it seems the guy doing the software stuff for Xunlong did some things correctly: He copied everything from longsleep's simpleimage stuff for Pine64 where applicable. But until he doesn't get rid off the smelly BSP stuff things might not work as expected. IIRC it has been already mentioned several times: Without someone wasting time on cleaning the mess up nothing will change.

 

I already invited the Xunlong guy to become part of linux-sunxi community (something a bit hard given the amount of rude comments regarding vendor software offerings) and I really hope he joins. Since then it's maybe just a little dialogue between him and longsleep and the other guys to fix things.

 

Regarding DVFS: I was a bit stupid before since I forgot which voltage regulator is used on OPI PC 2 (the good one known from larger Oranges accessible through I2C). Might be not a settings but more likely a driver issue so that voltage regulation currently doesn't work at all and the board boots with the cpufreq that is specified for u-boot (again 1008 MHz) which might be sane given that 1.1V are specified through resistors (at least that's the situation with H3 boards currently -- they come up with 1.1V if not configured otherwise)

 

Why should anyone here waste his own time to debug issues the vendor has to solve and is able to solve (contact with Allwinner)? BSP stinks so unless you must use it you don't use it. Period. And all this stuff is totally unrelated to Armbian. We surely won't provide any alpha or beta based on that. Those issues have to be resolved first. But that has been said not just once before.

 

Apart from that you're free to combine any Armbian arm64 rootfs with the Xunlong OS image skeletons (BTDT): feels slightly less crappy afterwards but has nothing to do with Armbian since our goal is to create images from scratch... that don't suck.

 

You already mentioned your drawer: That's the perfect place for any H5 board currently if you're not a u-boot or kernel dev. Check situation in 2017 again (not kidding).

[Christos]

..

You already mentioned your drawer: That's the perfect place for any H5 board currently if you're not a u-boot or kernel dev. Check situation in 2017 again (not kidding).

 

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.

[Christos]

Extracted and converted to .dts:

extracted.dts.txt

 

Please don't ask how to modify it and put back to u-boot.bin

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

[jernej]

@Christos,

you can easily check if /boot device tree files are taken into account. Change board name and read it back through sysfs after reboot. If this doesn't work, you can always try to overload dts loaded by U-Boot by stopping autoboot and manually load kernel and device tree.

[Christos]

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

[Horrorzilla]

Thanks for all the great work. Just got my Orange Pi PC 2 running and I am impressed so far. I just donated (only $15 US) what I could to show my appreciation for your hard work. I own  Raspberry Pi's, Odroids, a Cubieboard A20, and awaiting an Orange Pi Plus 2E.

[mdel]

posted some openssl benchmark for the H5 (opi pc2) on my crypto vpn stuff thread.

[Christos]

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

[hojnikb]

Is buddy the one providing images for xunlong ?

[Christos]

Is buddy the one providing images for xunlong ?

 

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

[Da Alchemist]

I am just taking a look the xenial Desktop image provided from "buddy" and i must admit i expectet less. What´s not working is setting the Display resolution , but running from a Samsung EVO, this System is  very responsive.

Using Firefox I am browsing the net by now and writing this Lines.

As some of you know i am interested in Audio Things and I found that i get real 8 Channels of output via HDMI right out of the Box. (Not the downmixed Output like on the H3´s, perhaps some of the Gurus can take a look at the Drivers because the H3 is not that far away) This is interesting for Things like Openelec.

 

Regards

[jernej]

I will update audio drivers from tinaos, which improves I2S (reported in another thread). Based on the fact that HDMI also uses I2S internally, I hope this will improve situation. From what I know, tinaos and H5 BSP codebases are not very far apart.

[Christos]

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.

[Da Alchemist]

What I found on the PC2 is, that it is capable of playing back 8 Channels with 96kHz@S32_LE, but when i turn to higher rates like 192kHz, Sound is "downmixed" to 2 Channels like o the H3. (S24_LE does not work at all)

[Christos]

Interesting, looks like H5 u-boot source & build is released

 

-> https://github.com/OrangePiLibra/OrangePi_H5SDK/commit/d9fcbd33ef61143bbc2e27cc9480686489905d00

[tkaiser]

Interesting

Really? What's different compared to h5 directory here: http://filez.zoobab.com/allwinner/

 

Until now the whole H5 story is a great lesson how stupid it is to ignore linux-sunxi community. But maybe reinventing the wheel is fun -- don't know.

[Christos]

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  

[tkaiser]

Nothing will change unless he (or someone else) gets rid of this stupid BSP structure. Said that several times here and over there and it makes me sad seeing all those contributors to this github repo failing and wasting their time for no reason. Still: ignoring linux-sunxi community (the knowledge and all the work already done) is both plain stupid and what's happening right now.

 

The work has been done already and by simply using these two repos as 'script' within 24 hours the real work could be started (getting dvfs working for example):

 

- https://github.com/longsleep/build-pine64-image

- https://github.com/longsleep/u-boot-pine64

 

BTW: any owner of an OPi PC 2 with a GbE network could already contribute even if this BSP mess hasn't been cleaned up: https://github.com/OrangePiLibra/OrangePi_H5SDK/issues/4#issuecomment-264772851

[Christos]

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?

[tkaiser]

From what I understand, @tkaiser the issue in Buddy's repo is with BSP blobs, right?

Well, if I write structure I usually mean structure and not blob.

 

As already repeated way too often: longsleep's repos can be used almost as a 'script'. Even a monkey can repeat the steps starting with a clean checkout of u-boot 2014.07 and then importing Allwinner's H5 BSP u-boot version (or the one from @sinovoip morons for their BPi M2 Ultra -- doesn't really matter) so you get an initial commit and the idea where Allwinner has changed what. And by studying his simpleimage repo (each commit has a comment! It's just reading from back to forth) you already get the idea how to throw away the BSP structure and why.

 

I invited Buddy to join linux-sunxi community. He prefers reinventing the wheel. Well, then let's start 2017 like 2015 ended. Everyone unhappy about Orange Pi.

[ErwinH]

BTW: any owner of an OPi PC 2 with a GbE network could already contribute even if this BSP mess hasn't been cleaned up: https://github.com/OrangePiLibra/OrangePi_H5SDK/issues/4#issuecomment-264772851

 

The tool works like a charm, but currently does not add anything usefull, regarding GbE. The board simply won't get higher speeds then approx 60MB/s TCP TX, with 100% CPU usage on one core. RX reaches 105MB/s easily with 2 cores at 100%.

[tkaiser]

The tool works like a charm, but currently does not add anything usefull, regarding GbE. The board simply won't get higher speeds then approx 60MB/s TCP TX, with 100% CPU usage on one core. RX reaches 105MB/s easily with 2 cores at 100%.

Did you test through all 64 reasonable combinations? And if so how look results like?

[ErwinH]

Did a quick run, only 4 seconds per test.

 

http://pastebin.com/JzwCdp78

 

Killing dhclient and OrangePi Corekeeper helps a little, but still not the values you'd expect.

[Christos]

Well, if I write structure I usually mean structure and not blob.

 

 

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?

[hojnikb]

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?

 

At least a working armbian rootfs with xunlong kernel would be something. Their debian image just plain sux.