Android on H6 Boards

[joaofl]

On 3.3.2018 at 4:23 PM, joaofl said:

Yes...  Unfortunately.

Do you have any clue on how to manually add the right driver to their Android? Since there is no OTA images, I don't know how to partially use the oPi kernel on others image.

 

Have you tested that any further? Does Kodi work properly?

 

So I tested Kodi playing different demanding video files (H256), and it works smoothly, without crashing at all. So far the most stable media center option.

 

But yes, we have no ethernet. So I was wondering how could we load the basics drivers from the Xulong image, into the PineH6 one. So I browsed for hours (because Im not at all familiar with this android weird partitions system, and with the OS itself).

 

First I realized both Pine H6 and OPiOnePlus use the same ethernet controller (the realtek 8211). Then I went for the schematics, to actually check if the  realtek chip was connected to the H6 the same way on both boards. Which it seems to be for me... (see the links below). So this leaves me with no answer at all... If both boards have the same chip, connected in the same way, why one only works with its own image?

http://files.pine64.org/doc/Pine H64/Pine H64 Ver1.1-20180104.pdf

http://linux-sunxi.org/images/7/7c/OrangePi_OnePlus_Schematics_v2.0.pdf

 

Then I used ImgRepacker to edit the image files. I realized there is a file sysconfig.fex contained inside the image, that has the configs regarding the pins of the H6 each peripherals is connected to. So I went and changed the pins from the Pine to correspond with the Xunlong image. Yet, no success...

 

Now I literally gave up for now, although I would appreciate any help in this term. Since the PineH6 distribution has no OTA image, how can I merge it with the Xunlong image, keeping only the required to get the ethernet working? Any suggestions? Thanks in advance!

 

Edit: Preferably without having to recompile the kernel... For 2 reasons: (1) because its a nightmare until you get it right, and even if you do, its likely that it is not as good as the one from the image itself. and (2) if we make it easy to add this driver, then for the next releases it would be just as easy to "re-add" the driver.  

 

Edit: @chwe splited from:

 

I didn't went through the whole thread to pick out everything android related, in case someone is unhappy and has more posts which should be merged here send me a PM. 

Edited March 5, 2018 by chwe
split notice

[tkaiser]

3 hours ago, joaofl said:

there is a file sysconfig.fex

 

Just a quick note: this sys_config.fex stuff is how Allwinner does hardware description since years and still these days even if the kernels they use now use something different called 'device tree'. So starting with their kernel 3.10 sys_config.fex is processed by some Allwinner tool to create a .dts and .dtb file (do a web search for 'A64 dev tree&sysconfig使用文档.pdf' to get 'nice' PDF describing the process)

 

In case you want to adjust pin configuration (eg. which pins are used to attach the external Gigabit Ethernet PHY -- I hope you know that the real Ethernet controller is part of the SoC) you need to either edit sys_config.fex and then pipe the file through Allwinner's converter or you search for the already created .dtb file, convert it back into .dts, adjust things and convert back to .dtb (requires a Linux installation and the dtc tool which in Debian/Ubuntu is part of the device-tree-compiler package)

 

It would be great if a moderator could split off all this 'Using Android on H6 devices' stuff my post included into an own thread below 'peer to peer support' since it really doesn't fit well here in this thread.

 

Wrt getting Ethernet to work you need

• to edit the right file where pin mappings are defined
• sometimes deal with proprietary hacks (at least this was the case with Pine64)
• need to take care about something called tx/rx delays that are board specific

You'll find a lot of the related info when searching around these issues with Pine64 two years ago. While I was partially part of the process back then for obvious reasons I consider this just a waste of time like everyone else who went through this already (dealing with this Allwinner BSP stuff in general). So from a Linux / Armbian point of view we need the relevant stuff being mainlined (community work) before we could consider starting to support any H6 device. Based on Allwinner's BSP this for sure will not happen.

 

[goosh]

5 hours ago, joaofl said:

But yes, we have no ethernet. So I was wondering how could we load the basics drivers from the Xulong image, into the PineH6 one. So I browsed for hours (becauseIm not at all familiar with this android weird partitions system, and with the OS itself).

 

I was doing the digging too. While stock img would result in "sunxi-gmac gmac0 eth0: eth0: Type(6) PHY ID 001cc915 at 7 IRQ poll (gmac0-0:07)", Pine H64 img would give "sunxi-gmac gmac0 eth0: No PHY found!". So I'd guess it's either tx/rx delays or pin mapping.

[Xalius]

