I have no idea what “lorgateway” is or how it works. If I had the device in hand, the time to prioritize working on it and to learn the details of the platform, I would start by checking and enabling, if needed, the CS lines and potentially an appropriate SPI device. &spi0, &spi-pins, and &spi_cs1_pins would be where I'd start. You'd have to look at ralink,mt7621-spi to determine how to set the clock rate for the device attached.
Thanks for your reply !
Hi nhanlee97,
i see you have the same problem as me :-). What i know is the MT7688 has an spi "silicon bug" an dyou need the patch the spi drivers that changes the duplex mode from full to half duplex.
The HW Omega onion2 is based on the same Mediatik device and they resolved the probelm by patching :https://github.com/OnionIoT/source/blob/openwrt-18.06/target/linux/ramips/patches-4.14/9999-spi-mt7621.patch.
I trhougt that i can use this patch for my device... But compiling crashes with these messge.
At the mement the project with MT7688 and LORA is on hold. If you have resolved or any ideas... please bs so kind and contact me.
ragrds Patrik
1 Like
Hi Patrik,
I haven’t fixed this problem until now. Thanks for your supporting. If I fix complete issue, I have share solutions with you.
Regarding,
nhanlee97
Hi nhanlee97
thanks, for your fast answer!
rak wirelss has a solution too but with openwert 15.05 chaos calmer and a very old Linux-Kernel 3.15
It would be great hear you again!
Patrik
Hi Patrik,
If you use mt7628 mediatek chip. You can use the RK7429 firmware in RAK firmware database web. It seem have a full LoRaWan stack in Openwrt firmware. It has the LoRa interface in web interface, you can get it when accessing through web browser.
Regard,
nhanlee97
Vào Th 4, 18 thg 9, 2019 lúc 17:14 Patrik via OpenWrt Forum mail@forum.openwrt.org đã viết:
Hi, i would like to compile my own openwrt.unfortunately rak Has no actual Source in repro. Successfully i compiled a raspi Zero with semtechs lora gw and packet forwarder with openwrt V18. 06 running. Its for playing. But for a production device i decide to use a soc with emmc. I think about a switch to another soc like qualcomm qca 4531. Its fully openwrt supported and has no spi probs... 
Regards
Patrik
That patch may still work, the message is that the build system can’t tell where to apply it. This happens when the source changes, such as with new kernel versions. Hand work is often needed to do the changes and change the patch.
Edit:
That looks like wholesale replacement of a couple of the SPI functions. Applying it to the original source from Onion should make it easy to unravel. I think it is just the way a patch tries to find its context isn't very robust here to changes.
I'm amused by
+/*
+ * The SPI core of the MT76xx is utterly broken,
+ * and a full duplex transfer will mess up the MSB of the transaction
+ * by setting it to the MSB-1 bit aka a 0x40 will be a 0xC0
+ * this means, that "real" full duplex SPI cannot be used
+ *
+ * As most drivers (also the driver we use), only does
+ * "quasi-full-duplex" aka. one transfer in and one transfer out
+ * this function will handle this just fine
+ */
Hi Jeff,
it means that every time when i update the opewrt source and the kernel version has changed i´ve to modify the patch? Incedible!
The bug is an official defect from MT76x family.
The "spi silicon bug" is a hardware bug and normally the producer -in our case Mediatek- has to do the patch-work!To this day, the module is still sold but the resources at github is older then 3 years wirh openwrt CC.
As an router module, i think it s ok. but for IoT thinks ... its better to cheack other posiibilities.
Patrik
This gives a hint as to why the OpenWrt project (or any project that depends on upstream sources like Linux) only supports one or two versions.
The failure of the patch to apply cleanly is likely due to so many kernel versions passing by without anyone maintaining the patch. Once updated, the general process is to "refresh" the patches regularly, with every new kernel version, so they don't get so far out of sync that the automated tools can't adjust them. The same goes for "backports" where changes from a current kernel are tried to be applied to older versions.
Yes, MediaTek probably should be fixing it for current kernels. Unfortunately there is little economic incentive for them to do so. Supporting their OEM customers with a functional SDK, even if on an old, known-insecure kernel is their priority, not a comparatively tiny community of coders that don't drive sales of MTK chips.
My guess is that once adjusted for a current kernel, the patch is unlikely to change significantly over the following year or so.
Edit:
It may well already be fixed upstream and available in stable/linux-5.0.y and later:
commit 354ea2ee6d2b
Author: Chuanhong Guo <redacted>
Date: Thu Dec 6 21:15:09 2018 +0800
staging: mt7621-spi: drop support for SPI mode 1/2/3
As explained in previous patch, this SPI controller seems to be
tested on SPI flash only before mass production and some bits are
swizzled under other SPI modes probably due to incorrect wiring
inside the silicon. Drop implementation of SPI mode 1/2/3 since
they are broken.
Also drop RT2880_SPI_MODE_BITS macro because we now have only
SPI_LSB_FIRST implemented and the mode_bits is so short that we
don't need a macro there.
Signed-off-by: Chuanhong Guo <redacted>
Reviewed-by: NeilBrown <redacted>
Signed-off-by: Greg Kroah-Hartman <redacted>
commit 108d9dd51363
Author: Chuanhong Guo <redacted>
Date: Thu Dec 6 21:15:08 2018 +0800
staging: mt7621-spi: drop the broken full-duplex mode
According to John Crispin (aka blogic) on IRC on Nov 26 2018:
so basically i made cs1 work for MTK/labs when i built
the linkit smart for them. the req-sheet said that cs1 should be proper
duplex spi. however ....
1) the core will always send 1 byte before any transfer, this is the
m25p80 command.
2) mode 3 is broken and bit reversed (?)
3) some bit are incorrectly wired in hw for mode2/3
we wrote a test script and test for [0-0xffff] on all modes and certain
bits are swizzled under certain conditions and it was not possible to
fix this even using a hack.
we then decided to use spi-gpio and i never removed the errornous code
basically the spi is fecked for anything but half duplex spi mode0
running a sflash on it
The controller will always send some data from OPCODE register under half
duplex mode before starting a full-duplex transfer, so the full-duplex
mode is broken.
This piece of code also make CS1 unavailable since it forces the
broken full-duplex mode to be used on CS1.
Signed-off-by: Chuanhong Guo <redacted>
Reviewed-by: NeilBrown <redacted>
Signed-off-by: Greg Kroah-Hartman <redacted>
Hi @NhanLee , Could you share with us the SPI solution for the HLK-7688?
I am also playing arround with a SX1276 module and I have the same issue.
Do you have some working git repository?
Thank you.
Hi manu80,
I recognized the software that I developed, cause this problem. So you should check against your applications. For instance, when I re-flash the official firmware from RAK company, it runs well.
NhanLee
Hi nhanlee97, instead of the official RAK firmware I want to compile my own adding some extra juice 
. Could you tell me how to fix that issue?
Thanks
Hi munu80,
I'm trying to fix these problem. When I find the best solution, I will post this solution in my github.
NhanLee
Which RAK firmware are you using?
Do you have the link to that?
Thank you.
Hi manu80,
This's the link https://github.com/RAKWireless/RAK831-LoRaGateway-OpenWRT-MT7628. You can controll deeply in to the Openwrt source code. In the last year, I successed when building. But I failed when running LoRaGateway feature.
NhanLee
Hi nhanlee97, I am fighting with the SPI.
I compiled with openwrt-19.07 successfully, the openwrt is running without problem but I can't make work the SPI.
I tried with "insmod spi-gpio-custom bus0=1,7,8,9,0,8000000,6" but I can't see any activity on the SPI pins using a logic analyzer and reading REG_VERSION.
Could you share the DTS file you are using to start up the /dev/spidev1.0 ?
Any other suggestion?
Thank you again.
Hi manu80,
Until now, I have still uncompleted when running a application on SPI peripheral. I tried to custom the DTS file. But, it wasn’t better than another. By the way the, it only run with RAK firmware
Nhanlee
Vào CN, 17 thg 11, 2019 lúc 03:50 Manuel via OpenWrt Forum mail@forum.openwrt.org đã viết:
Hi @manu80,
I'm also stuck in same issue to support driver for sx1276 lora module on openwrt router.Any suggestions.
Thank you for advance.
This topic is very confusing. But some solutions exist for long time ago! It’s very embracing that openwrt does not include the patchs/mantain them.
One solution it’s to enable spi bitbang. (Search Vocore2 SPI). And just to remember that i2c also does not works well. MT76x8 platform is very popular but it lacks of attention on openwrt.
1 Like