Posts made by luz

@Filipe-Madureira The official openwrt site/wiki has a lot of information and howto guides.

With OnionOS, everything related to the OpenWrt Web UI (LuCI) does not apply, but on the command line most things should work the same or at least in a similar way.

The set of packages installed by default is different from stock OpenWrt, so getting familiar with opkg and how to add package feeds might be helpful.

The standard network configuration is also different, but the powerful uci configuration management is available and worth learning (IMHO a very clever and efficient solution for cleaning up the mess of many different config files and formats). Also note that OnionOS uses a proprietary wifi driver not known in standard OpenWrt, so for details about wifi you need to check the onion docs.

@Filipe-Madureira You'll find many different use cases for the Omega2 here, I guess ;-)

My own use case is indeed very long term. I use the Omega2 modules in products that run 24/7 and are expected to do that for years (and have successfully proven that in the past two years already).

I find the combination of a well known router SoC (MT7688) running OpenWrt Linux, which is very carefully optimized for exactly such 24/7 networking devices, a very solid foundation to build on.

OnionOS adds a lot on top of OpenWrt to make it attractive also for the "OOTB" experiment type of projects. Still, it's OpenWrt, so most of the networking howtos of the OpenWrt community can be applied.

Plus, if needed, the Omega2 hardware can also run plain OpenWrt, which might be the way to go for pure networking projects.

