Armbian for OrangePi PC2, AllWinner H5

[Christos]

Hi,

 

Are there any news on if Armbian will be on the new H5 64bit board?

Orange released an Android SDK and an Android image but I guess everyone is waiting for a decent 64bit Debian.

 

Since took the plunge and got into the H5 wagon ordering one, I looked at the released info and obviously there was nothing I could use myself..

So the question goes to the Armbian gurus, guys do you think that there could be an Armbian release for H5 this year?

 

Christos

 

[Igor]

I got my board in Tuesday, most people got it today. We also got an H2+ and lot's of other tasks are already running. SDK looks pretty useless, like usually. Take a look: http://filez.zoobab.com/allwinner/h5/

 

At this stage, there is not enough good information to make a judgment.

[zador.blood.stained]

Especially since there is no public "user manual" for H5 yet. So progress regarding H5 will depend on compatibility with existing SoC's and bits of info from BSP kernel and u-boot source.

[Christos]

Orange is advertising PC2 with "Lubuntu and android" on their sales page so I guess they have to give some sort of Linux SDK soon.

 

At times like these I do see how useless is an OrangePi whatever board without a decent O.S. eg Armbian..

[Igor]

They can / will glue stock Allwinner u-boot, Android kernel and some generic (l)Ubuntu root file system, but even that is not simple from this stage. I think they even provide one build, but you need to use Phoenix tools to burn into SD card. If it boots / works, it's usually barely usable ...

[tkaiser]

Orange is advertising PC2 with "Lubuntu and android" on their sales page so I guess they have to give some sort of Linux SDK soon.

 

There is no Linux SDK. This is all the time just a huge tarball containing Android sources, BSP kernel + u-boot and some really ugly scripts that might be able to produce an Android image from all this stuff. In this case it's here: http://filez.zoobab.com/allwinner/h5/

 

Fortunately for users/buyers some of those linux-sunxi guys who brought Linux to A64 (Pine64) and some other talented developers are pretty excited about H5 now and dev samples arrive these days. If you're curious watching linux-sunxi IRC might be the best place to get an idea how things evolve: https://irclog.whitequark.org/linux-sunxi/2016-11-10

[Christos]

.. If you're curious watching linux-sunxi IRC might be the best place to get an idea how things evolve: https://irclog.whitequark.org/linux-sunxi/2016-11-10

 

Thanks, got the picture allright.

 

In the A53 arena, wich obviously looks it will be the way of things for the immediate future,

definitively there is a lot of work that needs to be done..

[tkaiser]

In the A53 arena, wich obviously looks it will be the way of things for the immediate future, definitively there is a lot of work that needs to be done..

 

We'll see. Being not that innovative (talking about Allwinner here) is an advantage. Given H5 is really just a funny mixture of H3 and A64 things could work pretty soon.

[Da Alchemist]

Is there any Wip on Armbian for this Board?

[tkaiser]

In fact I already ran Armbian/Xenial on this board (exchanging roots is both easy and boring) but this was just to get a known working setup to test with.

 

Currently a few bits are missing like buggy/outdated kernel, wrong/ignored hardware settings (affects network performance atm) and we try to help where we can to get this stuff resolved 'upstream'. I sent 'my' OPi PC 2 to jemk (linux-sunxi dev specialized in DRAM/video stuff) on friday and we try to give some hints to the guy doing software development for Xunlong: https://github.com/OrangePiLibra/OrangePi_H5SDK/issues

 

As long as these basic issues aren't resolved we won't start with board support.

[Christos]

Hopefully now that the actual informative H5 manual arrived, things could get some speed..

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

[tkaiser]

Hopefully now that the actual informative H5 manual arrived, things could get some speed..

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

Better read irclog from today. But on the weekend some progress has been made with regard to getting rid off blobs already: https://github.com/jemk/u-boot/tree/apritzel-h5-dram (jemk really is a wizard!)

 

But that's nothing the average OPi PC 2 customer cares about

[Christos]

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?

[Igor]

@Christos

 

Hold you horses. Perhaps you forgot that we do Armbian in our free time?

 

https://docs.armbian.com/Release_Changelog/

[hojnikb]

@Christos

 

Hold you horses. Perhaps you forgot that we do Armbian in our free time?

 

https://docs.armbian.com/Release_Changelog/

Much appreciated, as always

Good work from armbian and sunxi guys make those boards actually worth buying

[tomter]

I have received PC2 today in Slovenia. Board will wait till Armbian distro comes out.

[hojnikb]

Guys, anyone tried xunlong debian image ?

I can't seem to find script.bin to change the resolution...

[jernej]

I can't seem to find script.bin to change the resolution...

 

Having separate script.bin file is only community invented trick for easier script.bin manipulation. Allwinner build tools integrate script.bin in U-Boot binary. I recommend that you get fex file from sources, change it, convert it to bin and extend boot script to load it to address 0x43000000 just before kernel is loaded and run.

 

EDIT: We are talking about 64 bits... There is no fex/bin files for 64 bit arm, only dts/dtb. For that you have to have dtc, if you want to modify it. I'm not sure if this file is loaded from filesystem or like in bin case, integrated to U-Boot binary.

[hojnikb]

Having separate script.bin file is only community invented trick for easier script.bin manipulation. Allwinner build tools integrate script.bin in U-Boot binary. I recommend that you get fex file from sources, change it, convert it to bin and extend boot script to load it to address 0x43000000 just before kernel is loaded and run.

 

