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

L. D. Pinney ldpinney at gmail.com
Wed Feb 22 23:09:06 EST 2017


On Wed, Feb 22, 2017 at 8:57 PM, Dana Myers <k6jq at comcast.net> 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.

Whenever you (or anyone) adds functionality to a device you can expect
problems.
In this case some device foreign to the actual device in question.
More specifically a device such as a RFID module or STM32.

If you have a working patch...You can start here :

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



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> 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> 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
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20170222/c38a0726/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list