1. Home
  2. Omega Talk
  3. Omega2 current defects

Omega2 current defects

  • Douglas Kryder

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

    0
  • W

    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

    3
  • R

    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.

    0 Douglas Kryder 1 Reply
  • Douglas Kryder

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

    0
  • R

    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.

    0
  • C

    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.

    0 luz 1 Reply
  • luz

    @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_stress which 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?

    0 W 1 Reply
  • W

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

    0 C 1 Reply
  • C

    @wdu @luz

    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.

    0 luz 1 Reply
  • luz

    @Chris-Ouellette

    @Chris-Ouellette said in Omega2 current defects:

    @wdu @luz

    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!

    0 C 1 Reply
  • C

    @luz thanks

    0
  • C

    This thread should be pinned.

    1
  • M

    For the sake of completeness, I am documenting the changes in the help-desk texts, too.

    On the SPI issue, originally:

    @Maximilian-Gerhardt said in Omega2 current defects:

    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.

    I am not very pleased to see that the original text I quoted on that helpdesk was now changed to

    0_1515490408283_SPI2.png

    There isn't even any release date on there anymore. It's just "lol, we didn't get it working, but you can set up bit-banged SPI...".

    On the issue of no I2S drivers (https://onion.freshdesk.com/support/solutions/articles/24000019621-i2s-documentation), a new entry has appeared:

    Modified on: Thu, 4 Jan, 2018 at 4:20 PM
    The documentation on I2S will be available sometime in the February 2018, Stay Tuned!

    0
  • M

    OnionIoT has released a new firmware version b176 in https://onion.io/2bt-march-27-2018/ in which it is stated that:

    • a new WiFi driver "WiFi Warp Core" has been released, which fixes problems with:
      • general WiFi performance
      • Automatic Network Switching
      • Automatic Network Encryption Detection in wifisetup
      • Support for Hidden SSIDs
    • SPI Improvements
      • maximum transfer sizes increased to 4096 bytes
      • MSB corruption fixed for "some" devices ("We’ve observed that some SPI devices still show data corruption but others do not")
      • new python-spidev package for writing user-space programs with SPI (apparently different from old pyOnionSpi)

    Will re-test and recompile older programs to see how much it improved. Main post updated.

    3
  • Caio Mehlem

    Hello everyone. Does anyone know if it is possible to use this new "WiFi Warp Core" driver with a custom build of LEDE or OpenWRT? Are there sources or binaries available?

    Thank you!

    0 A 1 Reply
  • A

    @Caio-Mehlem

    It is binary kernel module:
    https://github.com/OnionIoT/OpenWRT-Packages/tree/master/wifi-warp-core/bin

    Based on this, Wifi seems to work on the custom build. I haven't checked, however.

    @Stephane-Foloppe said in Wifi not working after building customized image:

    hi,

    I just build my own firmware and wifi is working !

    ( I just have to manually select Coreutils to make the wifi drivers appears in onion/wifi )

    0
bugs 4
Log in to reply
 

Looks like your connection to Community was lost, please wait while we try to reconnect.