Jump to content

Bug GUI Armbian on Pinebook


leperotero

Recommended Posts

Most likely because 3D acceleration needs to be disabled. Its not working very well on some versions.

 

Try this - run this as root and reboot:

echo 'Section "Device"
Identifier    "Default Device"
Option        "AccelMethod" "none"
EndSection' >> /etc/X11/xorg.conf.d/01-armbian-defaults.conf

 

Link to comment
Share on other sites

Ok, this is my new file /etc/X11/xorg.conf.d/01-armbian-defaults.conf

 

Section "Monitor"
    Identifier        "Monitor0"
    Option            "DPMS" "false"
EndSection
Section "ServerFlags"
    Option            "BlankTime" "0"
    Option            "StandbyTime" "0"
    Option            "SuspendTime" "0"
    Option            "OffTime" "0"
EndSection
Section "Device"
    Identifier    "Default Device"
    Option        "AccelMethod" "none"
EndSection

But the problem persists :(

Link to comment
Share on other sites

On 9/12/2020 at 8:57 AM, Werner said:

As a temporary workaround  and until further investigation you can use armbian-config to switch back to the sunxi64-legacy kernel which contains 5.4 branch.

 

I downloaded Armbian_20.08.1_Pinebook-a64_focal_current_5.8.5_desktop.img and booted it from an sdcard, and seem to have the same issue: the armbian login window just briefly shows up, before the screen seems to go off.

 

If you just blindly type into the black screen you can see in syslog via ssh that you still log on..

 

Indeed switching to 5.4.62 seems to be a temporary workaround; now the armbian login screen does not disappear, and things seems to work normally..

 

I have no clue what's going on here, indeed sth with the new kernel?-)

Link to comment
Share on other sites

On 9/11/2020 at 9:05 PM, leperotero said:

Yes, I reboot many times and the problem persist... The computer load XFCE4, this connect the Wifi and after 5 seconds the screen is black...

maybe you should - like on my Pinebook- set the display brightness via /etc/rc.local?

#set display brightness
pkexec /usr/sbin/xfpm-power-backlight-helper --set-brightness 8

I did read out the actual dim value as 2:

#read-out display brightness
pkexec /usr/sbin/xfpm-power-backlight-helper --get-brightness
2

and I did set (via /etc/rc.local) a for-me-default value of 8
A value of 10 (max.?)was to bright for me :) 

Link to comment
Share on other sites

23 hours ago, guidol said:

maybe you should - like on my Pinebook- set the display brightness via /etc/rc.local?


#set display brightness
pkexec /usr/sbin/xfpm-power-backlight-helper --set-brightness 8

I did read out the actual dim value as 2:


#read-out display brightness
pkexec /usr/sbin/xfpm-power-backlight-helper --get-brightness
2

and I did set (via /etc/rc.local) a for-me-default value of 8
A value of 10 (max.?)was to bright for me :) 

 

Changed back to kernel 5.8.5, and changing the brightness like this just shows me a brighter black screen ;-) Issue remains the same, no output to the pinebook's screen,  can login by typing my password in the black screen, see the login happening via ssh.. 

 

Link to comment
Share on other sites

Was looking for a place to post a solution to this issue, but you guys have got there before me.As others have described, booting a (my) Pinebook with the latest version of Armbian (tried both Bionic and Buster) results in a blank screen seconds after boot.This is even after booting to multi-user.target when there should be no graphical display manager running.I got the latest kernel/version available for 19 and tried that (Kernel 5.4.62) and that worked.Previously I'd tried doing a full firmware upgrade, disabling the lightdm.service, setting the boot target to multi.user/3 and disabling the autologin (in case that had something to do with it) but under the 5.8 I got the blank screen each time.Not complaining here - just wanted to confirm I'd had the same issue.Love Armbian and all the great work that's being done - peace to all.

 

Manjaro ARM also does the same thing, by the way, so it's not just an Armbian issue

Link to comment
Share on other sites

I have loaded the latest Armbian_20.11.9_Pinebook-a64_buster_current_5.10.4_desktop.img and this problem is still present.

My pinebook 1080 boots but one second after the "starting kernel...." message the screen become black.

I would be grateful if somebody could kindly address this problem. Armbian has not been working on pinebooks for 4 monthes...

 

thank you in advance

Link to comment
Share on other sites

2 hours ago, rd235 said:

I would be grateful if somebody could kindly address this problem.

 

