Posts made by luz

@sergiosmail do you get anything when doing the following?

root@pixelboard:~# cat /proc/asound/cards
0 [AudioI2S       ]: Audio-I2S - Audio-I2S
                      Audio-I2S

If not, please check that you have enabled the kernel package sound-mt7620 in menuconfig.

The 210-omega2-sound-max98357a.diff patch makes sure that the snd_soc_max98357a module should get automatically loaded at startup. You can check in /etc/modules.d:

root@pixelboard:~# ls -la /etc/modules.d/*sound*
-rw-r--r--    1 root     root           126 Jan 30  2019 /etc/modules.d/30-sound-core
-rw-r--r--    1 root     root            13 Jan 30  2019 /etc/modules.d/55-sound-soc-core
-rw-r--r--    1 root     root            72 Jan 30  2019 /etc/modules.d/90-sound-mt7620

root@pixelboard:~# cat /etc/modules.d/90-sound-mt7620
snd-soc-wm8960
snd-soc-max98357a
snd-soc-ralink-i2s
snd-soc-simple-card

Finally, before you can play sounds:

root@pixelboard:~# alsactl init
Found hardware: "Audio-I2S" "" "" "" ""
Hardware is initialized using a generic method

From here on aplay and other sound tools should work

aplay /path/to/sound.wav

If you want more control, such as a mixer with two separate volumes for background music and game sounds, look at pixelboard's asound.conf

Also, playing mod files is fun (need very littel disk space, lots of tunes can be found online), possible with the hxcmodplayer package

@zazu-z You already quoted the thread where I described my i2s adventures from a few years back now. I struggled a long time to get the extra codec I wanted to build, but in the end it was a few lines added to target/linux/ramips/modules.mk.

Maybe looking at my original patch here, which adds the max98357A codec, might help to do the same for any of the other codecs available (visible in build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/linux-4.14.151/sound/soc/codecs).

@Alexandr-Didenko thanks for pointing me to that old post! Apparently that was a cut&paste error of mine back in 2017
I just edited it to have it point to the github repo now.

And what we can to write in feeds.conf.default?
This: src-git plan44 https://github.com/plan44/plan44-feed.git?

Yes, I think that would work (master branch should be the default) but to make sure I usually specify the branch explicitly:

src-git plan44 https://github.com/plan44/plan44-feed.git;master

Note that if feeds.conf does not exist already, first copy feeds.conf.default to feeds.conf and then append the new line.

(Side note: It's a widespread error to directly edit feeds.conf.default, altough one should not! feeds.conf is the mechanism intended to customize your build , like .config or the contents of files/. All of these are NOT in the openwrt git repo, and belong to you. feeds.conf.default however belongs to openwrt)

You seem to have the wrong repo URL for some reason. Where did it come from? Probably a mistake on my part publishing that URL somewhere (it's the url to my private staging repo for preparing stuff before I push to github - and obviously not publicly accessible). If you can point me to where you got that url from into your feeds.conf, I'll correct it, of course

Anyway, just use github URL: https://github.com/plan44/plan44-feed.git , in your feeds.conf (or feeds.conf.default in case you modified that one) then it will work.

@Suman-kumar-Jha if you are creating a fixture for the manufacturing process, then you could include a ethernet connection into the fixture. As I wrote above, if you have ethernet, you can flash custom firmware images without manual steps except connecting ethernet and power.

Here's my bash script that can find and flash factory-state Omega2(S)(+) on an ethernet network segment: omega2flash.sh.
The script is quite q&d, and only programs one omega at a time as-is (but it could be extended easily to flash multiple devices, contributions are welcome).

@Paolo-carrer As @György-Farkas said, connecting a SPI peripheral to the SPI pins and using CS1 for selecting it should work fine.

The reasons for caution with the SPI pins are two-fold:

• the flash chip containing the firmware and user files is connected via these pins. If you use them in an improper way, it will likely affect access to the file system, crash the system or prevent it to boot, and if write operations are disturbed, also brick the Omega as a worst case. But as long as your external SPI device properly behaves and is off the bus when CS1 is not active, no problem here.
• In addition, the three SPI output pins (MOSI, SCK and CS1) also serve as CHIP_MODE inputs. This means right after reset or powerup, the logic level on these pins is sampled to configure how the chip starts up. To make these levels as needed at startup, the Omega2 has internal pullup and pulldown resistors on these pins. Now, if you connect something to these pins that has a lower impedance than those resistors, the CHIP_MODE will be wrong and the Omega will not start correctly. Again - a properly connected SPI chip should have high impedance MOSI, SCK and CS1 inputs, and will not disturb operation. But for example if you connected a LED to CS1 to see when your external device is selected, that would be a lower impedance and might change the CHIP_MODE at startup.

Note that there are more MODE pins that may not connect to anything of low impedance during startup for the same reason: GPIO1 (DRAM_TYPE), GPIO45/TX1 (JTAG_MODE) and GPIO12 (EXT_BGCK), and some more on the Omega2S.
That's why I marked them bright red on my extended pinout diagrams - it's too easy to forget about this when looking for a free GPIO otherwise

@Wing-Lok Omega2 or Omega2S? The latter has a separate flash supply pin to power only the SPI flash chip, but not the SoC, which allows programming the SPI flash chip if you have a suitable in-circuit SPI programmer for that (I did that once for debugging purposes using a borrowed Segger programmer).
I don't know if it's possible to in-circuit program the flash on the Omega2, maybe there's a way to keep the SoC reset with high-impedance SPI pins (but SPI_CS0 active), but I doubt it.

I do the firmware deployment for my custom firmware devices (~1000 in the field so far) via ethernet. This is possible without any manual interaction except connecting power and ethernet, and then waiting.

The key is that the factory firmware of the Omega2(S) has IPv6 running on the ethernet by default, with a link local address derived from the Omega2's MAC. And as IPv6 easily allows to discover device's IPv6 on the local link (e.g. ping6 ff02::1%en7), a simple bash script can find the devices, send firmware via scp, and launch sysupgrade via ssh. This can also be parallelized to program multiple devices at the same time (with more than one ethernet dock, or with devices that have ethernet built-in like mine do).

Hope this helps!

@Modest-Polykarpovich said in [Resolved] How use select()/poll() with GPIO?:

[...] Could you please send me 100% work your code?

I see that you solved the problem already - cool!

Bus just in case - my implementation is this one, which is part of a larger set of utilities handling other peripherals such as i2c, spi, pwm and a lot of other stuff, based on a common mainloop for timers and I/O polling.

Hi @Modest-Polykarpovich,
I am not familiar with libugpio but I am using GPIO interrupts a lot in my own C++ code by directly using the /sys/class/gpio interface.

So I can't be sure, but It seems to me that your code misses the step to actually enable GPIO IRQs. To do that, you need to write rising, falling or both to the file /sys/class/gpio/gpioX/edge (with X being the number of your GPIO).
Maybe there is a function in libugpio to do that...

Other than that, your code looks entirely fine to me.

See here for documentation on the sysfs GPIO API

Very counterintuitively, you need a command separator before then. So, instead of

if  [ "$1" = "1" ] then …

just write

if  [ "$1" = "1" ]; then …

Or put the then on the next line

 if  [ "$1" = "1" ]
 then
   …

(as you already did in the elifcase)

Just think of then, elif, fi, do etc. as regular shell commands that need to start on a fresh line or must be separated by ';' from the previous command on the same line.

I‘d say, lua. That‘s what the openwrt web UI (LuCI) uses, and I guess uhttpd-mod-lua should be installable (or maybe already is installed?) on OnionOS. I have no own experience, though, because I build my own openwrt firmwares from sources.

The OpenWrt build system creates the feeds automatically, along with building the firmware image. After a complete build, all feeds can be found in bin/packages/mipsel_24kc (within the openwrt build directory).
Just copy these files to a web server and let /etc/opkg/customfeeds.conf (on your Omega2) point to the feeds you need.

Of course, you need the OpenWrt build system for the Omega2 to get started.

To add your own feed, create a directory on your machine (or a git repository elsewhere) and put the packages you need there. You can copy whole package directories from other third party feeds, or of course create your own packages.

To make the feed known to OpenWrt, edit feeds.conf (if it does not exist, copy feeds.conf.default to feeds.conf first), and add a line like:

src-git myfeed https://myserver.com/feeds/myfeed.git;master
src-link myfeed /path/to/myfeed

(first is in case you have git repository, second is just linking a local feed directory). See openwrt docs for details.

Then, you need to install the packages (meaning: make available for building, says nothing about actually building them, that's what you'll do in menuconfig, see below) using the ./scripts/feeds utility:

./scripts/feeds update myfeed
./scripts/feeds install -p myfeed mypackage

(the -p myfeed part is only needed in case other feeds might also contain a package named mypackage, to make sure the version from your feed is preferred).

After that, mypackage will show up as an option in make menuconfig.
Now you can set it to M (build the package, but do not include it into the firmware image, which means that you can install it with opkg later) or * (build and include into firmware image).

If you want an example for a custom feed for Omega2, you could have a look at my own custom feed.

@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