Posts made by Peter Buelow

No, I think the most logical solution is to find the message in the kernel and rebuild the platform without it. However, that's more risk than I can take. I'll pry end up implementing my own syslog receiver so I can filter it out.

I've been hunting, but I'm not finding what I want. I know I can use sysfs to poll for GPIO interrupts, but Kit Bishop also had the GPIO signal interrupt working for the Omega. I'm wondering if that GPIO signal interrupt capability is available for the 2+ in the latest builds somehow? There is no gpio-irq kernel module available in opkg that I can find, and as built, /sys/kernel/debug/gpio-irq doesn't exist. I know I can build the gpio-irq .ko for this board, but am still working on getting kernel modules to build for the Onion. Hope to solve that today or tomorrow depending on time.

The big question is, does this still work like it used to, or are we limited to sysfs and poll()?

Thank you.

Thank you, it wasn't. I had forgotten the oledSetTextColumns() call. Fixed it, thanks for the reminder/help.

I have the latest firmware, 0.3.2 b218, and the C library for the OLED control seems to ignore newlines. Strings with newlines work fine if I write using oled-exp, but they don't when calling oledWrite("string"). Has anyone else noticed this? Is there a workaround?

I'm going to file a bug here shortly.

I suspect this is either a bug in the iwinfo binary, or just a missing bit of statistical data from the WiFi firmware. It doesn't work on mine either.

I suspect they do this to save money. There isn't a compelling reason to have an Onion on both WiFi AND Ethernet at the same time as the chip itself isn't that powerful, so the only problem it would solve is to allow the chip to be on two different subnets at the same time. The network speed won't improve much by having both connected. I suspect it's a trade off they chose to take advantage of.

DHCP servers generally use MAC addresses for association in a database. It gets the MAC, stores some association data, and then sends out the response package. Since the connection TO the DHCP server is functionally anonymous from the requester, using MAC provides a very easy way to store associated data for lease continuation and what not. What you are seeing is two requests from two different interfaces into a DHCP server which just sees the same request twice, so it sends back the same results twice.

There isn't much you can do about this, but the question would be, do you need both active at the same time? If not, turn one off.

Replying to my own. I don't see GDB in the package database, so I simply built it from the LEDE system and copied it to my target.

Is it possible to disable the following logd message?

kern.info ap_client: 'apcli0' assoc: yes, mac: 10:c3:7b:d1:e1:f0

This happens every 8 seconds while the unit is up. The problem is that I'm sending log data to my NAS as my application is using the logd service to write diagnostic and error data that I want to be able to keep. Can this message be turned off somewhere? It's not useful as a debug mechanism, and I can't filter on the NAS to ignore that message. It's drowning out my application data.

Thanks in advance.

Is this something dumb I'm doing? Why can't I get gdb on my Onion? Using the opkg install gdb command fails with a no package found. I can find valgrind, but that doesn't help, and is the only thing that really shows up when I dig into searching opkg packages. Is this something I need to build myself? I can do that, but would rather just install it. Or did I miss a step somewhere?

Running latest firmware 0.2.2 b200 if someone knows the answer. Thanks.

Did you ever figure this out? I think if you just want a server running, install the latest firmware, and you have one running. Connect your omega to a local wifi network, and you have a .local available address on your subnet. I do this as I use an Omega2 as my MQTT server for my local network. I changed my hostname to mosquitto and now through my network via the web console app and I can connect to this server using mosquitto.local from other hosts. It doesn't take a lot of setup.

Or, was your question related to something else?

Is there a way to get at DHCP option content once booted? I'm looking around etc and whatnot, but am not able to find anything specific? I'm trying to pass an MQTT server address via DHCP so I can "discover" it.

Or, another possibility, how do I get the Onion to resolve .local addresses? If this is a problem local to me, so be it, but I can resolve mosquitto.local on my other linux and Mac boxes, but not my Onions. That would also allow me to solve the problem quickly.

[0_1547501358778_onion-iot-gnulib-fread-problem.patch.gz](Uploading 100%) This is a known issue with some build systems and the latest glibc update to 2.28 (see gnu.org link below). Other packages have been patched already, including OpenWRT and lede. Onion needs to pull that patch in to their system. Otherwise, you must use 18.04 latest to build with. I have the same issue on my new laptop which runs 18.10, and have no mechanism for going backward to an older glibc. I have to lean on my KDE Neon desktop to do builds right now.

To the Onion people, can you find and apply patches to get this going? I believe these links will help identify the issues. I can't seem to apply the patches correctly to the build, but will keep trying to see if I can find a workaround.

https://lists.gnu.org/r/bug-gnulib/2018-03/msg00000.html
https://github.com/coreutils/gnulib/commit/4af4a4a71827c0bc5e0ec67af23edef4f15cee8e#diff-5bcce8ce55246264586c4aed2a45ff89

** Edit **
Adding the OpenWRT patch used to make builds work.
https://github.com/openwrt/openwrt/pull/1290/commits/e5d47f32131849a69a9267de51a30d6be1f0d0ac

** Edit 2 **
It looks like the patch is already applied, but two files need to be "fixed" to get it to build.
I have a patch, but I can't attach it here. I'll add text if it helps anyone. I am still building and will test soon, so I can't prove yet that this fixes the problem. However, it should be a good start no matter what. Good luck.

