Is there a unix shell on this planet that does not have the -c option? :-)
But yes, there's no clear path leading to busybox shell docs, until one starts digging a bit harder, which I did a while ago:
The busybox shell originates from the almquist shell (ash). ash became dash when is was ported to debian, and later became the default /bin/sh on ubuntu. And ash was also included into busybox.
So when you want to know something about the busybox shell, the closest match is a dash man page.
It really depends what your demands are regarding WiFi.
If you can live with mediocre WiFi performance (for now), then use LEDE. You can build everything that is on the original Omega FW that way, except for the wifi driver. Onion uses a proprietary driver they can't publish, stock LEDE uses the fully open sourced, but not yet fully fine tuned, mt76 driver.
For all of my Omega2 based applications I built my own distro / FW image from LEDE, tailored to the use case. There is a learning curve to LEDE, but once you get a feel for it, it's a really nicely organized distro builder for tiny platforms.
For example you can start here, read about LEDE on their site and of course search this forum, which has a lot about custom FW builds.
If you want to get something as close as possible to original Onion FW, then you can start with their LEDE tree which is finally publicly available.
@Chris-Stratton Ah, that explains a lot - didn't know that.
Fortunately, the uboot env as such works on the Omega2. I use it to provision some information for my targets that must survive even when completely re-flashing the LEDE firmware. This works fine after the environment is saved once in uboot or (luckily) on a brand new Omega2 with the bootstrap firmware (the one that asks for WiFi and then updates to the real FW).
Actually, knowing that MT7688 systems do not make use of uboot env relieves me a bit - I was still a bit anxious I might have not understood all details and possibly causing problems using the env as I do.
You write "Omega 2S" - are you actually referring to the new SMD Omega2S? If so, then the answer is yes: GPIO43 is configurable as direct LED output for Ethernet activity (and GPIO44 is the same for WiFi).
On the Omega2 and Omega2S however, MT7688 pins GPIO43 and 44 are not exposed, so it does not work as easily.
Linux' LED support has a plugin module kmod-ledtrig-netdev intended for showing network activity on any GPIO, so you might be able to use that. See here for info about kernel LED support. But I have no idea whether the Omega2's networking drivers actually provide a trigger source for that mechanism.
@Burton-Strauss generally speaking, true - but in this particular case an important part of the bootloader configuration mechanism seems to be broken. That's not something that Onion should just ignore…
@Xplatforms said in [Resolved] Attaching PCM5102 to Omega2 (I2S):
@luz I'm asking because of that comment from onion admins:
in this topic: https://community.onion.io/topic/287/solved-i2s-pins-on-omega/5
I see. No idea why Boken came to that conclusion - but then, that was two years ago with the Omega1/AR9331. Could well be that ASoC (ALSA for SoCs) wasn't ready back then. After all, ASoC for the MT7688 started working apparently only with a kernel newer than 4.4.
Can you share your image for test purpose please?
The image is highly customized for the application (the "pixelboard" - tetris/game-of-life lounge table)), so it might be a bit difficult to use, but here's the image where aplay works via MAX98357A. You might need to enter "failsafe" mode and edit out the "*" in /etc/shadow for the root user to be able to login.
@Xplatforms I haven't really tested it, because in my application it's for game sounds (more beeping than music) and connected to a very tiny loudspeaker of limited quality.
But I see no reason why the sound should be inferior to USB soundcards. i2s as such is lossless, it only depends on the output chip and its specs. I am using the MAX98357A, a really tiny (3x3mm housing) class D mono amplifier chip designed for phone and tablet speakers, and I'd say my setup sounds like a phone.
On the contrary, USB sound is much more complicated and probably also needs more CPU time from the Omega2.
@György-Farkas It's no immediate problem, but something not entirely clean either.
The environment here means the u-boot environment variables (configuration of the bootloader and the linux boot process), which are stored in a flash partition u-boot-env of their own:
root@xyz:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "factory"
mtd3: 00fb0000 00010000 "firmware"
mtd4: 001393d6 00010000 "kernel"
mtd5: 00e76c2a 00010000 "rootfs"
mtd6: 00a00000 00010000 "rootfs_data"
There is a utility called fw_printenv which is supposed to display the environment, and fw_setenv to change these variables. These tools need /etc/fw_env.config to be present. For some strange reason, this file sometimes does not exist on a fresh Omega2. You can create one manually with
echo "/dev/mtd1 0x0 0x1000 0x10000" >/etc/fw_env.config
After that, fw_printenv works, but shows the same CRC error message you see in dmesg, because the data it tries to access is not valid.
However, when you start your Omega into u-boot command line (connect console, hold button and then switch on power and quickly press 1), you can see what really is in the uboot environment:
U-Boot 1.1.3 (Oct 18 2016 - 17:30:55)
Omega2 # printenv
bootcmd=tftp
bootdelay=5
baudrate=115200
ethaddr="00:AA:BB:CC:DD:10"
ipaddr=192.168.8.8
serverip=192.168.8.1
stdin=serial
stdout=serial
stderr=serial
From here, the uboot-env is writable, like:
setenv myvarname myvalue
saveenv
When you now boot the Omega again normally, and then use fw_printenv, there's no CRC error any more, and you see the same info as from the uboot command line.
Conclusion: something is wrong in the way the u-boot env is initialized on the Omega2, such that no correct CRC value is written.
To track down this entirely, we'll have to wait until Onion also publishes their modified u-boot - soon, I hope, now that they finally published their LEDE tree)!
@Lazar-Demin what about also publishing the modified u-boot?
(because, according to Murphy's law, it turns out that one of the issues I wanted to fix for a long time - incorrect initialisation of GPIO18/19 as AGPIO - is probably in the bootloader…)
@Jeff-Seese Nice solution!
However, in my case I had to find a way to provision (also, several hundreds) of Omega2, but only connected via Ethernet - without access to the serial port.
The solution was using IPv6: altough a factory-new Omega2 initializes the ethernet at boot, it does not configure a IPv4 address for it. But the ethernet interface does get a IPv6 link local address!
So what I did was using a Linux box (actually, LEDE as well, on an Alix 2D3) with a spare Ethernet port.
When an Omega2 is connected to that port, one can easily find its IPv6 link local address via ping6 (assuming eth2 is the separate ethernet interface):
ping6 -c 2 -i 4 ff02::1%eth2
This is a multicast ping to the all nodes address, and causes all connected devices to respond:
PING6(56=40+8+8 bytes) fe80::1884:720:42ce:499d%en14 --> ff02::1%en14
16 bytes from fe80::1884:720:42ce:499d%en14, icmp_seq=0 hlim=64 time=0.246 ms
16 bytes from fe80::42a3:6bff:fec1:28e3%en14, icmp_seq=0 hlim=64 time=0.765 ms
16 bytes from fe80::42a3:6bff:fec0:cfaf%en14, icmp_seq=0 hlim=64 time=190.962 ms
The responses include answers of the local linux box's own ethernet interface, but as the IPv6 link local address is derived from the device's MAC address, the Omega2's can easily be found: those with IPv6 in the form fe80::42a3:6bff:fec0:xxxx.
Knowing the IPv6, one can now login via ssh using the standard root/onioneer login, and from there do everything needed to provision the device. In my case, that's setting some uboot env vars and then uploading and flashing my own LEDE image.
The only hurdle on that path was automating a password based ssh login to a unknown device. There's a utility called sshpass that allows specifying the password on the command line. But there's also the host check that must be overridden - dropbear's ssh can do that by specifying the -y option twice, but dropbear's scp couldn't do the same, so I had to patch it (just let me know if anyone is interested in that patch).
BTW: this also works from any Linux or Mac without separate ethernet port. I needed the separate ethernet segment only for a subsequent test step which involved DHCP and IPv4 that should not mix with my normal LAN.
@sza2-sza2 thinking about it, it is likely AGPIO is enabled in the bootloader already. Onion's modified uboot for sure can use the ethernet, and probably that code was originally written for router-type boxes with all ethernet ports enabled.
Unfortunately, as per now, we don't have the Omega uboot source, so no way to check or even patch. But I hope this is only a matter of time, as it was for the LEDE tree which is finally available now!
@sza2-sza2 wow! Impressive analysis and I admire your patience to figure that out!
Indeed, that is useful to know. Technically I had „solved“ the problem with directly writing to the AGPIO_CFG register, but I was wary of that hack without knowing why this was needed in the first place. Now I feel better ;-)
LEDE is a router box OS, so it makes sense it makes the choice for Ethernet (AGPIO) by default. But still, it has to make that choice at some point, because after reset, the MT7688 is not in AGPIO mode. So there must be code somewhere else which enabkes AGPIO mode on in the first place. Probably low level ethernet init code...
IMHO it would make sense for a non-router device like the Omega2 to never ever switch these pins to AGPIO, because otherwise there's a short period of unpredictable signal level left between reset and the time whatever code has a chance to switch back to GPIO mode, making them unusable for some purposes.
Your work motivates me to dig in a bit and find (and eventually patch) that initialisation code :-)
@Lazar-Demin I'm really glad about the open source LEDE tree! Thanks!
As I am just on my way to vacation right now, I can't dig deep into it right now ;-)
But regarding PWM, the only thing that seems missing (I couldn't actually test, just compared my tree / .config with yours) is actually enabling it in the device tree.
I had to append
&pwm {
status = "okay";
};
at the end of target/linux/ramips/dts/OMEGA2.dtsi to make the /sys/class/pwm interface work for me with kernel 4.4 (lede-17.01), so it should work for the Onion FW build.
With kernel 4.9 however, (LEDE master) there seems to be some resource conflict over GPIO18 and 19, which makes the PWM driver fail at load. Couldn't find out details yet.
@Lazar-Demin Thanks for the effort that led to finally open sourcing your LEDE tree!
Rearding WiFi: why are you developing yet another WiFi driver? Why don't you put the efforts into improving mt76? mt76 has made a lot of progress lately, and is really usable now. For me mt76 is already stable enough to prefer it to any of the closed drivers, because - it is open!. Also, it seems to me, the config is more consistent. And the AP can be turned off.
@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!