Posts made by ckielstra

@Alexandr-Didenko Please, could you start a new topic for this question? In forums it is good practice to do so when you ask a new question, it makes it easier for other people to later find this same question. Also, this thread was dead for 2 years and is now on top of the active list again (another bad habit).

Just wondering.
Booting my device with Omega2 takes close to 1 minute, partially because a four python applications are slow in startup. Since my device never changes, would it be possible to dump a memory image and load this at boot?

Is there experience with this?
How fast would it be?
Any pointers on reading more info are welcome.

Same question to remove WiFi came in from our customer support department. We know we can disable the WiFi from software, but the customer has the specific security requirement that there should be no physical WiFi possible.

I'm sorry to hear that removing the 0 Ohm resistor and the ceramic antenna isn't enough to disable the WiFi. Are there other hardware changes we can make to permanently disable (break) the WiFi on the Omega2+?

Firmware installation using the recovery-button is very slow, close to 15 minutes. About 80% of the time is used for reading the data from USB and then programming the internal Flash memory takes the remaining 20%.

Installation over the web interface is faster with 10 minutes. Installation with sysupgrade from a USB drive is only 5 minutes.

I looked into the u-boot code and this is very old, about June 2013.
Where was the Omega2 bootloader forked from?

Has someone found a way to improve the usb loading speed in recovery mode?

Not sure why you bump a 4 year old topic.
Python 2 officially hit the End of Life (EOL) deadline on Jan 1 2020. As of this date, no new bug reports, fixes or changes will be made to Python 2 making the whole above discussion an obsolete topic; there is no other choice left than Python 3.

I want my Omega2+ to operate as a client that connects to a WiFi access point without the Onion's AP being active at the same time. I've found the FAQ https://community.onion.io/topic/3305/faq-how-do-i-turn-off-the-omega-s-wifi-access-point which states: "You cannot turn off the Omega's WiFi Access Point and still connect to an external WiFi network."

I'm wondering why that's impossible since the MediaTek API seems to support it.
The FAQ is 2 years old and I'm wondering if there have been any changes to the Warp core here.

We noticed that executing the recovery procedure in the bootloader takes considerable longer than manual executing an upgrade with sysupgrade. Respectively 9 to 6 minutes (approximately). Can we speed this up?

When examining the output on the serial port I see it takes about 3 minutes to read the binary file from USB. Executing the file copy manually when the Onion has booted is only a matter of seconds.

In u-boot main-stream a fix was made for a recurring 5ms delay in USB reading. I backported this fix but it doesn't seem to do a lot (I'll test further).

Are there other known reasons as to why the file reading in the recovery procedure takes so long? And how can we improve this?

When a USB drive is inserted it will be mounted as writable. How can I configure this to be read-only?
I had a look at the fstab configuration, there it is possible when the uuid is know. But in my application the user can insert any random drive so this doesn't work.

Are there other ways to configure USB for read-only access?

@Lazar-Demin Thanks for picking this up! Our build works again.

We experience the same error since about a week.

When you google for "onion shellinabox" then a link can be found to github, but that repository is now gone. This breaks building of onion-os.
Weird.

We don't use the onion-os, so as a quick-and-dirty work around we disabled building the Omega-os and shellinabox features in the build.

grep -v "CONFIG_PACKAGE_shellinabox=y" .config.O2-minimum | grep -v "CONFIG_PACKAGE_onion-os=y" > .config

Insertion of a USB drive sometimes doesn't trigger the USB autorun feature. Removing the drive and inserting again often does trigger the Autorun.

Browsing the code I noticed two things:

1. fstab configuration has delay_root configured with 5 seconds (/etc/config/fstab)
2. Autorun (line #57) starts with a 4 second delay.

This sounds like a possible conflict where the Autorun starts before the device is mounted. Am I right?

I ran into the same problem and found the root cause: pySerial v3.2 (and PySerial's master branch up till 2020-4) uses hard coded IOCTL values and these are wrong for the MIPS processor as used in the Onion. It is just impossible to set any custom baud rate different from the default Linux provided baud rates without getting the "not a tty" error.

The changes required to fix this are small. Use the correct IOCTL hard coded values and change the offset values for the baudrate settings to the correct position in the underlying C-struct.
I submitted my fix to have this incorporated into pySerial: https://github.com/pyserial/pyserial/pull/496