My Reform showed a somewhat strange behavior in the last weeks. When I started it, the OLED display showed everything as usual, but the reforms main screen wouldn’t start/light up. Like if there where no SD-Card inserted. It would take several attempts of starting my Reform until the screen finally would light up (Sometimes up to 10 or more attempts, sometimes 1 or 2). I was thinking maybe a mechanical failure of the SD-Card Slot, so I also tried to reinsert the SD-Card but I couldn’t see a difference in the behaviour.
I did apt upgrade and apt autoremove yesterday, but the problem was still the same, I even didn’t manage to start my Reform properly at all for one day.
Today I it fully charged. Again it needed several attempts. Then I didn’t turn it off the whole day and kept the power plugged in. Now as I’m writing this post I did several Shutdowns and Startups, and everything worked fine.
I’m still a newbie to Linux and Reform and I’m looking for a way to debug this issue. Can anyone help me how I should best proceed?
Hi, a mechanical failure of the SD-Card slot is possible. I had my Reform running fine but inserting an SD-Card would result in just being this printed in dmesg:
mmc0: error -110 whilst initialising SD card
In my case, the problem was probably material fatigue. I was able to restore the original functionality by slightly bending the metal pins through the rectangular hole of the SD-card slot. See this conversation for the full story: 2024-12-04.log
Your problem could of course be a very different one. To find out what’s going on, I would try looking at the serial output of your Reform from another computer. That is you would connect a USB UART adapter to one computer, then connect the RX, TX and GND cables of the adapter to S2 of the Reform (make sure to cross RX and TX) and then start a serial terminal emulator on the computer into which you plugged in the USB UART adapter. This is the part of the Reform handbook that talks about this: Advanced Topics — MNT Reform Operator Handbook, 2nd Edition documentation Once you can see what the Reform does in early boot even without the screen, you might be able to figure out what is going on.
If it is indeed a problem reading from the SD-Card, it could also be that the card itself is failing.
That’s what happened to the card I got with the Reform. Last time I tried to boot from it, it had troubles starting, and I also suspected the SD Card slot being at fault - until I tried to read the SD card on a different computer and had problems there too…
Thank you, that is some good advice and I try to follow it. First I’ll get a USB UART Adapter and I’ll let you know what shows up when I am ready to set it up.
I ran dmesg but the SD Card seems to work just fine.
Meanwhile I looked at my sway config file and found this section
I wondered if that could have caused some problems with the screen brightness at startup? Could that be as well? I left it out now to see if it changes something.
My reform does not keep the brightness value across restarts, so I doubt that’s the cause.
I’d really suggest to plug a serial cable to S2 and read the debug output on a second computer. That’s likely going to be the quickest way to get an idea of what is going on.
I am using this cable, by the way, but there are probably cheaper options available. Just make sure to get one of the correct voltage (3.3V).
Sorry for the delay, I was quite busy. After apt upgrade the issue appeared only once and after one try everything worked properly. No I’m using my Reform nearly daily without any problems.
I managed to get the UART Adapter up and running, but so far I have only an output of booting without any troubles. I hope I can manage an output showing the issue in the future. Meanwhile I got two Errors though and I am a bit lost whether they have any relevance:
no sdio debug board detected
L0:00000000
L1:20000703
L2:00008067
L3:14000000
B2:00402000
B1:e0f83180
TE: 360434
BL2 Built : 19:23:21, Sep 18 2020. g12b g9fde858 - gongwei.chen@droid11-sz
Board ID = 12
Set A53 clk to 24M
Set A73 clk to 24M
Set clk81 to 24M
A53 clk: 1200 MHz
A73 clk: 1200 MHz
CLK81: 166.6M
smccc: 0005c92d
board id: 12
Load FIP HDR DDR from SD, src: 0x00010200, des: 0xfffd0000, size: 0x00004000, part: 0
Get wrong ddr fw magic! Error!!
and the second one being:
100bdlr_step_size ps== 420
result report
boot times 0Enable ddr reg access
Load FIP HDR from SD, src: 0x00010200, des: 0x01700000, size: 0x00004000, part: 0
Load BL3X from SD, src: 0x00078200, des: 0x01768000, size: 0x00109400, part: 0
0.0;M3 CHK:0;cm4_sp_mode 0
MVN_1=0x00000000
MVN_2=0x00000000
[Image: g12b_v1.1.3390-6ac5299 2019-09-26 14:10:05 luan.yuan@droid15-sz]
OPS=0x10
ring efuse init
chipver efuse init
29 0b 10 00 01 17 25 00 00 06 37 32 34 54 31 50
[0.018961 Inits done]
secure task start!
high task start!
low task start!
run into bl31
NOTICE: BL31: v1.3(release):4fc40b1
NOTICE: BL31: Built : 15:58:17, May 22 2019
NOTICE: BL31: G12A normal boot!
ERROR: Error initializing runtime service opteed_fast
Bringing this up again after some while: After a period of flawless operation, my Reform started this strange behavior again. Sometimes the screen just won’t turn on at startup. Meanwhile I developed some paranoid/esoteric/desperate measures: Like thinking if I move the screen a view degrees than it will more likely turn on or putting in or pulling out the power supply will help to start it up.
I managed to compare the outputs with my UART Adpater. The difference I can make out is as follows:
Did you make the switch from tuigreet to gdm? I am currently porting the patch stack to kernel 6.15 and I noticed a nondeterministic issue where the backlight would not come on until gdm shows up. Does the backlight come on in your case?
No I did not switch. I usually don’t change much on the system, just keep doing apt upgrade and autoremove on a regular basis.
Do you mean screen backlight? No, the screen does nothing at all, it just stays completely off.
Since MNT switched from tuigreet to gdm, the adjustment of kernel loglevel to 3 (making it not mess up the tuigreet interface) was dropped and we are back at the Linux kernel defaults. If you want to keep using tuigreet and do not want to switch to gdm, then you have to manually set the loglevel to its previous value. I wrote about that here: Login menu appears, is then covered by errors - #3 by josch I created a new post and pinned it globally to maybe avoid more confusion going forward: System Image V5 Gnome default configuration changes (reform-tools 1.73 or later)
I’m currently investigating this issue for linux 6.15. Could you switch from tuigreet to gdm and tell me if this can at least be a workaround for you? Because even though backlight does not come on for the console (and thus you do not see tuigreet), the backlight should come on for gdm if the error that you see on 6.14 (can you please confirm that you are running that kernel version) is the same that I see now on 6.15. You switch to gdm by running:
