You know you can reduce the memory consumption by: 1) Lowering the number of parallel makes (using PARALLEL_MAKE in local.conf or maybe in a .bbappend for the package) 2) Limit the number of bitbake t

#yocto #kirkstone #meta-freescale #u-boot

That looks OK to me. Please check that the package wireguard-module (in your Yocto build) indeed contains a valid kmod for the kernel you actually run. If so, check that this kmod is on the target for

Good to hear you make progress! I also always use the latest Fedora as my development platform. It usually works without a problem (except for the warning). Only the uninative cannot always keep up wi

You are welcome, however: 1) Start a new topic for a new question 2) Do not top post to keep discussion threads readable I'm not a specialist, but I think I can answer your questions. IMHO, community

Sorry, got the name wrong. That is how it is called in OpenWRT. :-) What you need is "wireguard-module" and you can add it to IMAGE_INSTALL_append like wireguard-tools. Bas.

Aren't you missing the kmod-wireguard package in your image?

Ok, I missed that obviously. It is actually that interaction between the community and NXP that has brought i.MX support at the level it has. So if a performance problem might pop up, it is that same

Ah yes, I see. Linux-fslc is now really up to date with kernel.org. I recall (from 2017 era) that that was different. Maybe I'm wrong about that. Yes, thanks for the explanation. Bas.

At least you get an idea of what the HW platform can do. IMHO, you should never base your *product* on FSL. It is (at least, that is what was told me by (then) Freescale field engineers) only there to

Wouldn't make sense to first evaluate the performance of the platform (as Terry plans to do) first on an NXP fsl-* distro? In that case one can get direct support from NXP if required. After that, der

Your problem is that you are using an old version of Yocto (most likely an early Krogoth version) and things have moved on. Including file locations and possibly contents, as you had before with the g

#define #yocto #compilation #meta-freescale

Your problem is most likely with the host system being too new. What do you use to build on?

Additional: If it does not work, try doing the repo stuff in a container with a different Linux version. Or try a different internet connection. The Angstrom manifest README.md mentions the issue as w

This can be safely ignored. (Google it for explanation) Here something happened, possibly with your internet connection. Again. Flaky connection? The obvious result of the errors above. Quickest seems

No, looks fine. Just tip of Warrior branch. That one seems to be targeted by NXP at supporting the i.MX8 series (only). Maybe Otavio can shed some light on what best to use. The most recent FSL Commun

Ah, I assumed the default to be at the 4.9-2.3.x-imx branch. That one is based upon 4.9.166, which is much more close to the latest upstream. A recent kernel from a longterm branch is probable the bes

You need to specify KERNEL_DEVICETREE=imx6qp-sabresd.dts in your local.conf The reason is that the default DTS file (imx6qp-sabresd-btwifi.dts in this case) is not available in the kernel version you

Repo, git submodules or something like kas is a matter of taste and preference. Biggest advantage of repo is that a single small XML file can define a complete build or set of builds. Submodules are s

On 2018-06-19 10:16, Mauro Ziliani wrote: Please don't top post. I reordered the message to keep it readable. > > > Il 18/06/2018 17:07, Bas Mevissen ha scritto: >> On 2018-06-18 14:41, Mauro Ziliani

Not specifically this one, but on an RTL8812AU based wifi dongle on the same kernel for i.mx 6sx. That went pretty well. What is your problem? It is used a lot in the rPi world. BR, Bas.