Jump to content

joaofl

Members
  • Posts

    62
  • Joined

  • Last visited

Everything posted by joaofl

  1. 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).
  2. 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.
  3. 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.
  4. 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!
  5. 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?
  6. Another board released based on the Rockchip: http://www.openembed.com/index.php/goods/2/detail.html
  7. 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.
  8. 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
  9. 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.
  10. 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?
  11. have you tested it on the orange pi? If ethernet, HDMI audio, Kodi works smoothly, and if it doesn't freeze, then it should be the best image around. Will test it asap.
  12. Found out this forum which seems to be where beelink releases their images. http://freaktab.com/forum/tv-player-support/beelink-aa/beelink-android-tv-box/gs1/firmware-roms-tools-dh The latest one is GS1_106N0, from few days ago. But the freezing problem with Kodi persists.
  13. I did run some more experiments, and it is not related to RAM after all... There is little RAM available, but it still goes on with some 100 Mb free, which should be fine. The same blocking issue does not happen when using VLC... So I guess the problem is somewhat more complicated than lack of RAM. Maybe some driver issue. Do not really know.
  14. Yesterday i installed it. It seems way more well developed than the Zidoo one. Kodi runs smoth. BUT, both with the Zidoo and Beelink, when I'm playing a video file, usually some Bluuray rip, the board freezes after some 3 minutes of playback. I wonder if this is caused by lack of RAM, since we have 1Gb compared to the Beelink 2Gb. Do you suggest a way of figuring out why this is happening? Is there a way to tune android for a 1Gb system? How can I monitor the RAM usage? Cheers
  15. Issue is that Zidoo is taking a lot to update their firmware, and user are complaining a lot on their forums for their lack of responsiveness. So i found another compatible TV box. The Beelink GS1 TV Box which runs android 7.1 on a Allwinner H6. From some videos on Youtube, their distribution seems quiet stable. Have anybody tested it? Gonna give it a try tonight. Follows the link for the firmware: https://www.chinagadgetsreviews.com/download-android-nougat-7-1-firmware-beelink-gs1-tv-box-2.html
  16. It seems that once you get the error message, even if you block the service on the firewall after that, the error will still show up. So one has to block it before it first runs the check. It worked for me here with no problem. Although some apps are crashing among other bugs...
  17. Do you think that because OrangePiOnePlus has 1Gb RAM compared to the 2Gb from Zidoo is a problem?
  18. What do you mean by update binaries? It worked nice, but there were bugs while running some apps, and kodi was freezing during the playback of movies. It seems that the new release fixes that. I'm trying to upgrade it now using their own upgrade app, from the file downloaded to an USB pendrive. Lets see if it fixes... The new release of the Zidoo firmware: http://forum.zidoo.tv/index.php?forums/h6-pro-official-firmware-releases.47/ I think this is definitely the best functionality one can give to an OPiOnePlus. Edit: the upgrade was done successfully. It seems more stable, but it still crashes with kodi sound and image are also out of sync
  19. Not really... They have organized the folders structure, but the images there are still the same. However, they seem to have added the schematics there: https://mega.nz/#F!wbRFwYyA!a-xbNcCcBQl8UlvTdwNj-g!dXJxQJQJ
  20. My observations are: - Android distribution: sucks! Very premature. One can not do anything. I was intended to test video playing, but could not get Kodi to run, neither any other app since Google play is not installed. So, even the apps that show up in the menu do not work. So I rapidly gave up on it. Current when idle seemed stable at around 380mA - Ubuntu server: distro does not boot if you have HDMI plugged in.... Idle current is 410mA Ethernet seems to be really Gigabit... Results for iperf below. in this case the current rises to 550mA. [ ID] Interval Transfer Bandwidth [ 3] 0.0-60.0 sec 6.34 GBytes 907 Mbits/sec when using bidirectional simultaneous transfers with the following command: root@OrangePi:~# iperf -c 192.168.1.100 -t 60 -d ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 192.168.1.100, TCP port 5001 TCP window size: 113 KByte (default) ------------------------------------------------------------ [ 5] local 192.168.1.143 port 37423 connected with 192.168.1.100 port 5001 [ 4] local 192.168.1.143 port 5001 connected with 192.168.1.100 port 51684 [ ID] Interval Transfer Bandwidth [ 5] 0.0-60.0 sec 4.56 GBytes 653 Mbits/sec [ 4] 0.0-60.0 sec 4.92 GBytes 705 Mbits/sec Then I run the gcc_perf @Larry Bank from here: https://github.com/bitbank2/gcc_perf Average current was around 560mA, with peak 640mA. My conclusion is: This board makes sense as a remote video player, connected to some TV with Kodi, probably, so that you can stream from your main server. That because it has great ethernet, with great 4K video decoding capabilities.... One USB3 would make it a good choice for servers... But no...
  21. Got my hands on one today. Gonna run some tests. The company already provides Android and Ubuntu Server distributions to it, however im more interested on it for multimedia ends. Lets see how it performs. Is there plans for Armbian distro to it?
  22. Do you really see it this way? I would rephrase it: to help anyone who wants to make their S500 based board useful/functional, and get the best out of it... My intentions are more towards learning what is behind the scenes. Is there any problem? With or without USB3, I'm making the DietPi image, so I can use my board as some sort of NAS. My intentions is to drop the link to the image after getting it done. I also gave a try, wasting probably many more hours, and doing pretty much nothing, on my shallow knowledge. By disabling ones module, a cascade of errors show up during compile. You solve one, 10 more show up. In the end, if you eventually manage to compile, something probably won't work properly. Thanks a lot for your time.
  23. Thats true. But despite the speed limitation it seems stable so far. However, there is one warning I keep getting: [ 30.600191] drivers/video/owl/backlight/owl_pwm_bl.c/owl_backlight_is_on: get backlight failed! I tried to disable this module before compiling the kernel, but could not found it exactly. Do you have a clue? How can I get more info on the error, to better lead me to its corresponding module on the kernel?
  24. Got some surprising performance numbers: root@DietPi:/# hdparm -T /dev/sda /dev/sda: Timing cached reads: 888 MB in 2.00 seconds = 443.93 MB/sec root@DietPi:/# hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 356 MB in 3.00 seconds = 118.64 MB/sec root@DietPi:/# After all, USB3 works, for reading only! Does it make any sense? Why not to write? Because with the same HD on my notebook, I get 150MB/s for R/W... So the bottleneck is not at the USB HD controller.
  25. I tried to do some merge between sparky allo and lemaker distributions. Basically, I merged the changes done to sparky related to USB3, to a fork of lemaker. Menaged to compile it, but id did not change the USB3 limitation. Not sure what to try next.. Any idea?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines