Jump to content


Photo

devel: kodi_18 vs mipsel


  • This topic is locked This topic is locked
126 replies to this topic

Re: devel: kodi_18 vs mipsel #21 WanWizard

  • PLi® Core member
  • 58,429 posts

+1,274
Excellent

Posted 25 April 2021 - 15:10

:thumbs-up:


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2+fallback), Octagon SF8008 (S2+T2), Zgemma H9.2H (T2+fallback)

Many answers to your question can be found in our new and improved wiki.

Because to health reasons, I will not be active online very often anymore.


Re: devel: kodi_18 vs mipsel #22 Aliraza63

  • PLi® Tester
  • 175 posts

+22
Neutral

Posted 27 April 2021 - 08:54

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 


Vu+Duo2, Vu+Solo4k, VU+Duo4k,Octagon 8008 S2X


Re: devel: kodi_18 vs mipsel #23 A.A.

  • Senior Member
  • 251 posts

+5
Neutral

Posted 27 April 2021 - 10:02

#WanWizard

 

I tried to split kodi_18.inc and create the .bbappend in meta-vuplus but it is impossible...purposedly blocked.

 

https://github.com/v...4b4896eb103c243

 

We have two options imho:

 

1- insist with vuplus and revert that commit.  Need to add layer dependencies as well to the openpli layer in this case.

2 -create a bogus kodi-vuplus_18.bb which includes the main .bb. Ofc layer deps should be added.

 

Any idea?

Cheers

A.A.



Re: devel: kodi_18 vs mipsel #24 A.A.

  • Senior Member
  • 251 posts

+5
Neutral

Posted 27 April 2021 - 10:07

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 

Yes, on vuduo2 the OE-A images provide a running kodi for stb. I did not test sound on it yet.

We are now trying to spot the difference making kodi  crash on OpenPli: we are basically sure it builds correctly.

 

I personally don't know kodi internals, I think it tries to open some connection and fails (SIGBUS).

But which one? Linux input? Sound bus? dvb video sink?Networking? ....

 

WIP

 

A.A.



Re: devel: kodi_18 vs mipsel #25 ntj

  • Senior Member
  • 62 posts

0
Neutral

Posted 27 April 2021 - 10:19

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 

Yes, to answer your question.

 

I have tried Openspa with Kodi 18.9 on both DUO2 (mips) and Ultimo4k. (arm)

Both are working good and with sound.



Re: devel: kodi_18 vs mipsel #26 Aliraza63

  • PLi® Tester
  • 175 posts

+22
Neutral

Posted 27 April 2021 - 11:23

 

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 

Yes, to answer your question.

 

I have tried Openspa with Kodi 18.9 on both DUO2 (mips) and Ultimo4k. (arm)

Both are working good and with sound.

 

 

Thanks for the reply . I have tested now to . yes its working fine in my duo2 and duo4k to


Vu+Duo2, Vu+Solo4k, VU+Duo4k,Octagon 8008 S2X


Re: devel: kodi_18 vs mipsel #27 WanWizard

  • PLi® Core member
  • 58,429 posts

+1,274
Excellent

Posted 27 April 2021 - 11:32

https://github.com/v...4b4896eb103c243

 

We have two options imho:

 

1- insist with vuplus and revert that commit.  Need to add layer dependencies as well to the openpli layer in this case.

2 -create a bogus kodi-vuplus_18.bb which includes the main .bb. Ofc layer deps should be added.

 

What exactly is the issue with this?

 

It only removes bbappend capability from the BSP, which is indeed a good thing, we don't want a BSP appending to recipies outside the BSP.

 

So if kodi for VU+ requires something special, it needs to be addressed in the kodi recipes (there are already exceptions for VU+ present).


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2+fallback), Octagon SF8008 (S2+T2), Zgemma H9.2H (T2+fallback)

Many answers to your question can be found in our new and improved wiki.

Because to health reasons, I will not be active online very often anymore.


Re: devel: kodi_18 vs mipsel #28 A.A.

  • Senior Member
  • 251 posts

+5
Neutral

Posted 27 April 2021 - 12:33

 

https://github.com/v...4b4896eb103c243

 

We have two options imho:

 

1- insist with vuplus and revert that commit.  Need to add layer dependencies as well to the openpli layer in this case.

2 -create a bogus kodi-vuplus_18.bb which includes the main .bb. Ofc layer deps should be added.

 

