Can this patch please be applied? Current Sumo is broken without it. Thanks a lot, Bas.

For the meta-freescale sumo branch, change the branch of openembedded-core this layer depends on. Signed-off-by: Bas Mevissen <abuse@...> --- README | 2 +- 1 file changed, 1 insertion(+), 1

Hi Stefano, (please do not top post, reordered your response) See https://github.com/Freescale/meta-freescale/blob/master/README for some guidelines. I'm not a maintainer, so I cannot commit to meta-f

Good spot. This one is in already since October. Quite surprising that no one reported it before. Fix is trivial. Bas.

Thanks, works fine now. -- Bas. Tested-by: Bas Mevissen <abuse@...>

Hi Otavio, I noticed the Sumo branch is there, thanks for that. As you have seen, I already started using it to get the bugs out of it. Maybe it is good to announce it, so people start testing with it

Hi all, I'm currently using a very small Yocto build using only Poky and Meta-Freescale, both on current Sumo branch and ran into a build problem: ERROR: No recipes available for: /home/bas/Workspace/

Agreed, i.MX28 should work and Qt should at least function (even if not accelerated) before a sumo release can be made. In that case, I agree that i.mx8 support should wait for the next release. Waiti

Hi Otavio, Could you kindly provide us with a status update on this? I noticed no build errors on a build with current head of meta-freescale master branch with head of Poky Sumo branch: Is currently

This shows the Karo u-boot is configured to start /linuxrc: (...) default_bootargs=setenv bootargs init=/linuxrc console=ttymxc0,115200 ro debug panic=1 ${append_bootargs} (...) Solution 1 is to creat

Hi Andreas, I’m not sure whether the rtc driver in the Linux 3.14 kernel already supports device tree. You need to check that. For the device tree, you need to add something like: &i2c1 { clock-freque

(...) Current (2017-11-27) Linux-next boots fine. So no SPI issues on my i.MX6 board for this kernel version. -- Bas.

This is what Otavio kindly pushed in a4f7f0ac8250ff10d6111df25e7d940a2f36801a and I can confirm it works on my board (i.MX6 dual). Yes, will do that later this week. Thanks for your help, Cheers, Bas.

Thanks a lot! I can confirm it works like a charm. Cheers, Bas.

I tried linux-fslc@c4404197b0b22f479d9548e81a8a4ed639d4dd7c with commit 3e9b36edc01ec3b896bf212a2a7cccc32ed3f047 reverted and that works fine. What's the best thing to do now? Revert 3e9b36e for now a

No problem to try it, but it looks like this is a patch to be for the case one has *no* cs-gpios defined, while I *do* have them. -- Bas.

No problem, just wanted to be sure that I can rely on a pick I make myself or that we can have some way of making a choice that will stay available. This looks like an answer to my other question abou

That one looked innocent to me, but it is indeed the only change in spi-imx.c between the two commits I mentioned. It feels quite odd that no one would have noticed the regression in a month time. Jus

I also made a pick at some point (commit bed180659337fc7f7df86dd9dc146516abcee108, somewhere in 4.14 rc5 - rc6 space) that got deleted. What is the best strategy when one wants to use a very recent ke

I see a regression in imx SPI with this change: bd340b0f7370015791413ea458c0f56715f17e19: [ 8.610321] spi_imx 200c000.ecspi: registered master spi1 [ 8.626154] spi spi1.0: spi_imx_setup: mode 0, 8 bpw