Sonikku

As a sanity check I downloaded an H3Droid image and configured it on the OPi + 2E. It works, it plays back 1080p content no problem. This means the hardware is capable of satisfying my requirements. I did a lsmod- and sunxi-cedrus is loaded- the version I compiled from source. This explains the marginal improvement. The question now on my mind is- is Armbian the right OS for my particular use case? Android is not ideal in terms of development, because from my point of view, the Android SDK and all that kind of development is just painfully bloated and OOP-heavy. I've been involved in products developed on that platform, and there's always issues. Armbian has been an absolute joy- from vanilla C, Golang, and Python 3. You can do anything and fire and forget.. the OS is reliable enough for mission critical stuff. It would be awesome to get the video right, therefore if anyone has done it, or can spare the time to assist me I would really appreciate it. I have heard tales of people using drivers from Android, wrapping them and using them in Linux. Another issue with H3Droid is it seems to be one single person doing it, and we all know how that kind of development can lead to issues- I am not even talking about LGPL and such.

Thanks Werner I actually compiled Cedrus from source and installed it that way between your reply and now. It seems the improvement in video is marginal, or I've done something else wrong. I will check my steps again and test it because I noticed after the fact the authors have a test utility which exercises the hardware CODEC. But for now I've spent a whole day on this, will check again tomorrow.

Thanks, sorry about posting in the incorrect place. If the graphics driver is included, then that's good, how do I enable it because I've tried and it doesn't seem to make a difference. I played extensively with VLC to try and enable video acceleration.

Hi I have used Armbian quite a bit now for various projects with great success and even debugged my own hard-to-solve issues. I am considering using an H3 based board (OrangePi + 2E) to replace the cheap junk media player I use. Incidentally Armbian will run on that device, but I am not sure what the video support is like- its a RockChip RK3xxx series SoC. Now, out of the box, Armbian (Buster, Focal, etc..) video playback stutters on Full HD (720p and up) content, particularly at full screen. I understand this is because I need to install a binary blob driver for the GPU? I've done this on normal desktop PCs before running Ubuntu, which is very easy to do, however when it comes to Armbian I am a little bit unsure. I have searched the forum here and it seems that, if my understanding is correct, I need to compile Armbian myself with the specific options set to use the Sunxi-Cedrus driver? What is the easiest way to proceed? I have a Ubuntu box to compile the kernel available, if needed.

Final feedback and solution The issue happened again, and at the same time I was seated at my desk: Setup: Macbook Pro /w Kensington Desktop Hub to provide DisplayPort and Ethernet HP Desktop PC with Windows 7 Polycom Desktop Phone HP LaserJet Pro Wifi Access point All the above are on the same network switch Event I disconnected the Kensington device from my Mac (USB-C) I noticed something was wrong when my phone reported no network (It makes a chime when this happens) My Windows 7 box was doing a download and then said the internet was disconnected with high CPU usage.... hmmm.... My phone complained about no internet (Whatsapp went offline). Had to use the regular mobile LTE network. Root Cause When the Kensington unit is disconnected, it goes into a state where it jams the upstream network switch, it appears to flood the LAN with rubbish packets... the switch falls over or locks up. Also other devices see (and receive) these packets. Left to happen long enough, the OrangePi will crash as I have described. My colleagues have been able to reproduce this, and we've decided to throw the Kensington unit out. It is not a bug! The desktop phone also eventually crashes, and it takes out my Ubuntu 18.04 LTS file server eventually. The HP printer locks up completely and I have to power cycle it at the mains socket. So there we have it.. finally. Rogue device.

I am inclined to agree... but whatever I did the system is still up.

I think I know what the problem is The Windows machine also runs NordVPN, which is used for accessing censored content outside of my country (certain necessary software updates are blocked by our government) Recently, NordVPN changed the underlying network transport driver, which has not only broken a few things on the machine itself, it seems that when NordVPN is allowed to run on the machine and the machine has access to the OrangePi, that's when things go horribly wrong. Other devices accessed in a similar way have also shown odd symptoms.. an Android media player locked up and froze... so some combination of my software is either no good or there's a bug in Windows 7 that has since been patched. I am enjoying 9 days of uptime on the OrangePi and have elected to rather format the Windows 7 machine, reinstall all the software and keep it updated this time. NordVPN stuff will be done on a different machine now.