And you will kindly cover costs of that investigation? And all those we already did but failed to fix anything? Or at least do something we need?

 

2 hours ago, rd235 said:

Armbian has not been working on pinebooks for 4 monthes...

 

Legacy images with kernel 5.4.y works

https://armbian.hosthatch.com/archive/pinebook-a64/archive

We'll remove 5.10.y from download section.

Link to comment
Share on other sites

@IgorI have got a 720p white non-pro Pinebook A64.
I compiled via the armbian-build-system Armbian 21.02.0-trunk Buster with Linux 5.10.9-sunxi64 

 

On my Pinebook at first it does show the armbian-logo and the text until "starting kernel"

Then it goes black/dark/blank for a few seconds.

After that I DO GET again the armbian-logo but this time in the middle of the screen with a Win10-Circle-Loading-Logo

 

Now the logo and circle disappear and the backlight stays on with nothing on the screen :(

 

I connected a USB-Ethernet-Adapter and logged in via SSH to get the system-information from the armbian-monitor:

System diagnosis information has been uploaded to http://ix.io/2Ndg

 

But in the next reboots the USB-Ethernet doesnt seems to be recognized anymore (Link is blinking, but no IP from DHCP)

 

Link to comment
Share on other sites

7 minutes ago, guidol said:

Now the logo and circle disappear and the backlight stays on with nothing on the screen


Yeah, that's it. IMO something is wrong with / around LCD driver. I suspect this - Pine only sells Pinephone, which is the very similar hw, just in different form factor and by upstreaming LCD on Pinephone they break support for Pinebook somehow ... Since we already lost several afternoons trying to fix this it is unlikely to repeat that anytime soon. Not possible :( 

Link to comment
Share on other sites

1 hour ago, guidol said:

I did try totday the actual DietPi image....

 

That is expected since they take someone image (probably its armbian in this case) and repacks it with their branding and few bash scripts.

Link to comment
Share on other sites

Today I compiled armbian buster 5.4.88 legacy

 

Had not the armbian-logo with the Win10 Circle (after the kernel-screen) but a working boot-log.

 

After creating User/Password the Desktop was starting normally
(but in turkish, because I cant select english/german in my timezone :( )

 

But after configuring some settings in armbian-config and reboot after that the desktop wouldnt come on again - 

I only do get a blinking cursor :( 

 

Last Line in dmesg: [   64.079236] broken atomic modeset userspace detected, disabling atomic

 

System diagnosis information has been uploaded to http://ix.io/2Nic

 

[EDIT]  Had disabled Desktop with "Enable Desktop" because it did show "Enable Desktop" when the Desktop is already enabled :( Now Desktop came up again (also after asking to auto-login into the desktop)

 

PS: I deleted language tr_TR and installed de_DE additionally to en_US, but now the terminal says
"LC_ALL: cannot change locale (tr_TR.UTF8" but in .bashrc I also removed the tr_TR lines

/etc/environment is empty ....

Link to comment
Share on other sites

33 minutes ago, guidol said:

because I cant select english/german in my timezone


This is going to be fixed hopefully before next major release https://github.com/armbian/build/issues/2398

 

33 minutes ago, guidol said:

But after configuring some settings in armbian-config and reboot after that the desktop wouldnt come on again


We have notice this problem but it seems to be related to some Debian library. There are so many problems and so little time ...

Link to comment
Share on other sites

On 1/24/2021 at 6:05 PM, Igor said:

And you will kindly cover costs of that investigation? And all those we already did but failed to fix anything? Or at least do something we need?

I did not want to be offensive. The meaning of my words was supposed to be literal not ironic. I am sorry if my sentence has been misunderstood.
I am a developer myself, Debian guest maintainer of many packages, I know how bad can be a bug sometimes.
 

It is for sure a problem in the LCD driver. It is a pity because armbian+new kernel used to work like a charm before the kernel update.  Maybe it is possible to rollback to the latest working kernel (not to the legacy 5.4xx).IMO this would help to find the change in the kernel which caused the misbehavior.

Link to comment
Share on other sites

44 minutes ago, rd235 said:

I am a developer myself, Debian guest maintainer of many packages, I know how bad can be a bug sometimes.

 

I guess that doesn't take 50-80h from your every day? And you probably don't have thousands of users pushing on round the clock to fix this and that and asking how to run a space shuttle on a 15 USD device? :P Finding bugs under such circumstances? I can easily blow whole day just for giving you tips that you don't waste weeks, just days, while children are running around the house 1/2 of a day, then 1/3 of the time needs to be secured to pay for the bills. Including yours. Project costs are not near covered by donations. We have to add majority.

 

44 minutes ago, rd235 said:

It is for sure a problem in the LCD driver. It is a pity because armbian+new kernel used to work like a charm before the kernel update.  Maybe it is possible to rollback to the latest working kernel (not to the legacy 5.4xx).IMO this would help to find the change in the kernel which caused the misbehavior.


When you pull out full blown maintenance, things starts the process of breaking down. For things where we are close with, we are fixing them when they happens - usually by some upstream change or our mistake, here not. It is expected and vendor only cares about the toy that is selling which is IMO the cause of this problem. But I could also be wrong. I would need a silent afternoon just to confirm that. We have a good enough workaround, which we designed for you to stay happy and for us to not get crazy - legacy images. It is not possible to roll kernel back under any conditions -  you can freeze yours at last working version but we don't know which is.

Link to comment
Share on other sites

Hallo Igor,

 

thanks for taking the time. I tried to debug the issue my self but good stuck on booting an vanilla kernel (creating the uinitrd for it). Wondering if there is some documentation on how to boot the a64 without it (i dont see why we need one here).

 

Meanwhile i have some bootlog with from the armbian kernel (which you probably already have but which may help other to help here debugging)

 

[ ***  ] A start job is running for Armbian …ware optimization (28s / 2min 14s)
[   44.008360] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:crtc-0] flip_done timed out
[   54.237793] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:43:eDP-1] flip_done timed out
[***   ] A start job is running for Armbian …ware optimization (29s / 2min 14s)
[   74.744614] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:crtc-0] flip_done timed out
[   84.957794] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:43:eDP-1] flip_done timed out
[  OK  ] Finished Armbian hardware optimization.
[  105.469267] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:crtc-0] flip_done timed out
[  115.695951] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:43:eDP-1] flip_done timed out
[  125.928118] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:35:plane-1] flip_done timed out
[  OK  ] Reached target Basic System.
[  136.174199] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:crtc-0] flip_done timed out
[  146.438337] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:43:eDP-1] flip_done timed out
[  156.637767] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:35:plane-1] flip_done timed out
         Starting Accounts Service...
