Hikey960 Screen Problem



I build OPTEE + Android with https://github.com/linaro-swg/optee_android_manifest . I flash them successfully. But, when hikey960 device runs, screen is not displayed.
screen is 800x480 pixel 7inch touchable screen.

What do you think about problem?


If the screen is powered by USB, try powering it from the WALL and not from the hikey itself. USB power is software controlled, and turns on too late.


Yes it is powered by USB. But, screen is working and white. Is it another problem about driver?
@doitright I tried to take power from the wall. But, there is no display.


Do other displays work on the hikey?
Does that display work on other computers?
Do you have a link to the manufacturer’s website of that display?



Yes. Raspberry Pi etc.

Yes. https://www.waveshare.com/wiki/7inch_HDMI_LCD_(B)


Hmm. I was hoping that you would have a more common display instead of complete unknown.

The only helpful piece of information I was able to find on that display is that in the “user manual” (which is better described as an unintelligible broken english marketing pamphlet), it suggests manually setting the display mode. This suggests that the EDID may be non existent or broken, and that the display probably does NOT have a scaler in it.

KEEP the monitor plugged in via external power (the manual suggests a 3A power supply, which greatly exceeds what you should power by the hikey).

Try setting the video mode manually. This is done by appending something like this to the kernel commandline;


You can also try other rates, like @70, 75, 80, 85

— Note: it is possible that this display cannot be made to work with hikey960. I’ve never tried a display with that low of a resolution (lowest I’ve ever tried is 1024x600). The monitor may also not be willing to accept the timing output by the hikey, which is not HDMI compliant.


It is not working. I tried that you said


Some common diagnostic techniques are:

  • Look about in /sys/class/drm/ . There should be a directory for the HDMI connector and in that are properties such as “enabled” (if false you’ve probably found the problem) and “modes” (available video modes, etc) that can help.
  • Add “drm.debug=0xff” to the kernel command line. This should cause all the mode setting (and all other bits of drm) to issue log messages letting you know what the board is trying to output.

PS This is not specifically a reply to @doitright… I’m just a bit tired and pressed the “wrong” reply button.


Hello @danielt,

/sys/class/drm/ is like this:

# ls /sys/class/drm
   card0 card0-HDMI-A-1 renderD128 version
# cd card0-HDMI-A-1 && ls
   device dpms edid enabled modes power status subsystem uevent
# cat enabled

But, android is not displayed.


I also tried 1024x600 resolution. Android GUI is not displayed.
Screen : https://www.waveshare.com/wiki/10.1inch_HDMI_LCD_(H)_(with_case)

EDIT : I think, there is a problem about screen resolution or driver in hikey960. Because, my hikey620 board is working these screens and hikey960 worked with my 800x480 screen in Android 8

Hikey620 : Linux localhost 4.9.81-04720-gdc25463 #8 SMP PREEMPT Fri Nov 30 16:10:48 +03 2018 aarch64


Did you learn anything from modes or drm.debug=0xff?

Are you only running hikey960 with the optee_android_manifest stuff or did you try the proper version as well (preferable a known good version: https://github.com/96boards/aosp-known-good-manifests )?


Unfortunately, nothing.

hikey960 with optee_android_manifest


Sounds like your display is too sensitive to timing and doesn’t like the hikey. Use a different brand of display. And when you’re buying cheap import parts, it’s best to stick with parts that are extremely common – more likely that others have tested it. There are a million small LCDs on ebay with very common display controllers identifiable as PCB800xxx, which work great with hikey.


Buying a new LCD is not a solution. I work to learn why my screens dont work with hikey960. Because, hikey960 works with these screens in previous android versions. It can be changed at new version or there is a problem. I’m learning. too sensitive screen and try another are easy solution.


Don’t like to grumble but why wasn’t that information in the first post?

Can you see any difference in the drm.debug=0xff output between working and broken builds? (I usually fire them up in a side by side differencer such as meld).


Too sensitive of an HDMI controller isn’t an “easy solution”. Most display problems ARE caused by that, because to make it perfectly clear, hikey960 is not capable of generating HDMI compliant clock signals.

HDMI wants 60 Hz.
Hikey960 makes 58 Hz.

And like @danielt said, it would have saved a lot of time for you to have mentioned the fact that those monitors did previously work on the hikey960, because then we would know to focus your attention on the things that CHANGED, rather than going through every possibility.


Sorry for this. thanks for your new suggestion for solving problem.

I said that nothing. But, after re-controlling,
I learn this from modes:
# cat modes

logs about drm : https://paste.ubuntu.com/p/Ft9HSYkBz9/


That shows the driver continually trying to adopt 800x480@66 and discarding it as unsupported (‘BAD’) but I can’t see any EDID activity. It looks like you have grepped out part of the logs? If so, it is generally better to post unabridged logs (they contain version information and all sorts of good stuff).

Obviously the other question is what do the logs look like in the working case?


I took logs with this command : hikey960:/ # dmesg | grep -i drm


Don’t do that… no point in hiding diagnostic information from us.

In particular I can’t see what kernel version you are running… but if your build is based on v4.14 then you probably need some variant of this patch from v4.9: