Posts made by crispyoz

Thanks @Lazar-Demin saved me some work.

@defa85 I don't use VS code but you can debug python code using gdb and you can run a gdb server on Omega2. I mainly develop in C/C++ and debug using gdb remotely.

Thanks @Lazar-Demin and @luz . I'll look at the swd-spi overlay to see if it works for me, I need it on owrt 24.10 so hopefully it works there.

I'm not quite there with wrapper(s) yet, I agree they are great for standardisation but owrt 24.10 stable is already released and since rc5 performs well so I'm trying to keep more current.

@Lazar-Demin It's clear there were no coding standards, when I first looked at it I was a bit agast, but it's old and open source projects have come a long way since those days, try submitting that to the Apache project.

@Lazar-Demin a lot of the issues I'm seeing are caused because of the build tools version gcc 3.4.2 (released 2004), which is 9 major release behind the current 12/13 (I'm using OWRT 23). The issue @luz posted is not so unexpected due to the many changes related to how extern and inline has been implemented/standardised in the last 20 years.

As time permits I'm working though some of the these issues, but keep wondering if as you mentioned it would be better to spend time moving to a modern u-boot. I wonder if we could move to the modern u-boot but patch it to reduce size, or is it better to wait for the Omega3

@luz take a look at my fork of your fork. The issue seems to be caused by the use of extern inline in io.h and bitops.h if you change them to static inline it fixes the assembler issue.

Once that's sorted there as some other stuff to fix but I haven't had time to look at this yet.

Does anyone know why kmod-spi-gpio-custom was discontinued? I can't find any details in the sources but I have a recollection it related to a kernel change. I need full duplex spi and I'm better at software than hardware so I'm thinking about whether it's worth trying to revive it.

@luz can you give me the steps you followed and on what OpenWrt release. I can see if I can find the issue, maybe two heads are better than one.

@defa85 My first step was to divide the boot time into two sections. 1) System is up. 2) Network is functional.

If you start with section 1, issue the command service network disable and reboot (make sure you have a serial/usb connection). The system will start without loading the network, I expect this will be around 30 seconds.

Depending on what services and kernel modules you load, you may be able to tweak this a bit by disabling a service and loading it after your app, or removing kernel modules you don't need. We're talking a second or less for most of this standard stuff.

Network connection accounts for roughly 50% of the entire boot process so if you can optimise this you will notice an impact. An ethernet connection is faster and while you may think a static IP is faster, that is not necessarily the case on all routers. Disable ipv6, configure a specific channel if you are using wifi.

dmesg will give you the timings, but for more detail you can enable more detailed debugging during boot up by watching for this prompt:

Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level

press 4 and enter, then once boot is complete use the dmesg command to see the details and timing.

@luz An interesting question I asked myself when dealing with Omega2Pro flappy GPIO44 issue. I found I could modify the makefile to point to my standard buildroot, however I needed to install gcc-multilib and then it worked fine. I didn't investigate why, perhaps @Lazar-Demin knows.

@defa85 The answer to this hasn't really changed, I tested this a few times and the best I could get was around 30secs without networking. Ethernet with a static ip is a bit faster than wifi using dhcp, then of course your app load time and cloud connection time. You may be able to get your app up faster by placing it earlier in the procd load sequence, but I don't see any way to achieve 30 seconds.

@luz The bootloader can also be used to control state of the GPIO earlier than when he dts is loaded, you may recall the issue with the Omega2Pro where the LED was flapping around during boot. The changes are in lib_mips/board.c of in the onion bootloader code.

I discovered this while investigating this issue

If you don't have the code here are the steps to download the relevant code.

@Sarah-Clark The Dash firmware is based on OpenWrt 18.06. The current Onion release of OpenWrt 23 firmware is in Beta so it's targeting the core device which is the Omega2 and 2+. It doesn't currently support Dash or Pro devices. Perhaps as the Beta evolves these devices will be supported, but that's a question for the Onion team answer, @Lazar-Demin.

The Dash is basically an Omega2S+ with a touch screen, so the 23 firmware will work as if the device is an Omega2s+ hence all output is to the serial console. In fact on the Dash the setup docs show you how to redirect the console output to the touch screen. The package you need LVGL and communications is via the frame buffer.

To make the framebuffer available you need to modify the kernel configuration to enable:

Device Drivers > Graphics support > Frame buffer Devices

Then you can follow the configuration of LVGL to utilise the framebuffer.

Good luck with the presentation @luz ! Don't be nervous, just image everyone listening is naked. I'll get naked to listen, but that might be more disturbing

Thanks for posting @luz , a veritable treasure trove of Omega2 related stuff! I look forward to the next 8 years of stuff

BTW I've been using Ledchain 9 on OWRT 24.10rc3 and it's working perfectly.

@mayur_ingle For my 2c I'd run your device on a standard dock and see if you experience the same issue, I'd move yoru write to an SD Card and would also add a regular file system check that reports to the console to your script.

