AOSP -- Rockchip 3399
#1
First of all, I do NOT expect anyone to offer to fix this, since it really can't be fixed on the Kodi side. Rather, I'd like to share knowledge that I've obtained in investigating a failure.


For the last several days, I've been trying to get Kodi running on a 96boards Rock960, which has an rk3399 SoC and is running on Android 9. This board is very closely related to another board called RockPi 4, so everything here applies to that board as well, among probably others as well.

The symptom I was seeing (yes, WAS), is EGL_BAD_ACCESS, immediately upon launching the application. There are more details to the crash, but given how things panned out, it isn't important to go into detail on that aspect.

Fairly quickly, I discovered that some Kodi forks were working on it (that is, they started up, loaded the UI, and appear to be entirely functional). In particular, SPMC (both 16 and 17), as well as another fork, which is unmentionable due to its content. I only used it to see if it would actually start, and it did.

So I bisected SPMC17 until I found the commit that "fixed" it. It turned out to be nothing more than a re-branding commit.
https://github.com/koying/SPMC/commit/74...911d696005

After grepping through the entire AOSP tree and all the binaries used to run the board, I found the string "org.xbmc.kodi" in the binary only Mali EGL driver version r18p0.

I'll take the approach of Hanlon's razer and assume that they were trying to do something useful, and broke it by accident, rather than implementing this to intentionally cripple it.
And I don't know if the responsible party is ARM or Rockchip.

The point is that it can be made to work with nothing more than a change to the package name to anything but "org.xbmc.kodi".

I find it somewhat disturbing to find that they've put some kind of a hack into the binary driver referring specifically to something they don't own. One would expect that a more appropriate way to implement a hack like this would be on a system property or config file, or in the very least, by communicating with the entity who owns the subject software.

Anybody have any idea what can be done besides rebuilding with a different package name? Is that a fair use of the kodi trademark, or something the lawyers should be thrown at?


And for what its worth, it looks like Rockchip has the video decode acceleration implemented correctly now. 10 bit 1080p HEVC is decoded in hardware now, sans rockchip hacks.
Reply
#2
Can't find an edit button, so I'll append this;

The binary driver in question can be found here:
https://gitlab.com/rk-vendor/rk/platform...u/MaliT860
Reply
#3
New forum users have limited capabilities in the beginning. This will change over time when your post count goes up.
Got a Kodi problem? Provide a full Debug log (wiki) | Usefull pages: First time user (wiki) | Troubleshooting (wiki) | Free content (wiki) | Forum rules (wiki) | VPN policy (wiki)
Reply
#4
(2019-06-27, 20:41)lbdroid Wrote: Fairly quickly, I discovered that some Kodi forks were working on it (that is, they started up, loaded the UI, and appear to be entirely functional). In particular, SPMC (both 16 and 17), as well as another fork, which is unmentionable due to its content. I only used it to see if it would actually start, and it did.

You will likely find these Kodi package renamed Kodi Leia / Master will likely work as well:

https://app.box.com/v/kodi4sonytv

Reply
#5
(2019-06-28, 06:19)wrxtasy Wrote:
(2019-06-27, 20:41)lbdroid Wrote: Fairly quickly, I discovered that some Kodi forks were working on it (that is, they started up, loaded the UI, and appear to be entirely functional). In particular, SPMC (both 16 and 17), as well as another fork, which is unmentionable due to its content. I only used it to see if it would actually start, and it did.

You will likely find these Kodi package renamed Kodi Leia / Master will likely work as well:

https://app.box.com/v/kodi4sonytv 

Thanks, but I'm well beyond looking for renamed packages.
Further, as of this morning, Rockchip has already issued new EGL binaries as a response to this specific issue:
https://mega.nz/#!JdlWnSCL!n1KkUbs_TJ6Ly...BmCgapjfkc
The hack is still there, but they fixed the hack so it doesn't crash out.
The turnaround was under 12 hours. Imagine any western tech company responding that quickly.
I guess Rockchip must be really hungry.
Reply
#6
(2019-06-28, 13:59)lbdroid Wrote:
(2019-06-28, 06:19)wrxtasy Wrote:
(2019-06-27, 20:41)lbdroid Wrote: Fairly quickly, I discovered that some Kodi forks were working on it (that is, they started up, loaded the UI, and appear to be entirely functional). In particular, SPMC (both 16 and 17), as well as another fork, which is unmentionable due to its content. I only used it to see if it would actually start, and it did.

You will likely find these Kodi package renamed Kodi Leia / Master will likely work as well:

https://app.box.com/v/kodi4sonytv   

Thanks, but I'm well beyond looking for renamed packages.
Further, as of this morning, Rockchip has already issued new EGL binaries as a response to this specific issue:
https://mega.nz/#!JdlWnSCL!n1KkUbs_TJ6Ly...BmCgapjfkc
The hack is still there, but they fixed the hack so it doesn't crash out.
The turnaround was under 12 hours. Imagine any western tech company responding that quickly.
I guess Rockchip must be really hungry.  

Thanks lbdroid. Your investigation will likely be useful in investigating why our RK3399 board is also having the same EGL_BAD_ACCESS issue.

Where did your fixed binary come from? It does not appear that rockchip has committed to the gitlab repo you originally linked.
Reply
#7
(2019-07-04, 16:08)tepgarrison Wrote:
(2019-06-28, 13:59)lbdroid Wrote:
(2019-06-28, 06:19)wrxtasy Wrote: You will likely find these Kodi package renamed Kodi Leia / Master will likely work as well:

https://app.box.com/v/kodi4sonytv   

Thanks, but I'm well beyond looking for renamed packages.
Further, as of this morning, Rockchip has already issued new EGL binaries as a response to this specific issue:
https://mega.nz/#!JdlWnSCL!n1KkUbs_TJ6Ly...BmCgapjfkc
The hack is still there, but they fixed the hack so it doesn't crash out.
The turnaround was under 12 hours. Imagine any western tech company responding that quickly.
I guess Rockchip must be really hungry.   

Thanks lbdroid. Your investigation will likely be useful in investigating why our RK3399 board is also having the same EGL_BAD_ACCESS issue.

Where did your fixed binary come from? It does not appear that rockchip has committed to the gitlab repo you originally linked. 

Another person apparently got in touch with someone from rockchip, who gave him the link to that binary.
Reply



Logout Mark Read Team Forum Stats Members Help
AOSP -- Rockchip 33990
This forum uses Lukasz Tkacz MyBB addons.