lomady got a reaction from suberimakuri in RK3328 Kernel
Sharing a bit of feedback:
I tried nightly buster minimal build with 5.3 kernel for Rock64 rev2.0 and it does not reach the state when it is accessible over the network. Both LEDs on the ethernet connector are off. I did not connected the HDMI display and moved on to other things.
Hope this helps.
lomady reacted to AristoChen in Clock jumps back and resulting unresponsiveness
I have encountered this issue for many times on OrangePi PC, this issue happened by using following version
Armbian version: 5.41, Kernel version: 4.14.32 Armbian version: 5.77, Kernel version: 4.19.25 Armbian version: 5.90, Kernel version: 4.19.57 I have more than 10 Orangepi PC running busy tasks at the same time, and this issue happened more than 15 times in the past year, still have no idea how to deal with this, it is still able to send data to my server somehow, which means that the internet connection is available, but i'm not able to ssh.
I have tried the following methods:
Wrote a udev file to copy all system log when usb pendrive is detected, this works fine when device runs normally, but not working when encounter this issue. Using watchdog, works fine if using fork bomb to test, but not able to recover from this issue Tried connect to a keyboard and hdmi monitor, this works fine when device runs normally, but not working when encounter this issue. Using TTL serial to usb adapter, I'm able to control device when it runs normally, but not working when encounter this issue.
I found that dmesg record some error message as below when I encountered this again yesterday
Currently, I might try to continuously detect whether this error message occurred in dmesg, if yes, I will try using this command "sudo systemctl --force --force reboot"(it seems that /sbin/reboot does not work at the moment)
lomady reacted to drice in Clock jumps back and resulting unresponsiveness
This looks similar to the issue in this post:
CPU stall followed by clock getting set to an incorrect time. I think the clock issue is a symptom rather than a cause. I didn't see anything obvious in the call stack of this issue or the referenced issue but I'm not very good at reading those. Maybe someone who knows more can compare these posts and see if a root cause is obvious.
lomady reacted to windysea in A64 date/time clock issue
An ntp stratum is not related to accuracy nor precision - it is simply an indication of how many "hops" a given NTP server is from a reference clock. A stratum-0 is a reference clock (IE: atomic clock, GPS receiver, etc). A stratum-1 is the NTP server directly using that reference clock for time synchronization. An SBC with a serial GPS indeed can be a stratum-1 (the GPS would be stratum-0), and there are many public postings on doing this. In fact the NTPsec team is doing "research" on this topic and has published documentation regarding this.
The nature of the reference implementation of NTPd is specifically to maintain accurate time regardless of any hardware timers. Today's "50-cent" parts are still more stable than those orders-of-magnitude more expensive decades-ago when NTPd was first developed.
Google's NTP project may use their own "atomic clocks", but their public NTP servers tend to be on the poor end with respect to jitter. They're intended to be "close-enough", stable, and highly-available. They are not intended to be highly accurate. Their public NTP servers, for instance, implement leap-smearing rather than advertise a leap-second (when appropriate). For this reason Google strongly recommends not mixing their public NTP servers in a configuration with other NTP sources (bad things can happen, and in fact have happened in the past). Google's NTP servers also are behind anycast load-balancers. While this improves availability and end-device configuration simplicity it actually degrades performance.
In my own testing google's ntp servers typically have higher jitter than most of the larger NTP pool project pools, the latter of which are already commonly used as defaults in many OS distributions.
Configuring and building a non-tickless kernel is required in order to enable kernel-pps (aka "hard pps"), which typically has far less jitter than "soft pps". However, doing so even with the latest 5.1.y (DEV) kernels results in an unstable platform where the issue noted in this thread will manifest fairly frequently. It may just be that A64-based SBCs are not suitable to host NTP reference clocks and stratum-1 NTP servers but earlier kernels did not seem to have this issue so it may just be that a previous mitigation got lost along the way.
lomady reacted to Igor in Summer update. Bust.er4all boards
v5.90 / 7.7.2019
All images were updated. It mainly goes for a bugfix update, cleanup, adding Debian Buster release. Beware that software maturity with Buster is not just there yet (even it was declared stable) and with some applications (like OMV) you will encounter problems. Kernel/BSP wise, Debian Buster is the same, uses Armbian kernel, as our other builds. Most of the builds were briefly tested, but bugs might be hiding somewhere. This is the best what is out there thanks to greater Debian community, those around boards and of course ours which pushes generic Debian/Linux to the sky . Enjoy the summer time.
What's new? -> https://docs.armbian.com/Release_Changelog/
lomady reacted to ImmortanJoe in h6 computer fast enough to be a notebook?
As always the question is what you want to do with it
I'm typing this on a Pinebook which is fast enough for what I use it for. My Orange Pi Zero is fast enough for file and network services that I use it for. My RPi Zero is fast enough for running RISC OS. It's all down to your use case.
lomady reacted to Tido in Orangepi 3 h6 allwiner chip
Not armbian, of LINUX.
The implementation of the PCI Express controller of H6 is broken, you find more information here and here.
(the above text is from Pine64 H6 https://www.armbian.com/pine-h64/ )
Well, at least it is powered via barrel jack == one problem less
lomady reacted to turkerali in SOLVED: How to add an external RTC module to ROCK64 board
ROCK64 is a RK3328 Quad-Core ARM Cortex A53 board with up to 4 GB of RAM. Unfortunately it has a non-functional RTC (/dev/rtc0), which is not battery backed. If your board is not connected to internet 7/24, you can not use the NTP or systemd-timesyncd. Therefore you need to connect a battery-backed external RTC module to the ROCK64 header, and get the time via the i2c protocol. The good news is, the GPIO headers on ROCK64 is compatible with Raspberry Pi headers. Therefore almost any Raspberry Pi RTC module will work on ROCK64. But you need to do some tweaking to communicate with the RTC module. I will explain the required steps which worked for me.
1. Buy an external RTC module for Raspberry Pi, preferably with DS1307 chip. Here is an example:
2. Install i2c-tools package:
sudo apt-get install i2c-tools
3. Connect the RTC module to the board as in the attached picture.
4. Right now, you can not probe the RTC module, because most of the GPIO headers on ROCK64 board is disabled by default. (See https://github.com/ayufan-rock64/linux-build/blob/master/recipes/additional-devices.md for details.)
Therefore if you try to probe i2c-0, you will get the error below:
root@rock64:~# sudo i2cdetect -y 0 Error: Could not open file `/dev/i2c-0' or `/dev/i2c/0': No such file or directory Ayufan wrote a nice script named "enable_dtoverlay" to enable the GPIO headers on-the-fly. Here is the link: https://raw.githubusercontent.com/ayufan-rock64/linux-package/master/root/usr/local/sbin/enable_dtoverlay
Download this script and copy it under /bin and make it executable. We will enable "i2c-0" with this script, which we need for the RTC module. The command to enable i2c-0 is as follows:
/bin/enable_dtoverlay i2c0 i2c@ff150000 okay After you run this command, /dev/i2c-0 becomes available, and we can probe it via the command below:
root@rock64:~# sudo i2cdetect -y 0 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: -- -- -- -- -- -- -- -- If you see the number 68, you are on the right track.
5. Now we need the kernel driver for DS1307. Unfortunately DS1307 driver is not available with armbian kernel (see below).
root@rock64:~# cat /boot/config-4.4.162-rockchip64 | grep DS1307 # CONFIG_RTC_DRV_DS1307 is not set So we need to recompile the Armbian kernel with this option enabled. I will not cover the steps to compile the kernel, you can find it here: https://docs.armbian.com/Developer-Guide_Build-Preparation/
Let's hope @Igor or any other Armbian developer will enable this module by default, and save us from this burden.
After we compile the kernel with DS1307 driver, we are almost done. We need to tell the kernel that a DS1307 chip is using the i2c-0. Here is the way to do that:
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device After we execute this command, /dev/rtc1 becomes available, and points to our external RTC module. Please note that /dev/rtc0 is the onboard RTC, which does not work, and should be avoided.
We need to update the date/time information from the system for the first time. Here is the command to do that:
hwclock --rtc /dev/rtc1 --systohc Now our external RTC clock is set, and ready to take over NTP.
6. Edit /lib/udev/hwclock-set. Find the lines below, and update as shown:
if [ -e /run/systemd/system ] ; then # exit 0 /bin/enable_dtoverlay i2c0 i2c@ff150000 okay echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device fi
7. Edit /etc/rc.local, add the following lines to set the system clock for every boot:
8. Disable the below services, as we don't need them anymore:
systemctl stop systemd-timesyncd.service systemctl disable systemd-timesyncd.service systemctl stop fake-hwclock.service systemctl disable fake-hwclock.service
9. Reboot and enjoy your RTC module.
lomady reacted to Lope in Change default Kernel options: TC (traffic control (shaping)) options available as modules/enabled
These boards are well suited to routing/network traffic control functionality.
Currently the kernel has been compiled with Traffic Control stuff disabled, which makes it impossible to perform traffic shaping on stock Armbian kernel.
I'm busy recompiling the kernel as a temporary solution, but I will really appreciate it if the kernel build maintainer can please change the traffic control options from DISABLED to MODULE (at least)?
I have a bunch of Armbian boards but I'm testing with NanoPi Neo 2 right now.
I'll let you know the size of the modules once I've finished compiling.
lomady reacted to Werner in Change default Kernel options: TC (traffic control (shaping)) options available as modules/enabled
You can send a PR with your changes to the kernel config here: https://github.com/armbian/build
lomady reacted to tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA
Little update on the NAS Expansion board: the first time I had this thing in my hands and gave it a try with mainline kernel I was surprised why the JMS578 chips on the board did not allow to use UAS. It looked always like this (lsusb -t):
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M With no other JMS578 device around I experienced this and since I'm currently testing with Orange Pi Zero Plus (still no UAS) and In the meantime JMicron provided us with a firmware update tool.... I thought I take the slightly higher JMS578 firmware revision from ROCK64 SATA cable (0.4.0.5) and update the NAS Expansion board (0.4.0.4) with:
root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -v Bridge Firmware Version: v0.4.0.4 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -v Bridge Firmware Version: v0.4.0.5 root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sdb -b ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.5.bin Backup the ROM code sucessfully. Open File Error!! root@orangepizeroplus:~/JMS578FwUpdater# ./JMS578FwUpdate -d /dev/sda -f ./JMSv0.4.0.5.bin -b ./JMSv0.4.0.4.bin Update Firmware file name: ./JMSv0.4.0.5.bin Backup Firmware file name: ./JMSv0.4.0.4.bin Backup the ROM code sucessfully. Programming & Compare Success!! Success!
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M Please keep in mind that you need to update both JMS578 of course. I won't upload the newer firmware yet since thanks to Pine's TL Lim I'm in direct contact to JMicron now and it's about fixing another JMS578 firmware issue.
lomady reacted to Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party
ATF for building H6 boards is broken and building stops. Somebody needs to fix.
lomady reacted to Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party
Mine hanged with current stock settings already at first boot ... then I tried orangepipc2 DT and ... it looks fine. I notice DT is missing regulator bits and after adding them ... at least that problem is gone. I did several reboots and cold starts. At one cold start it hanged ... Not sure if everything is fine yet.
Possible related issue is wrong temperature. It's possible that protection kicks in? When idle it already shows 50° (33 shows my IR meter) and last time when I did stressing it reached critical temp of 92° which triggered controlled power off. This should not happen this soon.
lomady got a reaction from Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party
I just wanted to make a clean shutdown before pulling the power plug.
The problem is that the Prime does not boot after I plug the power back in. As I said it freezes at various stages as seen in the boot log on the monitor connected via HDMI. I even saw a message "Unable to handle kernel paging request at address xxxxx" once.
lomady reacted to Alastair in Bionic missing for Orange Pi Prime
A few months back, I set up an Orange Pi Prime on Armbian Bionic (Armbian_5.52.180715_Orangepiprime_Ubuntu_bionic_dev_4.18.0-rc4.7z). I'm now putting together a home automation workshop around this configuration, but it looks like it's now missing from the website (https://www.armbian.com/orange-pi-prime/) and download site (https://dl.armbian.com/orangepiprime/).
Is Bionic no longer supported for this board, or was this an oversight?
Is there something I can do to help?
lomady got a reaction from Tido in Kickstarter: Allwinner VPU support in the official Linux kernel
Here is a great talk about this