Odroid XU4 | Cloudshell 2 not working after Upgrade

For the record: No Boot (Solved) - ODROID
We however do this correct in our boot.ini already, and the device tree overlay(s) exist.

If it remains black, can you check whether the fb_hktft32 kernel driver was loaded?

lsmod fb_hktft32

And does the backlight sysfs entry exist?

ls /sys/class/backlight/

I need to sleep now, but will also check tomorrow.

No screen this morning.
By the way I am patched to v9.3.0

Here is the results of your requests.
root@DietXU4:~# lsmod fb_hktft32
Usage: lsmod
root@DietXU4:~# ls /sys/class/backlight
root@DietXU4:~#

Not working, not even the fan is on. Might have to shutdown for heat.

Interesting, I just tested it here, and works perfectly fine:

root@OdroidXU4:~# grep 'setenv cs2enable' /boot/boot.ini
setenv cs2enable "true"
root@OdroidXU4:~# uname -a
Linux OdroidXU4 6.1.79-current-odroidxu4 #3 SMP PREEMPT Thu Feb  8 13:10:24 UTC 2024 armv7l GNU/Linux
root@OdroidXU4:~# lsmod | grep fb
fb_hktft32             16384  1
fbtft                  36864  1 fb_hktft32
root@OdroidXU4:~# l /sys/class/backlight/fb_hktft32/
total 0
-r--r--r-- 1 root root 4.0K May  9 23:40 actual_brightness
-rw-r--r-- 1 root root 4.0K May  9 23:40 bl_power
-rw-r--r-- 1 root root 4.0K May  9 23:40 brightness
lrwxrwxrwx 1 root root    0 May  9 23:40 device -> ../../../spi0.0
-r--r--r-- 1 root root 4.0K May  9 23:29 max_brightness
drwxr-xr-x 2 root root    0 May  9 23:40 power
-r--r--r-- 1 root root 4.0K May  9 23:40 scale
lrwxrwxrwx 1 root root    0 May  9 23:40 subsystem -> ../../../../../../../../../class/backlight
-r--r--r-- 1 root root 4.0K May  9 23:40 type
-rw-r--r-- 1 root root 4.0K May  9 23:29 uevent
root@OdroidXU4:~# cat /sys/class/backlight/fb_hktft32/bl_power
0
root@OdroidXU4:~# echo 1 > /sys/class/backlight/fb_hktft32/bl_power
root@OdroidXU4:~# cat /sys/class/backlight/fb_hktft32/bl_power
1
2024-05-09 23:42:50 root@OdroidXU4:~# ls -l /proc/device-tree/soc/spi@12d30000/
total 0
-r--r--r-- 1 root root  4 May  9 23:40 '#address-cells'
-r--r--r-- 1 root root  4 May  9 23:40 '#size-cells'
-r--r--r-- 1 root root 16 May  9 23:40  clock-names
-r--r--r-- 1 root root 16 May  9 23:40  clocks
-r--r--r-- 1 root root 23 May  9 23:40  compatible
-r--r--r-- 1 root root 24 May  9 23:40  cs-gpios
-r--r--r-- 1 root root  6 May  9 23:40  dma-names
-r--r--r-- 1 root root 16 May  9 23:40  dmas
drwxr-xr-x 4 root root  0 May  9 23:40  hktft_cs_ogst@0
-r--r--r-- 1 root root 12 May  9 23:40  interrupts
-r--r--r-- 1 root root  4 May  9 23:40  name
-r--r--r-- 1 root root  4 May  9 23:40  num-cs
-r--r--r-- 1 root root  4 May  9 23:40  phandle
-r--r--r-- 1 root root  4 May  9 23:40  pinctrl-0
-r--r--r-- 1 root root  8 May  9 23:40  pinctrl-names
-r--r--r-- 1 root root  8 May  9 23:40  reg
-r--r--r-- 1 root root  4 May  9 23:40  samsung,spi-src-clk
-r--r--r-- 1 root root  5 May  9 23:40  status

