That’s the battery in the chestnut Librem5
As for the main board, it is not visible when you remove the first cover.
You have to remove about 7 screws which I did. But I was a bit out of time to find the next step.
Not sure if I have to remove the wifi adapter + modem to be able to open deeper.
This video might help you disassemble the phone:
(or you can watch it here if don’t want to contribute to the Google monopoly.)
Have they removed the annoying rounded corners on the display yet? It’s not much of a problem with the default UI, but with alternative UIs it definitely would be.
That is a surprisingly polished custom battery case for a temporary battery that won’t even be in the final phone!
That doesn’t quite work, since because the default UI hides them, it is only visible in full-screen applications: Why does the Librem 5 have bevelled edges, and what does this mean for alternative compositors?.
Oh I see, what can I try to see how it display?
I would think a fullscreen video would be enough. If not, some game ought to work.
@purismforum, If you don’t mind, I would like to find out if we can detect the cameras.
Can you first install the following packages:
sudo apt install device-tree-compiler i2c-tools
Then, switch to root and save the terminal output to a text file:
sudo -s
script ~/findcameras.log
Now let’s see if we can find the cameras:
dmesg | grep -i camera
v4l2-ctl --list-devices
(I’m not sure if you are using video4linux but worth a shot)
i2cdetect -l
ls -l /dev/vid*
dtc -I fs -O dts -o ~/devtree.txt /sys/firmware/devicetree/base
If that doesn’t find the device tree files, then try this to find the device tree binary file:
find / -name "*.dtb"
If you find the .dtb file, then use this command:
dtc -I dtb -O dts -o ~/devtree.txt /path/to/x.dtb
(replace /path/to/x.dtb with the .dtb file that you found using the previous command)
Finally, try this:
find /proc/device-tree/ -type f -exec head {} + | less
Finally stop logging the output and exit as root:
exit
exit
When done, post the contents of your /root/findcameras.log and /root/devtree.txt files. Hopefully, we can find the camera.
Here.
I had to install less + video4linux utils but that does not help much
Thanks @purismforum. The device tree listing says that both the cameras are “imx21”.
I assume that the back camera is the Sony IMX214 CMOS Image Sensor, which according to the product summary supports 4K and 2K at 30 fps and 1080p at 60 fps. Its device listing includes the flash LED and the Wolfson Media WM8962 audio DAC, so maybe it will use that chip for audio processing when filming. This sensor uses 1.2 Gbit/s on 4 lanes, whereas the MIPI CSI-2 interface on the i.MX 8M supports a maximum of 1.5 Gbit/s on 4 lanes, so I assume that the i.MX 8M can’t support an image sensor larger than 16MP.
I assume that the front camera is the Sony IMX219 CMOS Image Sensor (reference manual). It’s max video resolution is 1080p at 60 fps and it doesn’t include the Wolfson DAC in the device listing, so it probably doesn’t use it to process the audio.
Unfortunately, the device listings say that both of the cameras are disabled. Those sensors are nothing special, but Sony’s sensors are generally considered better than comparable sensors from other manufacturers (Samsung, Omnivision, etc.), which is why Sony controls 60% of the image sensor market.
Nice to know what we can expect on the hardware side, but it will probably be a long time before we have good software for the cameras.
Oh, one more thing, @purismforum. Would you mind posting the entire output from dmesg ?
dmesg > ~/dmesg.txt
sure here it is dmesg -T on librem5 chestnut full dmesg
FYI I disabled suspend as it crash the phone every time.
Strange. I’m not seeing “camera” in the dmesg output. Try this:
dmesg -s 99999 > ~/dmesg.txt
If that doesn’t work, maybe you have to run dmesg after rebooting to get all the kernel messages.
Thanks. The complete dmesg didn’t tell me anything more about the cameras, but I’m really impressed that it boots in 17 seconds.
The only remaining mystery is who manufactured the LCD screen. Maybe we can get that info from the EDID:
apt install read-edid edid-decode
get-edid | edid-decode
Or if that doesn’t work:
get-edid | read-edid
the 1st one did not work.
here is the 2nd one
get-edid | edid-decode
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 3
Looks like no busses have an EDID. Sorry!
I’m sorry nothing was successful. Maybe try some other arguments
if you played with them, or send an email to Matthew Kern pyrophobicman@gmail.com.
No header found
If it doesn’t use EDID, I wonder how it gets the info about what screen resolutions are supported. That must be programmed somewhere.
Do you see any info about the screen in the /var/log/weston.log file?
If not, edit the /etc/environment file:
sudo nano /etc/environment
and add this line:
WAYLAND_DEBUG=1
Then, reboot and check the contents of the /var/log/weston.log file.
/var/log/weston.log does not exist even with WAYLAND_DEBUG=1
See WAYLAND_DEBUG is set on the wayland process
root@pietro:~# ps -ef | grep -y way
purism 631 1 0 14:51 tty7 00:00:00 Xwayland :0 -rootless -terminate -listen 19 -listen 20 -wm 39
root 1072 1027 0 14:55 pts/0 00:00:00 grep -y way
root@pietro:~# cat /proc/631/environ
MAIL=/var/mail/purismUSER=purismXDG_SEAT=seat0XDG_SESSION_TYPE=ttyHOME=/home/purismDBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/busLOGNAME=purismJOURNAL_STREAM=9:19080XDG_SESSION_CLASS=userTERM=linuxXDG_SESSION_ID=1ETNA_MESA_DEBUG=no_supertilePATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binINVOCATION_ID=4ffa9084ddab48ce86879d715ee7cf52XDG_RUNTIME_DIR=/run/user/1000LANG=en_US.UTF-8SHELL=/bin/bashXDG_VTNR=7PWD=/home/purismWAYLAND_DEBUG=1XCURSOR_SIZE=24DISPLAY=:0_WAYLAND_DISPLAY=wayland-0WAYLAND_DISPLAY=wayland-0WAYLAND_SOCKET=22root@pietro:~#
