When TORADEX plans to release Poky-Pyro (poky-2.3) YOCTO Project for Colibri iMX6?

Technical Support
, , , ,
1

Taking YOCTO from the scratch I was able to build the complete YOCTO Project (from the Source Code), which I downloaded from here: High performance, low power Embedded Computing Systems | Toradex Developer Center

There were around 5 to 10 bugs/errors breaking YOCTO build (host machine INTEL i5 HP notebook, on bare metal Fedora 26 x86_64 installed) , but I was able to prevail all of these myself, and to install all of this mess to the SD Card (USB stick for some reason did not work from the U-Boot). The pointers I use are here: Flashing Embedded Linux to iMX6 Modules

I was able to make http://docs.toradex.com/102284-colibri-evaluation-board-datasheet.pdf all this to work with LXDE DT using X11/Xorg Xwindows, and Xorg Server. Home alone.

I have problems with half DVI (digital display I/F), but at this point of time it is not too important (I have analog VGA working with 19" monitor). I think I need more to tighten flat cable going from comm express to the development board!

Now… I need Pyro 2.3 (and much higher kernel that 4.1.x → maybe 4.10.y). Do you have any experimental YOCTO repo I can download and start experimenting for TORADEX Colibri iMX6 with development board V3.2B?

Thank you,
nobody

2

Hi

Now… I need Pyro 2.3

Current plan is to skip Pyro and directly move to the upcoming Rocko release. This may or may not be part of the 2017 Q4 release.

and much higher kernel that 4.1.x → maybe 4.10.y

The Colibri iMX6 is in mainline, device-tree and generic config.

Do you have any experimental YOCTO repo I can download and start experimenting for TORADEX Colibri iMX6 with development board V3.2B?

Unfortunately not.

Max

3

Hello Max,

Current plan is to skip Pyro and directly move to the upcoming Rocko release. This may or may not be
part of the 2017 Q4 release.

Did not understand entirely. You meant, it will be not part of TORADEX release?! If not (and TORADEX does not plan for Pyro), what TORADEX actually will release as 2017 Q4??

The Colibri iMX6 is in mainline, device-tree and generic config.

Good. Now, since TORADEX has recipes for that, why TORADEX does not build directly from mainline?? I can guess the answer, kernel I/Fs & APIs (mainline ones) are not compatible anymore with the rest of Morty, which is frozen in Time. My best guess is that TORADEX needs exactly to follow YOCTO Releases (every 6 months) and also to release its own release upon YOCTO Project’s new release.

I need at minimum Pyro (Poky 3.2.1), since I would like to use DNF packager. But since it is paired with RPM 4.x release, I’m not willing to back port many patches into Morty (to get rid of RPM 5.x) to make DNF work. I’ll wait for Rocko release, since DNF falls into long term YOCTO’s package strategy (and use smartpm in Morty if required), but I think it is unacceptable to have Morty for more that a year, as TORADEX latest YOCTO release. Don’t you agree, Max?!

Thank you,
nobody

4

Hi

Did not understand entirely. You meant, it will be not part of TORADEX release?! If not (and TORADEX does not plan for Pyro), what TORADEX actually will release as 2017 Q4??

Rocko is the release due in fall, so if we move away from morty with the 2017 Q4 release we aim to directly use Rocko.

Good. Now, since TORADEX has recipes for that, why TORADEX does not build directly from mainline??

Because we think the downstream SoC Vendor’s Linux versions offer better stability and usage of the SoC features the vendor tree is preferable for a general use case. If your use case contradicts that feel free to move to mainline.

I can guess the answer, kernel I/Fs & APIs (mainline ones) are not compatible anymore with the rest of Morty, which is frozen in Time.

There is no reason why you shouldn’t be able to run a morty rootfs with a mainline kernel.
If you want to use the Vivante binary user space drivers you would need to build the Vivante kernel driver as a module against your kernel sources in the same way it is built currently against the downstream kernel.
Note that Morty is still actively maintained.

My best guess is that TORADEX needs exactly to follow YOCTO Releases (every 6 months) and also to release its own release upon YOCTO Project’s new release.

Actually we don’t. Its up to us how close we want to follow the Yocto releases.
In fact many customers do not like us to change the baseline they are building on too often, they want to develop and sell products, not trying to keep up with our constant change.

I need at minimum …

We are aware that for each customer there is at least one ‘I need at minimum …’ which unfortunately is different each time.

but I think it is unacceptable to have Morty for more that a year, as TORADEX latest YOCTO release. Don’t you agree, Max?!

Your requirements and need for latest and greatest are noted, however as explained above I don’t agree.

Note that with meta-freescale and meta-freescale-3rdparty you have all that is needed to build a Poky image for a Colibri iMX6 on pyro.

Max

5

@max.tx Thanks for the explanation.
Additional question: Have you already started adjustments to Rocko?
Can I use yocto and toradex master branches now and hope that they will eventually become Rocko release?

6

Thanks for the explanation.

You are very welcome.

Additional question: Have you already started adjustments to Rocko?

Yes, but we do not plan to release any of this before earliest end of Q4 2017. Of course rocko-next branches may appear earlier but any of this is WIP and not really supported.

Can I use yocto and toradex master branches now and hope that they will eventually become Rocko release?

No, sorry we do not maintain master branches in that sense resp. they just point to morty currently.

My general advice is if you are inpatient and know what you are doing please do use upstream at your own discretion. However if relying on our fully integrated, validated & verified and therefore supported downstream BSPs mixing and matching them with any later upstream is usually a bad idea.

7

Thanks. Then I’ll stick to morty and do the update beginning next year.