<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 27, 2017 at 11:32 AM, Dana Myers <span dir="ltr"><<a href="mailto:k6jq@comcast.net" target="_blank">k6jq@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<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;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px">On Wed, Feb 22, 2017 at 8:57 PM, Dana Myers <<a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel" target="_blank">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;text-align:start;text-indent:0px;text-transform:none;word-spacing: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;text-align:start;text-indent:0px;text-transform:none;word-spacing: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></div></blockquote><div><div>Disagree this IS relevant. </div><div>The device in your case is the Onion Omega2.</div><div>There is only ONE thing connected to the SPI ... the NOR chip.</div><div>Is your second or third SPI peripheral soldered to the board?</div><div>Basically OpenWrt is working OK until you add something.<br></div><div>The problem is only present when something ELSE is connected to SPI.</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><blockquote type="cite">
</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.</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span style="color:rgb(0,0,0);white-space:pre-wrap">If you have a working patch...You can start here :</span></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
<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;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px"><a href="https://lede-project.org/docs/guide-developer/the-source-code" target="_blank">https://lede-project.org/docs/<wbr>guide-developer/the-source-cod<wbr>e</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... </div></blockquote><div><br></div><div>Why don't you post the [PATCH] here or even better to the LEDE-DEV list where it is more likely to find 'action'<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
<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></div></blockquote><div><br></div><div>My question is :</div><div><br></div><div>If you have a patch...why don't YOU know where to apply it?</div><div>If you expect someone help post the patch....even if YOU don't know what to do with it.</div><div><br></div><div><div>You will find it difficult to apply your patch specifically to mt7688.</div><div>It would more properly apply in target/linux/ramips/patches-4.<wbr>? and thus be applied to mt76?? as needed.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
<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></div></blockquote><div><br></div><div><div>I hope you can speak ZH-TW :)</div><div>You seem to be using LEDE.</div><div>Which brings up the question of why are you posting to the OpenWrt-dev list?</div><div>When you aren't using OpenWrt and seem to know full well from this thread that the patch should be applied upstream?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
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;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px">You can start here:
><i>
</i>><i> <a href="https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20" target="_blank">https://community.onion.io/top<wbr>ic/1560/spi-pins-for-the-omega<wbr>2/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" target="_blank">http://52.76.69.244/jforum/pos<wbr>ts/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" target="_blank">http://52.76.69.244/jforum/pos<wbr>ts/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" target="_blank">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" target="_blank">https://github.com/OnionIoT/so<wbr>urce</a> onion-omega2 branch ?
</i>>><i>
</i>>><i>
</i>>><i> I am not; I'm using <a href="https://github.com/lede-project/source" target="_blank">https://github.com/lede-projec<wbr>t/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" target="_blank">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> ______________________________<wbr>_________________
</i>>>><i> openwrt-devel mailing list
</i>>>><i> <a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel" target="_blank">openwrt-devel at lists.openwrt.org</a>
</i>>>><i> <a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel" target="_blank">https://lists.openwrt.org/cgi-<wbr>bin/mailman/listinfo/openwrt-d<wbr>evel</a>
</i>>>><i>
</i>>><i>
</i>>><i>
</i>>><i>
</i>><i>
</i>></pre>
</blockquote>
<br>
</div>
</blockquote></div><br></div></div>