clockworkpi

How I can fixe the screen connector

Was this with an A06 unit, or something else? I’m reading a few other posts and there seems to be some correlation between A06 and starting up only with charged batteries.
It would turn on and receive power, but even after leaving it on for over half an hour, the screen wouldn’t turn on.

An A06 4GB, with the stock OS you can download as well as the SD card delivered with it.

We’ll just have to gather more data. Something just isn’t adding up.
My data gathering for the day:

I put together my own OS from scratch (I wanted to experiment with a 32bit environment re compatibility) and that managed to boot up first time without batteries; albeit after having uses my Devterm with batteries coming using the stock 64bit OS.

A second attempt was made with the stock 64bit OS flashed freshly to an SD card, again without batteries. It worked without batteries.

It seems to be a problem that affects only some people with the first time running of their units. From then on, it works fine. Could it be that for QC, some units in batches are tested, thus “priming” it for use?

Regardless, if there are ever problems with the screen turning on, before tinkering with the cables, it would be far wiser to take a problem solving approach, and use a tried method that has worked for others; buying batteries.

If you can afford the devterm, the batteries are pocket change in comparison. The bigger question is, why are there so many people who don’t have batteries? With the delays in delivery, I would have thought that to be ample time to find some.

1 Like

I think this would be worth a thread of its own! I read every post and haven’t heard of anyone else who was able to put a different OS build on their DevTerm.

2 Likes

Ha, I’m not doing anything groundbreaking. Just decided to try making things from scratch minimally, and adding a 32bit architecture for backwards compatibility.
Eg,

dpkg --add-architecture armhf

apt-get update

apt-get install libc6:armhf libstdc++6:armhf
cd /lib

ln -s arm-linux-gnueabihf/ld-2.23.so ld-linux.so.3

See here: Running 32 bit applications on Aarch64 - Reviews, Tutorials, Hardware hacks - armbian forum

It’s kinda the reverse of what I did in the past re adding 64bit architecture support to a 32 bit OS, when I was running Dolphin on a rPi4 on raspbian; before it went 64 bit.

It’s a bit of a clusterfsck compatibility wise, so that’s why I made a separate OS installation with as little installed to prevent any version conflicts re downloading redundant packages/updates.

I mainly did it for compatibility and testing of 32bit exclusive apps, eg Renpy for potentially using the Devterm as a graphics novel driving machine.

Huge emphasis on “testing” since it was very hit and miss. More info regarding renpy and 64bit ARM compatibility here: 7.3.5 Doesn't work on ARM64 · Issue #2297 · renpy/renpy · GitHub

I think similar workaround have been mentioned in other threads. I’m definitely not somehow magically making a 32bit OS work it’s magic on the Devterm.

1 Like

Or, maybe, it’s just coincidence?

I deliberately did not buy any before having the device in hand due to the apparent uncertainty if they will fit, and I wanna be able to send them back if they don’t, in particular if I have to pay 40 - 50€ for the pair. Return deadlines for online purchases are 10 days over here.

1 Like

Wow 40-50€? Lets open a business where you live, I will source you the batteries :stuck_out_tongue:

1 Like

just put in a new sdcard, booted up with battery and power plug.
It turned on after a few seconds and showed the text output for booting. Screen is on and it says that it will need 6 minutes to expand the filesystem. No problem with a blank screen…

System is A06.

1 Like