Posts made by luz

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!

@Paolo-Ciuffetti it seems that this is related to @Dino-Ciuffetti 's question on another thread, is it?

As you say, I also guess it's a matter of getting /etc/config/network right, and understand swconfig. Most probably (but I'm not sure), enabling/disabling the switch is not something that can be done while up and running, but must be set up in the startup sequence.

I would try to glean information from existing MT7688 based router's firmware (Minibox V2.0, androegg.de...).

@Dino-Ciuffetti said in Adding multiple Ethernet Ports:

Hi! I really need 2 eth ports in bridge on omega2s. Please help. I have no link on the second port even after switching pins to AGPIO. Anyone here with a working l2 switch? Tnx.

I intended to try it, and made a PCB with two Ethernet jacks (https://oshpark.com/shared_projects/3Ix9lK3Z). But then the project only needed one port, and I didn't find the time yet to dig deeper.

As there are MT7688 based routers using OpenWrt (Minibox V2.0, androegg.de), one could try to look at those firmwares or ask the people who configured it.

Basically, I'd guess it's tinkering with /etc/config/network and the swconfig utility.

What did you try so far?

Hi @davidsi,

For my C++ home automation daemon, I needed to advertise and discover services via Avahi and wrote a Discovery class for that.

It's not generic, ready-to-use sample code, and is not completely free of dependencies. In particular, it uses the MLTicket class from p44utils to implement regular calls to avahi_poll and for delaying advertisement.

But I guess it could still be of use for you to see how to set up and run avahi from C++ in general, and for an example of a wrapper class for a service browser (ServiceBrowser class near the end of the source file).

The code is such that it is normally linked against the avahi client library libavahi-client (the normal case on the Omega2, that's when the avahi daemon process is running and your app is one of possibly multiple clients using avahi services).

But when you define USE_AVAHI_CORE as non-zero, then the code can also be linked against the avahi core library, which can be handy on really tiny embedded systems where your app is the only avahi user and you don't want the overhead of the separate avahi daemon.

OpenWrt 18.06 is technically just the next version after LEDE 17.01 (which was, technically, just the next version after OpenWrt 15.05).

Only on a organizational level, there were different opinions and goals within the project that caused development to continue under the LEDE name for a while.

So I very much expect that a (hopefully near) future version of the Omega2 firmware will be based on OpenWrt 18.06.

In fact, a stock build of OpenWrt 18.06 works fine on the Omega2, incuding usable WiFi via the opensource mt76 wifi driver. Most user-space Onion additions will probably work with no changes (omega2-ctrl for example is fine), some Onion specifc kernel modules might need small adjustments in the opensourced code. However, the proprietary wifi driver needs to be updated for the newer kernel by Onion themselves.

@Artem-Reznikov said in Omega2S+. How to disable Ethernet LED on the GPIO43?:

That command will completely disable Ethernet PHY, isn't it? It is the way, but I already use EPHY in my design, so no.

No, the ephy label in omega2-ctrl is misleading, it does not control ethernet phys, just the LED.

See AGPIO_CFG register for enabling/disabling ephys 1..4 (all together either ephy or GPIO, unfortunatly it is not possible to selectively enable only one of them -. ephy0 however can be used separately, with ephy1..4 in GPIO mode).

When I was designing a PCB for Omega 2S, I haven't had all the docs, and as a result I've used some of I2S pins, almost all SPI pins, etc. (literally, all the pins that could cause boot and other problems when they are pulled up/down) as a GPIO.

I was in the same situation a while ago when trying to find a usable wiring of my first Omega2 and Omega2S circuits, with all those various constraints...

To see all options for all pins of Omega2 and Omega2S at a glance, I augmented the official pinouts a bit in a PDF, including boldface labels matching the pin names in the datasheet and red labels on the pins that must not be pulled up or down at boot. That started in a forum thread about this back in the first Omega2 days...

Still, this is my most often used PDF when designing new Omega2(S) PCBs, maybe it's of use for you, too.

Even if the APA102 did work without gating the signal by CS1, I would still strongly recommend to use a level shifter (which also can do the gating via CS1) in between.

Because if you look at the APA102 datasheet, it specifies a minimum high level voltage of 0.7*VDD, which means 3.5V. The Omega2 as a 3.3V device can never reach that minimum.

So while directly connected APA102 might work, it's more by accident and certainly not a reliable setup. Changes in temperature for example might make it fail. (I have quite extenisve real-world experience with that, the 7000+ RGB LEDs in this platform are driven by Omega2S via 74AHCT125...)

So my recommendation would be to use a 74AHCT1G125 (single gate) or 74AHCT125 (4 gates) to solve both level shifting and signal gating problems with one cheap chip.

@Artem-Reznikov said in Omega2S+. How to disable Ethernet LED on the GPIO43?:

I've tried to remove the kmod-ledtrig-netdev package, and it didn't solved the problem.

kmod-ledtrig-netdev is to make a generic GPIO show network activity. However, the ethernet activity LED signal on GPIO43 is a MT7688 hardware feature, no kernel code involved.

In system/config/leds there is no another LED , but just omega2p:amber:system LED, which is apparently not the one that I'm trying to find.

As it is a MT7688 hardware feature, you need to configure it at that level. The omega2-ctrl utility has a option to change this - I never used it myself but I guess it should do the trick:

omega2-ctrl gpiomux set ephy gpio

To understand the underlying mechanisms, have a look at the MT7688 datasheet, page 62, GPIO2_MODE register. This is where you can switch the mode for the LED pins.

The …AN_MODE bits are relevant, because the Chip in the Omega2S is the MT7688AN (the datasheet, obviously largely copyied&pasted, talks about MT7628, the near identical predecessor of the MT7688).

In case omega2-ctrl should not work, you could also use devmem to change these bits directly from the command line (provided that utility is included in the current OnionOS build, I'm not sure about that):

devmem 0x10000064 32 0x05550555

This will make all the LED pins work as GPIOs.

There's one caveat: using these pins as GPIOs is the reset state of the MT7688 (see datasheet). Which means that some code in the bootloader and/or Linux actually explicitly changes the mode to make GPIO43 show ethernet activity.
Now, as we don't know what code is responsible and when it is called, it could be that these bits are not only changed during startup, but repeatedly during operation, for example when initializing network (/etc/init.d/network restart etc…).

So I personally would not use GPIO43 for a hardware function that could cause real-world problems in case it suddenly receives ethernet activity flicker...

@Caio-Mehlem welcome to the wonderful world of mass market applicance SoCs ;-)

Note that MediaTek is on the good side! There is at least a datasheet!

For the AR9331 that was used in the Omega1, there was no official datasheet available at all, only a leaked preliminary draft with a lot of inaccuracies. When asking Qualcomm/Atheros for a datasheet as a SME, their answer was: order a million pieces first…

On the other hand, to be fair - this is a completely different market than the traditional industrial electronics you (and me) were used to with well-documented chips from TI, Atmel, NXP etc. The prices are also rather different...

BTW: There is a MT7628_ProgrammingGuide PDF floating around the internet which has useful information that also applies to the MT7688. A particular nugget for me was the "interrupt table summary" on page 11, revealing the PWM interrupt channel I needed for my WS281x driver. However, information about the PWM interrupt mask and status registers is totally lacking even there. Finally I found that piece information in a driver in the android linux kernel tree...

@Maximilian-Gerhardt Regarding the SPI issue: Have you tried to apply the patch from Bernhard Wörndl-Aichriedler bwa@xdevelop.at I used for my TTN gatway? For SPI communication with the RAK831 it does the trick.