Jump to content

NanoPi K1 Plus + Armbian


viy

Recommended Posts

16 minutes ago, cmcgaha said:

Any desktop OS available for K1?

 

K1 is in a build system (parameter EXPERT=yes) for some time. Get it, build and check if and how the desktop works. Official images are late simply because we struggle to secure time/resources, sometimes also a reason, to make and support them.

Link to comment
Share on other sites

1 hour ago, cmcgaha said:

Hi Igor, Thank you very much. I was going to try to do the build like you suggested, will still try. I will try your OS now. I appreciate your help. 


I just discover one strange issue regarding video driver. My primary test monitor is 1280x1024 ... where desktop works fine, while 1080p or 4K desktop doesn't come up, text mode only. @jernej Is this a known problem?

Link to comment
Share on other sites

Good. I am having this problem now.  I was trying to troubleshoot, but no luck so far. I am using a 1080p touchscreen display and startx just flashes three times then back to command line. Thank you.

Link to comment
Share on other sites

46 minutes ago, Igor said:

I just discover one strange issue regarding video driver. My primary test monitor is 1280x1024 ... where desktop works fine, while 1080p or 4K desktop doesn't come up, text mode only. @jernej Is this a known problem? 

 

I just tested 1080p on my development linux branch which consist of linux-next at next-20180515 tag and R40 HDMI patches and it works fine (startx gives normal xfce desktop). However, rootfs is pretty old (year or so old Armbian), so it might not be representative.

 

I don't have 4K screen...

 

Coincidentaly, I just received a notification 5 minutes back, that WIP A64 HDMI patches breaks HDMI on H3. Please note that those patches miss some important things and please don't consider them if you don't want complaints from users (it works in some cases). I know what needs to be fixed, but since Jagan started on that, I will just provide reviews.

Link to comment
Share on other sites

1 hour ago, jernej said:

I just tested 1080p on my development linux branch which consist of linux-next at next-20180515 tag and R40 HDMI patches and it works fine (startx gives normal xfce desktop). However, rootfs is pretty old (year or so old Armbian), so it might not be representative.

 
I made few tests but could not narrow down to anything useful. H3 or H5 ... it works on our glued 4.14.y ... and it doesn't work on 4.17.y or v4.18-rc1 ... I tried on some older rootfs and with older u-boot. The same. Tomorrow is another day  :) 

 

We wait for 4.18.y ... anything before that is for testing and preparing patches.

Link to comment
Share on other sites

2 hours ago, Igor said:


apt-get install what_ever ... is not much of a problem of Armbian but Remmina.

agree, but not nice
after I found, downloaded and installed - libssh-4
reminna instaled and running normal ...

but where did the armbianmonitor go ?

 

Link to comment
Share on other sites

I downloaded the nightly build Igor made on 06/22 and can not get desktop to work.

Did like Viy said:

1) Burn to uSD

2) Boot uSD

3) armbian-config to install to eMMC

4) reboot (booting from eMMC)

5) armbian-config to enable desktop 

6) Nothing

I tried both lightDM and nodm. Neither worked. LightDM causes screen to go to black with no return. nodm causes screen to flash a few times and return to command prompt.

 

I tried on a 1920X1080 FHD HDMI display.

I tried on a 1600X1200 HDMI -> VGA display

 

same results: not working.

 

I know the display works. I can use a Rock64, OrangePi Plus 2E, Raspberry Pi, all can use display via HDMI cable.

 

If I run startx at command line I get: MESA-LOADER: failed to load device (see full log below)

 