As you can see, the bl_power attribute was off, but I could turn it on. Not sure whether this is because I have no actual CS2 attached, or whether this is a change from Linux 5.4 to 6.1. If so, we can create a udev rule to have it enabled OOTB at boot.

But in your case, the backlight device is not present at all? The lsmod command I have you was wrong, the grep pipe was missing. Can you repeat the commands I ran above? The one to check /proc/device-tree/soc/spi@12d30000/ is important to see whether the device tree has been applied. If not, it would not contain the hktft_cs_ogst@0 sub node/directory.


EDIT: Okay, with the new Linux 6.6 build it does not work anymore, only with Linux 6.1. I’ll check why.
EDIT2: Lol, simple reason: Overlays are now located in /boot/dtb/ instead of /boot/dtb/overlays/, no idea whether this is intended or not. In the source code, overlays are located in a sub dir, and the Makefile seems to even create a sub directory for the compiled overlays, but it is not present in the kernel package: ODROID-XU4: add overlay support · hardkernel/linux@bdc4c60 · GitHub

However, hence this does work for mw:

sed -i 's|dtb/overlays|dtb|g' /boot/boot.ini

Possible that this is fixed/changed, so maybe we should check in both dirs in our default boot.ini.

EDIT3: Out of interest, what is your MAC address?

ip l l eth0

Among many others, macaddr seems to have no effect anymore, and the MAC address here is still fixed. I hope it is different for every particular XU4, based on the serial number (or simlar) of the particular Ethernet adapter.

I moved to 6.6, how do I return to 6.1?
This is the info you requested:

root@DietXU4:~# grep 'setenv cs2enable' /boot/boot.ini
setenv cs2enable "true"
root@DietXU4:~# uname -a
Linux DietXU4 6.6.30-current-odroidxu4 #1 SMP PREEMPT Mon May  6 15:18:52 UTC 2024 armv7l GNU/Linux
root@DietXU4:~# lsmod | grep fb
fb_hktft32             12288  1
fbtft                  36864  1 fb_hktft32
root@DietXU4:~# l /sys/class/backlight/fb_hktft32/
-bash: l: command not found
root@DietXU4:~# cat /sys/class/backlight/fb_hktft32/bl_power
0
root@DietXU4:~# echo 1 > /sys/class/backlight/fb_hktft32/bl_power
root@DietXU4:~# cat /sys/class/backlight/fb_hktft32/bl_power
1
root@DietXU4:~# ls -l /proc/device-tree/soc/spi@12d30000/
total 0
-r--r--r-- 1 root root  4 May  9 19:37 '#address-cells'
-r--r--r-- 1 root root 16 May  9 19:37  clock-names
-r--r--r-- 1 root root 16 May  9 19:37  clocks
-r--r--r-- 1 root root 23 May  9 19:37  compatible
-r--r--r-- 1 root root 24 May  9 19:37  cs-gpios
-r--r--r-- 1 root root  6 May  9 19:37  dma-names
-r--r--r-- 1 root root 16 May  9 19:37  dmas
drwxr-xr-x 4 root root  0 May  9 19:37  hktft_cs_ogst@0
-r--r--r-- 1 root root 12 May  9 19:37  interrupts
-r--r--r-- 1 root root  4 May  9 19:37  name
-r--r--r-- 1 root root  4 May  9 19:37  num-cs
-r--r--r-- 1 root root  4 May  9 19:37  phandle
-r--r--r-- 1 root root  4 May  9 19:37  pinctrl-0
-r--r--r-- 1 root root  8 May  9 19:37  pinctrl-names
-r--r--r-- 1 root root  8 May  9 19:37  reg
-r--r--r-- 1 root root  4 May  9 19:37  samsung,spi-src-clk
-r--r--r-- 1 root root  4 May  9 19:37 '#size-cells'
-r--r--r-- 1 root root  5 May  9 19:37  status

I just ran all these commands and the screen turned on but not the fan! I am up to 50C

How can I get the fan running again?

This is the information from your edits. hope it helps:

