[unoffical] LE-9.2/9.80-Images for RK3229/RK3228

  • I don't think 1080p Netflix is possible on LE or CE.


    PS: Click!

    It would be possible on either if your CPU can handle decoding it. It has a way of tricking you into thinking your box can handle it when really it can't. My go to test is the Altered Carbon intro. I'm not even going to try that on the MXQ boxes running RK3229 because I know I'll be disappointed.

  • quickfast The hardware has to support Widevine level 1 to increase Netflix resolution. So yes, it's possible in theory, but I don't think the user has the right hardware.

    Flexin' vinyl, jammin' break beats. 8)

  • quickfast The hardware has to support Widevine level 1 to increase Netflix resolution. So yes, it's possible in theory, but I don't think the user has the right hardware.

    Using the Widevine CDM in Kodi you can decode it with the CPU. Unlike Widevine level 3 it can't be passed to the GPU for decoding.. I managed to get up to 720p on my amlogic s912 based box. At 1080p it fails the Altered Carbon test.

  • Hi knaerzche and all,

    I am trying to build the libreelec-9.2 branch on my own, it success smootly, but when I give the built image a run, nothing happens, the screen remains black, instead if I use the pre-built image all goes well.


    What am I missing?

  • We looked in our crystal ball but couldn't figure out your undocumented boot issue. UART logs would be more informative.

    The problem is not the boot itself, but the something in the build.

    As I said the latest release for mk809iv (Release RK322x-le92-d20c7bc · knaerzche/LibreELEC.tv · GitHub) boots pretty fine, so I expecting that cloning and building the libreelec-9.2 branch it have booted as it did in the latest release.


    I built it using the following commands:

    Code
    $ git clone https://github.com/knaerzche/LibreELEC.tv.git
    $ cd LibreELEC.tv
    $ git checkout libreelec-9.2
    $ PROJECT=Rockchip DEVICE=RK322x ARCH=arm UBOOT_SYSTEM=rk3228b-mk809iv make image

    The build completed, but then doesn't boot. I have also checked-out on the release commit (d20c7bc), but result is the same.

    I guess that I have missed something at build time. Otherwise release doesn't match the source code.

  • Your description implies that build completed but the devicee does not boot. It would be informative to know at what point in the boot sequence the device fails to boot, hence the request for UART output. However it looks like you're one of those users who is fixated on a specific thing and knows better than us how debug a boot problem. So /shrug and good luck. NB: LE 9.2 is a dead codebase so I would restart with LE10 anyway.

  • Your description implies that build completed but the devicee does not boot. It would be informative to know at what point in the boot sequence the device fails to boot, hence the request for UART output. However it looks like you're one of those users who is fixated on a specific thing and knows better than us how debug a boot problem. So /shrug and good luck. NB: LE 9.2 is a dead codebase so I would restart with LE10 anyway.

    eheh... I am one of those users who has no access to uart to debug the issue on the board and stunned that again and again "same" codebase does not produce same binary!

    I was expecting that freezing a release in a branch it would build and word out of the box for a supported device.


    I appreciated your support asking to share uart output (which again I am not able to provide), but it will be to probably make some change to a release that should work with no issue.


    Regarding the codebase, I don't like to work on beta releases, LE9.8 would be fine, but again same behavior, build ok, but no boot.

    Have you any other repo with working LE9.8 code for RK322x to test out?

  • goolpone You are making some assumptions about "codebase" that are just wrong. First of all, the fork is not "official" but rather a personal work from knaerzche , who may have thousands of reasons not to keep the master branch up with releases. I don't see a "freezed" status anywhere on this github fork, so your expectations have no basis.


    The serial output unfortunately is a very fundamental debugging tool with this kind of boards, without the UART dump it is close to impossible to say what is wrong with your image. There may be possible configuration faults, but we will never know. The boot process is quite complex and there any dozens of variables involved in.

  • goolpone You are making some assumptions about "codebase" that are just wrong. First of all, the fork is not "official" but rather a personal work from knaerzche , who may have thousands of reasons not to keep the master branch up with releases. I don't see a "freezed" status anywhere on this github fork, so your expectations have no basis.


    The serial output unfortunately is a very fundamental debugging tool with this kind of boards, without the UART dump it is close to impossible to say what is wrong with your image. There may be possible configuration faults, but we will never know. The boot process is quite complex and there any dozens of variables involved in.

    Mine are not assumptions but facts:

    - I know it is a fork and it is clear it is personal work, and I am still grateful to knaerzche for sharing it.

    - I do not want to point the finger to anyone nor accuse anyone for misalignments between source code and binary release, but fundamental of software development and maintenance is trackability and if two build for the same source code differs then there is something wrong in the code or in the build environment/execution.

    - There should never be thousands of reasons to not keeping source code and release aligned especially when the author is promoting its release in an open source environment releasing version for specific SoCs.

    - a commit in a specific branch is something that last forever so I guess one would commit in such branch something tested and working so such branch in going to contains the state-of-the-art for the related content.


    Again as you guess there should be possible configuration faults, but why there should be if I built the exact source code built by the author?

    I also know only author or close supporters can answer this.


    Just out of curiosity, are some of you able to build and run some of the version without making change?

    Again I do not want to just criticize but maybe highlight some possible issue in the build environment, inviting some of you, with access to uart, to try building from the source and maybe discovering an issue affecting other SoCs.

  • goolpone

    are you try to boot from SD card or from internal storage ?
    I give for sure your android is booting fine.

    Well a tricky way to have an INITIAL serial out put is connect a usb/ttl to pin 4 on sd reader counting from where the switch of sd is ( if big sd reader you must count from right to left , pin n°4 ).
    OF COURSE if you have sd inserted after a while it comes garbage from that pin , but if you boot android you will see every thing till the end.
    This my affermation could and could NOT work on your board and don't ask me why there is a serial output there, but it is, and it is very usefull.

    Would you upload photos of your board somewhere, please?

    Ty

  • Thanks for the tip Fabio.

    Yes, I am booting LE from microsd and yes, android boots fine, indeed when I put the sd card with my built, not functional, release, it shows a black screen and then boots to android.


    Unfortunately I have no usb/ttl cable under hand at the moment, but it is a very useful info.

    My board picture are here: [SOLVED] Help to identify firmware for MK809IV TV stick with RTL8723bs WiFi - FreakTab


    Grazie! G.

  • Mine are not assumptions but facts:

    Out of being polemic, those are opinions or mostly "good practices", depending from the point of view. Anyone is free to follow or not to follow them, take or leave it. And also debating on this does not move your issue forward nor backward.

    I also know only author or close supporters can answer this.

    Good luck with the "close supporters" then :rolleyes:

  • goolpone

    prego, you are welcome. It is a stick dongle and I remember uart pins should be exposed there.
    Any way UNFORTUNATELY for all of us enthusiastic people of these boards is veryyyy difficult debug without a uart because the steps involved in booting are a big chain and error is around the corner ( idbloader, trust_os, uboot )
    So it worths have a usb/ttl on the desk :-)

  • i got an mxq pro 4k 5g R3228a ddr3 1 gb ram damage emmc, board 329q_v 8.1 i tried all the image avaible to boot from sd, i only get blue led bright but no hdmi signal, tried multitool but same result, bright blue led blinking but no hdmi signal

  • knaerzche - Could you enable NVMe support in the linux kernel? I already did the change locally (for the HEAD in LibreELEC) and it works fine (RockPro64), but I don't know about github pull request and how to get the change online :-( I just copied the NVMe section from the armbian config over to the latest in LibreELEC.