Jump to content


Photo

OpenEmbedded toolchain for OpenPLi7 3.x kernels


  • Please log in to reply
53 replies to this topic

Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #41 Erik Slagter

  • PLi® Core member
  • 45,263 posts

+497
Excellent

Posted 22 December 2018 - 09:43

We currently have an issue with a bad interaction between a BSP "feature" from one vendor and the rest of OE, which causes many builds to fail. It seems we have the workaround for it now, but I am not 100% sure yet. If we fail here, I'll request help from you, ok?


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.

Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #42 athoik

  • PLi® Core member
  • 7,867 posts

+291
Excellent

Posted 22 December 2018 - 10:01

The real problem that we are having, is duet to the way we build images with shared libc headers.

We choose to use "shared feeds" and common libc headers for all.

So we do not build different mipsel feeds, different arm-cortexa feeds etc.

Having per vendor feeds or per machine feeds would require much much more bandwidth and build time.

Edited by athoik, 22 December 2018 - 10:01.

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #43 Erik Slagter

  • PLi® Core member
  • 45,263 posts

+497
Excellent

Posted 22 December 2018 - 10:13

I guess some of our collegues do it that way. I see it as a blunt workaround for the stupid errors vendors make in their BSP's every now and then. Until now we've managed to sort it all out, which, imho, is preferrable, but takes quite a bit of time and effort.

 

And that's where, in the end, the effort goes into, instead of always having master/HEAD of OE.

 

There is no option to have an arch/group for every vendor, just arch and machine, so if one would choose to switch, every machine would have it's own feeds including glibc. For about 70 machines, that's huge and also a nightmare to build.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.

Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #44 A.A.

  • Senior Member
  • 51 posts

0
Neutral

Posted 22 December 2018 - 11:53

I see,

 

can you point me to the toxic layer/recipe?

 

A.A.



Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #45 Erik Slagter

  • PLi® Core member
  • 45,263 posts

+497
Excellent

Posted 22 December 2018 - 12:58

Let's wait a while, it may have been solved now. We need a couple of build runs to be sure that it's really solved now.

 

It has to do with one vendor supplying it's own (newer) glibc (precompiled, from sumo) for some binaries for some of their machines. Now bitbake will see in this package a provides for glibc and in some cases it will use it for dependency linking, also on other models, even from other vendors. Now we have several packages in the feed, for machines that happen to have the same arch, that have a dependency on this vendor's "special glibc", which is of course wrong.

 

My proposed solution is to have the vendor add a "COMPATIBLE_MACHINE" line in that package that specifies the two machines where this package is required. We're testing this now and seems to work. Fingers crossed.

 

It's a nice example of our challenges, vendors tend to test their changes in a limited environment that only contains their own machines.


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.

Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #46 WanWizard

  • Forum Moderator
    PLi® Core member
  • 47,485 posts

+793
Excellent

Posted 22 December 2018 - 17:03

My proposed solution is to have the vendor add a "COMPATIBLE_MACHINE" line in that package that specifies the two machines where this package is required. We're testing this now and seems to work. Fingers crossed.

 

p.s. I have reverted the change we made in the develop BSP to test this, we can't keep building with a locally changed BSP.


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2), SAB Alpha Triple HD (S2+T2), Zgemma H3.T2C (T/C), Zgemma H6 (fallback), VU+Zero (fallback)

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

note: I do not provide support via PM !

 


Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #47 A.A.

  • Senior Member
  • 51 posts

0
Neutral

Posted 23 December 2018 - 00:43

Well, back on topic, the culprit of the failing build with musl is  linux-3.13-gcc-4.9.3-build-error-fixed.patch

It did not consider musl, I did fix it this way but probably the check about version must be removed alltogether.

 

GCC_VERSION = $(shell $(CC) --version | grep -e ^mipsel-oe-linux-gcc -e ^mipsel-oe-linux-musl-gcc | sed ...etc etc

 

I will fork and update the patches.

Cheers

A.A.



Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #48 Erik Slagter

  • PLi® Core member
  • 45,263 posts

+497
Excellent

Posted 23 December 2018 - 09:54

What is musl?


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.

Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #49 Erik Slagter

  • PLi® Core member
  • 45,263 posts

+497
Excellent

Posted 23 December 2018 - 09:54

 

My proposed solution is to have the vendor add a "COMPATIBLE_MACHINE" line in that package that specifies the two machines where this package is required. We're testing this now and seems to work. Fingers crossed.

p.s. I have reverted the change we made in the develop BSP to test this, we can't keep building with a locally changed BSP.

Is there alreay a PR out?


* Wavefrontier T90 with 28E/23E/19E/13E/9E/4.8E/0.8W/5W via SCR switches 2 x 2 x 6 user bands
* Ziggo digital cable TV (FTA)
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.

Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #50 WanWizard

  • Forum Moderator
    PLi® Core member
  • 47,485 posts

+793
Excellent

Posted 23 December 2018 - 12:49

What is musl?

 

musl provides a libc alternative.


Currently in use: VU+Duo 4K (2xFBC S2), Amiko Viper T2C (T2), SAB Alpha Triple HD (S2+T2), Zgemma H3.T2C (T/C), Zgemma H6 (fallback), VU+Zero (fallback)

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

note: I do not provide support via PM !

 


Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #51 ghuss

  • Senior Member
  • 33 posts

0
Neutral

Posted 23 December 2018 - 22:38

Thanks for Openpli 7 on Vu+ Dou working very well

 

 

User interface is missing "enable volume control with arrow buttons"


Edited by ghuss, 23 December 2018 - 22:39.

Vu+ Duo 2 


Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #52 ghuss

  • Senior Member
  • 33 posts

0
Neutral

Posted 23 December 2018 - 22:41

Thanks for Openpli 7 on Vu+ Dou working very well

 

Customize is missing "disable background scanning" openpli 7


Vu+ Duo 2 


Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #53 ghuss

  • Senior Member
  • 33 posts

0
Neutral

Posted 23 December 2018 - 22:58

Thanks for Openpli 7 on Vu+ Dou working very well

 

Customize is missing "disable background scanning" openpli 7

Sloved by using expert mode


Vu+ Duo 2 


Re: OpenEmbedded toolchain for OpenPLi7 3.x kernels #54 ghuss

  • Senior Member
  • 33 posts

0
Neutral

Posted 23 December 2018 - 23:00

Thanks for Openpli 7 on Vu+ Dou working very well

 

 

User interface is missing "enable volume control with arrow buttons"

Sloved by using expert mode


Vu+ Duo 2 





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users