Search the Community

Hello, I find armbian awesome and my problem is because of the manufacurers. I basically want to play accelerated video (because I need 4k). I tried amlogic, but it is not still supported (https://linux-meson.com/hardware.html) the status is partial for the chips I tried. I don't what "partial" means but I can hardware decoding. I also tried allwinner, several chips. In this page https://linux-sunxi.org/Sunxi-Cedrus I see that it is supported but I tried with new kernels, old kernels... Nothing worked. I always reach a point that stops me (like segmentation fault when loading sunxi modules, system freeze when using vdpau, compilation errors due incompatibility between version...) I was thinking of try some rockchip but I think that I will suffer the same pain so this is why I want to ask you guys because I am a bit lost and I am starting to think that everything I try is worthless. Can someone bring me some light? Any tip about what chips are more "friendly" with video acceleration and, if mainline kernel or not, player to use... All the documentation/posts I found are outdated or incomplete and this is the reason I am writing this post, because I am not able to find more information. I know that the manufacturers does not help and everything we have is due the awesome work of the community. It is complicated stuff. Any kind of information will be very helpful. Thanks

This PR enables kernel modules for various USB Gadget applications for rockchip 32 bit platforms (rk322x, rk3288) for both current 6.6 and edge 6.7 kernels. Also provides a bunch of patches to address issues with rk322x, whose peripheral mode does not really well with dwc2 driver yet. A couple of patches are self-produced after trial-and-error sessions, another pair are imported from rockchip 5.10 kernel and substitutes an older patch with a bit more refined code (see the "debounce" patch). edit: the patches addressing the rk322x issues probably are worth also for rk3318 and rk3328, since the controller is the very same with similar issues. During my tests, I quickly checked an rk3318 device and found it has the same behaviour (disconnection, system freeze, ...). I will do further tests and, in case, import the same patches for rockchip64 too. Jira reference number AR-2096 How Has This Been Tested? [x] Installed on live rk322x system, tested mass storage :heavy_check_mark:, ethernet :heavy_check_mark:, uac1/2 :negative_squared_cross_mark: [x] Installed on live rk3288 system in OTG mode, tested mass storage :heavy_check_mark:, uac1/2 :heavy_check_mark: For sake of curiosity, iperf3 run on rk322x in ethernet gadget mode: Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Armbian still support this way. I verified yesterday on Ubuntu Jammy derivative. Just add some command like touch /run/test following by reboot, login and see if file was created at /run I suggest you to use previous build (or latest but choose 5.4 from armbian config -> old kernels menu), freeze kernel upgrade and enjoy. I am not sure at this point what we will do with this kernel. If Hardkernel stop maintaining it, we might need to roll back to 5.4.y. I know. We are trying best to take that pain away. Also this way: https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results but problem is that all this costs a lot of time and we have to cover this from our own pockets almost entirely. Even doing it for everyone, also for our competitors that only wants you (our users) but not our costs of software support.

I just wanted to add some information here in case it helps. I'm running OMV6 stable on my Helios64 - config below, and note one caveat from the last kernel update: Kernel 6.1.50-current-rockchip64 (NOTE: Staying on 6.1.36 might be advised, network issues, see below) Armbian 23.8.1 Bullseye (clean install to Bullseye, sdcard then migrated to emmc) OMV 6.9.0-1 (Shaitan) Governor set to 408Mhz to 1800Mhz, schedutil governor (I don't remember why I selected this vs. ondemand, somehow I had the impression that it was better for ARM systems) 4 drives, WD Red 5400, 3x12TB, 1x4TB I run three drives in a MergerFS pool w/ SnapRaid on a regular run, fourth on a separate share. Offsite backups to Borgbase, run weekly. The NAS gets moderate usage - it holds media files, Proxmox VM backups, and 2 TimeMachine shares. No other random software or services, just OMV. My system is stable, no unexpected crashes or issues when running the python stress test above, or my Snapraid syncs. NOTE on the network issue with this kernel is that the most recent update had the effect of making the 2.5GB network interface (eth1, r8152 driver) unstable. It will run for a while, then randomly disappear. I only use it as a secondary path to my other server, so I was able to work around it fairly easily, but this would be a blocking issue if you relied on that. I had to build a kernel with an earlier version of the r8152 driver on another x86 machine with recent 6.1.x kernels, so I'm thinking it is the same/similar issue, but I haven't rolled back or done any serious troubleshooting yet. If you want to move to the 6.1.x branch, I'd recommend a good backup, and sticking with 6.1.36 for the moment. EDIT: The issue seems to be the same as this user's, related to Bookworm 23.08.1. I'll try their recommended solution of moving up the r8152 driver and see how it goes. I will also freeze updates for the moment if it works (armbian-config -> System -> Freeze).

