@Kegan-Brauning said in no wifi:
That is all fine and good but how do I 'wget' when I have no network connection? I am able to ssh in from another system [...]
Then you could wget the image to that other system and then scp it to the Omega2 (to /tmp).
But how are you able to ssh without a network connection?
@Armstead-Smith if the individual app is a package in a feed (can be a third party feed like Onion's, or your own), you can build it separately with
make package/MYPACKAGENAME/compile
This will produce a *.opkg package in bin/packages/mipsel_24kc/FEEDNAME. This can then be copied to the omega2 and installed with opkg.
Setting up your own feed with your own packages is not entirely trivial, but not really difficult either (with some time invested in reading up). I think it's worth doing, to get a nicely organized build.
If all you need is cross-compiling a binary without packaging, you could probably directly use the tools from the toolchain LEDE has build for you in build_dir/toolchain-mipsel_24kc_gcc-5.4.0_musl-1.1.16. You'd need a bunch of environment settings to direct compiler and linker to the correct headers and libraries - but I don't have practical experience with that.
@György-Farkas @Papy-Muzo sorry guys, I mixed up some information - my fault. You're right, STA only does not work with the Omega2 FW.
I'm mostly using stock LEDE, with the mt76 OS wifi driver which definitely can do station-only. I thought I had it also working on the Omega FW, but I mixed that up with Omega1 (and LinkitSmart7688)
Sorry, I should have checked before posting :-(
But why did it happen? Because the still-not fully open sourced (as promised) Omega2 FW divides the Omega community away from the LEDE community. Those that need their own kernel drivers (like me) can't use the Onion FW. So while I invest a lot of time in the Omega platform, like writing a fancy MT7688 hardware PWM LED chain driver, that effort goes into stock LEDE, and lets me (apparently) forget important details and drawbacks about the Omega FW...
Back on the technical level: Where does the proprietary Omega2 WiFi driver come from? Not MediaTek? So far I thought it was the same or a close relative of the LinkitSmart7688 WiFi driver, and that one does have a linkit_mode setting on the radio interface which can be set to ap, sta or apsta.
@Armstead-Smith Yes, the target still exists - no danger for it to go away anytime soon, the MT7688 is popular beyond the Omega2 ;-)
Assuming you got a current LEDE, such as the stable 17.01 branch from github: In menuconfig, under Target System ---> (first menu option), you should be able to find the MediaTek Ralink MIPS option.
Once this is selected (but not before!), in the Subtarget ---> menu you will find MT7688 based boards.
Once this is selected (again - not before), in the Target Profile ---> menu Onion Omega2and Onion Omega2+ will appear.
Then, you can type make and (depending on your machine) in 1-2 hours you'll have a stock LEDE image in bin/targets/ramips/mt7688 that will work with the Omega2. Note however that this is not the same as the Onion provided firmware - altough LEDE based as well, the latter is still not fully published, unfortunately.
Of course Omega2 can run in Station mode, as well as AP. And of course you can switch the AP off. Have you ever gone through the setup procedure of a Omega2?
AP is on by default so you have a way to connect to the Omega in the first place, and configure the station mode.
@ScrumpyJack Assuming you are using the Omega expansion dock's USB-A connector: This connector is powered directly (no electronics in between, see schematics) from the power supply you connect to the USB micro port.
So it's only that power supply which limits what you can draw from the USB-A connector - of course, within reasonable limits of thin contacts and wires, which I'd say is maybe 1.5-2A max.
According to specs, a USB device should not draw more than 500mA anyway. So I'd say one of these very common 5V/2A PSUs (like for RaspberryPi3) is sufficient for powering the Omega2 plus any reasonably standards adhering USB device.
Really, this is slowly but surely growing from a inconvenience to a real problem!
Because as it is now, you can only choose between:
I appreciate that you folks at Onion have worked very hard getting the hardware produced and shipped!
But not opening the Onion firmware build to the LEDE-savvy members of the community actually blocks contributions to the platform!
Cool things made by community members are limited to those (relatively few) who are willing to use LEDE and accept compromises regarding WiFi and Onion environment. The regular Onion firmware users cannot profit from these efforts. Same for detail knowledge - those that can go and understand details, and also potentially fix bugs, can't help those users with the regular firmware.
So @Boken-Lin @Lazar-Demin @Gabriel-Ongpauco @James-Liu and the entire @onion team, please give this some priority!
I spent the weekend trying to get this (Omega2 + MAX98357A connected via i2s) working. Not yet successful, but here's the status:
Most of the time I spent trying to understand ALSA (Advanced Linux Sound Architecture), ASoC (ALSA for SoCs), and what components and device tree entries are needed for finally putting a "sound card" together that can be used with the alsactl and aplay utilities.
Now I have such a setup, but unfortunately, trying to play a sound file with aplay immediately crashes the Omega2 :-(
In order to get the simple MAX98357A codec (similar to PCM5102 in that its a pure output device, with no i2c configuration) built, I had to do three things in LEDE (patches see below):
Then, in make menuconfig in Kernel modules -> Sound support I enabled kmod-sound-mt7620 and in Sound I selected alsa-utils
With this, I get a LEDE build where I can see that I have a "sound card" with cat /proc/asound/cards, and successfully (no error, no crash) initialize alsa with alsactl init.
But as soon as I try to aplay /tmp/mysoundfile, the Omega2 crashes apparently while memmapping something :-(
Any ideas welcome…
BTW: The pcm5102 will probably work with the soc-max98357a driver as well. The only difference I see is that the MAX chip has a input (SDMODE) to switch off the amplifier when not in use, via a GPIO. I set gpio 18 for that (via the sdmode-gpios line in the .dts), but it can be omitted.
Crash:
[ 322.634556] Kernel bug detected[#1]:
[ 322.638208] CPU: 0 PID: 1123 Comm: aplay Tainted: G W 4.4.61 #0
[ 322.645359] task: 83920000 ti: 83bba000 task.ti: 83bba000
[ 322.650828] $ 0 : 00000000 00000001 00000002 00000002
[ 322.656147] $ 4 : 8310f400 82d89948 82d89948 00004000
[ 322.661457] $ 8 : 00000018 80008c58 77c07000 00004000
[ 322.666770] $12 : 00001000 00006000 fffffffc 00004000
[ 322.672081] $16 : 8310f400 00000008 82d8c500 82c10600
[ 322.677389] $20 : 77c00000 77c04000 00000000 00000004
[ 322.682699] $24 : 00001072 77b74e00
[ 322.688011] $28 : 83bba000 83bbbdf8 00000000 83092250
[ 322.693321] Hi : 00000000
[ 322.696238] Lo : 00000004
[ 322.699223] epc : 83092160 snd_pcm_lib_default_mmap+0x30/0x48 [snd_pcm]
[ 322.706121] ra : 83092250 snd_pcm_mmap_data+0xd8/0xe60 [snd_pcm]
[ 322.712470] Status: 1100e403 KERNEL EXL IE
[ 322.716723] Cause : 10800024 (ExcCode 09)
[ 322.720787] PrId : 00019655 (MIPS 24KEc)
[ 322.724847] Modules linked in: i2c_gpio_custom p44_ledchain pppoe ppp_async iptable_nat pppox ppp_generic pl2303 nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE ftdi_sio cp210x xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG usbserial spidev spi_gpio spi_bitbang slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt snd_soc_simple_card snd_soc_ralink_i2s snd_soc_max98357a snd_soc_wm8960 i2c_mt7621 i2c_gpio snd_soc_core i2c_algo_bit ralink_gdma virt_dma mt76x2e mt7603e i2c_dev mt76 mac80211 cfg80211 compat ledtrig_oneshot ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables snd_pcm_dmaengine snd_compress snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_rawmidi snd_seq_device snd_hwdep snd input_core soundcore regmap_spi regmap_mmio regmap_i2c i2c_core regmap_core lzo_decompress lzo_compress leds_gpio ohci_platform ohci_hcd ledtrig_transient ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
[ 322.832567] Process aplay (pid: 1123, threadinfo=83bba000, task=83920000, tls=77c11d48)
[ 322.840675] Stack : 77c00000 77c04000 00000000 00000000 82d89948 80098938 00000000 00004000
82d8c500 00004000 000000fb 00000000 82d8c500 00000000 00000000 00000010
00000020 803e0000 00000001 82d89478 82d8948c 82d89488 77c00000 000000fb
82d8c500 00004000 00000001 00000002 00000000 00000004 82c10600 80098f38
77c09e24 00000000 83920000 83920030 00000000 832d9020 82c10634 82d8c500
...
[ 322.876798] Call Trace:
[ 322.879297] [<83092160>] snd_pcm_lib_default_mmap+0x30/0x48 [snd_pcm]
[ 322.885863] [<83092250>] snd_pcm_mmap_data+0xd8/0xe60 [snd_pcm]
[ 322.891903] [<80098938>] mmap_region+0x29c/0x544
[ 322.896589] [<80098f38>] do_mmap+0x358/0x3d4
[ 322.900943] [<8008a558>] vm_mmap_pgoff+0x70/0xb8
[ 322.905631] [<8009744c>] SyS_mmap_pgoff+0x8c/0xd8
[ 322.910413] [<8000682c>] syscall_common+0x30/0x54
[ 322.915178]
[ 322.916685]
Code: 24020002 14620002 00000000 <000c000d> 3c02830a 2442ce08 aca20048 03e00008 00001021
[ 322.926894] ---[ end trace 23ba50ddf57c2faa ]---
[ 322.934722] Fatal exception: panic in 5 seconds
[ 327.941901] Kernel panic - not syncing: Fatal exception
[ 327.949339] Rebooting in 3 seconds..
Patch for the makefile:
--- a/target/linux/ramips/modules.mk
+++ b/target/linux/ramips/modules.mk
@@ -120,12 +120,14 @@ define KernelPackage/sound-mt7620
KCONFIG:= \
CONFIG_SND_RALINK_SOC_I2S \
CONFIG_SND_SIMPLE_CARD \
- CONFIG_SND_SOC_WM8960
+ CONFIG_SND_SOC_WM8960 \
+ CONFIG_SND_SOC_MAX98357A
FILES:= \
$(LINUX_DIR)/sound/soc/ralink/snd-soc-ralink-i2s.ko \
$(LINUX_DIR)/sound/soc/generic/snd-soc-simple-card.ko \
- $(LINUX_DIR)/sound/soc/codecs/snd-soc-wm8960.ko
- AUTOLOAD:=$(call AutoLoad,90,snd-soc-wm8960 snd-soc-ralink-i2s snd-soc-simple-card)
+ $(LINUX_DIR)/sound/soc/codecs/snd-soc-wm8960.ko \
+ $(LINUX_DIR)/sound/soc/codecs/snd-soc-max98357a.ko
+ AUTOLOAD:=$(call AutoLoad,90,snd-soc-wm8960 snd-soc-max98357a snd-soc-ralink-i2s snd-soc-simple-card)
$(call AddDepends/sound)
endef
Patch for the kernel config
--- /dev/null
+++ b/target/linux/ramips/patches-4.4/0722-asoc-enable-max98357a-kconfig.patch
@@ -0,0 +1,11 @@
+--- a/sound/soc/codecs/Kconfig
++++ b/sound/soc/codecs/Kconfig
+@@ -487,7 +487,7 @@
+ tristate
+
+ config SND_SOC_MAX98357A
+- tristate
++ tristate "Maxim MAX98357A CODEC"
+
+ config SND_SOC_MAX98925
+ tristate
Patch for the OMEGA2.dtsi device tree source
--- a/target/linux/ramips/dts/OMEGA2.dtsi
+++ b/target/linux/ramips/dts/OMEGA2.dtsi
@@ -30,6 +30,31 @@
linux,code = <KEY_RESTART>;
};
};
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "Audio-I2S";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&cpu_dai_master>;
+ simple-audio-card,frame-master = <&cpu_dai_master>;
+ simple-audio-card,widgets =
+ "Speaker", "External Speaker";
+
+ cpu_dai_master: simple-audio-card,cpu {
+ sound-dai = <&i2s>;
+ };
+
+ dailink0_master: simple-audio-card,codec {
+ sound-dai = <&codec>;
+ };
+ };
+
+ codec: max98357a {
+ #sound-dai-cells = <0>;
+ compatible = "maxim,max98357a";
+ sdmode-gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;
+ };
+
};
&pinctrl {
@@ -51,7 +76,7 @@
i2s {
ralink,group = "i2s";
- ralink,function = "gpio";
+ ralink,function = "i2s";
};
spis {
@@ -170,5 +195,6 @@
};
&i2s {
+ #sound-dai-cells = <0>;
status = "okay";
};
@Luciano-S. It's a good thing LEDE and OpenWrt devs join forces again, sure!
However, it will not make any difference for the Omega firmware.
What would make a difference was when @Onion would finally fully open source their firmware build as promised, so that member of this community and Onion devs could join forces!
But as long as everything hinges on Onion folks finding time for it (which they don't, because they are too busy, and understandably so), progress stalls, and community enthusiasm is fading.
Onion, please allow us to help!
@mike-tedeschi unfortunately, after a seemingly perfect start with the patches from 20 days ago, the mt76 again behaves erratically for me as well.
Some days it works fine without a hitch for a long time, and then other days (like yesterday) performance is extremely poor and there are a lot of lengthy connection dropouts - without any change in the setup or wifi environment (as far as I can tell).
Still, I'm hoping they will eventually find the problem in the mt76 (psyborg and Daniel Golle apparently are working on it, e.g. see their slightly heated discussion over at the LEDE forum ;-)
Because I hate the hassles with scraping binaries from some other projects and then being tied to a specific kernel version, which prevents going with other LEDE improvements etc.
It would be different if for example Onion itself (hello @Lazar-Demin) would provide a daily bot-built binary blob of their driver matching the latest LEDE release, not only their specific Omega firmware…
@Chris-H not specifically for Windows, but I'd say better use one of the "make clean" options provided by LEDE than deleting stuff manually: see here.
@György-Farkas good find! Maybe you should change the title to something like "Useful info on power consumption", so people struggling with power supply issues will see it ;-)
:-( indeed.
But then, batman is already quite advanced WiFi usage.
Still, could be worth posting the trace to LEDE forum.
The device tree is baked into the firmware, and AFAIK (please correct me if I'm wrong) there's no easy way to put device tree overlays somewhere such that the Omega picks them up durig boot, unlike RPi.
If you want to modify the device tree, you'll need to build your own LEDE firmware. This by itself is doable (needs some time and disk space, though), but as Onion still hasn't released all parts of their own firmware you'll not get the same firmware but a stock LEDE. You can add some of their extensions that are on github, but their WiFi driver and other stuff is missing.
Having said that - the device tree source files for the Omega2 in LEDE are at target/linux/ramips/dts, in particular OMEGA2.dtsi (common stuff for Omega2 and 2+), OMEGA2.dts and OMEGA2P.dts.
@György-Farkas said in [Custom Omega 2 Expansion Dock. Need feedback]>
@Vijayenthiran-Subramaniam Sorry for this OFF.
Nice project. USB host port usually is a female A.
Good luck!
Nice project, but I would second @Vijayenthiran-Subramaniam - male USB A won't work because the Omega2 USB is a host port, and can't be run in device mode (see me raising the question here and @Chris-Stratton providing a definitive answer here)
@Marcin-Debowski @Thomas-Mason
I've been using the HLJ-6115ANL from iTead (datasheet here) successfully for a few projects.
The main advantage over the Bel Stewart is that it has the pins for PPoE (passive power over ethernet, i.e. DC+ on 4/5 and DC- on 7/8). And it's even less expensive.
@Thomas-Mason The EasyJack is not just a connector, it has built-in transformers, see datasheet of the SI-52003-F.
Without the transformers, you'll create direct DC connections between Ethernet cable and the Omega2. You might get away with that because the other end will have a transformer, but probably impedances are wrong and if you pick up any significant DC voltage (e.g. a PoE capable switch) on the cable, it will fry the Omega2. So I'd say - definitely not recommended.
@Douglas-Kryder The MT7688 does have four quite sophisticated hardware PWM units, however only two of them (pwm0, pwm1) have pins exposed on the Omega2. See here for some information , albeit in the context of generating WS281x LED signals.
I did not realize Modbus is RS485.
Does this mean that I already built a triple Modbus dock by accident by doing this? ;-)
(3 RS485 interfaces, Ethernet, 5..39V to 3.3V regulator, fitting into nice small Hammond 1591XXA case - designed to control Swiss Railway split-flap display modules)
@Fabian-Nydegger Interested, sure! Just no immediate application for it ;-)
I'm using Omega2 in my building automation devices already, but no Modbus (yet).
What is your application?