You can even build your own customized OpenWrt based firmware (that's what I do for my devices).

So definitely: yes, the Omega2 is good for long-term projects.

@György-Farkas said in How to estimate actual flash memory wear caused by SQLite3?:

@luz One more thing. Omega2's flash is an MTD device.

Yes, but "MTD" just means "Memory Technology Device", which is the Linux term for all memory-based storage types, including flash of all types (NAND, NOR etc.).

Eraseblocks wear-out and become bad and unusable after about 10^3 (for MLC NAND) - 10^5 (NOR, SLC NAND) erase cycles

The Omega2 SPI Flash seems to be NOR with 10^5 erase cycles.
Both W25Q128FV and MX25L25635E have this number in the datasheet.

MTD FAQ What are the differences between flash devices and block drives?

Eraseblocks are larger (typically 128KB - unfortunately I don't know what about on Omega2) than those 256 byte flash pages 4KB flash sectors.

cat /proc/mtd 

reveals it:

dev:    size   erasesize  name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "factory"
mtd3: 00fb0000 00010000 "firmware"
mtd4: 001668cd 00010000 "kernel"
mtd5: 00e49733 00010000 "rootfs"
mtd6: 00980000 00010000 "rootfs_data"

So at least at the mtd layer, it is operating with 64kB (0x10000) erase blocks.

@ccs-hello said in How to estimate actual flash memory wear caused by SQLite3?:

Very much depend on the P/E pattern (for a database which needs to store critical information.) If a specific file or a variable needs to be updated constantly, that sector will wear out fast.

I don't think that there is a direct file to sector mapping in JFFS2, so writing the same file (or part of file) 100'000 times will not write the same flash sector 100'000 times. It will cause 100'000 write operations of the size of the written data, but spread somehow (ideally: evenly) over the total of available flash blocks. That's what wear leveling is all about.

The question is just how near (or far) the wear leveling strategy in JFFS2 is from really even distribution of writes, in actual practice.

If that is the subject, now the question is how to deal with the it...
(1) specialized hardware (that has indexing, write cache, TRIM, relocation capabilities) <-- that is what the SSD is designed for

In general, yes, but the scope of my question is limited to the situation as present on a Omega2 (or similar), which is SPI NOR flash driven by JFFS2. The chip+JFFS2 are the "SSD" in an Omega2.

(2) software based, i.e., do it in RAM (enough RAM space allocated?, write-back before power is removed?, etc. etc.)

That's an important point. But AFAIK there is no internal mechanism in a MT7688 for powerfail writeback, so, as nice as this would be, we don't have that (or it would need to be built around the Omega2 with extra hardware).

So the context for my question is really actually written-back-to-flash SQLite3 transactions and their impact on flash wear.

Of course, my application already does as much buffering and pooling as possible in its intended use case, to minimize writes. But it boils down to these few hundred single SQLite table row updates per day with ~50 bytes of net change each.

I.e., there is no free lunch, use the right tool for the tasks at hand

I'm not asking for a free lunch ;-)

I'm just trying to figure out if the current lunch recipe might lead to a worn out flash too quickly or not...

As flash memory blocks do wear out after a number of erase cycles, I wonder about the practical implications.

The datasheet of the memory chip itself (AFAIK Winbond W25Q128FV for Omega2, W25Q256FV for Omega2+) states "More than 100,000 erase/program cycles".

I guess this means the entire flash memory can be erased and reprogrammed a 100'000 times at least. This should be well enough for any forseeable number of firmware updates ;-)

However, the thing I'm looking at is a 24/7 running device, which has to store a few hundred, maybe up to 1-2k state changes (with ~50bytes actual data) per day into a SQLite3 database, stored on the JFFS2 overlay file system of OnionOS/OpenWrt. I find it hard to guess how much raw write activity a SQLite single row insert actually causes. Assuming 256 bytes should be enough including all SQLite overhead, each state change would need erasing/writing a block of the chip.

Assuming 500 state changes per day, and assuming the writes would be levelled evenly over all available blocks (65536 of them), wearing out all blocks would take 35'000 years. That sounds like a lot of margin for a real world application!

Only - are the guesses made above realistic? Can we rely on jffs2 wear leveling to distribute the writes that evenly? Are there SQLite house keeping operations that might cause much more writing? Anything else I might have forgotten?

For those building their own images: mt76 open wifi driver has significantly improved again in OpenWrt 18.0.6.2.

YFYI: the mt76 (OpenWrt's official, fully open source driver for MT7688 WiFi) has received significant improvements again in OpenWrt 18.06.2. I had a specific AP where the previous version (of summer 2018, as in OpenWrt v18.06.1) barely worked and kept disconnecting after a few seconds. Now with the 18.06.2 version it became completely stable. I can really tell because I had a clean A/B comparison situation this morning: nothing changed except the FW - and WiFi went from essentially broken for real use to smooth and fast with the update. Nothing else touched ;-)

@fandres-* Thanks for sharing!

I could not find the footprint however, only the EESchema lib.

YFJI, I created a Omega2S lib/footprint a while ago, which is available on github along with other parts. Onion themselves also released a footprint file back then, but not in KiCad format.

A bit of progress:

I have created a patch that can be applied to the openwrt 18.06.2 tree which makes fbtft and all fb_xxx chip drivers available in make menuconfig, under Kernel Modules -> Video Support -> kmod-fbtft-support.

The main patch that adds these options is this one.

To make sure the build does not try to create a VGA console, I also added another small patch.

Finally, if you do this on a fresh OpenWrt 18.06 tree (and not on the onion fork which already contains mt7688 SPI fixes), you also need:

• this one for making MT7688 hardware SPI work at least in pseudo-fullduplex (real full duplex is broken in MT7688 hardware) and to allow SPI transfers >16bytes.
• and this one is not technically needed but nice to have because it fixes the bogus error message at startup regarding SPI and DT.

With these patches in place, you can select fbtft and a suitable display driver in menuconfig (I use fb_ssd1306 with a tiny 128x64 OLED for now, because that's the only display I have right now, the bigger color LCDs I ordered haven't arrived yet). Then build the firmware and install.

fbtft and all dependencies are autoloaded at startup, but the actual display must be instantiated as follows:

# load the chip driver
insmod fb_ssd1306
# parametrize it via the `fbtft_device` helper module
insmod fbtft_device custom name=fb_ssd1306 busnum=0 cs=1 speed=16000000 mode=0 fps=50 gpios=reset:0,dc:1 width=128 height=64 verbose=3

After that, the linux framebuffer console automatically kicks in and the display shows a blinking cursor :-)

clear >/dev/tty1
echo "Hello World!" >/dev/tty1
echo "Hello Omega!" >/dev/tty1
echo "Hello OLED!" >/dev/tty1
# connect a USB keyboard and have a supertiny console:
login -f root </dev/tty >/dev/tty1 2>&1

This type of display with so-called 4-wire SPI needs some extra signals (dc, reset, see gpios part in the insmod fbtft_device command). The complete wiring of what you see in the photo is:

• GND = GND
• VCC = 3.3V
• D0 = SCK -> Omega SCK/GPIO7
• D1 = MOSI -> Omega MOSI/GPIO8 (NOTE: Omega2 does not coldboot when this is connected to the SSD1306 OLED, probably need to add resistor into the line or remove pullup/down on the display itself)
• RES = Reset -> Omega GPIO0
• DC = Data/Command -> Omega GPIO1
• CS = Chip Select -> Omega CS1/GPIO6

Next step will be a sample app with LittlevGL but probably I'll wait with that until I have a color display, will be more fun then ;-)

Yes, there is ;-)

A bit of context: OpenWrt (on which OnionOS is built) is a network router OS, and as such it needs to have a web-UI which can access and modify system configuration and status. This OpenWrt Web-UI is called LuCI

ubus (u=µ, micro bus) is one part of the infrastructure for that, as it allows to query and command various system parts. uci (the unified configuration interface) is another part, it allows to manage more static configuration in a standardized way, and is accessible via ubus.

So in order for LuCI to use ubus to do stuff, including using uci, there needs to be a http-to-ubus bridge, which comes in the form of a uhttpd plugin called uhttpd-mod-ubus. There's documentation about this here.

As I'm a user of stock OpenWrt on Omega2, I'm not absolutely sure about the exact state of OnionOS, but judging from the .config on github uhttpd-mod-ubus is installed by default and should be working.

So I guess you need to start at creating a ACL and read on to understand how how to login and get a session id via http.

@Angus-Ryan I'm currently experimenting in this field. I want to use the existing linux' frame buffer fbtft drivers as a solid abstraction layer to the display hardware and not directly talking to the controller chips.
Drivers exist in the linux kernel tree for ILI93xx, SSD13xx and other popular chips used in small TFT and OLED displays.

On top of the frame buffer device, I intend to use the LittlevGL on top as the toolset to create GUIs.

I have just started experimenting, but there are other users who already have worked with fbtft and have posted useful info here and here.

As far as I can see in Onion's published fork of OpenWrt, the fbtft kernel drivers are not yet included in the Omega builds.

My goal is to create proper patch sets to enable TFT support in a clean openwrt tree, and provide the needed packages to build littlevGL in my own openwrt feed

I just started doing that, I'll keep you posted about progress.

About specific links - I ordered this one from ali express to start with - it uses the ILI9341 chip. Hasn't arrived yet, hope it'll work ;-)

