[OpenWrt-Devel] Howto/advice: Patch for variant of hardware platform?

Mon Feb 27 12:32:29 EST 2017

> On Wed, Feb 22, 2017 at 8:57 PM, Dana Myers <k6jq at comcast.net <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote:
>
> >/On 2/22/2017 6:18 PM, L. D. Pinney wrote: />//>//>/spi-mt7621.c has bugs ... isn't very helpful. />//>//>/I am a bit surprised you're not already aware of the SPI issues. />//>//I am not surprised at all ... ALL of my MT76x8 devices have only a single
> SPI-NOR Chip connected to the SPI.
> On every device it works as intended ... load the OS.

Of course - that's surely why this hardware bug in the MediaTek SPI peripheral
escaped from the factory; they implement and document functionality (full-duplex
operation), and either didn't test it or didn't regard the bug as critical. The
critical use-case of the SPI port is to read the flash device, which is half-duplex,
but that's not the only documented use of the SPI port.

MediaTek documents the SPI port as a general peripheral (and provides
an additional select line), and there's a bug in the hardware.
> Whenever you (or anyone) adds functionality to a device you can expect
> problems.
Thanks, though this isn't relevant at all. I'm not *adding* functionality to the device.
There's a bug in the SPI controller that's exposed when you try to use it as documented.

> In this case some device foreign to the actual device in question.
> More specifically a device such as a RFID module or STM32.
This isn't the case at all. There's a bug in the MediaTek SPI controller completely
independent of what (if anything) is attached to it. Simply attempting to *send*
a byte in full-duplex mode results in corrupted bits coming out of the MediaTek
SPI Master-Out line. It has absolutely nothing to do with external devices. It's a
bug in the MediaTek controller.

This has been interesting bit of bikeshedding, but back to my original question.
>
> If you have a working patch...You can start here :

> https://lede-project.org/docs/guide-developer/the-source-code

I have a working patch. I know how to do a PR. I know how to RTFM :-)
Which brings us full-circle to my initial query...

My concern (as alluded to in the subject line) is that I have a patch that
I know for certain is required for the MT7688 and I've tested on the MT7688.
I don't have other MT76xx variants to  to verify the presence of the hardware
bug, so I'm reluctant  to generically apply the patch to spi-mt7621.c - my
question is how to apply this patch for only the mt7688 target.

However, the more I think about it, I strongly suspect this bug is present
on all variants of the MT76xx, so the patch should be generically applied;
I need to find confirmation; I'll try contacting MediaTek.

Thanks,
Dana  K6JQ

>
>
>
> You can start here:
> >//>/https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20 />//>/which links to another forum thread which contains this *very* informative />/posting: />//>/http://52.76.69.244/jforum/posts/list/30/3683.page#12266 />//>/and suggested patch: />//>/http://52.76.69.244/jforum/posts/list/30/3683.page#12299 />//>/which is the basis of the patch I'm using. />//>/Please describe the problem? />//>/berniwa does a much better job than me in the above-linked posting. />//>//>/Can I reproduce the same problem on one of my many MT76x8 devices? />/If so how? />//>//>/I've only seen reports of the issue on MT7688-based devices (LinkIt 7688, />/Omega2) />/and I personally have observed it on the Omega2. />//>/The easiest way to reproduce it is to attempt to send an SPI sequence />/starting with the '10' bit sequence (first nibble of 0x8 .. 0xb). You'll />/find />/the leading '1' bit is sent as a '0'. />//>/I'd be somewhat surprised if the same issue wasn't present on all devices />/which />/incorporate the MT7621 SPI peripheral given the likelihood that MediaTek />/reproduces the same logic on every chip that includes the peripheral. />//>/The SPI driver also exposes the transfer limit of 16 bytes, which berniwa's />/patch addresses by breaking up a transfer as needed (keeping chip select />/asserted). />//>//>/The MediaTek Linkit github is based on OpenWrt 15.05 using a 3.18 kernel. />/The patches needed for 3.18 vs. 4.4 or 4.9 will be quite different. />//>//>/Understood; I didn't say that MediaTek was using the *same* patch, but that />/this issue is present on all MT7688 devices and that MediaTek has />/incorporated />/a patch for it. The patch I'm using is for 4.4, of course. />//>/If you could confirm the presence of the issue on other MT7621-based SPI />/peripherals, that would address my initial inquiry indirectly if we could />/just />/patch all instances of the MT7621 SPI build :-) />//>/Cheers, />/Dana K6JQ />//>//>//>//>//>//>/On Wed, Feb 22, 2017 at 7:00 PM, Dana Myers <k6jq at comcast.net 
> <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote: />//>>/On 2/22/2017 4:27 PM, L. D. Pinney wrote: />>//>>/Are you using https://github.com/OnionIoT/source onion-omega2 branch ? />>//>>//>>/I am not; I'm using https://github.com/lede-project/source (master />>/branch) />>//>>/However, I don't believe it makes any difference - spi-mt7621.c appears />>/to be identical in both and the same patch applies; and this isn't an />>/Omega2-specific issue. All MT7688-based systems have this issue; MediaTek />>/Labs patched their LinkIt repo for this. A fix really belongs upstream. />>//>>/Thanks - />>/Dana />>//>>//>>/On Wed, Feb 22, 2017 at 2:30 PM, Dana Myers <k6jq at comcast.net 
> <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>> wrote: />>//>>>//>>>/I'm working with the Onion Omega2, which is based on an MT7688 SoC. />>>/The MT7688 SoC is a variant of the MT76xx family; in particular, it />>>/shares the same SPI peripheral. Support for SPI is in />>>/..../drivers/spi/mt7621.c />>>//>>>/However, there's bugs with the SPI in the MT7688 which require a patch />>>/to spi-mt7621.c - and I don't know if the same bugs are present in the />>>/other MT76xx family members. It is possible the other MT76xx SoCs have />>>/the same hardware issue (I'd be surprised if not) but I can only test />>>/the MT7688 I have. />>>//>>>/I think I want to patch the source file only when building only the />>>/MT7688 />>>/target, but I'm not sure how to do that or if it's supported. />>>//>>>/So I'm looking for advice on how I might incorporate this patch so />>>/that it is only applied when building ramips/mt7688. />>>//>>>/Thanks, />>>/Dana K6JQ />>>/_______________________________________________ />>>/openwrt-devel mailing list />>>/openwrt-devel at lists.openwrt.org <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel> />>>/https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel />>>//>>//>>//>>//>//>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170227/23fe9bb2/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel