Hi @matiaslao, It's possible to use a flash programmer (external hardware) to write all of the partitions to the flash storage at once. First, create the image: use the flash programmer to read and create a binary image of an Omega2 that's setup how you want it, Then, write the image to other devices: use the flash programmer to write the image to other Omega2 devices. This is similar to the cloning process described in the FAQs. The key differences are: Cloning Flash Programmer Use Linux to create partition image Use a flash programmer (external) hardware to create an image of the flash Clones only the overlay partition Duplicates all partitions on the flash Our recommendation We recommend against using a flash programmer to write complete images to the flash. For one thing, the factory (aka art) partition holds wifi radio configuration and MAC addresses that are programmed at the factory and are unique to each device. If the factory partition is overwritten, you will need to boot the device (either into the bootloader or Linux) to, at minimum, write unique MAC addresses to the factory partition. If you're already booting into Linux, then it makes sense to use the sysupgrade command to install a firmware image as @JeffZhou mentioned above. This process will only update the firmware and kernel partitions, leaving the bootloader and factory partitions as they are. As a second option, in case this isn't helpful since you need to "clone" the firmware setup of a device, we recommend looking at this FAQ post: https://community.onion.io/topic/4563/faq-is-it-possible-to-clone-the-firmware-running-on-an-omega2-device-and-copy-it-to-other-omega2-units It doesn't overwrite the factory partition, but there are other trade-offs.

@nsmith said in Multiple devices on same SPI bus: Do i need to do insmod command three times with three different chip select pins? No, you can't insmod the same kernel module multiple times. But you can just append another three numbers for each additional CS you need, the first being the mode, the second the speed, and the third the GPIO for the CS. Like this, which adds a second CS with SPI mode=0, speed=100kHz on GPIO19, and a third on GPIO44: insmod spi-gpio-custom bus0=1,11,5,4,0,100000,18,0,100000,19,0,100000,44 You can repeat that up to a total of 8 CS lines! Then do fopen on the three resulting devices in /dev? Yes, these will be named /dev/spidev1.0, /dev/spidev1.1 and /dev/spidev1.2, resp. BTW: if you need multiple buses, i.e. another set of SCK,MISO,MOSI plus some CS, you can append bus1=2,... to the same command line, separated with a space. Up to 4 buses are supported.

@nsmith I use GPIO11 for CS1, there is no boot issue. I think it's because the Omega2's bootloader will set the GPIO11 as HIGH output during boot. Changing device tree cannot help in this case. Because no matter how you set pull-up or whatever in device tree, the Omega2 need to access flash memory to load the kernel with the defined device tree.

HW SPI is definitely used after boot. The SPI pins cannot be used as GPIOs. We recommend following the GPIO documentation and datasheet. Software SPI on any other GPIOs will work for you. See this post for more details. I understand that moving to sw spi or using a different ADC will likely require a board revision on your end, but that looks to be the best way forward.

In my opinion, it is spidev (package name, kmod-spidev), as it is the working module on OpenWrt 22.03 build for Omega2. I could see hardware SPI driver is present under /dev/spi* after installing it. Havent tested it yet by myself, though.

good call! @luz said in SPI SSD1306 Display boot problem: maybe it would make sense to mark the MOSI pin red in the datasheet too? Released v1.9 of Omega2S datasheet and v1.2 of Omega2 datasheet that includes SPI MOSI as a pin that's important for boot and must be floating. @luz said in SPI SSD1306 Display boot problem: And btw., the MT7688 datasheet links you have in the onion docs no longer work Thanks for the heads up! Updated the link to a copy that Onion hosts, so this should work indefinitely.

I'm successfully using an SPI wrapper I wrote several years ago for exactly the same kind of accesses (e.g. for MCP23S17). The routine to perform a read-then-write (or optionally, write-and-write-again) does quite the same as your sample code (see SPIBus::spidev_write_read() at lines 205ff in p44utils/spi.cpp. I didn't spot a functional difference to your code, so I'd assume your code should work (I know mine does, its in active use in many projects) Maybe there's a difference in how you open the spiFd? You can see that part in SPIBus::accessBus() at line 384ff. I'm using this code with both the MT7688 hardware SPI (which has a known hardware bug for full duplex, but that should not apply here, your read data starts after the write is over), and also with spi-gpio-custom software SPI. Hope this helps!

Hello again! The wiring is one issue (can't say for sure if it works with the expansion per se cause I have another breakout of the chip for testing purposes). Though, you can easily adapt this example -> https://www.element14.com/community/community/raspberry-pi/blog/2012/12/14/nfc-on-raspberrypi-with-pn532-py532lib-and-i2c and use I2C. Lastly, there is no official documentation regarding the schematics of the NFC/RFID expansion but our tests showed that that onion has left out SPI/I2C support for their chip -sth that needs to be checked. We are using python tools for now but I will get back to you if we find anything else!

@crispyoz I hadn't considered that, but it seems that getting the display connected to the Omega LTE might be the better option, if it's possible: the Omega LTE is infinitely more compact than most LTE options I've seen and having all of the network info available to software is a huge boon. From what I can tell the Omega Dash only differs in that it has the display adapter built-in, so if I can get the display connected to the Omega LTE and use the Dash drivers or OS, the LTE should be able to drive the display. Although I'm now tempted to grab the Dash and just plug in my display instead of the 3.2" and see if it works.

@luz Thank you for detailed explanation. I probably will use soft spi because of parallel usage needs of two devices. it will be too slow but there is no other chance. I will need to make some hardware design changes. But i couldnt understand why hardware spi count is limited in openwrt side. i know MT7688 has two hardware supported spi cs pin but it could be increased by openwrt side as adding gpios as cs with hardware spi. Thanks again @luz

@György-Farkas Thanks for the advice--It all sounds totally on-target. I have acquired a couple of cheap breakouts and am pursuing that solution.

@Jonathan-Jefferies still going strong thanks for the reminder - I've updated the OpenWRT-Packages repo to set the openwrt-18.06 branch as the default!