I seem to have found a solution for this issue, or at least a work around that works for me: YMMV
I've merged in the OpenWRT repo (git merge -X theirs openwrt/lede-17.01) into my OnionIoT/source repo. That built flawlessly ! :). So we're running kernel 4.4.153 now. That's nice on its own (always recommended to keep up with LTS kernel versions!).
Anyway, the SPI problem persisted. Then I removed the original Onion patch file for the spi-mt7621 module (rm ramips/patches-4.4/9999-spi-mt7621.patch) and rebuilt the image. Now we're using the unpatched mainline SPI driver. Guess what: this seems to work flawlessly! :) I'm a happy man now.
I only did some quick smoke tests, so it could be other SPI stuff breaks because of the missing patch. On the other hand, there have been some commits to the spi-mt7621 module in June, so the mainline might just be the only thing we need.
@Rogier-Lodewijks no, u don't need patch spidev, only spi-mt7621.c source file and it's in kernel yea. After this u can add cs-gpios in device tree, and spi device in node. Spi device can be spidev if u developing spi driver and u need its API. Thank you)
@György-Farkas Well I have tried pull down resistors, but the problem is that those pins aren't floating from the beginning, as probably the internal multiplexer does something before loading the kernel. As shown on logic analyser graph pins actually go high for around 7 sec and have 1us pulses every 25us or so, which are then detected by 74hc595. DPIO 11 doesn't have those pulses, but stays high (output state) till you don't run a scriptwhere you set the output to low on other side others - 17, 16, 15 go to floating state after that.
I then decided I will go with i2c port expander for more safe and predictable operation. MCP23008 is quiet handy as they are used in relay dock and have libraries written for it.
Thanks for your explanation! In the table of Pins that needs to be floating, GPIO7 anf GPIO8 are mentioned, although those pins are not marked as GPIO pins in the pinout diagram. Is this just a phrasing error, or are the wrong numbers stated?
Also about the floating input pins during boot mode, and please excuse my me for still being early at the learning curve, this only applies to input pins right? How do I set these pins as output pre, or during, the boot sequence?
A more specific question for my specific case, and don't hesitate to ask me to move this to a separate question if you think I should: If I connect an (intended) output pin to a NPN transistor gate over some 1k resistance, and connects the emitter to ground, is the pin considered floating or not? Can I hard wire this setup to GPIO1 and still boot up the omega?
@Marti-MG I hope I'm not too late.
If you want to use GPIO18 (PWM_CH0) only then you should remove U6 the 6 pin SOT23 marking C145 SMD IC only.
See also the official Omega-Power-Dock schematic.
After this modification Power Dock 1 remains fully functioning. You can check the battery level visually with the pover-dock command as before - but the 'battery level check' scripts will not work of course. Power Dock Checking the Battery Level
You could probably use the Omega GPIO's through open collector transistors or mosfets to drive the LEDS, then you won't have to worry about the 5V supply as it is isolated from the Omega's 3.3V. Read up on which GPIO pins to use though as some have special functions and you need to disable them using the omega2-ctrl gpiomux command