StuxNet

I didn't pick up on any 'condescending tone'. Don't mistaken bluntness and being forward for condescending. If the issues are result of using something for purposes other than mentioned and lack of understanding. Then perhaps that's simply the case. As such, it's not a bug and shouldn't be treated/claimed as such. I believe this is what was meant, more or less, that was lost in translation. "like to get outside help with issues?" I'm sure they would love to have outside help. Last I checked and AFAIK they have 4 developers. Having a 5th would be help. Not exactly reporting a bug, that's not really a bug. Nonetheless...

Not gunna be of much help but here's my two cents. Based on what you said, we know the issue isn't with the board, it's with the screen. By this, I mean you can tell the board is doing it's thing so the problem lies somewhere in how you're interfacing with the LCD or the LCD's hardware itself. I'm not at all familiar with that screen nor do I know how you have it setup, as you did not mention this, however the first couple things that come to mind are: Something with the screens buffer? Something with the capacitive touch feature? I'm sure it being a touch screen doesn't make things more simple. How you're interfacing with it or have it setup? When I've used screens in the past there has always been some python wrapper in the middle, crontab, bash script, etc... which when accidentally ran on top of each other or duplicates, things get weird. Then again that's so I can specify what is being displayed on the screen. I'm sure this is different when just displaying the desktop. Nonetheless. How do you have it set up? Some diagnostics that I might do, if I were you, to help glean some information would be... Time it: Does the screen lock up at the exact same time after boot? Or is it more sporadic? ie: After using the touch screen, starting up some unrelated service or program, etc... Boot up the system. Let idle. Then connect the screen. Does it lock up after the same amount of time? --> buffer?

Meant to ask that along with the crontab question. Glad you solved it.

Well if it 'seems' to crash I'm going to go ahead and assume it doesn't. If it does, provide log or error code. I'm going to assume it doesn't though if it works from command line. I'm not sure what you mean by CGI and I'm also going to assume that you're running the entire script from command line and not each line of code from the python shell/prompt. (I make this distinction because of personal experience) That being said, what command are you calling with crontab? Don't know why it would make a difference but seems worth mentioning: gpioinit variable is redundant since you aren't calling it later on. Try just gpio.init(). Same for setcfg(). So like this... ---- from pyA20.gpio import gpio from pyA20.gpio import port gpio.init() gpio.setcfg(port.PA19, gpio.OUTPUT) gpio.output(port.PA19, gpio.LOW) print "ok" -----

