A20-OLinuXino-MICRO 15.6HF LCD fails after upgrade to universal image

Started by davidlop, February 14, 2022, 03:17:04 PM

Previous topic - Next topic

davidlop

Recently I upgraded an old appliance (that was running some 3.4 kernel) to newer, mainline universal image. After perfect boot and log-in into it using ssh (not using root/olimex as it is not allowed, but olimex/olimex user -could be a nice point to note in documentation-), everything seems ok, but LCD isn't displaying anything at all.
I've seen some tricks with "white screen" on a smaller 4.3 touch display , also the LCD turn off entry, but trying the power-on sequence proposed does not solve anything (actually, it disables the backlight, that was working ok, and needs a reboot to light up again).
I tried to find on the device tree some display configuration, to no success. The only point I saw that doesn't look good, is pixel clock: if it is really what it should be (pixel clock in Hz), /proc/device-tree/panel/panel-timing/clock-frequency says it is at 152.00MHz (instead of the required value of about 76MHz that panel specifications state). May it be that this display has an incorrect configuration, on the new images, or am I missing some other point?
Just in case, on boot kernel says:
[   11.142253] sun4i-drm display-engine: bound 1e00000.display-frontend (ops 0xc0b69808)
[   11.142442] sun4i-drm display-engine: bound 1e20000.display-frontend (ops 0xc0b69808)
[   11.143023] sun4i-drm display-engine: bound 1e60000.display-backend (ops 0xc0b68fa8)
[   11.143056] sun4i-drm display-engine: attempt to add DMA range to existing map
[   11.151073] sun4i-drm display-engine: bound 1e40000.display-backend (ops 0xc0b68fa8)
[   11.152222] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xc0b67908)
[   11.153251] sun4i-drm display-engine: [b]No panel or bridge found... RGB output disabled[/b]
[   11.153292] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xc0b67908)
...but I can't tell if that's normal (provided the A20 has two Display Engine units, and one has no panel for sure)

Any clue will be appreciated... this is on a short appliances series (20 units), with quite old hardware (both display and A20 board are from about 2015), but I can't tell what display revision is, because everything is mounted on the enclosure and access is not at hand currently.

Thanks in advance ;D


LubOlimex

Yes, root can't be used over SSH for security reasons. My advice is to change your passwords after first login.

Did you try running our display setup script first? The scripts related to displays are olinuxino-display and maybe olinuxino-overlay (if some of the pins used in olinuxino-display are disabled).

Make sure you are using latest image from here:

http://images.olimex.com/release/a20/

More info can be found in this document:

https://github.com/OLIMEX/OLINUXINO/blob/master/DOCUMENTS/OLIMAGE/Olimage-guide.pdf

The scripts sources can be found online at the following links:

https://github.com/OLIMEX/u-boot-olinuxino/blob/release-20211130/board/olimex/common/lcd_olinuxino.c

https://github.com/OLIMEX/olinuxino-overlays/blob/master/scripts/olinuxino-display
Technical support and documentation manager at Olimex

davidlop

Thank you for your quick response, Lub.

I understand root is better not allowed on ssh, that's what I always set up on any new system; telling on the latest doc that olimex/olimex do work would save some research time  ;)

From the start I followed doc (as far as I could: with no serial console), and yes, I used the display utility to select display; and image was the very last available yesterday. After selecting appropiate display, backlight worked fine, and display parameters were available on /proc/device-tree/panel/panel-timing/ (and all seemed right to me, except the pixel clock, and absolutely blank LCD).

After a few hours and some head-scratching, I finally managed to connect a serial console, to try the u-boot configuration. In this case, while booting, display works for a second or two, I could see about four text lines, just before it went off (I guess that was when linux kernel started to boot, that probably set the out-of-range-by-2x pixel clock?).

I can't find where you set-up the display mode, maybe finding values set there could help me to figure out what's happening ;D

Thx!