• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map






Everything posted by joaofl

  1. True... As buggy as the previous.. development seems to be stagnant
  2. Xunlong have released a new android image (v1.3) with Google Play working. Have anybody tested it? Any other improvement expected? Here is the link:!wbRFwYyA!a-xbNcCcBQl8UlvTdwNj-g!9TBmCJAL
  3. Video drivers were added to the H6 GPU at Allinner's git repository: Is there any progress with Armbian for the H6 boards?
  4. To get the OrangePi image with the Pine H64 image, replace the whole boot_package.fex file from one to another. If you wanna hack the dtb files, then you have to unpack the .fex file into this 3 dtb files. The first 2 can not get converted from dtb to dts. The third one does seem to be the one we are interested.. Another important point is that, when I've tried to repack the fex file with dtb files mixed from one Orange to Pine, I got an unbootable image. So there is some dependencies among these 2 first dtb files and the main one. The first bytes seem to play a role on on getting the whole thing working, dont know which. Maybe it is simply because the main dtb file is referenced somewhere else by its byte position in the files. Maybe simply by changing the files size can mess it up (only guessing). @tkaiser follows the link to the dtb and dts files extracted from android image of the PineH64:!4MMQjbbC!gonZ69Vbx4rp3F5x9Y1Cig @Noah E. Koeppel I followed the steps from this post here on linux. If you cant get it right let my know.
  5. @tkaiser I'll upload it and drop you the link asap
  6. Compiled and tested, but it seems more buggy than the image they provide. Haven't tested much, but Ive noticed for example that it doesnt go Idle. Should test a bit more, but it seems that they dont include their tunning on the image they distribute.
  7. I missed that Now its compiling... Lets see how it goes... Ill test the output image as well to check if there is any improvement compared to the previous one.
  8. That worked. But now when I type make -j 6 (which I guess is missing in your tutorial), I get another error: ninja: Entering directory `.' ninja: error: 'device/softwinner/petrel-p1/kernel', needed by 'out/target/product/petrel-p1/kernel', missing and no known rule to make it build/core/ recipe for target 'ninja_wrapper' failed make: *** [ninja_wrapper] Error 1 But notice that I'm trying to compile the PineH64 android. I've tried with all options from 22 to 26 (the petrel ones).
  9. this command requires python-lunch to work, but still, after typing it it gives the error: No such file: /home/joao/.lunchrc Should I compile from an specific absolute directory? Wont make do the job?
  10. There is another tip I found on the PineH6 forums to get GooglePlay working on it. Consists of replacing /system/priv-app/GmsCore with the /system/priv-app/PrebuiltGmsCore from the Zidoo OTA. After that play services is said to work fine.
  11. 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
  12. @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...
  13. This is not on ubuntu's 16.04 repositories.. How could you get it?
  14. 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).
  15. 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.
  16. 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.
  17. 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.!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!
  18. 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?
  19. Another board released based on the Rockchip:
  20. Thats definitely a nice document, at least its hard to find found it here But not really sure how to read it.
  21. 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: 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
  22. 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? H64/Pine H64 Ver1.1-20180104.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.
  23. 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?