Jump to content

Armbian for OrangePi PC2, AllWinner H5


Christos

Recommended Posts

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ;)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :D) but it's pretty useful for emulation stuff. Given how mali450 is like 3 times better in h5, this would help a lot.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines