After building the openwrt firmware hlk-7688 for my module, there are some errors on SPI pin. HLK-7688 module uses mt7688an chip. This module contains SPI FLASH storage and SDRAM. HLK-7688 has two SPI master: 2 CS pins. I think CS0 pin for working with SPI flash storage and CS1 is free. And this is the source openwrt: https://github.com/RAKWireless/RAK831-LoRaGateway-OpenWRT-MT7628.git. I have edited some parameter in this source. But I face to the problem - spi32766.1 device. When I run application lora with spidev32766.1, the CS0 run together. The end, I want to re-config spidev32766.1 and delete CS0 go out the spidev32766.1 device. May be effect when config on these file: https://github.com/RAKWireless/RAK831-LoRaGateway-OpenWRT-MT7628/tree/master/wiswrt/rak/purewrt-rc2/target/linux/ramips/dts. MT7628.dts and mt7628an.dti
Thank in advance !
RAKWireless, while it may be based on OpenWrt, is not OpenWrt. As OpenWrt is open source, within the licensing requirements, people are free to fork and modify it as they see fit. Support of that fork needs to go through that Github repo, or through another means suggested by its author(s).
OpenWrt supports what may be a similar device https://openwrt.org/toh/seeed/linkit7688
Thanks for your support. I'm so confused about my edit on my .dts file. At present, I worry about the spidev32766.1 parameter. Can you look at my .dts file and feedback me if you have another solution. I edit my .dts file for purpose using SPI_CS1 pin on HLK-7688 module. I think HLK-7688 likes the same architecture as Linkit Smart 7688. So my HLK-7688's ".dts" file follow the Linkit Smart 7688's ".dts" file. This is the link to my .dts file (https://github.com/nhanlee97/RAK831-LINKIT7688/blob/master/products/wisLora/target/linux/ramips/dts/MT7628.dts). Some rows between 85 and 92 for spidev32766.1 which spidevice for communicating RAK831 loragateway. The goals is spidev32766.1 has CS1_PIN and SPI_CLOCK = 8Mhz. Do you agree with my editing on this file? I'm expect your feedback about this.
Thank in advance !
P/s: the link to mt7628.dtsi (https://github.com/nhanlee97/RAK831-LINKIT7688/blob/master/wiswrt/rak/purewrt-rc2/target/linux/ramips/dts/mt7628an.dtsi)
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.
&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 !
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.
I haven’t fixed this problem until now. Thanks for your supporting. If I fix complete issue, I have share solutions with you.
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!
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.
Vào Th 4, 18 thg 9, 2019 lúc 17:14 Patrik via OpenWrt Forum firstname.lastname@example.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...
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.
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 + */
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.
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.
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?
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.
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?
I'm trying to fix these problem. When I find the best solution, I will post this solution in my github.
Which RAK firmware are you using?
Do you have the link to that?
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.
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.