Hi I have some feedback regarding this issue. I am using Armbian Focal (current version) and the issue persisted, until, I found out where it was coming from. I have been able to repeatedly generate the system crash at will, it takes a few hours but it can be guaranteed to happen. The cause is a particular Windows 7 host that has not been updated in years. It runs Windows 7 SP1 and the Windows Update was last run 3 years ago. Other Windows 7 machines have been updated and they have no effect on this board running Armbian Focal. So I guess there is some network bug in old Windows 7 versions (which Microsoft has since patched, most likely) such that when the host browses the SMB share or even does a host lookup on the Armbian host, it sends something that upsets the network stack, because in this condition, while the OrangePi is technically unresponsive, it still, surprisingly responds to ICMP requests. What I have done is to remove the particular Windows 7 host from the network (unplugged the LAN cable) and the problem has disappeared. I am now on 6 days of uptime on Armbian. Therefore I am fully convinced the Windows 7 host has a network stack bug, sends garbage to the OrangePi board and this somehow upsets the TCP stack in Armbian. Neither another machine running the same Windows 7 copy (but it is updated until Microsoft stopped rolling out patches in March 2020), or a Windows 10 machine, nor several Ubuntu machines, nor a Macbook Pro affect this OrangePi. Solid as a rock. I will investigate the issue further if I have time, to pinpoint the exact cause but honestly, its easier to get rid of Windows at this point. The machine in question is used for DTP uses i.e. Corel Draw and other software that's not available on Mac or Linux.

For the CPU speed I keep everything as standard as possible. I haven't done that no. To put it this way, this is stock Armbian with one item installed... RabbitMQ. We thought we had a problem with RabbitMQ and we found that Buster addressed it somehow, so that's unrelated.

Greetings everyone. I have sucessfully used Armbian Bionic in a production environment. Its really great. I am now evaluating Armbian Buster and I am seeing a strange issue perhaps you can direct me where to look so I can do troubleshooting. With the board connected to our corporate network, it takes about 48 hours when the whole board (OrangePi+ 2E) will crash with the CPU burning up. The second time it happened I had htop running to try and diagnose the problem. Investigation revealed that rngd became unstable due to the nm-applet. This led me to re-running the known conditions when this happens, with the network disconnected and now it doesn't crash. Below is a screenshot of the crashed state. Any ideas of where to look would be appreciated. My gut feel tells me this is network related and indeed, by disabling the network interface the problem goes away.

Thank you There's the first mistake... /etc/modules is missing.. I didn't know it had to go in there. Will change that and then test again

Hi I am having issues getting an external RTC (DS1307) to work properly on the OrangePi + 2E I am using the current version of ARMBIAN 5.6.5 (Stretch) The hardware side of things works perfectly. If I use i2cdetect -y 0, I see the I2C bus transaction on an oscilloscope and I also see the device as shown 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- The problem is when I try and attach a driver to this device permanently, it seems to work until I have to reboot or power down. When I reboot, the device is again displaying as above. I do not see "UU" as I would expect. I followed the steps here, but it doesn't work. It does seem to work, however on older versions of Armbian. https://forum.armbian.com/topic/4074-real-time-clock-ds3231/ I have done all the steps as per the thread, I also made changes to rc.local, but none of these work. All that happens is the OrangePi boots up to some arbitrary time until it can get the correct time via NTP. So obviously the driver is not being loaded at boot and the rest of the system fails to get time from it so it falls back to NTP. Any suggestions or perhaps the correct way of doing this?

Hello there I have had great success using Armbian as a base OS to run my commercial application. Finally free of Microsoft Windows CE However the time is now at hand when I need to clean things up before it goes out in the field. As far as possible I need to hide some stuff and one of the things I need to do is as follows: 1. Disable (or hide- I prefer this as it is needs to be re-enabled if we have problems) the text that scrolls during boot. 2. Change the black background with the Armbian logo in the middle. I preferably want to change this to our own logo and some custom text, retaining the Armbian logo at a different position. I suspect this stuff is in uboot, and I would appreciate it if you could tell me where to look, and if this happens to be compiled into uboot, a pointer as to where I can find information how to do it. I have never gone this far down the rabbit hole with Linux so I appreciate any/all help.

Thanks for the info- I spoke to Steven at OrangePi and he explained to me how this works in much detail which also confirms that secure boot is a WIP. In the meantime, until it works (and when it does I will be eagerly ready to try it), we will enclose the device in a steel box, until at least Linux is booted and we can run our own security apps and daemons.

Hi all I need to develop a customized application on the OrangePi that uses this Allwinner H3 chip. So everything about this is the standard Armbian, with one change- I need to add security code into the loader to secure the board Prior to this I have only ever developed superloop C code on processors such as these i.e. no OS present. In those cases we had the development tools from the vendor or a JTAG probe. What I need to do is I need to customize the loader code to do certain security tasks. My question is, where is this loader sitting? (presumably its in the FLASH), and, is its source part of this distribution? Also, when they make these boards, how do they install these loaders onto the blank boards? It would be most useful if I could know what happens after CPU reset- I presume the CPU starts booting from the FLASH and then executes the loader found there. Initially a JTAG tool is required to put this loader on the board presumably?