diff -Naur m4-1.4.17/lib/freadahead.c m4-1.4.17-patched/lib/freadahead.c
--- m4-1.4.17/lib/freadahead.c 2013-09-22 01:15:20.000000000 -0500
+++ m4-1.4.17-patched/lib/freadahead.c 2019-01-14 15:27:44.358019520 -0600
@@ -25,7 +25,7 @@
size_t
freadahead (FILE fp)
{
-#if defined _IO_ftrylockfile || GNU_LIBRARY == 1 / GNU libc, BeOS, Haiku, Linux libc5 /
+#if defined _IO_EOF_SEEN || GNU_LIBRARY == 1 / GNU libc, BeOS, Haiku, Linux libc5 */
if (fp->_IO_write_ptr > fp->_IO_write_base)
return 0;
return (fp->_IO_read_end - fp->_IO_read_ptr)
diff -Naur m4-1.4.17/lib/fseeko.c m4-1.4.17-patched/lib/fseeko.c
--- m4-1.4.17/lib/fseeko.c 2013-09-22 01:15:55.000000000 -0500
+++ m4-1.4.17-patched/lib/fseeko.c 2019-01-14 15:27:57.733774421 -0600
@@ -47,7 +47,7 @@
#endif

/* These tests are based on fpurge.c. /
-#if defined _IO_ftrylockfile || GNU_LIBRARY == 1 / GNU libc, BeOS, Haiku, Linux libc5 /
+#if defined _IO_EOF_SEEN || GNU_LIBRARY == 1 / GNU libc, BeOS, Haiku, Linux libc5 */
if (fp->_IO_read_end == fp->_IO_read_ptr
&& fp->_IO_write_ptr == fp->_IO_write_base
&& fp->_IO_save_base == NULL)

Thanks, but I had seen that a few times before. The step I was missing was to reproduce the project it was forked from, but replace the contents. I remember from a while back that someone posted some step by step to get it to build correctly in the lede source/package/kernel path when you build lede using make menuconfig, but maybe I'm making that up.

I guess if I spent a few minutes more thinking about it, I may have figured it out sooner. The gpio-irq sources are missing the structure to get Lede to incorporate and allow for a quick build. I've forked the gpio-irq sources and modified it with the correct makefile structure in an attempt to make this easier to do (I think).

Anyway, you can find my fork here.

cd source/package/kernel
git clone git@github.com:buelowp/gpio-irq
cd ../../
make menuconfig

Find the new module in Kernel Modules and then Other Modules
Select it as a module (M)
exit saving .config
make

You'll can find it in build_dir/target-mipsel_24kc_musl/linux-ramips_mt76x8/gpio-irq

I've been trying to find the original instructions related to adding the gpio-irq kernel module in the OnionIoT github. I have found lots of references to the problems, and to instructions about cross compiling. Nothing about how to add individual paths to the build system. There used to be a page that had the exact instructions to add it to the system in sources/packages such that menuconfig could pick it up and build it when it builds the kernel. If I remember right, you had to add it to some package file somewhere (I tried tmp/.package*) to get the kernel system to pick it up. I can't find that reference anymore. Can someone lend me a hand? Or, maybe, did Onion add that module to a firmware yet? I didn't see it in the latest.

I have the cross compiler running, I can build against target and run code. My problem is figuring out how to get kernel modules built correctly. I know there was a page somewhere, I just can't find it now that I'm looking for it again.

Or, does someone have the .ko already built I can just DL from somewhere?

Thanks in advance.

Reply to an old topic, but I thought I would share. This cmake definition works, but ignores the actual sysroot and causes workarounds needed to do linking. To fix this, you need to tell cmake to define SYSROOT with the following. I create a new variable CMAKE_FIND_TARGET_PATH and point it to the sysroot path in the lede build area. The compiler needs to be told that sysroot is not the compiler path, but the actual target filesystem area. This is an important distinction, and avoids having to use -rpath and other linker options.

SET(CMAKE_FIND_TARGET_PATH <path to>/staging_dir/target-mipsel_24kc_musl)
SET (CMAKE_SYSROOT ${CMAKE_FIND_TARGET_PATH})

Finally, you need to tell the compiler where the sysroot include directories are

ADD_DEFINITIONS ("-isystem <path to>/staging_dir/target-mipsel_24kc_musl/usr/include")

Then, you can use the following logic in your local CMakeLists.txt to find Onion libraries.

add_library (onioni2c SHARED IMPORTED)
set_target_properties(onioni2c PROPERTIES IMPORTED_LOCATION "${CMAKE_FIND_TARGET_PATH}/usr/lib/libonioni2c.so")

This will make it work with the compiler std paths (so std::cout will be found and work correctly), and it will allow you to find <onion-i2c.h> and the others correctly.

Hope this helps everyone.

@Patrick-Rainsberry said in Eagle layout for Omega2+ ??:

https://www.amazon.com/gp/product/B01LYCMS4P/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1

Thank you for the link, that looks about right, but how do you mean a little short?

Thank you for this. Longtime Eagle user, but I'm starting to learn Kicad as I think Eagle might have a limited future for me with their new ownership. Question though, where can you buy the headers? Does anyone have a digikey (or other supplier) part identification? I am building a new shield for a lighting/LED application, and don't want to solder the onion to the board, but rather, install via headers. I just can't find the headers it seems. Thanks in advance.

-Pete