What exactly is the issue with this?

 

It only removes bbappend capability from the BSP, which is indeed a good thing, we don't want a BSP appending to recipies outside the BSP.

 

So if kodi for VU+ requires something special, it needs to be addressed in the kodi recipes (there are already exceptions for VU+ present).

 

 

 

Nothing really forbids to have .bbappends in the BSP layers...in fact it is the standard in OE/Yocto for the kernels... [1]

 

Anyway the thing is that in an ideal world meta-openpli should not contain machine-specific recipes nor variables with machine-overrides (ie blah_vuduo2).

Ideally it should not even contain a kodi.bb but just a .bbappend pointing to the meta-kodi layer...

 

So that kodi_18.inc should not exist there :)

 

my 2 cents

A.A.

 

 

[1] https://www.yoctopro...html#bsp-layers



Re: devel: kodi_18 vs mipsel #29 WanWizard

  • PLi® Core member
  • 58,429 posts

+1,274
Excellent

Posted 27 April 2021 - 12:36

I know it is not forbidden, the problem is that they may alter recipes from elsewhere. For the rest, I completely agree with you that all hardware linked recipes should be in the BSP.

 

It is different when, like OE-A, one controls everything, and one can setup the correct structure from scratch. With BSP's not being under our control, it is always going to be difficult.


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2+fallback), Octagon SF8008 (S2+T2), Zgemma H9.2H (T2+fallback)

Many answers to your question can be found in our new and improved wiki.

Because to health reasons, I will not be active online very often anymore.


Re: devel: kodi_18 vs mipsel #30 A.A.

  • Senior Member
  • 251 posts

+5
Neutral

Posted 27 April 2021 - 14:23

One more question: the recipe was imported from meta-kodi and we unconditionally inherit systemd.

 

What are the effects? None?

I'd say it should be first checked against DISTRO_FEATURES.

 

A.A.



Re: devel: kodi_18 vs mipsel #31 WanWizard

  • PLi® Core member
  • 58,429 posts

+1,274
Excellent

Posted 27 April 2021 - 14:42

Where is that? I don't think that has any effect if systemd isn't used, a lot of recipe's have systemd support.


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2+fallback), Octagon SF8008 (S2+T2), Zgemma H9.2H (T2+fallback)

Many answers to your question can be found in our new and improved wiki.

Because to health reasons, I will not be active online very often anymore.


Re: devel: kodi_18 vs mipsel #32 A.A.

  • Senior Member
  • 251 posts

+5
Neutral

Posted 27 April 2021 - 14:50

It should not harm.

 

It's here

https://github.com/O.../kodi_18.bb#L14

 

Instead, more relevant is perhaps pulseaudio?

https://github.com/o...kodi_18.bb#L142

 

I don't see special reasons for it but maybe there are...

 

Cheers

A.A.



Re: devel: kodi_18 vs mipsel #33 A.A.

  • Senior Member
  • 251 posts

+5
Neutral

Posted 28 April 2021 - 10:40

While the OE-A image is unbuildable atm (samba) I installed OpenSPA and immediately installed kodi on it.

Here the logs: https://pastebin.com/PxY4yPbq

 

BTW we have different directfb versions

 

WIP

A.A.



Re: devel: kodi_18 vs mipsel #34 WanWizard

  • PLi® Core member
  • 58,429 posts

+1,274
Excellent

Posted 28 April 2021 - 12:32

Your last change produced an error in the nightly builds for all Zgemma ARM models (H7 and up):

2021-04-28 11:05:14 ERROR: kodi-1_18.9+gitrAUTOINC+0655c2c718-r0 do_package_qa: QA Issue: /usr/lib/kodi/kodi-stb contained in package kodi requires libEGL.so, but no providers found in RDEPENDS_kodi? [file-rdeps]
2021-04-28 11:05:14 ERROR: kodi-1_18.9+gitrAUTOINC+0655c2c718-r0 do_package_qa: QA Issue: /usr/lib/kodi/kodi-stb contained in package kodi requires libGLESv2.so, but no providers found in RDEPENDS_kodi? [file-rdeps]
2021-04-28 11:05:14 ERROR: kodi-1_18.9+gitrAUTOINC+0655c2c718-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
2021-04-28 11:05:14 ERROR: Logfile of failure stored in: /openpli/oe/develop/build/tmp/work/h10-oe-linux-gnueabi/kodi/1_18.9+gitrAUTOINC+0655c2c718-r0/temp/log.do_package_qa.27315
2021-04-28 11:05:14 ERROR: Task (/openpli/oe/develop/meta-openpli/recipes-mediacenter/kodi/kodi_18.bb:do_package_qa) failed with exit code '1'

 


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2+fallback), Octagon SF8008 (S2+T2), Zgemma H9.2H (T2+fallback)

