destroyedlolo

Hello, didn't worked on the subjet for a while as too busy by other task and as I duno if I have or not to modify uboot as well. Anyway, it's still crashing on 2 days basis maximum. Now, I gather additional information : I'm not sure it's really linked with Cairo or any graphical stuff. In case where the PI is not totally stuck, the CPU load become over 2 but my graphical dashboard is still working with network connectivity, BUT avahi is not working anymore. So I'm suspecting (without further information) a problem with Avahi. Bye Laurent

Hi, During the last crash, I got in the stdout of my application some error coming form the kernel (like "kernel message :" + some hexa code). So I'll try to rebuild the kernel with the setting I'm using on Gentoo. But it's not clear to me the relationship with uboot. 1/ are any information shared b/w uboot and the loaded kernel ? 2/ especially, if I'm doing any changes in the DTS, do they have to be applied to the uboot side ? 3/ do I have to rebuild and reinstall uboot as well ? Thanks Laurent

Hello, Unfortunately changing the governor did'nt helped. Bye Laurent

Hi, Only thing needed is an HDMI screen, a working MQTT broker (Mosquitto, ...) and I can wrote some fake mqtt provider if needed. All the other thing is totally open-source. I can also provide in compiled form. A Lemaker's BananaPI or M1 is working as well. I duno about the DTS, but the FEX was exactly the same b/w BananaPI and BananaPro with only a small setting for a (normally unused) UART and obviously the WiFi adapter. It the first time I"m using this board and Armbian : previously, it was a BananaPI under Gentoo. I switched 2 weeks back as I lost my ADSL connection and BananaPro WiFi was useful to bridge with my Phone. So I duno what should be "stable image" or even the stable DTS (potentially the bPI one but I didn't tested yet). I may try with my bPI's Gentoo image to see if it's working (which will be a proof the DTS are almost the same but the WiFi) and takes it's DTS. Now I'm not sure it evolved since I installed my previous system. Ok, I'll try. Bye, have a nice W.E.

I sent all the information I can as even Armbian-monitor is hanging (as I said). About your last message, as you know, it was night b/w and on the morning I was ... working So just got the notification. I thought it was part of the information I copy/pasted. Anyway, the image is the one from download page, Armbian Buster for BananaPRO, with some apt-get updates to keep the system up to date but it doesn't improve (or degrade) the situation. The provided one : 5.8.16, no change, no module added (like i2c, 1-wire, ...) My bPRO was displaying its dashboard as usual. The framework related code is here : https://github.com/destroyedlolo/Selene with DRMCairo plugin. It's not linked to anything special (message arrival or such) as they are coming all day long without trouble. The same code is running on my test machine, a BananaPI (M1) under Gentoo with the same plugin and exactly the same code (by the way, I didn't check about libraries versions). As I said previously, it has been compiled exactly on the same way, w/o any CPU optimization. Otherwise, nothing else is running : stock system without X, only with network enabled. I did apt-get on : libnss-mdns libcairo2-dev libncurses (but was not used when it crashed) liblua5.1-dev libdrm-dev libfreertype6-dev In addition, I compiled locally Patho-c from official sources and obviously my framework. Not tested. 2 scenarii : - or the board is totally struck after displaying the same message as the kernel.log, and in this case the solution is a power cycle - or system is still heathy and fully usable (my dashboard is even running), without any other messages or process missing but with a CPU load of 2.0 and without stuck processes. I also trying to trace in my own application if it's linked to something special but it's happening randomly whatever is the message that triggered a GUI update. It's not a kernel problem as it's the same I'm using on Gentoo. As I found on other discuss related to the same kind of A20 Oops, it may be (conditional !) a compilation issue where some libraries has been compiled with options that are not compatible with A20. The pb is to identify with one and I don't have enough clue and/or knowledge to identify witch one with the only trace I got. There is no accusation, only fact : - my box is not stable enough for the expected usage - at the time of writing, I didn't got any reply. Now, I can spend some time to figure out the root cause of this issue, it's not because I'll probably switch I'll give it up with this solution. Cheers aussi.

Hello, After some seach, it seems it's linked to a compilation option that is not tuned for A20 and then use instruction that doesn't exist on this CPU. The problem is I'm unable to identify which component is it : kernel, system, libraries, ... In addition to the stuck system, I installed CAIRO library (not the full stack, only CAIRO and it's dependencies) and is used by my own applications. I'm incline to think it"s now my own application they are compiled w/o any architecture optimization options (only -O2) and are working well on my Gentoo's BananaPIes. Any idea to find out which is the culpite component ? How are compiled Armbian's packages ? Thanks Laurent