X.Org X Server 1.19.2
Release Date: 2017-03-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-4-arm64 aarch64 Debian
Current Operating System: Linux nanopik1plus 4.17.2-sunxi64 #21 SMP Thu Jun 21 14:39:44 UTC 2018 aarch64
Kernel command line: root=UUID=467fb03c-c302-4b62-8891-84ef761afc8f rootwait rootfstype=ext4 console=tty1 console=ttyS0,115200 panic=10 consoleblank=0 loglevel=1 ubootpart= usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=memory swapaccount=1
Build Date: 16 October 2017  08:11:43AM
xorg-server 2:1.19.2-1+deb9u2 (https://www.debian.org/support) 
Current version of pixman: 0.34.0
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/nmi/.local/share/xorg/Xorg.0.log", Time: Thu Jun 21 18:27:23 2018
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
MESA-LOADER: failed to retrieve device information
gbm: failed to open any driver (search paths /usr/lib/aarch64-linux-gnu/dri:${ORIGIN}/dri:/usr/lib/dri)
gbm: Last dlopen error: /usr/lib/dri/sun4i-drm_dri.so: cannot open shared object file: No such file or directory
failed to load driver: sun4i-drm
EGL_MESA_drm_image required.
(EE) 
Fatal server error:
(EE) AddScreen/ScreenInit failed for driver 0
(EE) 
(EE) 
Please consult the The X.Org Foundation support 
     at http://wiki.x.org
 for help. 
(EE) Please also check the log file at "/home/nmi/.local/share/xorg/Xorg.0.log" for additional information.
(EE) 
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error
 

 

 

Link to comment
Share on other sites

Hi Viy,

Thanks for the suggestion, but that didn't work, or I did something wrong. Below are my steps. I appreciate your help.

 

1) Burn Armbian_5.46.180622_Nanopik1plus_Debian_stretch_dev_4.17.2_desktop.img to uSD card
2) Power on K1
3) Login as root, create new user
4) command line shows: "Now starting desktop environment..."
5) screen blinks 5 times
6) still at command line
7) connect to wifi (internet)
8) armbian-config
9) System -> Firmware -> Update board firmware <OK> ... Firmware Updated <Reboot>
10) Reboots to command line. Login as root
11) armbian-config -> Software -> Full
12) Esc
13) System -> Desktop -> Enable -> Lightdm
14) Software installs. Screen goes blank

Link to comment
Share on other sites

Just now, cmcgaha said:

Software installs. Screen goes blank


This is apparently a bug. I am preparing 4.14.y kernel which is not affected by this problem.

Link to comment
Share on other sites

1 hour ago, jernej said:

What is CMA size? I would suggest 128 MB for test.


Yes! That was the problem. Thanks for the hint.

 

Solution for current images is adding

extraboardargs=cma=128M 

to /boot/armbianEnv.txt.

Link to comment
Share on other sites

26 minutes ago, Igor said:

Solution for current images is adding


extraboardargs=cma=128M 

to /boot/armbianEnv.txt.

 

I would suggest more permanent solution in kernel config for nightlies - CONFIG_CMA_SIZE_MBYTES=128

 

While CMA allocated memory can be used for other things when unused, not everything can be put there. This means that in extreme cases you can run out of memory with seemingly enough unused memory (which belongs to CMA). 128 MB can be considered as safe value, especially when VPU driver will be ready. However, for boards with 512 MB RAM or even less this can be a bit too much. 1080p image needs ~8 MB of memory for single image and 4K ~32 MB. I'm not sure if X11 or desktop use double or even triple buffering. If they do, just multiply by 2 or even 3. As you can see, 4K takes a lot of memory.

Link to comment
Share on other sites

1 hour ago, jernej said:

I would suggest more permanent solution in kernel config for nightlies - CONFIG_CMA_SIZE_MBYTES=128


https://github.com/armbian/build/commit/731b5672780d813ac5e2cc34d5a3aa5195a92d23

I added there as well. We already have it in 32bit configuration for some time, but it was forgotten here.

 

Then perhaps we can enforce this kind of logic: if BUILD_DESKTOP="no" add cma=16 ... else #cma=16 # enable if you run this headless to release 104Mb of memory reserved for graphics operations?

Link to comment
Share on other sites

2 minutes ago, Igor said:

Then perhaps we can enforce this kind of logic: if BUILD_DESKTOP="no" add cma=16 ... else #cma=16 # enable if you run this headless to release 104Mb of memory reserved for graphics operations?

That would work, I think.

 

What about cases when someone later "upgrades" headless version to desktop?

Link to comment
Share on other sites

11 minutes ago, Igor said:

We already have it in 32bit configuration for some time, but it was forgotten here.

Uh, does that mean that there is different issue on H3? You said it doesn't work on BPi M2+ and that you have CMA set to 128...

Link to comment
Share on other sites

4 minutes ago, jernej said:

Uh, does that mean that there is different issue on H3? You said it doesn't work on BPi M2+ and that you have CMA set to 128...


No, I mixed this a bit. DEV = 4.17, CMA=16 while NEXT = 4.14, CMA=128 ... so only our DEV configs (also 32bit I see now) was broken here.

 

13 minutes ago, jernej said:

What about cases when someone later "upgrades" headless version to desktop?

 

I can control this if they upgrade with our tool, our desktop ... while for others is a bit more tricky.

Link to comment
Share on other sites

38 minutes ago, jernej said:

What about cases when someone later "upgrades" headless version to desktop?


How to determine the value of CMA from userspace?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines