Global Moderators

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.