@Graham-Keellings The Omega2 is not using an ARM chip, but MIPS. That’s s a different architecture.

Still, I don’t think that the CPU architecture would be a problem. The thing to check is the resource requirements. The Onega2 has significantly less RAM than a RPi, is slower and the Linux running on it is a downsized distribution with an overall size of about 1/100 of what you have on a RPi.

Bottom line: it really depends on how fat adacore is and what extrnal libraries it needs to run.

But it seems other people have already done things with ada on OpenWrt - maybe you find more relevant info there.

Have a look at these annotated pinouts for Omega2(+/S) for seeing all possible pin functions.

1. Omega 2+ has three UART? I know about UART0 and UART1, but what pins support UART2?

@CAP-33 as @György-Farkas said, the answer to question 1 is GPIO16/17 for UART_TXD2/UART_RXD2, when you switch the GPIO multiplexer with omega2-ctrl gpiomux set spi_s pwm01_uart2

2. What pins support PWM and how to use them? (Is it possible to connect the servo motor?)

On the Omega2(+), only two (of the chip's total of 4) PWMs can be used. On the Omega2S you have all four.

There are three options for exposing PWMs:

• As pwm01_uart2 in the answer to question 1 suggests, using that statement not only enables UART2, but also exposes PWM0/1 to the other two SPI slave pins GPIO14 and 15. Of these, only GPIO14 and hence PWM0 is available in the Omega2(+)
• Using omega2-ctrl gpiomux set uart1 pwm01 you can expose PWM0/1 to pins GPIO45/46, resp.
• Finally you can enable PWM0/1 individually on pins GPIO18/19 with omega2-ctrl gpiomux set pwm0 pwm and omega2-ctrl gpiomux set pwm1 pwm

You can use the PWMs for anything that needs PWM, including servo motors. The MT7688 PWMs are very precise, it has 32bit range with a maximum resolution of 25nS.

3. What is it Group refclk, Group ephy and Group wled?

• Group refclk affects thg refclk pin (GPIO or clock)
• ephy should be named eled and can enable Ethernet activity LED output on GPIO43 (only Omega2S)
• wledcan enable WiFi activity LED output on GPIO44 (again, only Omega2S)

Hi @Chris-Morgan, I did not rebuild the boot loader so far, but just avoided using PHY pins for outputs that need to be stable during powerup in the projects I did since.

Would be nice though if @onion would (or maybe already has?) fix this in their bootloader, such that newer Omega2's would no longer suffer from that problem.

@cas I wish it would!

But I think the WiFi hardware Intellectual Property (IP) is something entirely different than the basic MIPS processor architecture.

But MIPS going open source it is a strong signal that hopefully will make other IP holders (for the Omega2 WiFi, it would be MediaTek) consider open source as a good option.

Hi @TomiCode

Very nice board ;-)