root@DietXU4:~# sed -i 's|dtb/overlays|dtb|g' /boot/boot.ini
root@DietXU4:~# ip l l eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 00:1e:06:36:af:fc brd ff:ff:ff:ff:ff:ff

EDIT:
I went up and found schnitzelbrain fanscript.sh file that runs in cron and I started playing around with it lowering the threshold and now the fan is on. I will leave it on and adjust it again tomorrow, the temperature is down to 35 C.
Let me know how I can help!!

So far so good. Then the only problem/difference is, that /sys/class/backlight/fb_hktft32/bl_power is set to 0, i.e. disabled by default, which is weird. I’ll have a look whether this can be changed via device tree. Else we’ll just add a udev rule to turn it on at boot. I really see zero reason why one would enable the Cloudshell 2 overlay, but would not want to have the LCD turning on at boot. For you as a quick solution:

echo 'SUBSYSTEM=="backlight", KERNEL=="fb_hktft32", ACTION=="add", ATTR{bl_power}="1"' > /etc/udev/rules.d/cs2-backlight.rules

Having it tuend off during night run in our dietpi-cloudshell script, is of course another reasonable feature.

Regarding the fan: Was the threshold lower with the Linux 5.4 kernel?

Weird, here, also with Linux 5.4, the bl_power is off by default. Still, possible that this is due to the fact that I have no actual LCD attached:

root@OdroidXU4:~# cat /sys/class/backlight/fb_hktft32/bl_power
0
2024-05-11 16:23:03 root@OdroidXU4:~# uname -a
Linux OdroidXU4 5.4.275-current-odroidxu4 #1 SMP PREEMPT Tue May 7 14:32:02 UTC 2024 armv7l GNU/Linux

Just in case you want to test (remove the udev rule then), I generated a Linux 5.4 build again:

cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-{dtb,image}-current-odroidxu4.deb
dpkg -i linux-{dtb,image}-current-odroidxu4.deb
rm linux-{dtb,image}-current-odroidxu4.deb
reboot

I rechecked the overlays source linux/arch/arm/boot/dts/overlays/hktft-cs-ogst.dts at d19d2ecfb7eb8079369619a10c6c88861e915e98 · hardkernel/linux · GitHub (identical across all kernel versions) and tested some attributes which do work for other backlight devices, but did not change the fact here, that bl_power remained off here, as well with Linux 5.4: Linux Kernel Documentation :: devicetree : bindings : video : backlight : gpio-backlight.txt
Also the Odroid Cloudshell 2 related scripts do not contain any step to toggle this attribute.

Would be interesting whether this is different for you.

And yet another update: I implemented a CloudShell 2 LCD toggle into dietpi-config > Display Options > LCD/OLED Panel addon, which enables the overlay and installs the udev rule, to have the backlight powered at boot. Also dietpi-cloudshell toggles the power during on/off times: v9.4 · MichaIng/DietPi@0ab8c42 · GitHub

If you want to test:

G_DEV_BRANCH dev

Thanks, not sure if I should poke around in there any more.

root@DietXU4:~# cat /sys/class/backlight/fb_hktft32/bl_power
1
root@DietXU4:~# uname -a
Linux DietXU4 6.6.30-current-odroidxu4 #1 SMP PREEMPT Mon May 6 15:18:52 UTC 2024 armv7l GNU/Linux

It looks like it is working now.

1 Like

I ran it and nothing new.

When you stop cloudshell the screen does tun off but not the the backlight. good thing no one sleeps in this room.

When you turn it off manually, if is expected, but when you enable the “Auto screen off” time, and that time window is reached, it should turn off. This is the code which runs:

[[ $G_HW_MODEL == 11 && -f '/sys/class/backlight/fb_hktft32/bl_power' ]] && echo 0 > /sys/class/backlight/fb_hktft32/bl_power

Glad to say that it is all working now. The backlight turned off when the Auto screen Off kicked in. Fan is on and CPU is a good temperature.

Thank you!!

1 Like

By chance would any of this work for the original cloudshell lcd as well? LCD is black no matter what is enabled for dietpi-cloudshell. I created a post here.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.