@Lazar-Demin If you have ipv6 installed it will default a link local address on each interface. Same as 169.254.x.x ipv4 addresses. An easy test is to use ping 6 command:

ping6 -c 2 -i 4 -I wlp0s20f3 ff02::1

Where "wlp0s20f3" is the name of my notebook's interface and the ff02::1 is the link local "all nodes" address, like broadcast address (but that term upsets the ipv6 professors). It will respond with the ipv6 address of all nodes on link local. Here 's what's on my development network:

ping6 -c 2 -i 4 -I wlp0s20f3 ff02::1 
ping6: Warning: source address might be selected on device other than: wlp0s20f3
PING ff02::1 (ff02::1) from :: wlp0s20f3: 56 data bytes
64 bytes from fe80::b06d:1d07:966:4c65%wlp0s20f3: icmp_seq=1 ttl=64 time=0.160 ms
64 bytes from fe80::feec:daff:fe31:e1c6%wlp0s20f3: icmp_seq=1 ttl=64 time=2.94 ms
64 bytes from fe80::8bb4:297b:abb:7968%wlp0s20f3: icmp_seq=1 ttl=64 time=3.27 ms
64 bytes from fe80::46d9:e7ff:feb8:53a7%wlp0s20f3: icmp_seq=1 ttl=64 time=3.54 ms
64 bytes from fe80::6ad7:9aff:fe02:b2b8%wlp0s20f3: icmp_seq=1 ttl=64 time=3.58 ms
64 bytes from fe80::c251:7eff:fe5d:7c73%wlp0s20f3: icmp_seq=1 ttl=64 time=3.58 ms
64 bytes from fe80::76ac:b9ff:fe4e:29db%wlp0s20f3: icmp_seq=1 ttl=64 time=3.58 ms
64 bytes from fe80::b6a3:82ff:fe4b:20b6%wlp0s20f3: icmp_seq=1 ttl=64 time=3.58 ms
64 bytes from fe80::f64d:30ff:fe6b:8b4a%wlp0s20f3: icmp_seq=1 ttl=64 time=3.59 ms
64 bytes from fe80::188a:822d:9b56:843c%wlp0s20f3: icmp_seq=1 ttl=64 time=3.93 ms
64 bytes from fe80::42a3:6bff:fec4:1d8e%wlp0s20f3: icmp_seq=1 ttl=64 time=4.24 ms
64 bytes from fe80::d8f4:6b58:8b5e:cd9f%wlp0s20f3: icmp_seq=1 ttl=64 time=73.7 ms
64 bytes from fe80::a2dc:4ff:fe2a:8411%wlp0s20f3: icmp_seq=1 ttl=64 time=181 ms
64 bytes from fe80::a91:15ff:fefe:8897%wlp0s20f3: icmp_seq=1 ttl=64 time=304 ms
64 bytes from fe80::10b7:9243:cdf4:873e%wlp0s20f3: icmp_seq=1 ttl=64 time=304 ms
64 bytes from fe80::b6fb:e4ff:fec9:3b8%wlp0s20f3: icmp_seq=1 ttl=64 time=308 ms
64 bytes from fe80::f29f:c2ff:fec5:9ab2%wlp0s20f3: icmp_seq=1 ttl=64 time=356 ms
64 bytes from fe80::f29f:c2ff:fe09:fe1%wlp0s20f3: icmp_seq=1 ttl=64 time=878 ms
64 bytes from fe80::b06d:1d07:966:4c65%wlp0s20f3: icmp_seq=2 ttl=64 time=0.081 ms

--- ff02::1 ping statistics ---
2 packets transmitted, 2 received, +17 duplicates, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 0.081/128.421/877.572/217.804 ms

You can see they all start with "fe80" which indicates these addresses are created by the Stateless Auto Address Configuration function of ipv6 (SLACC). So even if you set an ipv6 address on an interface ipv6 will still create the link local address.

There is a lot to ipv6, but this is one of the nice little features.

@MK Correct. OWRT 19 was really not much more than a kernel and toolchain upgrade. OWRT 20 was never officially released. OWRT 21 included a load of networking changes so it was the most logical to change up to but then OWRT 22 came along pretty quickly and fixed the 2038 date issue and upgraded firewall technology so it was nice step forward. Alas it broke the GPIO numbering so many of us needed to rejig things and that takes time. Hence 23 is the logical step forward.

The custom firmware build I use is mainly to debloat things and add in my own software and configuration, I try to stay as close as possible to the Onion build.

@MK When I switched from OpenWrt 18 to 22 is was quite smooth, but it depends on what functionality you are using. Initially the network setup was a pain, then changing MUX setting of a couple of pins was an issue. Then an issue with ledchain, then an issue requiring conversion of sqlite3 db. Mostly these were easily resolved so now I run 23 on my devices without issue. Also initially I started experimenting with OWRT 19, jumped to 22 then went into production on 23.

Thanks @luz ! I've was offered these LEDs here locally in Oz and was wondering about compatibility.