Posts made by luz

@JP-Norair I'm still wondering what could be the difference between your Omega2 setup and mine.

Because in my current project (means: I heavily using the code every day), I am using poll() all the time. I also found that the library I'm using even occasionaly uses tcflush(TCIFLUSH) and tcflush(TCIOFLUSH) - I thought it didn't, in my previous post.

The read code is simple, when poll() returns a POLLIN, a single read() reads everything currently available. tcflush() is used only after detecting receiving errors (unexpected message lengths, crc errors).

What kernel, musl and openwrt version are you using?

My versions are linux 4.14.95, musl 1.1.19 and openwrt 18.06.2

All openwrt v18.06.x use musl 1.1.19. LEDE v17.01 was using musl 1.1.16, upcoming openwrt v19.07 will use musl 1.1.23, but I found no commit in musl since 1.1.19 I could relate to anything fixed regarding serial ports.

From the fact that @Lazar-Demin confirms the use of the standard 8250 driver, and the MIPS platform is not an obscure corner case for linux, I would agree that the problem is more likely a musl thing.

@JP-Norair thx for posting your findings! That's very useful to know.

Regarding your questions above: yes, I've been using poll(), yes I've transmitted binary packets with all values 0..0xFF. And the baudrate was 115200bd.

But, obviously, I haven't used TCIFLUSH.

I agree this looks like a driver bug.

But still I am surprised such a significant bug would be in Linux' 8250 standard driver without somebody having noticed and fixed it loooong ago...

Maybe I'm missing something and it's not the standard 8250 driver that is included in OnionOS builds?

hi @JP-Norair,

I am using ttyS* devices myself for very similar purposes (packet sending/receiving, high baudrates), with no problems so far.

So I wonder what exactly could be the problem your're seeing.

You wrote:

By the time poll() returns, the tty buffer is already long gone.

What exactly do you mean by that? Are you loosing incoming data?

IMHO the ttyS0 driver can buffer a lot of incoming data, so poll() speed should not be an issue, as long as you read() enough data at a time.

ttyS0 on the Omega2 is using the standard 8250 driver including the buffering mechanisms of the tty core. These buffers are dynamically allocated but can grow very large, the limit seems to be 2*64 = 128 kBytes (see TTYB_DEFAULT_MEM_LIMIT)

Based on what I can glean from testing dozens of different poll/read configurations, I think the tty driver keeps a buffer of only 8 bytes (which is probably just the hardware FIFO).

The device tree source for the mt76x8 (the target/linux/ramips/dts/mt7628an.dtsi file in your buildroot) shows the uarts specify ne16550a compatibility:

uartlite: uartlite@c00 {
    compatible = "ns16550a";
    reg = <0xc00 0x100>;
    ....

This will select the PORT_16550A configuration, with a FIFO size of 16 bytes.

But the hardware FIFO size should not matter for your problem - the interrupt response time of the Omega2 (~5uS) is way fast enough to empty that FIFO into the large tty driver buffers without loosing any data.

So I guess it must be something else than the serial driver's buffer size.

Maybe you can post a code snippet showing how your poll() / read() loop looks like?

@Lucas-Gozalvez

Why not just ssh into the omega and run logread -f?

For normal logging this should be sufficient. Of course, if you need to debug a kernel crash that brings down the system, you might need netconsole to see the "famous last words" of your kernel...

If you have the Onion Omega2 Firmware Build System already up and running, it's easy:

Just call

make kernel_menuconfig

And then navigate to -> Device Drivers -> Network device support -> Network core driver support and enable Netconsole.
Then exit the menu and save the config.

Now build the firmware on the openwrt level:

make
# can take hours if it's the first time you do it...

Now you have a complete firmware, containing a kernel with Netconsole built-in, or, if you had configured <M> in the menu and not <*>, the netconsole loadable kmod.

BTW: this generally works for tweaking kernel options that are not directly exposed in the openwrt level make menuconfig.
But as make kernel_menuconfig modifies the kernel config template files of openwrt, changes might interfere with changes openwrt later tries to apply on top.

@peter-garner-0 there is a ntpd installed and running already as client. In the init scripts it is called sysntpd, because it is a part of the openwrt base system.

The command line utility is named ntpd (technically it is part of busybox, like most command line tools are in openwrt).

Ususally, you don't need to manually call it, as it is set up to run at system start automatically. It synchronizes the time from the openwrt/lede pool of ntp servers by default. You can see these using openwrt's UCI configuration tool:

# show system's ntp settings
uci show system.ntp

You'll get something like:

system.ntp=timeserver
system.ntp.server='0.openwrt.pool.ntp.org' '1.openwrt.pool.ntp.org' '2.openwrt.pool.ntp.org' '3.openwrt.pool.ntp.org'
system.ntp.enabled='1'
system.ntp.enable_server='0'

If you want to change the ntp servers, you can do that using UCI as well:

# delete existing list of servers
uci set system.ntp.server=
# add one or more servers
uci add_list system.ntp.server='my-ntp-server.org'
uci add_list system.ntp.server='my-other-ntp-server.org'
# commit the changes
uci commit
# have (sys)ntpd reload its own config
/etc/init.d/sysntpd reload

@UFD BTW, regarding sound: my reason for wanting sound was background music for a game. So first I tried to get timidity working, but did not manage to get it play directly via asoc, and also found that it was a bit on the heavy side for the Omega2 with all the required instrument samples.

Then a colleague hinted me at hxcmodplayer, which can play the vintage .mod format (examples here) and is extremely lightweight. I packaged it for openwrt in my feed here, just in case ;-)

@UFD Sorry, I was wrong. Nothing extra appears in menuconfig. There already is a option sound-mt7620, but that's it. What the patches do is

• add the snd-soc-max98357a codec kernel module (in addition to the snd-soc-wm8960 that was already there.
• add a device tree node to actually load and configure a i2s sound output via a max98357a (in target/linux/ramips/dts/OMEGA2.dtsi). This makes the build work with a max98357 sound output. This device tree node would need to be changed to use the WM8960 instead.

Back then, I tried to make the codec modules appear individually in menuconfig. I wasn't successful, but because I suceeded later doing something similar for TFT framebuffer drivers, I forgot I failed for the sound modules and thought the codecs were selectable in menuconfig ;-)

I have i2s sound output with a MAX98357A running for quite a while, but I never used the original firmware.

With LEDE 17.01 (kernel 4.4) I never got it to run, it either crashed or at least produced no sound. But since LEDE master (which became today's OpenWrt 18.06) switched to kernel 4.9, it started to work fine. It still does with today's 4.14.

Since then, I build all my firmware by appling the following two openwrt tree patches:

• this one enables basic i2s and gdma support in the device tree
• this one makes ALSA sound components and the MAX98357A codec available in make menuconfig, and adds a simple audio out device in the device tree.

So I guess you'd be able to get working i2s sound by building your own firmware (see Onion Omega2 Firmware Build System on github) with these two patches applied, and actually enabling max98357 support via make menuconfig.

@Lazar-Demin any reason against adding these two patches to the regular firmware build?

BTW: the console / dmesg lines that when i2s is working:

[   10.257675] ralink-i2s 10000a00.i2s: mclk 480KHz
[   10.274881] asoc-simple-card sound: HiFi <-> 10000a00.i2s mapping ok

@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.