Hello, First of all, I'm new on Armbian I got some a stack dump on the console and can see following messages on kernel.log : --- Oct 24 14:27:28 localhost kernel: [183195.142242] 8<--- cut here --- Oct 24 14:27:28 localhost kernel: [183195.152222] Unable to handle kernel paging request at virtual address 2f68f25c Oct 24 14:27:28 localhost kernel: [183195.167942] pgd = 36f6b267 Oct 24 14:27:28 localhost kernel: [183195.179169] [2f68f25c] *pgd=00000000 Oct 24 14:27:28 localhost kernel: [183195.191263] Internal error: Oops: 805 [#1] SMP THUMB2 Oct 24 14:27:29 localhost kernel: [183195.204864] Modules linked in: brcmfmac brcmutil axp20x_adc evdev lima sun4i_gpadc_iio gpu_sched industrialio cfg80211 sun4i_ts sunxi_cir rfkill sun4i_ss sunxi_cedrus(C) zram uio_pdrv_genirq uio cpufreq_dt ip_tables x_tables autofs4 pwrseq_simple sun4i_gpadc realtek Oct 24 14:27:29 localhost kernel: [183195.247439] CPU: 0 PID: 7113 Comm: kworker/0:3 Tainted: G C 5.8.16-sunxi #20.08.14 Oct 24 14:27:29 localhost kernel: [183195.266241] Hardware name: Allwinner sun7i (A20) Family Oct 24 14:27:29 localhost kernel: [183195.281439] Workqueue: events dbs_work_handler Oct 24 14:27:29 localhost kernel: [183195.295783] PC is at cpufreq_callback+0xfe/0x12c Oct 24 14:27:29 localhost kernel: [183195.310236] LR is at cpufreq_callback+0x109/0x12c Oct 24 14:27:29 localhost kernel: [183195.324760] pc : [<c010b86e>] lr : [<c010b879>] psr: 80000033 Oct 24 14:27:29 localhost kernel: [183195.340961] sp : ed8a5df0 ip : 00000000 fp : ed8a5ebc Oct 24 14:27:29 localhost kernel: [183195.356183] r10: c0f050d4 r9 : c0e8c228 r8 : 00000001 Oct 24 14:27:29 localhost kernel: [183195.371378] r7 : 00000000 r6 : 00e8c080 r5 : ed9c9e00 r4 : c0f0548c Oct 24 14:27:29 localhost kernel: [183195.387980] r3 : 00000000 r2 : 2f68f080 r1 : 00000008 r0 : 00000000 Oct 24 14:27:29 localhost kernel: [183195.404570] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none Oct 24 14:27:29 localhost kernel: [183195.421987] Control: 50c5387d Table: 6b97806a DAC: 00000051 Oct 24 14:27:29 localhost kernel: [183195.437887] Process kworker/0:3 (pid: 7113, stack limit = 0x2dcc7ac2) Oct 24 14:27:29 localhost kernel: [183195.454629] Stack: (0xed8a5df0 to 0xed8a6000) Oct 24 14:27:29 localhost kernel: [183195.469286] 5de0: 00000001 00000000 00000000 00000000 Oct 24 14:27:29 localhost kernel: [183195.488000] 5e00: c0fc11f4 ffffffff ed8a5ebc 00000001 00000000 ffffffff ef69a580 c0136947 Oct 24 14:27:29 localhost kernel: [183195.506830] 5e20: ffffffff 00000000 c0fc11f4 00000000 00000001 c0fc1208 ed8a5ebc c0136a8f Oct 24 14:27:29 localhost kernel: [183195.525689] 5e40: 00000000 ed9c8600 00000000 ed8a5ebc ed9c9e00 ed8a5ebc c0f050d4 ed8a4000 Oct 24 14:27:29 localhost kernel: [183195.544663] 5e60: 00000000 c0136ae3 00000000 c0136ae3 00000008 c078e231 ed9c9e00 ed9c9e00 Oct 24 14:27:29 localhost kernel: [183195.563711] 5e80: ef689e00 c08a5e4d 00000000 00000000 00000002 c104d804 00000000 c078e323 Oct 24 14:27:29 localhost kernel: [183195.582889] 5ea0: ed9c9e00 00000000 00080e80 c078e859 ed935280 00002710 a7107534 ed9c9e00 Oct 24 14:27:29 localhost kernel: [183195.602209] 5ec0: 000ea600 00080e80 000000a1 c0f04fc8 ed9c9e00 ed935280 ed935d00 0022dd00 Oct 24 14:27:29 localhost kernel: [183195.621615] 5ee0: edfcb900 ed935d00 00000000 c07915f7 c0791569 ed9352b8 00000000 ed935284 Oct 24 14:27:29 localhost kernel: [183195.641127] 5f00: ed9c9e00 c0fc15a4 00000000 c07923b1 ed9352b8 edf98280 ef69a580 ef69d700 Oct 24 14:27:29 localhost kernel: [183195.660729] 5f20: 00000000 c01309fb ed8a4000 ef69a580 ed8a5f48 edf98280 ef69a580 edf98294 Oct 24 14:27:29 localhost kernel: [183195.680265] 5f40: ef69a598 c0f03d00 00000008 ed8a4000 ef69a580 c0130d47 edf98294 c0fdb887 Oct 24 14:27:29 localhost kernel: [183195.699815] 5f60: edf98280 ed0b5280 ed0b5e40 00000000 ed8a4000 c0130c4d edf98280 ec11bebc Oct 24 14:27:29 localhost kernel: [183195.719431] 5f80: ed0b52a4 c0135b07 0000004f ed0b5e40 c0135a1d 00000000 00000000 00000000 Oct 24 14:27:29 localhost kernel: [183195.739128] 5fa0: 00000000 00000000 00000000 c0100159 00000000 00000000 00000000 00000000 Oct 24 14:27:29 localhost kernel: [183195.758788] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Oct 24 14:27:29 localhost kernel: [183195.778422] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 Oct 24 14:27:29 localhost kernel: [183195.797908] [<c010b86e>] (cpufreq_callback) from [<c0136947>] (notifier_call_chain+0x43/0x5c) Oct 24 14:27:29 localhost kernel: [183195.817958] [<c0136947>] (notifier_call_chain) from [<c0136a8f>] (__srcu_notifier_call_chain+0x33/0x70) Oct 24 14:27:29 localhost kernel: [183195.839094] [<c0136a8f>] (__srcu_notifier_call_chain) from [<c0136ae3>] (srcu_notifier_call_chain+0x17/0x1c) Oct 24 14:27:29 localhost kernel: [183195.860797] [<c0136ae3>] (srcu_notifier_call_chain) from [<c078e231>] (cpufreq_notify_transition+0x7d/0x154) Oct 24 14:27:29 localhost kernel: [183195.882698] [<c078e231>] (cpufreq_notify_transition) from [<c078e323>] (cpufreq_freq_transition_end+0x1b/0x6c) Oct 24 14:27:29 localhost kernel: [183195.904941] [<c078e323>] (cpufreq_freq_transition_end) from [<c078e859>] (__cpufreq_driver_target+0x1fd/0x410) Oct 24 14:27:29 localhost kernel: [183195.927309] [<c078e859>] (__cpufreq_driver_target) from [<c07915f7>] (od_dbs_update+0x8f/0x108) Oct 24 14:27:29 localhost kernel: [183195.948495] [<c07915f7>] (od_dbs_update) from [<c07923b1>] (dbs_work_handler+0x29/0x4c) Oct 24 14:27:29 localhost kernel: [183195.969159] [<c07923b1>] (dbs_work_handler) from [<c01309fb>] (process_one_work+0x15f/0x3b0) Oct 24 14:27:29 localhost kernel: [183195.990458] [<c01309fb>] (process_one_work) from [<c0130d47>] (worker_thread+0xfb/0x3e0) Oct 24 14:27:29 localhost kernel: [183196.011469] [<c0130d47>] (worker_thread) from [<c0135b07>] (kthread+0xeb/0x10c) Oct 24 14:27:29 localhost kernel: [183196.031639] [<c0135b07>] (kthread) from [<c0100159>] (ret_from_fork+0x11/0x38) Oct 24 14:27:29 localhost kernel: [183196.051656] Exception stack(0xed8a5fb0 to 0xed8a5ff8) Oct 24 14:27:29 localhost kernel: [183196.069549] 5fa0: 00000000 00000000 00000000 00000000 Oct 24 14:27:29 localhost kernel: [183196.090862] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Oct 24 14:27:29 localhost kernel: [183196.111734] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Oct 24 14:27:29 localhost kernel: [183196.130431] Code: e004 f854 2020 4432 (f8c2) 71dc Oct 24 14:27:29 localhost kernel: [183196.147319] ---[ end trace 3a2dd626830effd8 ]--- Then CPU load goes to 2.00 but no process consumes power as per Top : it's happening on 2 days basis, randomly. Another issue : I tried to run armbianmonitor -u but it hangs after some messages (bellow) and the cpu load goes to 6.00 again without anything noticeable. ---- ---- Thanks Laurent

