<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Wed, Feb 22, 2017 at 8:57 PM, Dana Myers <<a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel">k6jq at comcast.net</a>> wrote:
><i> On 2/22/2017 6:18 PM, L. D. Pinney wrote:
</i>><i>
</i>><i>
</i>><i> spi-mt7621.c has bugs ... isn't very helpful.
</i>><i>
</i>><i>
</i>><i> I am a bit surprised you're not already aware of the SPI issues.
</i>><i>
</i>><i>
</i>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.</pre>
</blockquote>
<br>
Of course - that's surely why this hardware bug in the MediaTek SPI
peripheral<br>
escaped from the factory; they implement and document functionality
(full-duplex<br>
operation), and either didn't test it or didn't regard the bug as
critical. The<br>
critical use-case of the SPI port is to read the flash device, which
is half-duplex,<br>
but that's not the only documented use of the SPI port.<br>
<br>
MediaTek documents the SPI port as a general peripheral (and
provides<br>
an additional select line), and there's a bug in the hardware.<br>
<blockquote type="cite">
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Whenever you (or anyone) adds functionality to a device you can expect
problems.</pre>
</blockquote>
Thanks, though this isn't relevant at all. I'm not *adding*
functionality to the device.<br>
There's a bug in the SPI controller that's exposed when you try to
use it as documented.<br>
<br>
<blockquote type="cite">
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;">In this case some device foreign to the actual device in question.
More specifically a device such as a RFID module or STM32.</pre>
</blockquote>
This isn't the case at all. There's a bug in the MediaTek SPI
controller completely<br>
independent of what (if anything) is attached to it. Simply
attempting to *send*<br>
a byte in full-duplex mode results in corrupted bits coming out of
the MediaTek<br>
SPI Master-Out line. It has absolutely nothing to do with external
devices. It's a<br>
bug in the MediaTek controller.<br>
<br>
This has been interesting bit of bikeshedding, but back to my
original question.<br>
<blockquote type="cite">
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
If you have a working patch...You can start here :
</pre>
</blockquote>
<br>
<blockquote type="cite">
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a href="https://lede-project.org/docs/guide-developer/the-source-code">https://lede-project.org/docs/guide-developer/the-source-code</a></pre>
</blockquote>
<br>
I have a working patch. I know how to do a PR. I know how to RTFM
:-)<br>
Which brings us full-circle to my initial query...<br>
<br>
My concern (as alluded to in the subject line) is that I have a
patch that<br>
I know for certain is required for the MT7688 and I've tested on the
MT7688.<br>
I don't have other MT76xx variants to to verify the presence of
the hardware<br>
bug, so I'm reluctant to generically apply the patch to
spi-mt7621.c - my<br>
question is how to apply this patch for only the mt7688 target.<br>
<br>
However, the more I think about it, I strongly suspect this bug is
present<br>
on all variants of the MT76xx, so the patch should be generically
applied;<br>
I need to find confirmation; I'll try contacting MediaTek.<br>
<br>
Thanks,<br>
Dana K6JQ<br>
<br>
<br>
<blockquote type="cite">
<pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
You can start here:
><i>
</i>><i> <a href="https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20">https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20</a>
</i>><i>
</i>><i> which links to another forum thread which contains this *very* informative
</i>><i> posting:
</i>><i>
</i>><i> <a href="http://52.76.69.244/jforum/posts/list/30/3683.page#12266">http://52.76.69.244/jforum/posts/list/30/3683.page#12266</a>
</i>><i>
</i>><i> and suggested patch:
</i>><i>
</i>><i> <a href="http://52.76.69.244/jforum/posts/list/30/3683.page#12299">http://52.76.69.244/jforum/posts/list/30/3683.page#12299</a>
</i>><i>
</i>><i> which is the basis of the patch I'm using.
</i>><i>
</i>><i> Please describe the problem?
</i>><i>
</i>><i> berniwa does a much better job than me in the above-linked posting.
</i>><i>
</i>><i>
</i>><i> Can I reproduce the same problem on one of my many MT76x8 devices?
</i>><i> If so how?
</i>><i>
</i>><i>
</i>><i> I've only seen reports of the issue on MT7688-based devices (LinkIt 7688,
</i>><i> Omega2)
</i>><i> and I personally have observed it on the Omega2.
</i>><i>
</i>><i> The easiest way to reproduce it is to attempt to send an SPI sequence
</i>><i> starting with the '10' bit sequence (first nibble of 0x8 .. 0xb). You'll
</i>><i> find
</i>><i> the leading '1' bit is sent as a '0'.
</i>><i>
</i>><i> I'd be somewhat surprised if the same issue wasn't present on all devices
</i>><i> which
</i>><i> incorporate the MT7621 SPI peripheral given the likelihood that MediaTek
</i>><i> reproduces the same logic on every chip that includes the peripheral.
</i>><i>
</i>><i> The SPI driver also exposes the transfer limit of 16 bytes, which berniwa's
</i>><i> patch addresses by breaking up a transfer as needed (keeping chip select
</i>><i> asserted).
</i>><i>
</i>><i>
</i>><i> The MediaTek Linkit github is based on OpenWrt 15.05 using a 3.18 kernel.
</i>><i> The patches needed for 3.18 vs. 4.4 or 4.9 will be quite different.
</i>><i>
</i>><i>
</i>><i> Understood; I didn't say that MediaTek was using the *same* patch, but that
</i>><i> this issue is present on all MT7688 devices and that MediaTek has
</i>><i> incorporated
</i>><i> a patch for it. The patch I'm using is for 4.4, of course.
</i>><i>
</i>><i> If you could confirm the presence of the issue on other MT7621-based SPI
</i>><i> peripherals, that would address my initial inquiry indirectly if we could
</i>><i> just
</i>><i> patch all instances of the MT7621 SPI build :-)
</i>><i>
</i>><i> Cheers,
</i>><i> Dana K6JQ
</i>><i>
</i>><i>
</i>><i>
</i>><i>
</i>><i>
</i>><i>
</i>><i> On Wed, Feb 22, 2017 at 7:00 PM, Dana Myers <<a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel">k6jq at comcast.net</a>> wrote:
</i>><i>
</i>>><i> On 2/22/2017 4:27 PM, L. D. Pinney wrote:
</i>>><i>
</i>>><i> Are you using <a href="https://github.com/OnionIoT/source">https://github.com/OnionIoT/source</a> onion-omega2 branch ?
</i>>><i>
</i>>><i>
</i>>><i> I am not; I'm using <a href="https://github.com/lede-project/source">https://github.com/lede-project/source</a> (master
</i>>><i> branch)
</i>>><i>
</i>>><i> However, I don't believe it makes any difference - spi-mt7621.c appears
</i>>><i> to be identical in both and the same patch applies; and this isn't an
</i>>><i> Omega2-specific issue. All MT7688-based systems have this issue; MediaTek
</i>>><i> Labs patched their LinkIt repo for this. A fix really belongs upstream.
</i>>><i>
</i>>><i> Thanks -
</i>>><i> Dana
</i>>><i>
</i>>><i>
</i>>><i> On Wed, Feb 22, 2017 at 2:30 PM, Dana Myers <<a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel">k6jq at comcast.net</a>> wrote:
</i>>><i>
</i>>>><i>
</i>>>><i> I'm working with the Onion Omega2, which is based on an MT7688 SoC.
</i>>>><i> The MT7688 SoC is a variant of the MT76xx family; in particular, it
</i>>>><i> shares the same SPI peripheral. Support for SPI is in
</i>>>><i> ..../drivers/spi/mt7621.c
</i>>>><i>
</i>>>><i> However, there's bugs with the SPI in the MT7688 which require a patch
</i>>>><i> to spi-mt7621.c - and I don't know if the same bugs are present in the
</i>>>><i> other MT76xx family members. It is possible the other MT76xx SoCs have
</i>>>><i> the same hardware issue (I'd be surprised if not) but I can only test
</i>>>><i> the MT7688 I have.
</i>>>><i>
</i>>>><i> I think I want to patch the source file only when building only the
</i>>>><i> MT7688
</i>>>><i> target, but I'm not sure how to do that or if it's supported.
</i>>>><i>
</i>>>><i> So I'm looking for advice on how I might incorporate this patch so
</i>>>><i> that it is only applied when building ramips/mt7688.
</i>>>><i>
</i>>>><i> Thanks,
</i>>>><i> Dana K6JQ
</i>>>><i> _______________________________________________
</i>>>><i> openwrt-devel mailing list
</i>>>><i> <a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel">openwrt-devel at lists.openwrt.org</a>
</i>>>><i> <a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel">https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel</a>
</i>>>><i>
</i>>><i>
</i>>><i>
</i>>><i>
</i>><i>
</i>></pre>
</blockquote>
<br>
</body>
</html>