53 replies to this topic

[A.A.]

About moving to Thud, I forgot to post this not-so-well-known link:

 

https://wiki.yoctopr...eMigrationGuide

 

Cheers

A.A.

[Erik Slagter]

I am not going to rush into Thud now. That will be the next project. My experience is that many BSP will need adjustments, we have to make PR's for all of these and make sure they're applied. Then most of the time all HbbTV and Kodi "solutions" break and also need to be fixed or even worse, worked around. There is a reason why we are slow to follow up on OE versions.

 

But thanks for the tips, I will come back here somewhere in 2019.

Edited by Erik Slagter, 14 December 2018 - 20:23.

[A.A.]

I understand you're afraid about moving to the next Yocto release.

 

Just remember the move from sumo to thud is way less painful fo the BSP's.

I do maintain BSP and middleware layers and really there are just minor adjustements to do.

 

Nothing compared to the pre recipe-specific-sysroot state you had not long ago.

 

IMHO you should have a -dev branch tied to OE master: just my 2 cents.

Keep up the good work!

 

Cheers

A.A.

[Erik Slagter]

Our last "migration" has been from Pyro to Sumo and it has been quite some work to get it successfully building. I am not even sure everything actually runs.

 

I don't see a need at all to be trying to get close to OE head, but I will try to get a migrational branch to the newest OE stable once Sumo has been merged.

 

Don't forget 99.9% of the users only use enigma on the receiver, so they really won't see the difference.

 

Actually I'd rather spend some time migrating the whole stuff to systemd. Are you familiar with doing that? It seems some kernel confs are required (PR's....) and some OE configs that I don't have completely clear.

[A.A.]

I'ts absolutely reasonable now that you are at RC stage.

 

About kernels, first I'd like to ask you why are there so many recipes for kernels which are not updated anymore (almost).

I would reorder i.e. meta-vuplus differently, a recipe for each kernel version,  but maybe the point of this is to have atomic updates, like updating a single machine withouth bumping PR.

 

Oh, about kernel machine PR's...I think it is long deprecated. Maybe needed for packaging and updating the kernel in the feeds?

I simply don't use it...

 

About systemd I have to confess I still use sysvinit but the switch is easy enough. Afair some kernel configs are requred but it is more or less like for udev (CGROUPS etc   https://github.com/s...b/master/README ).

FWIW the qemu images built with OE/Yocto did run flawlessy with both init managers, same kernel.

 

I try to rework just the 3.13.5 to show you what I mean.

Cheers

Andrea

 

P.S.

I am still wondering about the kernel build-failure using musl toolchain: it is just crazy!

Chat with kernel guru:

 

Me: so CC=mipsel-oe-linux-gcc  is good  but CC=mipsel-oe-linux-musl-gcc is bad

"...

I think it's a combination of two things:
 1) the two toolchains default to different MIPS CPU types, besides using different C libraries

 2) arch/mips/Makefile does not always override the CPU type the same way we do on arch/arm/

 

Me: I just change TC_LIBC variable then I'd say the latter

 

I meant it has to be both

however you should be able to fix it by changing either one, so a kernel patch to fix the mips Makefile by itself would be sufficien

 

from a quick look at arch/mips/Makefile, I see that it adds -march=... arguments to the 'cflags' variable, which is what we pass to gcc for .c files, but I don't see the same getting passed for .S files, which would explain the error.

...

as I said, no idea why it would depend on the libc you use, but it explains why you get that error when you use an unmatched gcc configuration

i.e. a gcc targetting a CPU that lacks instructions from the .S file

assuming this is a BMIPS based CPU, the kernel passes "cflags-$(CONFIG_CPU_BMIPS)      += -march=mips32 -Wa,-mips32 -Wa,--trap"

but the assembler complains that it's targetting mips3, so that option did not reach it

...

 

this is what we do on ARM for it:
arch/arm/Makefile:KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float

...

Edited by A.A., 15 December 2018 - 14:25.

[WanWizard]

BSP's are not maintained by us, but by the manufacturer. And (as you correctly mentioned), not a lot of them are very knowledgable when it comes to OE and bitbake...

 

We've contemplated doing it ourselfs so it can be setup a lot better, but we don't have the resources for it, maintaining all BSP's can easily become someone's day job...

[Erik Slagter]

BSP's are not maintained by us, but by the manufacturer. And (as you correctly mentioned), not a lot of them are very knowledgable when it comes to OE and bitbake...

 

We've contemplated doing it ourselfs so it can be setup a lot better, but we don't have the resources for it, maintaining all BSP's can easily become someone's day job...