You know that the AW Android 7.1 SDK for H6 is available at http://files.pine64.org/os/sdk/H64-ver1.0/H6-Android-7.1-SDK.tgz ? So you can split that off into parts and re-implement the Android platform parts for OPi...

[joaofl]

6 hours ago, tkaiser said:

edit sys_config.fex and then pipe the file through Allwinner's converter

thanks for the explanation. I actually saw some of your posts related to the H64 which helped me.

So, there is this tool to convert fex2bin from here: http://linux-sunxi.org/Sunxi-tools

 

But my doubt is: After I get it converted, how can I replace the original dts+dtb? I can not really find them in this tricky Android boot partition, that shows no files, neither by unpacking the image file. If I understood correctly, the fex file then gets converted into the device-tree dts+dtb at compile time? So why is the fex text file there in the image at all?

 

There are some differences on the rx-tx delay comparing the two boards, there is also difference on the naming of the pins, and some default values are different as well. Also the power lines are named differently as well.

Follows the gmac config on both files for your reference:

 

Xunlong:

;------------------------------------------------------------------------------;
; 10/100/100Mbps Ethernet MAC Controller Configure                             ;
;------------------------------------------------------------------------------;
;   配置选项：                                                                 ;
;   gmac_used  ---  1: gmac used, 0: not used                                  ;
;   gmac_powerx --  A[:B] A: axp channel, B: voltage value                     ;
;   phy-mode    --  rgmii, rmii, mii                                           ;
;   tx-delay    --  transmit clock delay: 0~7                                  ;
;   rx-delay    --  receive clock delay:  0~31                                 ;
;------------------------------------------------------------------------------;
[gmac0]
gmac0_used         = 1
phy-mode           = "rgmii"
gmac_rxd3          = port:PD00<5><default><3><default>
gmac_rxd2          = port:PD01<5><default><3><default>
gmac_rxd1          = port:PD02<5><default><3><default>
gmac_rxd0          = port:PD03<5><default><3><default>
gmac_rxck          = port:PD04<5><default><3><default>
gmac_rxctl         = port:PD05<5><default><3><default>
gmac_txd3          = port:PD07<5><default><3><default>
gmac_txd2          = port:PD08<5><default><3><default>
gmac_txd1          = port:PD09<5><default><3><default>
gmac_txd0          = port:PD10<5><default><3><default>
gmac_txck          = port:PD11<5><default><0><default>
gmac_txctl         = port:PD12<5><default><3><default>
gmac_clkin         = port:PD13<5><default><0><default>
gmac_ephyrst       = port:PD14<5><default><3><default>
gmac_mdc           = port:PD19<5><default><3><default>
gmac_mdio          = port:PD20<5><default><3><default>
gmac-power0        = "vcc-io"
gmac-power1        = "axp806_aldo3"
gmac-power2        =
tx-delay           = 0
rx-delay           = 0

 

From PineH64:

 

gmac0_used          = 1
phy-mode            = "rgmii"
gmac_txd0          = port:PD10<5><default><3><default>
gmac_txd1          = port:PD09<5><default><3><default>
gmac_txd2          = port:PD08<5><default><3><default>
gmac_txd3          = port:PD07<5><default><3><default>
gmac_txen          = port:PD12<5><default><3><default>
;gmac_rxerr         = port:PD06<5><default><3><default>
gmac_txclk         = port:PD11<5><default><3><default>

gmac_rxd0          = port:PD03<5><default><3><default>
gmac_rxd1          = port:PD02<5><default><3><default>
gmac_rxd2          = port:PD01<5><default><3><default>
gmac_rxd3          = port:PD00<5><default><3><default>
gmac_rxdv          = port:PD05<5><default><3><default>
gmac_rxclk         = port:PD04<5><default><3><default>
gmac_clkin         = port:PD13<5><default><3><default>

gmac_mdc           = port:PD19<5><default><3><default>
gmac_mdio          = port:PD20<5><default><3><default>

gmac-power1        =  
gmac-power2        = 
gmac-power3        = 

tx-delay           = 2
rx-delay           = 0

 

[joaofl]

7 hours ago, tkaiser said:

(do a web search for 'A64 dev tree&sysconfig使用文档.pdf' to get 'nice' PDF describing the process)

Thats definitely a nice document, at least its hard to find found it here

https://pan.baidu.com/s/1nu2SMCT#list/path=%2F

But not really sure how to read it.

 

[tkaiser]

10 minutes ago, joaofl said:

So, there is this tool to convert fex2bin from here: http://linux-sunxi.org/Sunxi-tools

 

