Half Duplex SPI Transactions
If you're looking to do a half-duplex SPI transaction (where Chip-Select is held active between blocks), check out the xfer3 function in the python-spidev module.
In the python-spidev module readme
An example of usage in a community thread
If you absolutely need full-duplex SPI
The Omega2 family does not support full-duplex transactions on the hardware SPI bus, but you can make a software (bit-bang) instance of an SPI bus that will support full-duplex.
More info on software-based SPI buses in this FAQ post.
If you want a version with more features for the same task, there's been omega2flash here for quite a while now
It has some additional features such as:
prevents programming the same omega2(s+) twice
can handle (early production) omega2s having no ethernet address and fix that.
can set the uboot environment (useful place to have per-device info such as hardware version, without the need for different firmware images).
can flash extra files (initial data for the jffs overlay) along with the firmware image.
can be run in a loop (e.g. as a service) to program any omega2 hardware it finds on the specified ethernet interface. It does so sequentially, but as initiating the firmware update only takes a few seconds, whereas completing the update can take minutes, this amounts to pretty parallel flashing of multiple devices.
can run on standard macOS/Linux, but also runs on OpenWrt under ash shell - so a "flasher" device can be built based on any OpenWrt capable device (I have a PC-engines Alix for that).
uses expect tool (usually available on macos/linux) to enter ssh password or sshpass on OpenWrt.
Any comments, input, contributions welcome, it's on github.
After having the auto-provisioning up and running I still have a small imperfection in play.
Whenever mtd -r write <IMAGE-NAME>.bin firmware finishes it does not do the -r because it complains about not being able to [e]rase a block. ...it exits with 1
Writing from 20211027-pan35-blusser-9-5.bin to firmware ...
[e]Failed to erase block
mtd verify doesn't end well either.
After a reboot the omega seems to be running my custom firmware happily, so I dont worry too much yet, but it keeps nagging
I have followed the instructions closely, also tried a couple of times more to make a new .bin file using the dd method.
This is how that runs:
root@Pandora3-74F3:/mnt/mmcblk0# dd if=/dev/mtd3 of=20211108-pan35-blusser-9-5.bin
64896+0 records in
64896+0 records out
Any idea where i should look?