Jump to content

Nanopi Neo4 - no output to HDMI Monitor


JohnG

Recommended Posts

Armbianmonitor:

Hello,

 

I am working with "Armbian_21.08.1_Nanopineo4_focal_current_5.10.60" on a nanopi Neo4.

 

During the initial boot, the (HDMI) monitor shortly displayed some text (went to fast to

read) and then went blank and the monitor turned off. However, output came through

the serial debug port (USB2) and I was able to complete the initial setup. Now, I can now

connect with SSH, but it would be nice to be able to work directly.

How can I redirect the output to the HDMI monitor?

 

Cheers,

John

 

Link to comment
Share on other sites

Hello,

 

Hmm, some views, but no responses. Maybe this is not the right place for this question?

Is anybody else running Armbian_21.08.1_Nanopineo4_focal_current_5.10.60 on a nanopi NEO4

board successfully with the HDMI output working? Maybe I am missing something really simple

here.

 

The output to the HDMI monitor works for the initial boot "DDR Version 1.24 20191016 and

also for u-boot "U-Boot 2020.10-armbian (Aug 08 2021 - 15:20:44 +0200)". The HDMI monitor

switches off after the line "Starting kernel ...", so I am assuming this is an ubuntu topic and

this is not the right place for such questions. I have been looking for information

about how the HDMI works on ubuntu, but while I have some notions about ubuntu/linux world,

I consider myself a newbie and the HDMI topic on ubuntu seems to be a really big thing.

Any suggestions or pointer in what direction or where I could look?

 

Any help on this one is much appreciated.

 

Greetings,

John

Link to comment
Share on other sites

Not owning the board my self I can't say for sure, but I do have a RK3399 from the same vendor and HDMI is fine and I'm also running Ubuntu. In my experience it has very little to do with the distro you are running and more to do with the kernel. If you are seeing an output during the initial boot process, but not when it gets handed off to the kernel, than that would suggest to me its kernel related. Maybe something isn't ticked on in the defconfig of that build?

 

Have you tried a different kernel? Do you see anything of substance in dmesg or lsmod? dmesg | grep hdmi; lsmod | grep hdmi

 

Edit: Have you tried a different monitor? Maybe it doesn't like the default resolution of the current display you are using? Most monitors have a auto detect button or option, have you tried pressing it?

 

Link to comment
Share on other sites

Hello Cornelius,

 

Thank you for your fast response. It is good to know that the image is working with HDMI on your similiar board. May I ask which one you have?

 

Yes, I have tried the different images supplied by FriendlyElec which run well and stable and the HDMI screen works fine. The power supply is stable and delivers

3A @ 5 V and I am using a San Disk ultra card, which should have acceptable quality. So, I would think that the hardware is okay, but as Igor has pointed out in other posts, that is no guarantee. The monitor is from fujitsu and has an auto button on the front which I have never used to date. As you suggested I tried pressing to see if it would help and at different points during the kernel boot and after the system is running, but without success. What is the best time to press the button?

 

I have looked at dmesg before, but feel quite overwhelmed with the wealth of information and am not sure where to look. As you suggested, here is the output from dmesg | grep hdmi:

root@nanopineo4:~# dmesg | grep hdmi
[    4.529641] dwhdmi-rockchip ff940000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY)
[    4.532350] rockchip-drm display-subsystem: bound ff940000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm])
[    9.140887] rc rc0: dw_hdmi as /devices/platform/ff940000.hdmi/rc/rc0
[    9.141029] input: dw_hdmi as /devices/platform/ff940000.hdmi/rc/rc0/input5

and for lsmod | grep hdmi:

root@nanopineo4:~# lsmod | grep hdmi
snd_soc_hdmi_codec     20480  1
dw_hdmi_i2s_audio      16384  0
dw_hdmi_cec            16384  0
snd_soc_core          237568  6 snd_soc_rt5651,snd_soc_hdmi_codec,snd_soc_rockchip_spdif,snd_soc_simple_card_utils,snd_soc_rockchip_i2s,snd_soc_simple_card
snd_pcm               118784  4 snd_soc_rt5651,snd_soc_hdmi_codec,snd_soc_core,snd_pcm_dmaengine
snd                    90112  6 snd_soc_hdmi_codec,snd_timer,snd_soc_core,snd_pcm
dw_hdmi                53248  2 dw_hdmi_i2s_audio,rockchipdrm
drm_kms_helper        245760  4 dw_mipi_dsi,rockchipdrm,dw_hdmi,analogix_dp
cec                    73728  3 drm_kms_helper,dw_hdmi_cec,dw_hdmi
drm                   573440  11 gpu_sched,drm_kms_helper,dw_mipi_dsi,rockchipdrm,dw_hdmi,panfrost,analogix_dp

 

From the lsmod, I saw the drm service is tunning. As I understand it, this service has something to do with directing the output stream to the desired output device (is that right?). When looking at the whole output for dmesg, I found the line suggesting that the loading of the drm module was being skipped:

[    7.186297] systemd[1]: Condition check resulted in Load Kernel Module drm being skipped.

and yet the service seems to be running. Could this have something to do with my issue?

 

What do you mean with defconfig of the build? Where can I look at this?

 

Sorry, for all the questions. I like to learn and as I once hear, "No question. No answer." :-)

 

Cheers,

John

 

 

Link to comment
Share on other sites