Nope, that's the wrong one (only suitable for Allwinner's old 3.4 kernel). You need to modify the .dtb file or use the Allwinner BSP/SDK to start with sys_config.fex. All Ethernet related entries for the Orange board have to be taken from Xunlong otherwise it won't work.

 

When dealing with this stuff 2 years ago I was a bit late to game. At that time longsleep already had done an amazing amount of work to cleanup the Allwinner BSP mess and we could deal with a build system that was at least somewhat useable. Back then he switched from sys_config.fex directly to .dts but in the meantime ayufan reverted to sys_config.fex with his builds (I searched for the relevant commits but did not find them. Maybe @Xalius has a clue how the initial conversion works).

 

So you probably find some information here but I've no idea how filesystem structure looks like on those Android builds.

[Xalius]

I think the quick and dirty way is to extract the dtb directly form the image (using a hexdump, it's somewhere attatched to the u-boot blob usually) and then just use dtc to change the config...

[goosh]

Any chance this could be employed?

 

**phy_write(phydev, 0x28, 0xd591)**

[joaofl]

7 hours ago, Xalius said:

You know that the AW Android 7.1 SDK for H6 is available at http://files.pine64.org/os/sdk/H64-ver1.0/H6-Android-7.1-SDK.tgz ? So you can split that off into parts and re-implement the Android platform parts for OPi...

 I could try to... But could not really find tutorials on how to compile and generate the images... Typing make does not do the job. Do you have any tutorials you would like to point out?

[tkaiser]

5 hours ago, tkaiser said:

in the meantime ayufan reverted to sys_config.fex with his builds (I searched for the relevant commits but did not find them.

 

I asked ayufan in the meantime and he pointed me to https://github.com/ayufan-pine64/boot-tools/blob/with-drm/Makefile#L113-L116 for this. No idea about requirements/tools needed and where they can be found. Just had a quick look into https://github.com/Allwinner-Homlet/H6-BSP4.9-tools but immediately ran away after clicking around. It's the usual AW mess...

[Noah E. Koeppel]

2 hours ago, joaofl said:

 I could try to... But could not really find tutorials on how to compile and generate the images... Typing make does not do the job. Do you have any tutorials you would like to point out?

http://www.orangepi.org/Docs/BuildingyourownAndroidfirmware.html

 

That should give you a very basic allwinner image, just use the config for sun50iw6p1

[tkaiser]

6 minutes ago, Noah E. Koeppel said:

http://www.orangepi.org/Docs/BuildingyourownAndroidfirmware.html

 

...is outdated like hell and only suitable for A20 boards that are not available from Xunlong any more since years. 

[Noah E. Koeppel]

It's the same process, just use the new source

Edit: I'll make a little guide elsewhere at some point.

 

[tkaiser]

22 minutes ago, Noah E. Koeppel said:

It's the same process, just use the new source

 

http://wiki.lemaker.org/BananaPro/Pi:Building_your_own_Android_firmware -- this is where the above has been copied from. I'm not that concerned about people wasting their time following inappropriate 'tutorials' rotting somewhere on the Internet but more why all this off-topic Android talk has to happen here in this thread? Why can't this be moved to 'peer to peer support' where it belongs to?

 

With those 64-bit ARMv8 SoCs there is a lot different (e.g. ARM Trusted firmware). How to deal with a cleaned up BSP is most probably best described here: https://github.com/longsleep/build-pine64-image/tree/master/u-boot-postprocess 

 

Wrt mainline I would better look there: https://forum.pine64.org/showthread.php?tid=5790&pid=35873#pid35873

 

It doesn't really matter which H6 device is in use since all that matters is the SoC. Board specific hardware settings need to be extracted from sys_config.fex files and then adopted (both to other hardware and other u-boot/kernel version -- the Allwinner BSP .dts files use a different structure than proper mainline stuff)

[joaofl]

So I managed to get the ehternet working on the OPiOnePlus running the PineH64 image.

Finally I have a stable media center, with kodi and youtube running smoothly. So far, quiet stable.

 

So in summary, after a lot of digging, I figured out some tools to: (1) unpack both android images from Xunlong and PineH64, and (2) copy the dtb files from one image to the other one.

 

If you only want it up running, then you can download the image that I already modified from  the link below, with no need to do the hacking. Otherwise, follows the steps below.

 

https://mega.nz/#!lEsCFRhZ!eCHcaScxpmFyb54Q3cOi-YgZpe5rLjNg6bap_S9ZGdk

 

-------- How to ------------

First one needs download both image files (Xunlong and Pine) and then unpack them using the imgRePacker tool, from here

 

Then, you move the file boot_package.fex from the Xunlong to the Pine image. Then you re-pack it using the same imgRePacker tool.

 

Burn it, and it should work.

-----

If you want to customize the dtb file, then there is a couple of steps more.

 

You need to unpack the boot_package.fex files to expose the 3 dtb files that are inside it (only the third one seems to be a valid one), using this tool

 

Once they are unpacked, one can use the command  dtc -I dtb -O dts -o out.dts in.dtb  to convert the binarry to string, and edit it....

 

To re-pack the boot_package.fex file you have to do the other way around, and convert back the 3 extracted device trees from string to binary back.  The to repack them simply type cat *.dtb > boot_package.fex (that considering that you have the extracted dtb files ordered alphabetically.

 

Thats it!

[joaofl]

4 hours ago, Noah E. Koeppel said:

http://www.orangepi.org/Docs/BuildingyourownAndroidfirmware.html

 

That should give you a very basic allwinner image, just use the config for sun50iw6p1

I tried for some half an hour to compile it, but like @tkaiser said, the tutorials are so outdated that even I can see there are things going wrong. So I gave up, and went trough the dirty way directly.

 

I guess they keep it hard to build on propose, maybe to make hard for their competitors to use their image.

[Noah E. Koeppel]

20 hours ago, joaofl said:

I tried for some half an hour to compile it, but like @tkaiser said, the tutorials are so outdated that even I can see there are things going wrong. So I gave up, and went trough the dirty way directly.

 

I guess they keep it hard to build on propose, maybe to make hard for their competitors to use their image.

strange, i never had any issues, i'll try and make instructions for what worked for me.

edit: now that I say that i have issues reproducing what I did, figures...

[Noah E. Koeppel]

Here's what I did, I guess i skipped some irrelevant parts: (I've done this in Ubuntu 16.04 and 17.10 must be x64 )

1.  Extract the sdk and bsp into a directory, no spaces. (Get it from OrangePi MEGA or PineH64 Wiki page) You'll have an 'android' directory and a 'lichee' directory

2.  Install gawk, awk will give you an error otherwise,  mkbootimg(the included one didn't work for me), and java if it's not installed, as well as the android build requirements

$ sudo apt-get install gawk openkjdk-8-jdk

$ sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip

 

3.  cd to lichee and run:

$ ./build.sh -p sun50iw6p1_android -c 7.x -k linux-3.10
or
$ ./build.sh config
then select 2 - 0 - 2 for H6 android 7.x

note: if you get an error such as 'mkbootimg not found' and you're on 17.10 try 'sudo apt-get install android-tools-mkbootimg' and running the config again.

4. cd to ../android and run (must be in android root directory):

$ source build/envsetup.sh
or
$ . build/envsetup.sh

$ lunch

I've had luck with petrel_*_p1 eng number 22-26

 

5. Extract the kernel

$ extract-bsp

6. Make!

$ make
or optionally
$ make -j#
where # is number of cores for multi-thread (faster)

Now you'll have a populated 'out/' folder, your android rootfs is in here if you want to do stuff to it before packing.

 

7. Pack for phoenixcard

$ pack

this will create an image in ../lichee/tools/pack/sun50iw6p1_android_petrel-p1_uart0.img

 

8. Flash and boot! Transfer the image to windows and burn it in startup mode using phoenixcard 4.

 

  Congratulations, you have a very buggy allwinner stock android build but hopefully you can make it work for you.  

A default settings image will probably work on the orangepi one plus but the further from that you get the more you'll have to configure it.

[joaofl]

7 minutes ago, Noah E. Koeppel said:

Congratulations, you have a very buggy allwinner stock android build but hopefully you can make it work for you.  

A default settings image will probably work on the orangepi one plus but the further from that you get the more you'll have to configure it.

 

Ill give it a try later.

Have you tried to compile the PineH6 distributions? Maybe it is less buggy, and provides a better starting point.

 

Edit:

I've been running the PineH6 Android for two days now. It Runs nicely. Youtube with 4K videos are the only situations that I saw small glitches on the video reproduction. Otherwise its great.

 

The OS itself is still very limitted. The luncher is really bad, the GooglePlay does not open, and apps have to be installed through adb. But apart from that, it humiliates my old raspberry media center in terms of performance. I managed to stream and seek through 20Gb videos from my server smoothly.

 

So I would say that, if we manage to get that image right, it can be a good thing.

[Noah E. Koeppel]

The sdk download from pine doesn't seem much different than the orange pi one, they're both only really usable as a starting point.  The Android image for pine runs really nicely on pine and I wouldn't bother trying to build it from source at this point.

[joaofl]

1 minute ago, Noah E. Koeppel said:

The sdk download from pine doesn't seem much different than the orange pi one, they're both only really usable as a starting point.  The Android image for pine runs really nicely on pine and I wouldn't bother trying to build it from source at this point.

 

Sure, but I mean building the Pine image to actually use on the OPi1P. Maybe its a better starting point for it than the Xunlong image is, due to its buggy current state (as you pointed).

[tkaiser]

On 6.3.2018 at 3:02 AM, joaofl said:

 

On 5.3.2018 at 10:03 PM, Noah E. Koeppel said:

http://www.orangepi.org/Docs/BuildingyourownAndroidfirmware.html

 

That should give you a very basic allwinner image, just use the config for sun50iw6p1

I tried for some half an hour to compile it, but like @tkaiser said, the tutorials are so outdated

 

Those old tutorials were made for the situation back then half a decade ago (that old is Allwinner's BSP for A20 which the original LeMaker tutorial has been written for). They do not mention for example that you need a more recent Ubuntu build host with more recent BSP drops and they especially don't mention that you need a x64 Ubuntu in the meantime since building on x86 will fail. These old tutorials are simply not worth a look.

 

For people wanting to improve on their skills getting an Allwinner BSP to work it's a great idea to dig through all of this. But since these BSP have never meant to be used by end users or even board makers (usually Allwinner engineers do the job for their customers which are Android device manufacturers and not the users later using those devices!) it's just a mess to deal with.

[tkaiser]

And for those still happy to get their hands dirty:

• http://files.pine64.org/os/sdk/H64-ver1.1/H6-lichee-v1.1.tar.gz (new version but still based on kernel 3.10.65)
• How to get their 4.9 kernel built: https://github.com/Allwinner-Homlet/H6-BSP4.9-brandy/pull/1/commits/9f24623786dd1bd83cac9938f81516e671a1e304 and why it's useless: https://github.com/Allwinner-Homlet/H6-BSP4.9-brandy/issues/2

So everything as expected

[joaofl]

13 hours ago, Noah E. Koeppel said:

android-tools-mkbootimg

This is not on ubuntu's  16.04 repositories.. How could you get it?

[Noah E. Koeppel]

1 hour ago, joaofl said:

This is not on ubuntu's  16.04 repositories.. How could you get it?

You're right, now I'm super confused, maybe it's in one of the other packages? Try building the kernel without it, if you don't get an error that says mkbootimg not found then it's all good.  Otherwise I can try reinstalling 16.04 and track down what i did to make it work.

edit: you can also try 'android-tools-fsutils' but I can't verify that it has that file at the moment

 

as for new lichee I haven't tried it but it might work better (or worse) and i wouldn't even bother with the 4.9 BSP as takiser said

[joaofl]

@tkaiser

 

I'm looking at PineH64 kernel DTS files, and there are lots of them. More specifically to the h6 chip, there seems to have these ones:

 

joao@machina ~/Repositorios/pineh64/lichee $ find -name sun50iw6*.dts
./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-soc.dts
./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-pro_v1_0.dts
./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-perf1_v1_0.dts
./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-petrel-p1.dts
./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-qc.dts
./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-perf2_v1_0.dts
./linux-3.10/arch/arm64/boot/dts/sun50iw6p1-fpga.dts

 Do you have any idea where this files are referenced from? Where in the kernel source can we chose which dts to be converted into dtb, and loaded to boot? And also, how to figure out which one is being loaded?

That would be the first step to make PineH64 image also compatible with the OPi

 

@Noah E. Koeppel

 

So far the its working. The kernel have compiled successfully. Lets see the rest. Maybe its part of the android-sdk package...

[tkaiser]

14 minutes ago, joaofl said:

Do you have any idea where this files are referenced from?

 

Neither know nor care. The last time I looked into an Allwinner BSP was over a year ago for H5. Immediately gave up since such a mess. When dealing with A64 another year before we were all lucky that longsleep did the hard work to turn the BSP mess into something useable and put all the stuff combined with documentation on Github. 2 years ago dealing with 64-bit Allwinner SoCs was fun and exciting, I doubt anyone talented will do the job again with newer BSP like the one we're talking here about. So better become familiar with dtc and editing ugly .dts files with all values in hex...

[Noah E. Koeppel]

Maybe it just converts everything in that folder?

[joaofl]

But then in the end there is only one dtb file inside /lichee/out/sun50iw6p1/android/common/sunxi.dtb

On that folder there are hundreds of dts files, for different platforms, chips and boards. Its somehow related to the compiling options you provide "sun50iw6p1" but not sure how..

 

But we can always do the dirty job of simply replacing the the dtb file before compiling android