I cannot stress this enough.

 

The problem with maintaining the BSP yourselves is that you will never have the required inside low level technical information to do it right. The BSP is not only a kernel (that one is trivial).

[babsy98]

all kernel build fixed to build with gcc 8.20 allready  take a look  :here: https://github.com/o...4.3/meta-brands

[dax]

IMHO you should have a -dev branch tied to OE master: just my 2 cents.

Keep up the good work!

When I asked a similar question I was crucified

[WanWizard]

That was your perception.

 

And I think Erik has already explained why we don't, and why we think it is not very useful.

[A.A.]

WanWizard, Erik,

 

You are probably right, from the point of view of Distro-Maintainer a moving branch is only dangerous.

But I don't ask you to develop on it, just to build it now and then to see what's behind the corner in OE realm.

 

I give you a fresh example: yesterday gcc7.3 was removed from master and gcc9 appeared.

Another one: yesterday the glibc-2.29 branch was pinned (I have already tested on mipsel, is ol).

 

So I imagine the next release will be gcc8 and glibc-2.29.

How this can impact the build of meta-openpli it's beyond me atm but I am positive thinking there are just minor issues.

 

Finally, I got the impression that most of your development has nothing to do with OpenEmbedded, is mostly enigma2 and vendor stuff, so it is legit to just choose a stable toolchain.

 

Cheers

A.A.

[WanWizard]

Those things make it even more complex, given the different images we make and the different requirements their underlying OE has. For example, OpenPLi 4 runs on Morty and I still build that with gcc 4.9. Not to mention the misery that currently exists with the native versions of glibc, that still needs te be addressed (current develop doesn't build on Ubuntu 18-04 due to the fact it uses glibc 2.27). And we now have one meta-layer that requires 2.27 but can't switch because of the same reason (but the other way around).

 

I've been working with CentOS in combination with devtoolsets, and that seems promising, as I can use choose gcc 4 to 7 on a single build server, per build run. I've seen gcc 8 is available as a devtoolset, but only just, I don't see gcc 9 being made available any time soon...

 

I think this is more for Erik, I'm the ghost of Christmas past and Christmas present, he's more the ghost of Christmas future...

[dax]

@A.A.:Why you don' t collaborate with the team in order to have a branch tied to oe-master?

[Erik Slagter]

Thanks for the offer, but no.

 

On one hand, what do we have to gain by always using the very latest version of OE? Only problems and vendors to contact, having their BSP's fixed, again and again, while many vendor are very reluctant to do that.

On the other hand, it only gives me yet more to do, while we're already seriously understaffed. It's not that we're bored from having nothing to do.

 

So what do you think I'll chose?

[Erik Slagter]

I'd rather have some helping hand fixing existing issues...

Edited by Erik Slagter, 19 December 2018 - 21:04.

[WanWizard]

I'd rather have some helping hand fixing existing issues...

 

Yes please, I wouldn't mind a bit of life back...

[A.A.]

Surely I'll help you where I can but don't expect too much...I am developer for hobby in the spare time.

 

I started as OE maintainer but once kernel developers disappeared I had somehow to replace them.

What I do is to build OE regularly for a few legacy devices trying to help upstream with kernel fixes.

I almost have all arm-based toys (64MiB RAM) but a couple of devices are mips, one is vuduo2.

 

Where I mostly spend my time is with K.K.K. (kernel, klibc, kexec/kexecboot) and I am really new in the stb/dtb world.

Unfortunately my python-foo is very low so I can just report bugs wrt enigma2.

 

About kernels I am playing a bit with a linux-vuplus-kexecboot but as always with mips there are issues matching old kernels with the right kexec version.

I have just sent the necessary fixes to OpenEmbedded to build the stuff and now I am researching a bit about CFE, upstream generic bmips 4.20 kernel, devicetrees provided by bcm.

Hopefully there are less issues with arm-based devices.

 

At the moment I am borrowing LEDE fixes for the ancient kernels.

I'll let you know.

 

Cheers

A.A.

[Erik Slagter]

How about the blind helping the deaf here? Because we're in a similar position.

[A.A.]

How about the blind helping the deaf here? Because we're in a similar position.

Heh, you got  me.

 

I will follow the forums, afaik there aren't mailing lists or irc channels.

As for OE build problems I can surely help.

I do speak some ancient C as well

 

Cheers

A.A.

[WanWizard]

I will follow the forums, afaik there aren't mailing lists or irc channels.

 

We're in the planning of moving from Atlassian Stride to something else (looking at Mattermost atm), I'm sure we can accomodate a channel for this.