@Zebulon-McCorkle I would like to get an official footprint from Onion as well!
However, for the time being, you might want use my KiCAD library. It has a Omega2S footprint which I could already test to some degree (manual soldering on one prototype board - I had access to an early Omega2S sample).
So that footprint should be fine, but of course, it's not official and there can always be details… Just create a PR on github if you have improvements…
@luz said in About U-Boot bootloader:
BTW: I would prefer Onion spending time for developing cool new hardware they can sell for profit and sustain the company, rather than struggling with the tedious maintainance of a private LEDE tree!
As it turns out (today's newsletter revealing it) - they did develop new hardware: the Omega2S :-)
This one is targeted at OEMs, meaning people who use the Omega2 platform in their products - and rely on being able to build everything from sources! So finally publishing not only the complete LEDE setup but also the U-Boot modificiations gets essential now!
@Douglas-Kryder yes, I tend to believe in good intentions until proven otherwise.
You can call me naive ;-)
But really doing open source is not easy - it's already not trivial to get the feel for open source as a developer, but it's unbelievable to see again and again how difficult it seems to be for decision makers. There's still a deeply ingrained anxiety that opening means giving options away, and thus could be a bad business decision. So even with good intentions, things tend to get stranded midway - instead of pushing through into the profit zone of real open source, which is free development resources!
Had the firmware build been available for improvement (rather than replacement by stock LEDE as it is now), I bet the community would long have fixed many general Linux/LEDE/chipset issues and many questions on this forum could be answered by a simple link to a improved/fixed firmware image.
BTW: I would prefer Onion spending time for developing cool new hardware they can sell for profit and sustain the company, rather than struggling with the tedious maintainance of a private LEDE tree!
@Patryk-Wychowaniec said in PWM available on which dock?:
There's no PWM mechanism in Omega 2 itself so I think there's no way it is available on the mini dock or power board.
Of course there is! The MT7688 has a four channel PWM unit, 2 of them can be made available on Omega2 gpio pins 18 and 19 (using omega2-ctrl).
I use these PWM units to drive WS28xx-type LED chains.
There's even standard kernel support for these PWMs - see "Using PWMs with the sysfs interface" paragraph of this document. Problem here is that this is not enabled in the standard Omega FW build so far, and because that build is still not fully open source (to lament once again) , there's no easy way to enable it. But if you can build your own LEDE FW images, the PWMs are easy to use and very precise.
@sza2-sza2 it works now!! :-D
Thanks a lot for the detailed steps!
I was using lede-17.01 before, which is still on kernel 4.4 and had the problem with DMA that made it either crash or (with my attempt to fix it with 942-omega2-dma-bughunt-WIP) not transfer data to the output.
Apparently, some work and bugfixes for the mt76xx SoCs got upstreamed into Linux mainline between 4.4 and 4.9. At least, the DMA related LEDE patch target/linux/generic/patches-4.4/132-mips_inline_dma_ops.patch that contains the code which was causing the crash, has disappeared in LEDE master.
Anyway - i2s sound output with max98357a works now, with less patching than before! Great!
But no advance without new problems - with kernel 4.9 the PWM support (/sys/class/pwm/)… does not work any more, because it tries and fails to claim gpio18 for some unknown reason, which is already claimed by something else, for another unknown reason ;-)
As much as I like the Omega2, so annoying it is to see what a terribly hard time the onion devs seem to have to fulfill their GPL obligations, be it for the full LEDE setup, be it for the modified U-Boot :-(
The latest changes in the published LEDE clone in Onion's github are from January.
Come on, even Apple has learnt to develop in the open! Please @Lazar-Demin just push that LEDE tree of yours, including the .config, /files/* and possibly patches! And UBoot! As is!
Nobody expects an untagged master branch to be anything but work in progress! If it does not build as-is, if some packages are missing because they are copyright issues (proprietary Wifi driver?) - still much better than months and months of void!
And it would really be sad if you were working hard (I'm sure you are!) for the next Omega2 firmware without giving the community a chance to contribute to it!
@sza2-sza2 Wow! Terrific news!!
Thanks a lot for the nice diagrams (Saleae Logic is great ;-)
Did you apply all of my patches, in particular, did you apply 942-omega2-dma-bughunt-WIP?
Because since that patch, I can use aplay without crash, and I even see the WS clock running during the time a sound plays, but there is zero output on the data line. So I thought that something is wrong in the DMA setup, such that no data reaches the i2s engine. But if it works in your case, it can't be a fundamental DMA problem. Maybe something as mundane as a short on my PCB… (I'll re-check that, although needs some time to disassemble the pixelboard)
BTW: what is the SHA of the LEDE (git rev-parse HEAD) you've been using?
@Diego-Sueiro I didn't say exactly that, I'm well aware that you can build for tiny targets with Yocto ;-)
What I was saying is that I found yocto as a build environment is much more complicated and heavy than LEDE/OpenWrt. Of course, it needs to be, because it covers a much wider range of targets that LEDE.
But to target Omega2-like devices, I found LEDE refreshingly clear and simple to work with (after some work done with Yocto before).
@sza2-sza2 here's my lsmod snd section:
snd 40910 10 snd_soc_wm8960,snd_soc_core,snd_compress,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_rawmidi,snd_seq_device,snd_hwdep
snd_compress 6303 0
snd_hwdep 4350 0
snd_mixer_oss 12761 1 snd_pcm_oss
snd_pcm 63018 5 snd_soc_ralink_i2s,snd_soc_wm8960,snd_soc_core,snd_pcm_dmaengine,snd_pcm_oss
snd_pcm_dmaengine 2779 1 snd_soc_core
snd_pcm_oss 35825 0
snd_rawmidi 15402 0
snd_seq_device 2191 1 snd_rawmidi
snd_soc_core 97120 4 snd_soc_simple_card,snd_soc_ralink_i2s,snd_soc_max98357a,snd_soc_wm8960
snd_soc_max98357a 1776 1
snd_soc_ralink_i2s 6064 2
snd_soc_simple_card 5216 0
snd_soc_wm8960 22720 0
snd_timer 15598 1 snd_pcm
soundcore 3836 1 snd
The difference to yours seems to be that in my case snd_soc_ralink_i2s has a use count of 2.
I'd guess that snd_soc_ralink_i2s not being used at all must be something in the device tree, so below are my target/linux/ramips/dts/mt7628an.dtsi and target/linux/ramips/dts/OMEGA2.dtsi files. I would have preferred to upload them here, but board software says I am not allowed to upload?! Pastebin, then.
@Venet said in Wifi connection problem with Omega2:
@luz Did you remove the resistor as suggested by Ken Konrad, so as to disable the internal antenna?
No, I didn't.
Now as you mention it, I remember having read that suggestion a while ago. Sounds like a logical thing to do - but as good as the WiFi is now as-is, I feel no immediate urge to treat my Omega2 with the soldering iron ;-)
@elefas-GR said in Wifi connection problem with Omega2:
So my 2 cents on this adventure is to make sure that your Omega2 and your router are very close to each other when you are trying to connect.
For the same reason, connecting an external antenna can help a lot, I recently learned!
I had a case where connecting the Omega to the access point was really impossible. By chance I had a 2.4GHz WiFi antenna plus connector cable lying around (belonging to other equipment) that matched the Omega2's antenna connector. I connected it without expecting too much, but - wow! The signal strength as shown by iwinfo was 30db better. That's a huge improvement! And that Omega works fine since, in the exact same environment where I wasn't able to even establish a connection a single time before.
@Keitaro While opening the complete setup to build matching kernel modules is definitely something @onion should do (@administrators, @Lazar-Demin, hello again…), there's a ugly workaround for this: you can just force the module to load:
opkg install --force-depends kmod-gpio-irq_4.4.71\+HEAD-1_mipsel_24k.ipk
This is not without risk - if kernel internals have changed too much between the kernel you are running and the kernel the module has been compiled for, this will crash the system or cause any other undefined behaviour.
Having said that, the kernel APIs used by kmod-gpio-irq haven't changed between kernels 4.4.46 and 4.4.71, so it should work in this case.
Hi @sza2-sza2,
glad I'm not the only one still trying to get this working ;-)
Maybe you can compare your LEDE diffconfig with my diffconfig that you find here at github. This should reveal what things are missing/different.
The diffconfig ist the delta between a fresh LEDE default configuration and the configuration used to build a particular image. To create your diffconfig:
./scripts/diffconfig.sh >"diffconfig-for-my-setup"
I'm usually building my images from the lede-17.01 branch, my last attempt with alsa soundcard present, but not sound coming out the i2s was built from commit 524ed5088e900821307694180d77038df5a3ea9a. I also apply a few more patches to LEDE than the ones shown above (all patches are collected here), but none of the other ones should be relevant for i2s/sound.
Hope that helps. It would be nice if we can figure out i2s sound eventually!
The original poster said that he hit it and it eventually started working again, which doesn't seem ideal.
Maybe not ideal, but better than a nonworking relay. When the relay contacts are stuck together because of only a bit of micro-welding, a mechanical shock has a chance to unstick them. But of course, that's not a fix for the missing contact protection, so…
[...] Is the Relay Expansion faulty?
Probably not - it's just that relay contacts can't just switch any load, even when nominal voltage and current seem in range.
If the load is not purely resistive (few are), there are always current and voltage spikes you need to take care of to protect the relay contacts. And because the needed measures depend on what you connect (AC or DC - see my attempt to explain it in that lengthy thread referenced above), that can't be part of a generic relay expansion.
If the relay specs are far above your actual load, you usually get away without any protection. But a pump for a pond sounds more like it could be near the specs, so there's probably no wide margin left for the contacts to "swallow" spikes without damage.
This is probably the inductive load of the pump that welds the relais contacts.
There's a lot of information about that in this somewhat older thread
@Alfonso-Blanco There are two general problems with the hardware SPI:
The SPI is already in use for accessing the flash chip inside the Omgea2. So you always have to share the hardware SPI with the operating system's need to access the flash (file system). This means you don't get the full bandwith, and if something goes wrong on the SPI, there's a high probability it will affect the file system's operation or even its integrity.
The hardware SPI in the MT7688 chip cannot do full duplex - only half duplex.
So in many cases, GPIO based software SPI is the better and safer option.
Of course, if you have very specific needs requesting hardware SPI, and sharing with flash / half duplex are no problems for you, then using it is possible.
@Paul-Wright If you just want to drive neopixels from the Omega2, you can also do that without Arduino dock using my PWM based kernel driver for WS28xx type LEDs. It just provides a linux device /dev/ledchainx, where you write a string of bytes representing the RGB (or RGBW, for SK6812 LEDs) values of the LEDs.
@Lachlan-Peter how did you do the factory reset?
With the /overlay having almost the same size as /rom, I would guess something in the update/reset process has duplicated most of the firmware into the overlay, for some reason, instead of completely emptying it.
I would have a look into /overlay, that's where you can see the files which occupy those 7.3M.
@LaurentN Although I'm not fluent at all in Python, I'd say there's no reason why Python should not work fine controlling LED chains with p44-ledchain.
@LaurentN said in WS281x, SK6812 driver for the Omega2? [Solved]:
However sometimes (especially when I have to calculate the RGB values and then compose the string), I get an error 'ValueError: invalid \x escape'
That sounds like you are trying to use the literal string syntax (the backslash escapes in \xhh form, with hh being a two-digit hex number) to construct your string, but maybe in a way that sometimes outputs only one digit instead of two, which could be the cause of the ValueError?
Probably there's a more direct way to get numeric byte values into a string or byte array in Python.
@Laurent-Nittler yes, you can dim (and color) every LED separately!
In fact, the bytes you write to the /dev/ledchainX device correspond to the brightness (duty cycle) of the red, green and blue part of the LEDs (and a separate white LED for SK6812). With this, you can set any color and any brightness.
Let's assume you have WS2813 connected to PWM0, then
echo -en '\xFF\xFF\xFF' >/dev/ledchain0
switches the first LED to full white brightness (255=0xFF = full on for all three R,G,B channels. Whereas:
echo -en '\x7F\x7F\x7F' >/dev/ledchain0
sets all three LEDs to half duty cycle (127=0x7F)
A somewhat dimmed green (red=off, green=160=0xA0, blue=off) would be:
echo -en '\x00\xA0\x00' >/dev/ledchain0
and so forth.
To control more LEDs, just write a longer string to /dev/ledchain0, 3 bytes for every LED in the chain (4 for RGBW LEDs like SK6812).
Of course, you wouldn't do that with echo except for the first manual tests, but using some script/program that calculates the string to be sent to /dev/ledchain0.