Heck yea dude. This is honestly the first time I'm hearing/looking into Q4OS so I really shouldn't speak on it. What I can say though is that even if they offered the same support for OPi Zero (which they don't afaik) Armbian would still be the way to go. It's prolly been around longer and at the very least comes with this awesome community and has way more support/foundation. I don't think it's a coincidence that you found yourself here That's not to say Q4OS doesn't serve a purpose, I'm sure it does. Just saying you prolly shouldn't buy a pick axe when you need a shovel. That being said, I honestly think it would be easier and way more efficient use of your time to take the stable version of Armbian, install it. Then systematically uninstall the 'redundant' software you don't want. Personally, I think it's already pretty dead simple but I know the usefullness of having stripped something down to the core. I have a buddy that I'm in touch with face to face that knows how to build images for the Opi Zero from the ground up. I'm not familiar with "Lazarus" and this might be coming at the wrong direction for your use case but he might be able to 'buildroot' an image for the OPi Zero from the ground up. That's as simple as it gets. Want me to run it by him for you? TL;DR: You would save yourself days/months of time just picking up a vanilla Armbian kernel for the OPi Zero and uninstalling stuff or alternatively building your own image from the ground up (using armbian branch) than you would trying to get/use Q4OS on OPiZero.

Ummm?... because Q4OS only supports Pinebook, Pine64 and Raspberry Pi as per their downloads page. Unless I'm missing something. Even if I am, that would mean their "ARM port" download is trying to do something similar to Armbian by being compatible with multiple devices. Aside from chromebooks, tablets, etc... I think you'd be hard pressed to find an argument for using Q4OS over Armbian especially for OPiZero. Maybe that's just me though. https://q4os.org/downloads1.html So what's your reasoning as to why you opt for Q4OS over Armbian?

COM port communication over OTG works fine for me out the gate. Across multiple OPiZero's and dozens of instances. Have you tried typing into the console output? This got me before. Sometimes boot is finished and you're at a blank terminal depending on when you boot/connect your UART adapter. You just need to press enter or something get a visual response. Otherwise: What UART adapter are you using? I take it you're using Putty? You're positive that the UART adapter connected properly? RX --> TX and TX --> RX? I wouldn't ask any of this is they weren't also mistakes I've personally made and learned from.

I made it simpler by renaming some stuff and omitting extra crap from previous project so check the link again. That's about as simple as it gets. You really only need to read lines 27-38. https://gist.github.com/BiTinerary/2734ac46e80af2b1a2158c9f0ba79e25#file-shutdownswitch-py-L27-L38 The script simply put, checks every second to see if the GPIO (that you still have to change on line 8) pin is pulled high or low, up or down. If pulled high, send shutdown command. If low, do nothing. Continue the loop. If those ten lines of code are too complicated then I can't help you. Read up on programming. I can suggest some pretty good books. Keep in mind that I can't remember if my reed switch defaulted to open or closed so the high/low might be switched around for you. This simply means that when you run the script if the button isn't pressed it might print "Shut Down Computer!" instead of doing nothing. If this is the case for you, simply swap lines 33 and 36. Debug with print statements so that you're not unintentionally shutting down your OPi PC. Lemme know how it goes.

For personal simplicity I would git clone https://github.com/duxingkei33/orangepi_PC_gpio_pyH3 Setup whatever pin you're connecting the switch to using the PYA20 library's (above) example code as seen here: https://pypi.python.org/pypi/pyA20 Use that library read the switch. For example: If pin high/low or on/off, use python subprocess or os.system functions to run linux shutdown, reboot command. I might be able to give you a sample script or more concise instructions but don't hold your breath. For now I'll give you this, which is a pretty damn good start for having not really started This is a script I was using on a NanoPiNeoAir using a reed (magnetic) switch attached to a door but could be easily changed to suit your needs. I've commented out the stuff that you won't need but much of the variable names are the same soo.... pretend the door is your switch! Or you can change the prompts/names yourself. https://gist.github.com/BiTinerary/2734ac46e80af2b1a2158c9f0ba79e25 P.s. You'll need to specify the pin you're using for your button but if you use my script in tandem with the tutorial you link to (replace LED with switch) it should 'technically' work. Hack away at it, see what you can come up with and report back. Also..... you have heatsinks on your RAM dies but not your CPU? Sup with that?

Currently using one for... MFRC522 RFID Timeclock and script triggering SMS tirggered IOT server with API hooks. Armbian monitor browser GUI with embedded window of noVNC, plans to add another window for camera. Will be using one for... A pulse oximeter sensor (MAX30102) that's connected to an infant and the speakers of an electronic rocking chair. Documenting installation instructions of a bunch of sensors/modules for OPiZ on Github I don't know if the sensor is going to be sensitive enough for a newborn, much less reliable. Plus I still have to get it to work on an OPi but it's, in any case, an effort to minimize the risk of SIDS.

My money is on one of the first things mentioned and suggested. An issue resulting from CPU usage. Especially since you've gone on to mention you've underclocked the CPU. When you search for the first error (INFO: rcu_preempt detected stalls on CPUs/task) the first 3 results specifically apply to your situation! ie: real time applications, 1ms delay, etc... https://unix.stackexchange.com/questions/252045/rcu-preempt-detected-stalls-on-cpus-tasks-message-appears-to-continue https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt This one (https://stackoverflow.com/questions/35401317/rcu-preempt-self-detected-stall-on-cpu-0) specifically mentions "continuous us[e] of CPU from a high priority thread for a long time" Maybe I'm missing minutiae in regards to the "RCU CPU Stall Warnings" peppered throughout those results but again, i'd bet money on it. Try not underclocking a board that has been known to drop out when the CPU load is pushed to it's max? I highly recommend reading through the bullet points of the second link provided. It details potential causes "for RCU CPU Stall Warnings". Read through them and use them as diagnostics to your specific use case. See if you can get different results or change something. Respond back with your findings. With all due respect intended, if you don't do as suggested because the answer isn't a direct fix, you might as well not even be on the forum.

Replace friend with customer and you've lived my life. Good to know you figured it out. Take care.

I'm running RetrOrangePi on OPi PC+, (512GB RAM vs 2GB RAM) and I can easily run way more intensive ROMS (N64, PS1, etc...) without fault. Have been doing so for quite some time on top of other custom scripts and while loops. Personally this tells me it's an issue with DOSBox. I assume its meant for linux, not like Retr(Arch)Opi is meant for ARM architecture. My suggestion? Stop what you're doing. It's been done. I don't know how you would install RetrOpi ontop of an existing kernel (can you even do that? [if you do, document it!]) so just commit to downloading that image. Direct link copy/pasted from their website for OPi+2e board: http://www.retrorangepi.org/images/3.0.1/RetrOrangePi-3.0.1.Orangepiplus2e.tar.gz Run doom (included by default last time I checked) and hit up it's ScummVM emulator for Red Alert and other PC Roms. (I'm currently revisiting SpyFox in: Dry Cereal) Then, w/e you're using legacy Armbian for, install/setup and do that after the fact. From your post is sounds like emulation/roms is the priority sooo... why not use the emulation station/lib retro/armbian utility designed for that purpose? Otherwise, justify why you need a different kernel (legacy) setup more than that. Good luck.

*MERP* As it turns out "not even applicable."

Good on ya for using try/except/finally however I believe this problem could have been avoided with a couple more. Since you try/finally it never errors out as it would if you ran the commands manually. It always has somewhere to go, which is what you need it to do. My suggestion is what I've learned from personal experience as a cowboy coder (take with grain of salt) is... 1: Always be cautious when using sleep() or other timeouts. It's best to start bigger in dev/testing and then push it to it's limits as it's proven to work. Sleeping and while loops can cause some weird things to happen depending on the application. 2: Do something with you exceptions! I see you except Exception as e but I don't see you reference "e" anywhere. You've commented out "Write exception to log" so I'm sure you had good intentions but.... were going to do it. I prefer to let the script crash and write to a log. That way you get a better idea of what's going with the raw exception and know empirically something is up because your script isn't running anymore Anyways, that's my 2 cents. Might not even be applicable since I can read your code but I'm not familiar with it. Regardless, I'd like to think it's still worth a whole 2 cents since they're lessons I've learned. Take care, good luck!

Yup. As mentioned, obviously pins would be different but I thought maybe you could 'map' that existing library to conform to NanoPi 2. I honestly have no clue though. That kinda stuff is not my forte. Wanna drop a link of your findings? Potentially help some other use down the line?

I was also wondering this, but the original tutorial also references 2222 not standard SSH of 22.

Sure. Are you going to do it? Document the directions and post your results? Kinda like the tutorial you followed to make this post? I'm sorry but most of the folks here are focused on building and expanding the Armbian kernel. Not really in a position yet to take feature requests. If they were, they would already be inundated with everyone else's requests and I would imagine it being first come first serve. Sorry. All that is to say..... no. Feel free to contribute though ;D As for the initial inquiry. I honestly have no idea. Full disclosure, I've never had the compulsion to make a fully encrypted system as I've never had reason or drive to but I understand why some might. That being said I'm pretty sure "Connection refused" is WAY too general of an issue. Could be authentication issue, user error, did you experience any issues following that pretty long (especially for linux standards) tutorial? You followed "every step multiple times" but I would find it skeptical if you didn't have 1 or 2 yak shaves in there. Unless OP of tutorial is a wizard..... Can you give us any more details regarding your issue? Honestly, it might be best to contact OP of tut. They might be most qualified/familiar with the pitfalls of the setup. Not to mention, the most inclined individual to help diagnose. Contact him/her? Furthermore, what's this? Applicable? It does explicitly mention unlocking disk via SSH, is "commented out" and is an edit of the OP that isn't part of the original "steps" you mentioned to have followed multiple times. Could be something depending on if you did/n't do it. Not to mention, I think I'm reading the post right (by commenting out, it allows unlock over ssh) but that's not how I read it the first time.

I don't think this is at all what you're asking for but I was able to use pyA20 library to successfully toggle and read some reed switches, SSD1306 screens and more using a NanoPiNeoAir. Obviously pins would be different but at least they have the same manufacturer in common. Just thought I'd put it out there. Don't know if it's going to be any help. Good luck.

Nice quick reply. Can't believe I didn't think to consult a schema. Then again I probably wouldn't have known what to do with "FPC24-05PH"... so thanks. Also, Sweeet! I already have these in bulk. Must be pretty standard because that's what is used in a lot of mice/keyboards, PlayStation optical drives and I think their controllers too. In any case, thanks again.

As some might imagine, you can buy a bunch of different ribbon cables on Aliexpress. Different pitches, pins, etc... I could just buy the camera module but I would like an extended cable for my uses, just to be safe. It looks like the one it comes with is prolly only 6 inches. I can't quite discern from the product listings the type of ribbon cable used for OPi cameras and I'd like to know so that I can bundle it with my next purchase. So, if anyone who has one, can provide pictures (with something reliable to scale) or details, it would be much appreciated. If I find an extension option that proves to work, I'll post it here. Searching for Orangepi Camera cables, etc... doesn't produce very many results. Whereas I'm know if I searched "24 pin ribbon cable" for example there are many results, with various pitches, orientation and lengths. I already asked the seller but I'm not holding my breath. Thanks for any help yall.

Yup yup. This I know. Wasn't asking for help just trying to help out dude I quoted. I'm very familiar with op_mode=2. It's probably the third time you've told me xD (I understand you're just trying to make the info known) Also, I've tried manually modprobing it, custom configs, armbian-config with no luck. No pressure though. You've got more important things to worry about and I'm well aware armbian-config is in first versions and expect bugs. TL;DR: I gotchu.

Lil late to the party but, AP Mode under FriendlyArm distro is simple... Run: turn-wifi-into-apmode yes I've yet to get it working under Armbian to date of this post but I also am just not reading about Igor's 'workaround' posted above. To Armbian's credit Access Point mode does work, it just doesn't allow (lease) connections to devices. Someone with better understanding of TCP/IP under linux might be able to solve that problem. Until then, when I know. You'll know.

Simply, no. Not that I'm aware of. I've personally tested onboard UART and over USB-OTG for days on end. I've not experienced any problems (that weren't of my own doing ;D) Then again, I'm also using a small heatsink and mini 5v fan. What are you doing with OPi/Arduino? The reason I ask is because I've experienced 'drop outs' in connection over SSH/UART, etc... (which exhibit similar behavior to what little description you provide) as result of power for various reasons on OPi. Updating/installing/compiling large packages High CPU usage Poor power cable Combination of the above + Heat Are you cooling OPi at all? Heat is a known issue with OPi Zero. Provide logs and/or more description. ie: armbianmonitor -u Isn't convincing enough evidence for me to rule out: Problem with UART, not necessarily "on Orange PI Zero." Problem with the Arduino's communication to the UART

MERP. My bad. Just going off what I've experienced and trying to insulate the devs from all the newbie mistakes I hear them complain about every time I turn around. Sorry I didn't catch that abscure https://www.denx.de post. Just doin my best. You're more than welcome to offer anything constructive and as a dev, you knoe you don't need my permission.