[  166.899900] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:crtc-0] flip_done timed out
[  177.148191] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:43:eDP-1] flip_done timed out
[  187.357792] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:35:plane-1] flip_done timed out
         Starting Save/Restore Sound Card State.
[  197.597808] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:crtc-0] flip_done timed out
[  207.837779] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:43:eDP-1] flip_done timed out
[  218.102088] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:35:plane-1] flip_done timed out
[  OK  ] Started Armbian first run tasks.
[  228.356302] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:crtc-0] flip_done timed out
[  238.557787] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:43:eDP-1] flip_done timed out
[  248.797769] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:35:plane-1] flip_done timed out
         Starting Bluetooth service...
 [  259.089793] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:41:crtc-0] flip_done timed out
[  269.315817] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:43:eDP-1] flip_done timed out
[  278.242162] Unable to handle kernel paging request at virtual address 0000000040030027

 

and later on the trace to it

 

[  279.621805] ------------[ cut here ]------------
[  279.621822] [CRTC:41:crtc-0] vblank wait timed out
[  279.621904] WARNING: CPU: 1 PID: 193 at drivers/gpu/drm/drm_atomic_helper.c:1513 drm_atomic_helper_wait_for_vblanks.part.28+0x274/0x290
[  279.621907] Modules linked in: hci_uart btqca btrtl btbcm 8723cs_old btintel bluetooth uvcvideo cfg80211 ecdh_generic axp20x_adc analogix_anx6345 axp20x_battery axp20x_ac_power videobuf2_vmalloc analogix_dp sunxi_cedrus(C) rfkill lima ecc sun4i_gpadc_iio gpu_sched industrialio l
[  279.622012] CPU: 1 PID: 193 Comm: kworker/1:2 Tainted: G      D WC        5.10.18-sunxi64 #trunk.1
[  279.622014] Hardware name: Pinebook (DT)
[  279.622030] Workqueue: events splash_callback_animation
[  279.622039] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--)
[  279.622044] pc : drm_atomic_helper_wait_for_vblanks.part.28+0x274/0x290
[  279.622050] lr : drm_atomic_helper_wait_for_vblanks.part.28+0x274/0x290
[  279.622052] sp : ffff800012a03910
[  279.622056] x29: ffff800012a03910 x28: 0000000000000000 
[  279.622062] x27: 000000000000042c x26: ffff000044646000 
[  279.622068] x25: 0000000000000000 x24: 0000000000000001 
[  279.622074] x23: 0000000000000038 x22: 0000000000000001 
[  279.622080] x21: ffff000042396700 x20: ffff0000421f8080 
[  279.622085] x19: 0000000000000000 x18: ffff8000114d17d0 
[  279.622091] x17: 0000000000000014 x16: 0000000000000002 
[  279.622097] x15: ffff8000114d1810 x14: 0000000000002548 
[  279.622102] x13: 0000000000002580 x12: ffff000075b71a20 
[  279.622107] x11: 0000000000000002 x10: ffff000075b66320 
[  279.622113] x9 : ffff000075b6dac0 x8 : 206b6e616c627620 
[  279.622119] x7 : 5d302d637472633a x6 : 0000000000000001 
[  279.622125] x5 : ffff000075b93810 x4 : 0000000000000000 
[  279.622130] x3 : 0000000000000027 x2 : 0000000000000023 
[  279.622136] x1 : 5280998379074000 x0 : 0000000000000000 
[  279.622143] Call trace:
[  279.622150]  drm_atomic_helper_wait_for_vblanks.part.28+0x274/0x290
[  279.622156]  drm_atomic_helper_commit_tail_rpm+0x64/0x80
[  279.622160]  commit_tail+0xa4/0x1a0
[  279.622165]  drm_atomic_helper_commit+0x160/0x408
[  279.622172]  drm_atomic_commit+0x4c/0x60
[  279.622181]  drm_client_modeset_commit_atomic.isra.17+0x1d8/0x270
[  279.622187]  drm_client_modeset_commit_locked+0x60/0x1a0
[  279.622195]  drm_fb_helper_pan_display+0xb8/0x1d8
[  279.622202]  fb_pan_display+0x8c/0x100
[  279.622207]  dummy_update_start+0x20/0x48
[  279.622213]  fbcon_switch+0x368/0x568
[  279.622219]  redraw_screen+0x144/0x270
[  279.622225]  splash_callback_redraw_vc.part.4+0x34/0x48
[  279.622230]  splash_callback_animation+0x4c/0x60
[  279.622237]  process_one_work+0x1f0/0x3c0
[  279.622241]  worker_thread+0x270/0x520
[  279.622247]  kthread+0x120/0x128
[  279.622253]  ret_from_fork+0x10/0x30
[  279.622258] ---[ end trace d29e482d74631eef ]---

 

