This is fixed in u-boot 1.1.3 release date 18th November 2020. There is another version 1.1.3 with release data Feb 2019, which still has this bug.

@justRobsi this sounds like a power issue. When installing packages the wifi radio is working to download the files, the CPU is writing the download to RAM, etc. There's a lot going on so the power draw increases significantly and sharply. To get over this hurdle during development, I recommend either: Using an Omega2S Development Kit - it allows for swapping Omega2S modules and has the required power circuit Getting a (through-hole) Omega2 or Omega2+ and a Dock for your development - this will eliminate any power supply issues And then when making your own circuit to power the Omega2S, please refer to the Omega2S Hardware Design Guide and the Omega2S reference schematic

You are right, not exact, but close enough. THANK YOU ! I've ordered 400 (and a couple of other things from their cool site.

@naveen_kumar To create swap file, follwo the docs: https://docs.onion.io/omega2-docs/extending-omega-memory.html I don't hink you need swap given that I was able to install the losent mqtt without any. Just follow my earlier email, use top command to view your memory use

@Jim-W I would expect the O2P to be available in the first weeks of the new year. However, this is all dependent on many things outside of our control. On O2P vs O2SP: It really depends on your situation. In general, we recommend using the S models for anything that's being produced in larger quantities. But it's also valid to continue with the O2P. We do have customers who produce 1000s of devices at a time using the O2P. A major benefit of the O2P is that it's more plug and play - SD slot and WiFi antenna are already on the device A few benefits of the O2SP: Way more GPIOs and an additional UART exposed Generally our distributors have more inventory of this part than others Hopefully that helps, let me know if there's anything specific I can weigh in on

@nsmith You need an antenna of some sort, the Omega2+ has an antenna on it's little PCB, but the Omega2S is not on a PCB so it has no antenna. You have a choice a UFI antenna or an SMD antenna, the UFI antenna may give you better wifi but it's plugged in to the Omega2S UFI connector then you have to mount it somewhere. Just google UFI antenna there are loads available, I've tried several and they all functioned fine but personally I use an SMD antenna so it can be mounted discreetly on the board, the DigiKey part # is 712-1010-1-ND, they have 450,000+ in stock. Your link was to the Omega2S which has 64MB RAM and 16MB Flash, if you need more you can use Omega2S+ which has 128MB RAM and 32MB Flash same as the Omega2+ you have been referring to in your recent posts. https://www.digikey.com/en/products/detail/onion-corporation/om-o2sp/9922958 Here is the Omega2 reference schematic which helps you to design your PCB to use the Omega2S. https://github.com/OnionIoT/Omega2/blob/master/Schematics/Omega2S-Reference-Schematic.pdf

That makes Sense, so my Power Wiring should be correct. I see that in your schematic and in the datasheet the HW Reset and VDD_FLASH are connected via transistors. Any Benefit to that compared to just pulling them to GND via a Switch? CPU_RST_SWITCH simply bridges to GND.

@Antony This is explained here in the documentation: https://docs.onion.io/omega2-docs/oled-expansion-python-module.html#oled-py-draw-from-file

@JeffZhou Thanks a lot, for your response! I think that the 2nd point (VCC current) was the root cause of my issues: I used an AWG30 wire for all VCC lines which was too thin to carry the current. Regarding the UART <-> USB-Bridge the issue still persists, it requires a little fiddling: opening the serial connection after counting to three after plugging in. Then it worked booted in 100% correctly so far. Best Regards!

@Russell-Pirie "...will they all fit??...." You'd need to be specific as to what they are and how they are configured in order to answer that. I'm not sure you need to rewrite a bluetooth driver, most users would utilise "Bluez" package for bluetooth, perhaps take a look at that package and see if it meets your requirements, here's a link to the package: https://openwrt.org/docs/guide-user/hardware/bluetooth/usb.bluetooth I flash my devices using a bash script (well ash), it just connects to the device(s) using ipv6, uploads the firmware and then ssh's into the device and execute the firmware upgrade. You could tweak my script a bit to make it handle multiple devices at once. I did about 40 of them today using my exiting script, one by one while I was eating lunch and watching the news. My script is here: https://community.onion.io/topic/4483/script-to-deploy-firmware-to-device-using-ethernet-ipv6 The other option is to boot into u-boot and flash from USB.

@sscalf fill out the quote form and respond to the email that we send you!

@cspensky take a look at this tread. https://community.onion.io/topic/4330/unable-to-flash-firmware-from-usb/12?_=1612513950216 @tjoseph1 has a nice solution

I think I'm closer to the answer. It seems to lie in the register AGPIO_CFG at address 0x1000003C. It switches the GPIOs 14 through 29 between the digital pins and the analog ethernet counterparts. Would this modification to AGPIO be done in the DTSI file, some bootloader/kernel parameter or do I need to make a patch to something somewhere? I'm aware I could use something like devmem to directly set this register from userspace but I assume there is something a bit cleaner?

@jossvall The UART TXD0 and TXD1 pins fall into the "must be floating or pulled down at boot time" category. That should be satisfied by most UART devices. Excerpt from the Omega2S Datasheet:

@supczinskib Kewl. Glad to see you are making progress. I continue to watch with interest.

Two years later: Just in case anyone runs into that problem, I found a solution that work from linux userspace: In the kernel messages (which can be viewed with the dmesg command), there is a line like: [ 0.358842] m25p80 spi0.0: w25q128 (16384 Kbytes) or (in newer OpenWrt versions): [ 0.639801] spi-nor spi0.0: w25q256 (32768 Kbytes) This is a message from the spi-nor kernel driver after detecting the actual flash chip. So it is not dependent on the flash size that is baked into the firmware image, but shows the real size of the flash chip. Both of the example lines above are from a firmware made for the Omega2. The first is run on an actual Omega2, the second shows 32M so it is a Omega2+. The only gotcha with this is that the dmesg buffer is not infinite and will loose older lines when too many new ones arrive. This means detecting the flash chip size needs to be done shortly after startup. So I put the following line into a startup script (e.g. /etc/rc.local) : dmesg | sed -n -r -e '/spi0.0: .*w25q/s/.*(w25q.*\))/\1/p' > /tmp/flashchip With this, the chip name and size is captured and can be read any time later from /tmp/flashchip to detect an Omega2(S)+ vs Omega2(S). Finally - Solved!

Your information is very interesting. Thank you for sharing