Hello, has anyone tried (for X88pro10 owners) to restore the front panel clock? Also, when installing @timfischbach Armbian 23.08, the display is broken, so I installed the 22.02 from Hyper HDR tutorial mirror and works fine. but i needed to freeze the kernel and install the latest 5.x as all 6.x kernels ends up with no HDMI (because I use it with desktop. after all the updates, My system reports this: daniel@X88-Pro10-01 OS: Armbian (23.8.1) aarch64 Host: Rockchip RK3318 BOX Kernel: 5.15.93-rockchip64 Uptime: 15 hours, 26 mins Packages: 1294 (dpkg) Shell: zsh 5.8 Resolution: 1920x1080 Terminal: /dev/pts/0 CPU: (4) @ 1.296GHz Memory: 1358MiB / 3973MiB Hardware acceleration seems broken as Minetest 5.3.0 (OpenGL 2.1) at lowest settings run at 6 fps and 0.AD has graphics problems and runs at 7 fps and CPU @ 100% Anything I have done wrong?

Hi!, I tried kernel 6.5.2 vanilla make oldconfig, + enable JMicron PATA driver USB is working but I don't know if dwc3 is by chance reset or due to the fix... EDIT: dwc3 reset still doesn't work, waiting for the fix So yes, please freeze your kernels

Description This is experimental support for DDR dynamic frequency changing for Allwinner H3. It based on: https://github.com/smaeul/u-boot/commits/patch/h3-dram-devfreq https://github.com/smaeul/linux/commits/wip/devfreq-a83t Discussion on linux-sunxi listing: https://lore.kernel.org/linux-sunxi/CAKAF0m_6C68ox5z-NX1D6rjREgiySmSdxcda-KRvyehZssD5OQ@mail.gmail.com/T/#t My fixes for H3 Due to H3 hardware bugs (see listing) it implemented by software "emulation" of MDFS: It uses a special helper in the u-boot PSCI code. This is needed, because changing DDR freq is possible only in the SRAM. Before freq changing all secondary CPU's put in the while(true) on PSCI handler (in SRAM). This is needed, because after DDR RAM enters self-refresh mode any RAM access leads to a complete freeze. We must suspend all execution on any secondary cores to prevent this. And, finally, call PSCI callback SUNXI_PSCI_DRAM_DVFS_REQ on CPU0 for changing frequency. Not great, but works. Similar way implemented in the original legacy sunxi kernels: https://github.com/Tina-Linux/tina-v83x-linux-4.9/blob/master/drivers/devfreq/dramfreq/sunxi-ddrfreq.c#L1373 But instead of PSCI in u-boot it uses a dirty hack by writing code from kernel to the SRAM. P.S.II'm not sure if this module should be enabled by default. Most of users want performance instead of power saving. Maybe better and safer to disable this in DT (by status = "disabled"). And who needs it can enable using DT overlay. How Has This Been Tested? Build and update kernel Build and update u-boot Run something like this: https://gist.github.com/Azq2/955b4ebaaa526243e3d4b111d9afa5c9 Tested: [x] h3 (orangepilite) Not tested: [ ] a33 (support added by this patches) [ ] a83t (support added by this patches) [ ] a64 [ ] h5 Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Thank you! BTW. We are just about to switch to a completely reworked version of it: https://www.armbian.com/newsflash/code-freeze-and-moving-to-new-framework/ This should also help dealing with RT patches. If we had someone around to deal with RT patch discrepancy, we could also generate RT kernels.

As stated in my comments here (but it seems no one is reading this blog post comments anymore ...) : https://blog.kobol.io/2020/10/27/helios64-software-issue/ - With 5.8.17 i have kernel panics. - With 5.8.14 i have freeze. So what to do in order to have a stable situation ?! It seems to be "under load" (one freeze during RAID array being built, and several ones (with .14 or .17 kernels) while files were being copied through the 1Gb/s network interface). - System newly installed and running on fresh SSD card. - 5*3.5" WD HDD plugged in / RAID5 mdadm array (so no M.2, ...) - nothing else done on the NAS (nothing has been installed on the OS, no processes in memory outside raid + rsync or scp file copying through SSH)

I used Igor's advice for another issue : Workaround: armbian-config -> system -> Other -> Switch to other kernels , pick previous, freeze, wait | |linux-image-current-mvebu64=22.08.2 5.15.69-mvebu64 | | | |linux-image-current-mvebu64=22.05.3 5.15.48-mvebu64 | | | |linux-image-current-mvebu64=22.05.1 5.15.35-mvebu64 | | | |linux-image-current-mvebu64=21.08.1 5.10.60-mvebu64 | | <<-- CPU scaling is not broken I progressively downgraded to kernels 5.15.69, than to 5.15.48 and 5.15.35. None of them allowed to fix CPU scaling. This is rather strange, as I run another espressobin, which doesn't loose CPU scaling with kernel 5.15.48-mvebu64. This second espressobin is version 5 and u-boot running at 1000 MHz. This could give a clue to fix broken CPU scaling in kernel 5.15.xx. Just to remind, that root@ebinv7# dmesg -l emerg,alert,crit,err [ 1.917740] debugfs: Directory 'd0060900.xor' with parent 'dmaengine' already present! [ 2.420702] Unsupported CPU frequency 1200 MHz <<-- vs -->> ebinv5 @1000 MHz After 5.15.x disenchantment I've downgraded to 5.10.60-mvebu64, which fixed CPU scaling : root@ebinv7:/boot# dmesg -l emerg,alert,crit,err [ 2.319871] debugfs: Directory 'd0060900.xor' with parent 'dmaengine' already present! [ 5.739975] advk-pcie d0070000.pcie: link never came up root@ebinv7:/boot# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1.20 GHz available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 200 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.20 GHz (asserted by call to hardware). cpufreq stats: 200 MHz:22.65%, 300 MHz:8.94%, 600 MHz:0.09%, 1.20 GHz:68.32% (1637) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1.20 GHz available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 200 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.20 GHz (asserted by call to hardware). cpufreq stats: 200 MHz:22.65%, 300 MHz:8.94%, 600 MHz:0.09%, 1.20 GHz:68.32% (1637) root@ebinv7:/boot# lscpu Architecture: aarch64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Vendor ID: ARM Model: 4 Model name: Cortex-A53 Stepping: r0p4 CPU max MHz: 1200.0000 CPU min MHz: 200.0000 BogoMIPS: 25.00 NUMA node0 CPU(s): 0,1 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Spec store bypass: Not affected Vulnerability Spectre v1: Mitigation; __user pointer sanitization Vulnerability Spectre v2: Not affected Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid Has this bug been reported and scheduled for fixing? On the other side, why do I still receive 2 upgrades available, while 22.08 is already setup? Welcome to Armbian 22.08.6 Bullseye with Linux 5.10.60-mvebu64 root@ebinv7:/boot# apt list --upgradable Listing... Done linux-dtb-current-mvebu64/bullseye 22.08.6 arm64 [upgradable from: 21.08.1] linux-image-current-mvebu64/bullseye 22.08.6 arm64 [upgradable from: 21.08.1]

This is how mainline Linux looks like. Features breaks all the time (caused by constant kernel changes / development) and its impossible to track as this is simply too expensive. Linux distributions in majority are not doing any testings of those functions, while our test system is too primitive to detect something like this. A few more hundreds of thousands would be needed to put in, which is, in case you want free service, impossible. If detection would be made, someone needs to invest hours to fix it. Currently waiting things, average resolving rate = 400 days. So you have an idea how little you are investing into maintenance on top and around chaotic mainline Linux experience. Workaround? Those usually always exists. One of them is going to armbian-config -> system -> other kernels and switch to older kernel, where this function was working. Then freeze kernel (which is anyway good thing for production deployment) and check from time to time if this was fixes. No, nobody will send you email when this will be fixed ...

I would check out some of NicoD's videos on YouTube, as he is a desktop Armbian user and has made several videos from that perspective. I am sure there must be some other forum threads around here about it as well. If you meant swapping SD cards, then OK. But if you mean a true live distro, like on a USB thumb drive (as on x86), then probably not (in most cases) as arm/SBC world is very different from x86, especially around booting. If you can't get that to work in a (bloated) browser, a workaround I often use is to open the video in mpv. In fact you can do something like 'mpv youtubelink' and mpv has youtube-dl (or equivalent) installed as a dependency and can usually download and display the video all in one go. Saved me more than once on several low-spec or older devices. I somehow missed this on first read. But I guess it is one of your main requirements. I don't think you will find that. Because Linux kernel, and drivers, etc. (what you might call firmware) are being developed all the time. And so they will be moving forward, and released with new versions of Armbian. Having said that, at least with Armbian (and Free Software in general) you can see what the sources are, where they come from, when they get upgraded, build your own if you like, etc. There are also some options to freeze kernels, etc. which would get you pretty close to what you are looking for I think. As close as I think you will be able to get, anyway. Very few of these vendors provide any real long term (mainline) software support. Such is life in SBC world. These devices are fascinating, but it is up to us to keep them working (N.B. some of links/statements in my forum signature).

OK, well the solution is that the kernel needs the cgroup.freeze feature which is only in kernels above 4.15. Which I am running Linux 4.9.255-sun50iw9 aarch64. I am going to try and see if one of the other newer builds will boot and go from there tomorrow.

Hi, after having successfully had my H96Max+ working for a few days now with a single major hiccup I would like to inquire about three items. The single issue that I encountered was a total freeze during intense activity on the SD card while copying files transferred through wifi. This copying is something that I could have done in a much quicker way but that I purposely did this way to stress the machine with a 2+ hours of continuous activity. However, because I had this single freeze, that did not happen again, it is difficult for me to say if this was due to some OS or hardware instability or maybe some external factor (e.g., a power fluctuation). It would be interesting to me to know if someone else experienced similar issues. I would like to know if RK3328 supports some form of hardware watchdog timer to be used with the watchdog daemon. I understand that once the machine is installed (thanks for the great work of jock and possibly others), maintaining the machine up to date and secure should be relatively easy, since most of the OS can be updated through the regular armbian repos. In my understanding the notable exceptions are the kernel packages at https://users.armbian.com/jock/rk3318/upgrade/ namely those that had to be put on hold wrt apt (linux-image-edge-rockchip64 linux-headers-edge-rockchip64 linux-dtb-edge-rockchip64). If I understand correctly, these can only get updated thanks to jock's effort because rk3318 is not part of armbian (yet). Having these packages depending on a single person best effort means on one hand that gratefulness to Jock is huge but on the other hand may also represent a potential issue. I thus wonder how difficult is it to re-build them by https://github.com/paolosabatino/armbian-build/tree/rk3318 and the armbian kernel tree, how much does the rk3318 diverge from the mainline kernel, how easily/frequently do the rk3318 patches break against newer mainline kernels and how difficult would it be to recover from a bad kernel (in case one tries to build and deploy a kernel for learning how to do it and something goes wrong). Thanks for any help!

For anyone that runs into this. I too went back to 5.9.14. My process to fix was to download Armbian focal with 5.9.14. Write Armbian focal to SD Card/USB Stick. Boot from SD Card/USB Stick (hold the boot button on the NanoPC). Log in as root, mount the /dev/mmcblk2p1 (this is the emmc) to /mnt/mmc. Copy (cp -rv /boot/* /mnt/mmc/boot/ ) everything in /boot to /mnt/mmc/boot. BUT! Do not overwrite your armbianEnv.txt. Rename it or move it to keep it from being overwritten. In my case I'm booting from EMMC but my rootdev is on my NVME. I made the mistake of writing over the armbianEnv.txt which is why I share the warning. If you do, you'll get a missing rootdev error on boot (and you'll hear a sad horn sound in your mind). Reboot into the SD Card Armbian again, mount /dev/mmcblk2p1 as before and edit armbianEnv.txt as root. My root partition on my NVME is /dev/nvme0n1p1. Comment out the existing rootdev (which is actually the rootdev of your SD card - Doh!) and replace it like this: #rootdev=UUID=e3841b02-afff-4f2d-9b88-990f1e858c10 rootdev=/dev/nvme0n1p1 Should get you going again. keep in mind, this will get you booted. Services that depend on or compiled for your kernel headers (like Docker) will fail. You'll need to fix your kernel branch using armbian-config > System > Other (Other Kernels) as well. I'd also recommend you freeze your kernel from future kernel updates with armbian-config > System > Freeze

armbian-config - wireless network connect, - AP (hotspot) in bridged or NAT mode, - freeze and unfreeze kernel and BSP upgrades, - edit boot environment, network, FEX, welcome screen items, - switching between available kernels and nightly builds, - enabling read only root filesystem (Ubuntu only), - set display resolution (H3 boards with legacy kernel), softy - TV headend (IPTV server) - Syncthing (personal cloud) - SoftEther VPN server (VPN server) - Transmission (torrent server) - ISPConfig (WEB & MAIL server) - Openmediavault NAS (NAS server) - PI hole (ad blocker) - MiniDLNA (media sharing) Welcome to submit / push your modifications if you think they are interesting for general public.

@kratz00 @FredK Actually, let me revise this after re-reading again. To note that when you have 5 or more drives running on the Armada 3700 series SoC like in ESPRESSOBin there are bugs in the DMA transaction process that can be hit which will trigger some weird events such as kswapd using 100% CPU and terminating all IO access, Kernel Panic, Drive failures reports by sata controller or a freeze. I have seen this predominantly occur during a raid reshape but it can happen at other times as well. On the ESPRESSOBin one of the things that can help get around this is if you are using mdadm and raid5 you can use the xor engine in the chip to handle DMA calculations and this will help to offload it under a lot of conditions. The module is 'marvell-cesa' on ESPRESSOBin, I would guess its is names similarly here. Especially with 5.x.y series kernels I have had to use this. I am currently running a raid of 7x3TB drives on a 8 port PCIe adapter placed into a mini-pcie to PCIEx1 adapter slot attached to the mini-pcie on the board. It is stable under 5.4.y or newer with that module inserted, otherwise under high load from NFS or local system for extended periods I will see errors first where it will fail to allocate dma requests in time and then shortly after system instability, usually resulting in any of the above mentioned outcomes. Maybe if you are not using that module you could compile it and see if it helps with this issue in the newer kernels. Past that it did sound possible if this isn't specifically something caused by change in kernel version like it could be related to bad SATA cable or under power. my 2 cents. Cheers!

Hi there, This is my firs msg to this forum. First off I'd like to congratulate the devs on the superb work they've been doing. I own a RockPro64 for almost a year and always wanted to use it as both a small server (with a few services installed as for example FTP, NextCloud, etc) and as a media center connected to my TV via HDMI to run Kodi (so no need of a desktop... only Kodi and remote SSH access), but since hardware acceleration was a must, I'd never found a suitable option. So I've been using LibreELEC and installing things I need mostly using Docker (which is not that a good solution since I wanted a 'real' server). The thing is yesterday I found this topic and noticed the nice work you guys have been doing. I installed it (eMMC, which seems to be working smoothly so far), but I have a couple of questions I'd like to ask if possible. Since I don't need a desktop is there a way to boot automatically on Kodi, since it's all 'graphical' I'll need on this machine? I've seen a couple of old Kodi tutorials suggesting the creation of a systemd file, but I'm not sure if it's still valid to use with Armbian. Another option I saw here in this very forum, suggesting either placing kodi-gbm-wrapper in /etc/rc.local or disable the desktop and add "kodi" to my .bashrc (which I believe would be more suitable in my specific case). Which one do you suggest? And what would be the best way I could do that, considering that I just need boot on Kodi and remotely ssh the box? Another question is the kernel. I've read this whole thread and noticed that you optmized and hacked things deeply. I also noticed that the armbian-config tool has an option to 'freeze' the kernel. In order to keep using your optimizations I must freeze the kernel or it won't be necessary? And what about other updates? May I safely keep doing 'apt-get udate && apt-get upgrade' and just rebuilding your script? Another detail I noticed is about Kodi itself. As soon as I run it yesterday I saw a message warning about an update. I imagine I must not update, correct? The last question is about mainline kernels. I understand that you guys developed a specific solution to a specific scenario (in this case, a legacy kernel). Are there any plans to maybe develop a similar solution to mainline, though? Thank you very much for any help and keep up the good work. :)

Next memory exception (page allocation failure) I found while doing rsync... This time I even disabled ram-log (50MB). ZRAM still @ 50%. During this failure the system did not freeze. So even if you have 512M, there might still be something broken with page allocation on kernels after 4.9.x! [ 147.806318] rsync: page allocation failure: order:0, mode:0xa20(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0 [ 147.806351] CPU: 0 PID: 1451 Comm: rsync Not tainted 5.4.8-sunxi #19.11.6 [ 147.806355] Hardware name: Allwinner sun8i Family [ 147.806392] [<c010da8d>] (unwind_backtrace) from [<c010a0b1>] (show_stack+0x11/0x14) [ 147.806409] [<c010a0b1>] (show_stack) from [<c093634f>] (dump_stack+0x6f/0x7c) [ 147.806427] [<c093634f>] (dump_stack) from [<c022dfa9>] (warn_alloc+0x99/0x100) [ 147.806440] [<c022dfa9>] (warn_alloc) from [<c022ebf9>] (__alloc_pages_nodemask+0xbe9/0xc9c) [ 147.806451] [<c022ebf9>] (__alloc_pages_nodemask) from [<c022ee1b>] (page_frag_alloc+0xe3/0xec) [ 147.806463] [<c022ee1b>] (page_frag_alloc) from [<c07ec1e1>] (__napi_alloc_skb+0x6d/0xac) [ 147.806481] [<c07ec1e1>] (__napi_alloc_skb) from [<c06e362d>] (stmmac_napi_poll_rx+0x285/0x7d8) [ 147.806498] [<c06e362d>] (stmmac_napi_poll_rx) from [<c07fe703>] (net_rx_action+0xdb/0x2dc) [ 147.806511] [<c07fe703>] (net_rx_action) from [<c01022f7>] (__do_softirq+0xdf/0x288) [ 147.806524] [<c01022f7>] (__do_softirq) from [<c01202c3>] (irq_exit+0x7b/0x90) [ 147.806541] [<c01202c3>] (irq_exit) from [<c01601d3>] (__handle_domain_irq+0x47/0x84) [ 147.806557] [<c01601d3>] (__handle_domain_irq) from [<c05ca51d>] (gic_handle_irq+0x39/0x6c) [ 147.806569] [<c05ca51d>] (gic_handle_irq) from [<c0101ae5>] (__irq_svc+0x65/0x94) [ 147.806574] Exception stack(0xc00bbd78 to 0xc00bbdc0) [ 147.806581] bd60: cd0fde58 c00bbec8 [ 147.806590] bd80: c00bbe10 00002c20 cf0ab3c0 00000002 cd0fde58 cfb3e010 cfb3e037 00000003 [ 147.806599] bda0: 00000027 c00bbe78 5841c1d2 c00bbdc8 c025bf6f c0266be0 a0070033 ffffffff [ 147.806614] [<c0101ae5>] (__irq_svc) from [<c0266be0>] (__d_lookup_rcu+0x50/0x114) [ 147.806630] [<c0266be0>] (__d_lookup_rcu) from [<c025bf6f>] (lookup_fast+0x3b/0x1bc) [ 147.806642] [<c025bf6f>] (lookup_fast) from [<c025e195>] (path_openat+0xcd/0xe14) [ 147.806651] [<c025e195>] (path_openat) from [<c025fabf>] (do_filp_open+0x4f/0x90) [ 147.806665] [<c025fabf>] (do_filp_open) from [<c0251081>] (do_sys_open+0x125/0x194) [ 147.806677] [<c0251081>] (do_sys_open) from [<c0101001>] (ret_fast_syscall+0x1/0x62) [ 147.806681] Exception stack(0xc00bbfa8 to 0xc00bbff0) [ 147.806689] bfa0: b6ee4000 b6f53968 ffffff9c bebada14 00020000 00000000 [ 147.806698] bfc0: b6ee4000 b6f53968 bebada14 00000142 bebada14 00478418 00008000 00466948 [ 147.806705] bfe0: 00000142 bebad8c8 b6e7c25d b6e05746 [ 147.806709] Mem-Info: [ 147.806726] active_anon:99 inactive_anon:249 isolated_anon:0 active_file:447 inactive_file:502 isolated_file:0 unevictable:4 dirty:0 writeback:0 unstable:0 slab_reclaimable:3973 slab_unreclaimable:7604 mapped:592 shmem:80 pagetables:415 bounce:0 free:32645 free_pcp:56 free_cma:32145 [ 147.806739] Node 0 active_anon:396kB inactive_anon:996kB active_file:1788kB inactive_file:2008kB unevictable:16kB isolated(anon):0kB isolated(file):0kB mapped:2368kB dirty:0kB writeback:0kB shmem:320kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [ 147.806756] Normal free:130580kB min:5388kB low:5708kB high:6028kB active_anon:368kB inactive_anon:1004kB active_file:1752kB inactive_file:2052kB unevictable:16kB writepending:0kB present:262144kB managed:243968kB mlocked:16kB kernel_stack:1168kB pagetables:1660kB bounce:0kB free_pcp:224kB local_pcp:32kB free_cma:128580kB [ 147.806758] lowmem_reserve[]: 0 0 0 [ 147.806766] Normal: 3*4kB (EC) 207*8kB (UEC) 158*16kB (UEC) 41*32kB (UC) 12*64kB (C) 13*128kB (C) 7*256kB (C) 2*512kB (C) 1*1024kB (C) 0*2048kB 29*4096kB (C) = 130564kB [ 147.806801] 1050 total pagecache pages [ 147.806808] 6 pages in swap cache [ 147.806813] Swap cache stats: add 18554, delete 18543, find 779/1883 [ 147.806816] Free swap = 52860kB [ 147.806818] Total swap = 121980kB [ 147.806821] 65536 pages RAM [ 147.806824] 0 pages HighMem/MovableOnly [ 147.806826] 4544 pages reserved [ 147.806829] 32768 pages cma reserved

It will upgrade to more recent DEV kernels if you will run apt update and upgrade unless you choose to freeze kernel updating in armbian config or manually (not recommended).

Hi! I'm using Armbian with Ayufan's 5.3.0rc4 kernel (until ~1 month ago when I decided to freeze the dev kernels, they were not able to expose the pwmon for the fan that I need to keep running to cool my nas case). But I've seen lots of updates flying around about uboot. So I am wondering: are there significant improvements to uboot? I am currently using an old version of uboot on the SPI flash (so it is a little painful to test new version) and I am wondering if I should disable my SPI in order to have uboot on my emmc (to boot off the emmc) or if there is even a newer option to reflash my spi with a newer uboot... Thanks, Mathias PS: so far, every time I've reflashed my SPI with Ayufan's sd-card image, it was very, very slow and I never got any visual feedback so I had to leave it for several hours to be sure it would work

before the freeze-temperatures we had this error-message on some boards. So we are where we were before. This error was in/with newer kernels (dtb?)

https://forum.armbian.com/topic/10767-updated-kernels-for-odroid-xu4/ It's a small upgrade which align with Hardkernel's and upstream changes which are mainly some minor bug fixes only. Extracting, testing each change and writing this to a special file is too time consuming and tell little. Peek the logs if you see anything that is important to your use case: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v4.4.184 https://github.com/hardkernel/linux/commits/odroidn2-4.9.y + our changes with updates to some wifi if relevant: - added wireless drivers for 88x2bu - updated wireless drivers for Realtek 8811, 8812, 8814 and 8821 - updated wireless drivers for rtl8188eus & rtl8188eu & rtl8188etv - added latest Wireguard driver It was tested for booting, so it should be safe to upgrade ... in case something is odd, you can still revert and use older kernels, perhaps freeze them and update packages only. Very unlikely that you will need this - support for XU4/HC is matured.

I have try to defreeze the kernel. Next, I begin with issues, the same issue with iptables. I just understood that the armbian firmware was upgraded, but not the kernel which always stay on 4.14.18-sunxi. So I try to install a kernel which correspond to the version of armbian... After I make a mistake, I have click on Other swith to Nightly kernels. It has upgraded the armbian on 5.83.190502 nightly. To try coming back to the stable version I have edited the file /etc/apt/sources.list.d/armbian.list to come back at stable version with '''deb http://apt.armbian.com''' But it still booting with nightly version. I have choose again the kernel 4.14.18-sunxi and Freeze the updates for the moment. But how can I rollback to a stable version of armbian ??

Only side effect would be slightly increased power consumption at idle, for other clock frequencies. I don't have a sense for how many non 1GHz espressobins are out in the world. As it stands many v7 boards kernel panic, freeze or reboot with all kernels missing the equivalent of this patch. I have v5 and v7 and all are 1GHz (though if you read above, apparently it really is 800 MHz internally and I'm waiting for FlashBurn to confirm the cpufreq code executed the 1000 MHz code path.