So while i`m not familiar with the the details of the display init i assume this is not the display but the gpu / drm driver crashing.

Any advice where to go from here to help with fixing the issue would be very appreciated.

Link to comment
Share on other sites

On 3/9/2021 at 1:35 PM, derpeter said:

So while i`m not familiar with the the details of the display init i assume this is not the display but the gpu / drm driver crashing.

I've tried for months to clarify the reason of such issue ...

My last working kernel was 5.7.6, and the issue appeared as soon as 5.8.0, I've done "diff" between both branches and I still didn't figured out the glitches ...

Link to comment
Share on other sites

so has this patch been incorporated into any of the most recent builds??  https://github.com/armbian/build/commit/d49be78b702d7779f78d2655126a56e7f2ea7426

I just downloaded (7/10/21) Armbian_21.05.1_Pinebook-a64_focal_current_5.10.34_xfce_desktop.img.xz

and it has the same issue so I am guessing no?

In which case if I build it myself it should be incorporated?  i.e. the build is based on latest source?

Link to comment
Share on other sites

7 hours ago, dkebler said:

In which case if I build it myself it should be incorporated?  i.e. the build is based on latest source?

Compare the sources from 2021.05 tag linked above with master to check if the patch is present. If so it is included in a build.

Link to comment
Share on other sites

Looking at master branch for that tag  that would be no as there is no

patch/kernel/sunxi-dev folder in the master for that tag

https://github.com/armbian/build/tree/v2021.05/patch/kernel

 

so does this patch have to be moved into the sunxi-current to be included in the release (or manual) builds from master branch?

 

So if I want build to inlcude this which branch/tag should I use?  It's not clear to me.  Or...when might this patch eventaully make it into the master branch latest tag?

 

I've never built a kernel or complete image for armbian so I'm kinda stabbing in the dark when it comes to repo structure and where commits get put and when and why.  Any tips welcome.

 

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines