@Tisham-Dhar assuming you're using the hardware SPI and not bit-banging, I think it would be more straight-forward to use the designated SPI CS1 as the chip select, and then use a mux, with other GPIOs as control signals, to route the CS signal.
It's very likely possible to use the hardware controller with a GPIO CS signal, but it would likely involve quite a bit more work than the alternative.
@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)
@Paul-Chabot: From the datasheet you linked, these UCS1903 chips are close relatives to the WS281x family of LED chain chips.
To generate the required signal with SPI, you'd need to have a SPI interface available exclusively for the purpose (which you don't on Omega2), and you need to have tight control of the SPI to send a long uninterrupted stream of data (which usually works on Arduino&Co, but is difficult on a Linux system).
But luckily, there's hardware better suited for the task than the SPI in Omega2's MT7688 chip: the PWM unit. It's still a bit tricky to meet all timing constraints, but definitely possible. I know because I wrote a kernel driver named p44-ledchain exactly for the purpose ;-) I needed it for Omega2 based projects like this (with 200 WS2813 LEDs).
Now, the UCS1903 has slightly different timings specs than the chips already supported in p44-ledchain (WS2811, WS2812, WS2813, P9823, SK6812). Still, I think it should work with the P9823 setting. If not, just let me know and I can add another option for the UCS1903 chip to the driver.
If you want to give it a try:
Install the driver (needs --force-depends because there's no 100% kernel version match):
wget http://plan44.ch/downloads/experimental/kmod-p44 ledchain_4.4.61%2B0.9-2_mipsel_24kc.ipk
opkg install --force-depends kmod-p44-ledchain*
Then load the driver and configure it for a chain of 100 P9823 (see here for detailed description of the module parameters):
Now you need to configure one of the GPIO pins to provide PWM0 output (GPIO 18 or 46 have that option):
omega2-ctrl gpiomux set pwm0 pwm; # for GPIO 18
omega2-ctrl gpiomux set uart1 pwm01; # for GPIO 46
Finally you need to connect your DIN of the first UCS1903 in the chain to the PWM0 output pin of the Omega2 (GPIO 18 or 46). As the Omega2 is 3.3V and the UCS1903 is 5V powered, the high level coming from the Omega2 might not be sufficient for the UCS1903. In my experience with WS281x chips, it can work sometimes, but not reliably. So the right way to do it is adding a level shifter such as a 74AHCT1G125.
Now you can just write a string of RGB values into /dev/ledchain0 to control the LEDs, for example:
@Douglas-Kryder for what? Pine is just simple dev board, ok, raspberry shows the same error, should I go to raspberry forum? I use flashrom, pine64 is connected by spi, and is used for communication only
upd: I resized uboot.bin up to required size and flashed it without errors, tomorrow I will solder it back to omega2 and test it
@Lindsay-Wright Theoretically you could put variation of the Linkit Smart OpenWrt build on them which should have the patch to switch SPI to half-duplex mode and thus avoid the bit corruption due to a hardware issue with full duplex. But that is obviously a bit of a non-trivial project - ultimately, it just resemphasizes the problem pointed out long ago, that Onion's persistent refusal to release sources which build to a system with working wifi means that the community can't fix little problems for them, and all the work of fixing everything falls on their overstretched team.
Another approach you could consider would be to bit-bang SPI, or use a small MCU to bridge to it from I2C or a spare UART.