The defconfig is what was used during kernel compilation. Beyond that its not gonna do you much good unless you know exactly what you are looking for. You can find it under /boot/config-*.

 

As for the board I'm running, its the NanoPC-T4.

 

dmesg | grep model; dmesg | grep hdmi; lsmod | grep hdmi
[    0.000000] Machine model: FriendlyElec NanoPC-T4
[    0.107313] platform ff940000.hdmi: Fixing up cyclic dependency with ff8f0000.vop
[    0.107394] platform ff940000.hdmi: Fixing up cyclic dependency with ff900000.vop
[    3.196953] dwhdmi-rockchip ff940000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY)
[    3.197886] rockchip-drm display-subsystem: bound ff940000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm])
[    5.948920] rc rc0: dw_hdmi as /devices/platform/ff940000.hdmi/rc/rc0
[    5.948995] input: dw_hdmi as /devices/platform/ff940000.hdmi/rc/rc0/input12
snd_soc_hdmi_codec     24576  1
snd_soc_core          262144  5 snd_soc_rockchip_pcm,snd_soc_hdmi_codec,snd_soc_simple_card_utils,snd_soc_rockchip_i2s,snd_soc_simple_card
snd_pcm               126976  3 snd_soc_hdmi_codec,snd_soc_core,snd_pcm_dmaengine
dw_hdmi_cec            16384  0
snd                    94208  4 snd_soc_hdmi_codec,snd_timer,snd_soc_core,snd_pcm
dw_hdmi_i2s_audio      16384  0
dw_hdmi                53248  2 dw_hdmi_i2s_audio,rockchipdrm
drm_kms_helper        278528  4 dw_mipi_dsi,rockchipdrm,dw_hdmi,analogix_dp
cec                    57344  3 drm_kms_helper,dw_hdmi_cec,dw_hdmi
drm                   552960  8 gpu_sched,drm_kms_helper,dw_mipi_dsi,rockchipdrm,dw_hdmi,panfrost,analogix_dp

I'm not seeing a lot of difference here beyond me not getting that drm being skipped bit.

 

You should be able to change kernels using armbian-config "last time I checked?", its possible that a downgrade or upgrade may solve your problem. If you have a spare monitor or even a TV with an HDMI port, it might be a good idea to give that a shot.  

Link to comment
Share on other sites

Hello Cornelius,

 

yes, building a kernel is out of the question, but thank you for the pointer to /boot/config-*. I may not understand it, yet I will take a look and can learn some. So, this is interesting for me.

 

The output from your machine helps a lot for comparing. Thanks for that. I do not see much difference either. The part I found about skipping the drm was in the full dmesg output without any filter. Funny enough, if I use grep to filter for drm, then this line does not show up. I don't know why.

 

I will also look into the pointer about changing the kernel. I have never done that before, so new adventure :-)

 

Thanks again for your time and help.

 

Cheers,

John

Link to comment
Share on other sites

I run my NanoPC-T4 as a fully flagged desktop with all the bells and whistles. I have uploaded my dmesg so you have a reference what messages to expect. More components, not called HDMI, are required for display support.

27 minutes ago, JohnG said:

The part I found about skipping the drm

This is user space that tries to load kernel modules and expected when the modules are built in or already loaded by the kernel.

dmesg

Link to comment
Share on other sites

Hello Usual User,

 

Thank you for your comments and your full output from dmesg. I will need some time to work through thus and it helps a lot!

 

What build are you using?

I ask, because your dmesg starts with

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.14.0-60.fc34.aarch64 (root@trial-01) (gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1), GNU ld version 2.35.2-5.fc34) #1 SMP Mon Aug 30 18:20:33 CEST 2021

 

while the the image I am running is Armbian_21.08.1_Nanopineo4_focal_current_5.10.60 which starts like this:

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.10.63-rockchip64 (root@runner4) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021

 

It seems that the tool chains for the build are different. Did you compile and link the build yourself?

 

Greetings,

John

 

Link to comment
Share on other sites

41 minutes ago, usual user said:

I run my NanoPC-T4 as a fully flagged desktop with all the bells and whistles. I have uploaded my dmesg so you have a reference what messages to expect. More components, not called HDMI, are required for display support.

This is user space that tries to load kernel modules and expected when the modules are built in or already loaded by the kernel.

dmesg 51.33 kB · 2 downloads

The kernel and build I use is custom, so I found it to be a pointless venture to bother trying to post it. He is currently on 5.10.y and we are both on 5.14.y "mine being 5.14.9", which is kind of a different beast from the current LTS. Also it isn't Armbian related, so to me it would make more sense to check the other kernel options he has available to him self, than to just throw out random full dmesg's that will most likely not be the same.

 

But that's just my opinion. 

Link to comment
Share on other sites

I am running at an entire different user space. But this doesn' t matter. Also the exact kernel version doesn' t matter. The only thing that is really important is that the elements that are needed by the hardware are also built. dmesg tells you which components are used. Looking at kernel config does only tell wich modules are build, but not if they are realy used. E.g. my kernel is built with a large number of modules. With the help of initramfs it is suitable for all devices with aarch64 architecture. When the kernel is booting it will either probe the hardware or know via devicetree wich modules are required. The customizieing I am aplying is to pull display support and everything to mount the rootfs as build-in. This way I have early display support and I can run without initramfs. Everything else will be loaded later as module.
In order to learn which components are needed, it is very helpful to have a dmesg from a running system.

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