As a workaround, you could use software SPI instead of hardware SPI. Unfortunately you'd need to re-route the SPI connections to different pins, as the hardware SPI pins can't be switched to GPIO because SPI is needed for accessing the flash. For SW SPI just load the spi-gpio-custom module for example like:

  # bus<Y>=<devid>,<SCK>,<MOSI>,<MISO>,<mode>,<speedInHz>,<CS>
  insmod spi-gpio-custom bus0=1,1,2,3,0,100000,0

After this, you have a 100kHz SPI bus at /dev/spidev1.0 using GPIO0..3 for CS/SCK/MOSI/MISO in that order. For the mode parameter, see spi.h. I'm using this in several Omega2 based projects successfully.

Hi @Radim-Vesely

OpenWrt's sysupgrade probably already does a lot of what you need. For example, it has a simple mechanism to keep any files or directories across updates. Have a look at the files in /lib/upgrade/keep.d/, these list paths that must be preserved. You can simply put a file of your own there, listing the extra paths you need to be preserved (and usually, itself, to make sure it is also kept).

Also have a look at sysupgrade's -f option, which allows you to specify a .tar.gz archive which should be applied after the upgrade. This can even be a remote url, so you can utilize that to automatically install some extra things on top of a standard update.

So even without a custom image, you can already do a lot just with sysupgrade.

But of course, a custom image gives you full control of the entire distribution. For anything you need to maintain for a longer time, I strongly recommend it (having done a dozen projects this way already myself). There is a learning curve, but once you've get a bit accustomed, OpenWrt is a clean and comfortable environment to maintain even complex projects.

You can easily organize the extra packages you need in a source feed of your own (just a git repo somewhere). Copy feeds.conf.default to feeds.conf and add your feed url there. Then you can use the ./scripts/feeds utility to install (=make available for building) those packages, and once that's done, the packages from your feed will be available for choosing via make menuconfig, and including them into the firmware image at the next make.

Creating packages is not too complicated either, once you understand what it is: a meta-makefile describing a) where to get the source, b) what the depenencies are c) how to build, d) what build results or static files need to be copied where in the target system.
Fo simple packages you can omit a) and just include the sources into the package itself.

Now that's only a rough summary to give an overview. It's definitely worth digging in a bit, for example about the build system in general and creating packages. There's a lot more useful info in that wiki...

Most of my own custom builds are available with some explanatory README in my public openwrt feed. For example, p44ttngw-config builds a LoRA gateway firmware on top of LEDE 17.01.

@Alexandr-Didenko said in How to control WS281x RGB LED strip?:

• 1. If disconnect WS2813 from omega2 pin and connect again - then WS2813 behaves wrong.

Note that WS2813 DIN pins are quite delicate, and very easy to destroy or at least get a latch-up.

• Never send a data signal to a WS2813 which is not powered with 5V properly.
• if the cable is longer than a few inches, use a shielded cable for the data.
• maybe use a serial resistor in the data line to dampen spikes a bit - you have quite heavy undershoots on your scope diagrams you posted earlier in this thread.

• 2. First pixel sometimes shifting. For strip consisting of 10 LEDs - in programm we must write 11 LEDs

Sounds like a damaged first LED to me.

I thought it was a problem on my side. But no. It in Omega or yours side.

I'd be surprised.

Because in the meantime, I have used the exact same circuitry for a large installation with 20 Omega2 each driving 518 WS2813, and all of them ran 100% stable severals days uninterrupted. One of these panels still is in my office and I use it to test new stuff every day, and it runs practically 24/7.

Only one caveat: if you have software installed that makes use of the other hardware PWM unit's interrupt, please make sure to use the latest p44-ledchain (OpenWrt 18.06 build here), because there was a bug in handling the PWM interrupts.

@Daniel-Bachmann Yes, the MAC must be (and is) globally unique. However note that you should take the entire MAC into account, not only the last 16 bits (4 hex digits).

As you calculated, 16 bits allow only for 65536 different MAC addresses, and every Omega2 needs at least 2 of them, one for the WiFi and one for the Ethernet. So Onion will (or already has) run out of this range.

Onion currently got the MAC addresses 40:A3:6B:Cx:xx:xx assigned from the global MAC pool (see here for a quite complete list), which is a total of 16*65536 = 1048576 addresses. Should be enough for a while, but still, Onion might obtain another range at some point in time.

So as a really stable software ID, I would only use the complete MAC.

You can get the MAC by looking at ifconfig (or ip link) command line tool output, or using C/C++ code like the one I'm using for that purpose (macaddress.hpp/macaddress.cpp).

Note also that only universally administered addresses (UAAs) are unique, where locally administered addresses (LAAs) are not. The difference is in bit1 in the first byte, if it is 1, then the address is not globally unique. All MACs actually exposed to a network must be unique, but internal ones might be not. Onion addresses starting with 40 are unique, of course. But if you have IPv6 on, you see that a LAA is used to build the IPv6 link local address (starts with 42). More details -> wikipedia

@Cooper-Chan have a look at /etc/rc.d. There you see softlinks to scripts in /etc/init.d. At boot, the 'S*' link's scripts will be called in alphabetical order (the 'K*' links are for shutdown)

The user startup script /etc/rc.local is called from /etc/init.d/done, which is linked as /etc/rc.d/S95done.

The random seed init however is linked as /etc/rc.d/S99urandom_seed, that's why you see rc.local called before random is ready.

To change this order, don't change the links manually, because these are generated. Instead, disable the service you want to change the order for, edit the START=xx lines you find at the beginning of all scripts in /etc/init.d, and then re-enable it, like:

/etc/init.d/someservice disable
vi /etc/init.d/someservice
# edit the START=xx line
/etc/init.d/someservice enable

However, I would not change the existing done script, as it does other things the system might rely on.

Instead, just create your own script for example as /etc/init.d/zzready (zz prefix to make it alphabethically the last among all S99 scripts):

#!/bin/sh /etc/rc.common
START=99
boot() {
  # call your startup script here
  sh /etc/mystartup.sh
}

and then enable it for autorun:

/etc/init.d/zzready enable

hope this helps!