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

Mon Feb 27 21:19:56 EST 2017

On Mon, Feb 27, 2017 at 11:32 AM, Dana Myers <k6jq at comcast.net> wrote:

> 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.
>
> Disagree this IS relevant.
The device in your case is the Onion Omega2.
There is only ONE thing connected to the SPI ... the NOR chip.
Is your second or third SPI peripheral soldered to the board?
Basically OpenWrt is working OK until you add something.
The problem is only present when something ELSE is connected to SPI.

> 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...
>

Why don't you post the [PATCH] here or even better to the LEDE-DEV list
where it is more likely to find 'action'

>
> 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.
>

My question is :

If you have a patch...why don't YOU know where to apply it?
If you expect someone help post the patch....even if YOU don't know what to
do with it.

You will find it difficult to apply your patch specifically to mt7688.
It would more properly apply in target/linux/ramips/patches-4.? and thus be
applied to mt76?? as needed.

>
> 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.
>

I hope you can speak ZH-TW :)
You seem to be using LEDE.
Which brings up the question of why are you posting to the OpenWrt-dev list?
When you aren't using OpenWrt and seem to know full well from this thread
that the patch should be applied upstream?

> Thanks,
> Dana  K6JQ
>
>
> You can start here:
> >>*     https://community.onion.io/topic/1560/spi-pins-for-the-omega2/20 <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 <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 <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 <https://github.com/OnionIoT/source> onion-omega2 branch ?
> *>>>>>>* I am not; I'm using https://github.com/lede-project/source <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 <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/86f1518d/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel