Omega2 current defects
-
Thanks @Rudá-Cunha for the input. I've added some quickly gathered info in the original post.
@György-Farkas Thanks, I'd also like this to receive some attention, but after discovering that a few of these issues have been reported since the sale of this product with no fix yet, I'm rather unoptimistic..
-
The SPI summary substantially mis-states the actual situation. See the mediatek site for the correct information.
-
@Chris-Stratton Do you have any references? What exactly is wrong? I am aware that this is kernel and/or MT7680 bug. Doesn't change the fact however that it simpy doesn't work on the newest firmware.
-
I agree.
If it is a defect of the MT7680, should not the defect have been detected when developing hardware and disclosing that it has SPI support?
-
@Maximilian-Gerhardt said in Omega2 current defects:
@Chris-Stratton Do you have any references? What exactly is wrong?
I hope @Chris-Stratton won't mind me answering in his place.
I think he was talking about this stuff:LinkIt Smart 7688 (MediaTek MT7688AN - OpenWrt)
Limitations and Known Issues
https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/limitations-and-known-issues
-
I think we should precisely differentiate three areas:
- There are bugs in the Mediatek MT7688, affecting SPI, I2S and I2C, see link in @György-Farkas' post above. If you blame Onion for using this chip, then please name a better one in the same price range having at least partially open specs. The MT7688 is nothing more than a slightly IoT-zed router chip. Its ethernet, USB, UART and WiFi hardware is solid, but its SPI was originally designed to connect the flash chip only, and things like PWM and I2C seem to have been added without much care. Sad, but certainly MediaTek's fault.
- There's not enough open documentation for the MT7688 to write solid drivers without a lot of try and error. As said, at least there is a publicly available datasheet (there was none for the Omega1's AR9331!), but it is little more than a list of register addresses and bits. No conceptual descriptions of any of the function blocks, very little context. So the drivers that exist in the open source LEDE stack have shortcomings just because the hardware is not documented properly. On the other hand, those developers who do have more information, are bound by NDAs so can't contribute to the open drivers, e.g. WiFi. This is the sad state of affairs around a only semi-open SoC chip.
- And then there's Onions strange way to (not) communicate all this properly to their users. It took an eternity until the LEDE build and uboot was opensourced, missing a lot of opportunity to get help from initially enthusiastic community members. And now, inexplicably, they don't respond to carefully collected information and hints like @Maximilian-Gerhardt 's excellent summary, and apparently don't update their firmware. IMHO, only that part is the real issue
Bottom line: there are compromises when building a $6 computer. You can argue Onion should have built another RPi instead for $30, but I am very happy they didn't, because once you know the limitations, the Omgea2 and Omega2S are fantastic devices to build small networked devices.
But Onion should actively communicate the pros and cons, admit problems, provide workarounds and quickly integrate work from others for the MT7688 into their firmware.
For example, this patch making hardware SPI usable by running it in half-duplex mode (full duplex is broken in MT7688 hardware).
As a side note: I am very curious to see how they will handle execution of the clock project - they'll need SPI for the display, probably I2S for sound, probably a ws2812 driver for the light bar. Sometimes developing a real application (vs. just cobbling together examples how to do cool stuff) helps improving the basics
-
i'm curious to know if anyone thinks that the firmware has been updated since they offered b160 in march 2017. and if it has if anyone thinks onion should have shared the build with this community. i think it has and it should have been shared.
-
As someone on this forum posted a link to the helpdesk before, I have found a (kinda) interesting article: https://onion.freshdesk.com/support/solutions/articles/24000014450-spi-issue-resolution
SPI issue resolution
Modified on: Thu, 7 Sep, 2017 at 12:52 PM
Hi everyone,We are keep getting the emails with regards to SPI issue resolution. We are currently working on a new SPI driver that will hopefully fix or at least improve this situation.We are also testing it and hope to release it in Q3 or Q4 or this year. >However, we cannot promise the full resolution of this problem. Above all, it is possible to setup software based SPI. It would, at least, have an upper limit in speed. Thank you for reading, stay tuned.
If only it was at a more visible place, like a thread from the Omega Team with a list of things being currently worked on on their progress.. Well, but here we have it, maybe in Q4 (of which 2/3 are already over), we will have a fix. Or not, like with the deadline for a new WiFi driver. I'll keep this thread updated.
-
@Maximilian-Gerhardt hello, thanks for the info. as to the wifi & spi issues it may be that since those issues directly involve the now current alarm clock on kickstarter since that device uses an omega2s it could be that onion does not want to release the current status of that firmware.
-
I've also made some minor modifications to the SPI driver:
- don't use full-duplex mode, since it does not work (seems to be HW bug)
- support for GPIO CS
- support for large buffers
In general, I mainly threw code out to rely more on the generic spi.c infrastructure. Together with some modifications to the .dts file, this resolves many of the issues that people complain about on the SPI driver. Additionally, the driver can now support 'fast read' and does not need the chunked-io parameter. This speeds up in general performance of flash accesses. Combined with a higher SPI clock speed, I have obtained more than double of the flash read performance compared to the current driver.
Example modifications to the dts file:
For CS GPIOs:cs-gpios = <0>, <0>, <&gpio1 9 0>, <&gpio1 10 0>; ... spidev@2 { compatible = "spidev"; reg = <2>; spi-max-frequency = <40000000>; }; spidev@3 { compatible = "spidev"; reg = <3>; spi-max-frequency = <40000000>; };For better flash performance:
- m25p,chunked-io = <31>; + m25p,fast-read;I've put the driver on github https://github.com/wdu/mt7688
-
Q4 2017 at the end and we have no resolution of Wifi and SPI and the company is worrying about launching more products with defects than solving the problems.
-
@Rudá-Cunha yes that is troubling to me also because they might have solved some issues and decided not to provide them to the group of people who funded their project. remaining silent about the issue was a primary reason i did not support the clock and if asked advised against funding the clock for this and other reasons. onion is creating a very negative corporate image that will have a negative down force on the image of the company as well as success of future projects. it's a damn shame, but management is corrupt or plain stupid. i don't know if it was widely noticed but they charged clock funders full price for 2 weeks and out of concern, i guess, of low response, started accepting near 1/2 normal pledge, to become clock pledge. this certainly negatively affected the early adopters and further promoted a negative image of the company. if they were going to drop pledge to 1/2 price they should have refunded the prior full price pledge instead of screwing early adopters.
-
Do not tell me I had great plans. Giant purchases to mass produce. But I paused for defects. They wanted to plug the hole launching with the Arduino (SPI, I2C ...).
It seems to me that they are launching products to enable the company to sustain itself, forgetting the quality.
-
Onion has updated their post indicating a SPI driver fix planned for Q3/Q4 of 2017 to state: "So far, we've tried fully disabling Full-Duplex transmissions, however, this still causes data corruption in Half-Duplex transmissions."
I've had a discussion with Pavel and Lazar concerning the SPI interface. They indicated that they are not spending much time working on it once they discovered the switch to half duplex did not fix the issue.
Their recommendation is to go with the SW bit-bang driver or if higher performance is needed add an external processor to handle the SPI communications or a hardware bridge to the SPI interface such as an i2c to SPI bridge.
-
@Chris-Ouellette that is interesting information, thanks!
However, I wonder why SPI with this halfduplex patch from narioninc works so well in my case. It is a TTN (LoRa) gateway, where SPI is needed to communicate with the actual radio module (RAK831). Specifically, the LoRa software contains an utility called
util_spi_stresswhich does high-speed R/W test. I can run it for hours with no errors.Is there information about what circumstances exactly cause data corruption? Maybe the access patterns used by LoRa software just by accident don't trigger the problem?
-
@luz I have only seen data corruption in full duplex mode, half duplex works. It would surprise me if half duplex mode has a bug, since the SPI flash works reliable. In full duplex, I have observed errors in the second bit (always 1 or 0, don't remember exactly), depending on the state of the first bit. This makes the first transmitted byte unreliable.
-
Odd that the Onion guys weren't able to get half duplex mode working.
What is the best way to get a kernel image with the SPI fix? If you could point me to the information on how you created your kernel image I would greatly appreciate it.
I'm new to the Linux world, I apologize for the basic question.
-
@Chris-Ouellette said in Omega2 current defects:
Odd that the Onion guys weren't able to get half duplex mode working.
Indeed. As @wdu points out, unreliable operation of the hardware in half-duplex would make SPI flash unreliable, which isn't the case. So I guess it must be a matter of having the right drivers.
What is the best way to get a kernel image with the SPI fix? If you could point me to the information on how you created your kernel image I would greatly appreciate it.
I always build entire OpenWrt/LEDE images tailored to my device's needs. I documented the way to build a full image (that of my TTN gateway) here. It's not entirely trivial, but should be doable with some basic Linux command line experience. However the result is a specialized image, which will boot with any Omega2 into console, but lack most of the Omega tools (no web-UI, no wifi setup tools etc.).
So you might want follow more generic LEDE build instructions from Onion's docs, and just apply the SPI-related patch before running the build.
@wdu's mods seem to be more thorough and offering nice additional features (GPIO baseds CS lines, cool!), but so far I haven't found the time to test that, and can't provide help for that. I'm sure @wdu can
Of course, the best solution would be Onion adding one or the other patch to their firmware, and actually release it!
-
@luz thanks
-
This thread should be pinned.