Many answers to your question can be found in our new and improved wiki.

Because to health reasons, I will not be active online very often anymore.


Re: devel: kodi_18 vs mipsel #35 A.A.

  • Senior Member
  • 251 posts

+5
Neutral

Posted 28 April 2021 - 12:51

Ah, ok,

 probably they have PRIVATE_LIBS ot there isn't the rprovider.

 

Vuplus seems fixed but if you want we can readd the INSANE_SKIP but limiting it to the affected machines.

Something like INSANE_SKIP_${PN}_Zgemma-model

 

A.A.

 

Edit: it does provide the rdepended libs. No private libs.

https://github.com/z...ddriver.inc#L11

 

zgemma-v3ddriver-h7 should be added to _zgemma-model rdeps of kodi then.


Edited by A.A., 28 April 2021 - 13:00.


Re: devel: kodi_18 vs mipsel #36 WanWizard

  • PLi® Core member
  • 58,429 posts

+1,274
Excellent

Posted 28 April 2021 - 13:00

The machines failing are: h7, h9, h10, h11, h9se, h9combo, h9combose, i55se, i55plus


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2+fallback), Octagon SF8008 (S2+T2), Zgemma H9.2H (T2+fallback)

Many answers to your question can be found in our new and improved wiki.

Because to health reasons, I will not be active online very often anymore.


Re: devel: kodi_18 vs mipsel #37 A.A.

  • Senior Member
  • 251 posts

+5
Neutral

Posted 28 April 2021 - 13:23

h7 -> "zgemma-v3ddriver-${MACHINE}"

h9, h9se, h9combo, h9combose, h10, i55se, i55seplus  -> "zgemma-mali-3798mv200"

h11 -> "zgemma-mali-3798mv310"

 

AFAIS we should add that BSP-derived stuff to kodi_18.inc

 

Cheers

A.A.

 

P.S.

Sorry for the mess, I am building for vuduo2 only atm


Edited by A.A., 28 April 2021 - 13:26.


Re: devel: kodi_18 vs mipsel #38 A.A.

  • Senior Member
  • 251 posts

+5
Neutral

Posted 28 April 2021 - 13:29

I am now wondering..is it better to add virtual/egl to RDEPENDS to catch all these cases?

A.A.



Re: devel: kodi_18 vs mipsel #39 WanWizard

  • PLi® Core member
  • 58,429 posts

+1,274
Excellent

Posted 28 April 2021 - 14:41

I don't know, I'm far from a bitbake expect... :)

 

If you want me to test something, let me know, I have a local build environment for the h9.


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2+fallback), Octagon SF8008 (S2+T2), Zgemma H9.2H (T2+fallback)

Many answers to your question can be found in our new and improved wiki.

Because to health reasons, I will not be active online very often anymore.


Re: devel: kodi_18 vs mipsel #40 A.A.

  • Senior Member
  • 251 posts

+5
Neutral

Posted 28 April 2021 - 15:21

Kodi has virtual/egl in depends and that should be enough for the buildsystem to register [1]

 

The problem seems to be with the recipe dlopen'ing at runtime or with the unversioned shlibs or when libs are declared private_libs: the conclusion is we need libEGL.so and libGLESv2.so

 

 

I think we could add more lines to kodi_18.inc for these Zgemma like:

 

#Zgemma

RDEPENDS_${PN}_append_h7 = " zgemma-v3ddriver-h7"

RDEPENDS_${PN}_append_h9 = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h9se = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h9combo = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h9combose = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h10 = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h11 = " zgemma-mali-3798mv310"

RDEPENDS_${PN}_append_i55se = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_i55seplus = " zgemma-mali-3798mv200"

 

 

Or maybe adding a generic RDEPENDS_${PN}_append = " virtual/egl virtual/libgles2"

This would be one-liner but need some more thoughts...

 

A.A.

 

 

[1] https://www.yoctopro...me-dependencies


Edited by A.A., 28 April 2021 - 15:23.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users