Hello, I'm connecting to my Armbian system from Gentoo boxes but Arbian takes a full controle of remote xterm. Consequently, impossible for me to do some copy/past using my mouse. How to avoid that ? Thanks Laurent

ok, thanks : I'll try. As I would avoid to force users to recompile system's packages, I patched my framework as well to fall back to framebuffer as well.

Well, it is supposed to be part of libdrm but has been disabled as per a ticket I found. The only examples I found to directly use Linux' frame buffer using DRM use it to retrieve display geometry and bitmap

Hello, I'm porting one of my application to Armbian. But where can I found libkms ? I did a apt-cache search but it didn't found anything ? Thanks Laurent

I found a good tutorial about low level programming on DRM/KMS. The only need is libdrm : working pretty well so I give up with DirectFB / SDL2. My only concerne is I'm not able to make LeMaker 3.5' LCD with 5.x kernel but it's another subject. THanks Laurent

X is not launched at all (as not installed ). You did your test on ARMbian only compiling SDL2 ? I think I found a solution using direct DRM/KMS + Cairo. But of it don't suite my need, I'll try ARMbian if you confime.

It's what I did after having activated Lima support in Messa. But the pb is ... it's crashing as explained above. The pb is not gentoo or not gentoo, it's the lack of support with SDL when you're not using X and more when it's not on Raspberry. It's why I'm looking if it will work w/o cheating with binary distribution.

Hello, I'm currently running Gentoo on my BananaPIs (M1). I'm using one as graphical Dashboard using DirectFB. Unfortunately, DirectFB is deprecated, not anymore supported and facing some compilation issue. Time to change. I tried with SDL configured with KMS but it's crashing. I don't want to install X because it will take ages to compile without any garanty it will work at the end. So ... probably the time to change. So, is DirectFB still supported on Armbian ? If not, is SDL2 working without X support. If not, with X support ? And if so, is X accelerated ? Thanks Laurent