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

  • 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:

    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

Log in to reply

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