EDIT: We are talking about 64 bits... There is no fex/bin files for 64 bit arm, only dts/dtb. For that you have to have dtc, if you want to modify it. I'm not sure if this file is loaded from filesystem or like in bin case, integrated to U-Boot binary.

 

I see. I'm really after changing the resolution to 1080p instead of 720p

[jernej]

hm... you can try to enter u-boot console and change settings with fdt commands. I didn't yet analyze whole boot sequence...

[tkaiser]

I see. I'm really after changing the resolution to 1080p instead of 720p

 

Change 4 to 10 (0xa) here. And then try to figure out where this change should happen.

[Christos]

Change 4 to 10 (0xa) here. And then try to figure out where this change should happen.

 

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?

[tkaiser]

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?

 

Please try it out and report back and if that doesn't work grab their SDK and start to explore what's happening (been there, tried Allwinner's BSP, had to vomit and gave up). When I did the same using dtc with other parameters nothing happened. And it would really be interesting why. These are tasks that might improve situation a bit.

[Christos]

Please try it out and report back and if that doesn't work grab their SDK and start to explore what's happening (been there, tried Allwinner's BSP, had to vomit and gave up). When I did the same using dtc with other parameters nothing happened. And it would really be interesting why. These are tasks that might improve situation a bit.

 

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)

[hojnikb]

Looking at the dts file in github and the one i was able to extract from ubuntu image, it seems that a53 is running at 1.2Ghz, but oddly enough only goes up to 1.01Ghz according to cpufreq widget. Am a doing something wrong here ?

 

at least scaling works, since it clocks itself down to 480Mhz.. still not sure about voltage though.

[hojnikb]

Please try it out and report back and if that doesn't work grab their SDK and start to explore what's happening (been there, tried Allwinner's BSP, had to vomit and gave up). When I did the same using dtc with other parameters nothing happened. And it would really be interesting why. These are tasks that might improve situation a bit.

 

Is it possible that device tree is actually integrated into the uboot image ?

So you would have to extract it from uboot first and then convert it to dts to actually edit it.

[tkaiser]

Looking at the dts file in github and the one i was able to extract from ubuntu image, it seems that a53 is running at 1.2Ghz, but oddly enough only goes up to 1.01Ghz according to cpufreq widget. Am a doing something wrong here ?

 

DVFS still doesn't work, board remains at 1.1V, every higher clockspeed means instability. Therefore 1008 MHz is the maximum allowed.

 

Nothing will change until: https://irclog.whitequark.org/linux-sunxi/2016-11-29#18292284; (and this also won't change -- someone has to do this job otherwise nothing will change since no one wants to touch Allwinner's smelly BSP). Since longsleep did all the work on Pine64 because he needed it for his own use and he's interested in a H5 board with at least 2 GB DRAM as already suggested it might be a good idea if @Igor asks Steven to simply send out an OPi 3 dev sample to longsleep while all the brave souls working on mainlining H5 stop to work

 

Is it possible that device tree is actually integrated into the uboot image ?

 

Yes, that's exactly the problem (was the same with every other Allwinner BSP for every other Allwinner SoC before). Their smelly build script creates a bunch of stuff that has to be written to the first sectors of the image/card. Most probably that's what you're interested in: https://github.com/OrangePiLibra/OrangePi_H5SDK/blob/master/external/uboot.bin

 

Again: Unless someone has the balls to start cleaning up this BSP mess nothing will change regardless what's happening in detail (for whatever reason changes to .dtb have no effect)

[hojnikb]

DVFS still doesn't work, board remains at 1.1V, every higher clockspeed means instability. Therefore 1008 MHz is the maximum allowed.

 

Nothing will change until: https://irclog.whitequark.org/linux-sunxi/2016-11-29#18292284; (and this also won't change -- someone has to do this job otherwise nothing will change since no one wants to touch Allwinner's smelly BSP). Since longsleep did all the work on Pine64 because he needed it for his own use and he's interested in a H5 board with at least 2 GB DRAM as already suggested it might be a good idea if @Igor asks Steven to simply send out an OPi 3 dev sample to longsleep while all the brave souls working on mainlining H5 stop to work

 

 

Yes, that's exactly the problem (was the same with every other Allwinner BSP for every other Allwinner SoC before). Their smelly build script creates a bunch of stuff that has to be written to the first sectors of the image/card. Most probably that's what you're interested in: https://github.com/OrangePiLibra/OrangePi_H5SDK/blob/master/external/uboot.bin

 

Again: Unless someone has the balls to start cleaning up this BSP mess nothing will change regardless what's happening in detail (for whatever reason changes to .dtb have no effect)

 

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.

[zador.blood.stained]

Yes, that's exactly the problem (was the same with every other Allwinner BSP for every other Allwinner SoC before). Their smelly build script creates a bunch of stuff that has to be written to the first sectors of the image/card. Most probably that's what you're interested in: https://github.com/OrangePiLibra/OrangePi_H5SDK/blob/master/external/uboot.bin

You can look at DTB in question in u-boot.bin starting at offset 0xCF000

 

Again: Unless someone has the balls to start cleaning up this BSP mess nothing will change regardless what's happening in detail (for whatever reason changes to .dtb have no effect)

Let me rephrase that a little bit: Unless someone needs to run legacy kernel on H5 or has nothing more useful to do in their life nothing will change. Surely basic mainline support will land in u-boot and kernel may be in 2-4-6 months and then we'll be able to use this board with basic (headless or simplefb) setup.

[hojnikb]

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.