Looks like a problem at your end. You are building for i.MX7 and not 6? What Poky version are you using? Looks like it is not current (Morty). I just did the following: bitbake gmp -c cleansstate bitb

Will this be merged to Morty as well? This seems fine for Morty as well. This is a good idea, however it will break custom DTS files which I think is not acceptable in a stable branch. A solution for

Great. True, but it might a bit harsh. Luckily it is documented now :-) (having said that, my current development is following morty blindly and I haven't had anything broken yet) Regards, Bas.

This reminds me of an issue I ran into with the same package. It failed with QA issues: ERROR: imx-uuc-0.5.1+gitAUTOINC+3440b11083-r1 do_package_qa: QA Issue: No GNU_HASH in the elf binary: '/work/bui

On 10/04/2017 13:05, Esponde, Joel wrote: (...) >> This reminds me of an issue I ran into with the same package. It failed with >> QA issues: >> >> ERROR: imx-uuc-0.5.1+gitAUTOINC+3440b11083-r1 do_pac

Bas Mevissen First make sure the actual hardware is there, as these boards come without the nand populated. Bas.

github and neither one had this fix. (I tried, master, morty and pyro branches). Has it been committed yet or is this needed to be done manually? (please don't top-post, fixed it for you) I never got

I basically agree, however the patch itself was ready and good to go. Requiring people to use stuff like git format-patch and git send-email is the actual shame. Figuring out how these things work, se

On 30/08/17 21:40, Otavio Salvador wrote: Hi Otavio, Teemu, > I did the update and merged the fix on master branch. Teemu please > give it a go and let me know if it works fine to you so we can > back

I can confirm git.freescale.com is slow. This might easily lead to timeouts. git clone git://git.freescale.com/imx/linux-imx.git Cloning into 'linux-imx'... eatremote: Counting objects: 3791253 remote

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

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

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

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

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.

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

Thanks a lot! I can confirm it works like a charm. Cheers, 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.

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