Often, a Linux device allows to access the serial console for diagnostic of the boot process. The devkit has an UART debug header for this purpose, the pinephone provides it via the headphone connector. I have expected to find such a port easily available on the Librem5, e.g. via the USB-C port in some way. But apparently, this is not the case. This would leave only the test points, which are, with a different layout, present in Evergreen, too. Is this right or is there any other mean available to get down to the kernel messages or the u-boot dialog?
Check again, serial console over USB is enabled by default alongside networking gadget. Are you getting anything in lsusb?
Thank you, but please re-read my question. I do get a serial console over USB but only after the boot process is fully completed. Before, i do not have any /dev/ttyACM0 nor /dev/ttyUSB0 or so. I thus never saw any u-boot dialog or kernel output of the boot process over this line. The first thing i managed to get over this line is a login prompt.
But perhaps, i do something wrong. The procedure i use is:
- plug in the USB-C to USB-A on a fully power phone and find /dev/ttyACM0.
- power of the phone keeping the cable plugged in and find no /dev/ttyACM0.
- replug the cable and find no /dev/ttyACM0.
- power on the phone again, and find a /dev/ttyACM0 showing only a login prompt.
I though then, putting the device into serial download mode and using
uuu would perhaps provide an u-boot dialog and kernel messages routing the serial line over USB. But apparently it does not. And there is no /dev/ttyACM0 at that point.
So is there any other procedure to get to the u-boot dialog or early kernel messages beside using the test points?
Oh, sorry, I miread indeed. The UART console is available only over debug pins as far as I know. I never really connected it myself outside of the dev kit.
Thank you very much. Good to know. I’m just starting to adapt myself to the circumstances.
I usually setup an unintrusive rescue system at that point, e.g. something using tftp and nfsroot, to ease fixing silly misconfigurations that prevent booting. Fully reflashing the system would mean to loose any other content or modifications.
From what i’ve seen so far, this should still be possible, but it is simply more difficult to configure and use it right without having access to the UART line.
There’s another way to do it:
If you mess with qemu-user-static enough, you should even be able to chroot into it. Granted, it’s only good for fixing, not for diagnosing.
Thanks, i was not aware that Jumpdrive runs on Librem 5 already. That could perfectly do it. I’ll give it a shot … and … in fact, this works.
Following notes might help to build it:
- I’m running a debian here on the pc.
- I had stuff from the aarch64 toolchain already installed
- an extra
apt-get install gcc-arm-none-eabiwas additionally necessary to get over compiling some Cortex_M4 stuff for u-boot.
make purism-librem5to build the stuff.
To boot into jumpdrive, one needs to put phone into flashmode and run
The phone then comes up with the splash screen saying:
Start the flashing procedure from your PC or connect to 172.16.42.1 over telnet
The partitions on the phone become available for mount much like as if they were plugged into the PC as usb-sticks. They came up as /dev/sdg1 (sd-card), /dev/sdf1 (boot-partion), /dev/sdf2 (root partition) here. I did:
# mount /dev/sdf2 /mnt # cd /mnt # chroot . # _
without any need to mess with qemu-user-static, which was apparently already installed above.
To telnet into the phone, setup the network first:
# ip addr add 172.16.42.2 dev usb0 # ip link set usb0 up # ip route add 172.16.42.0/24 dev usb0 # telnet 172.16.42.1 Trying 172.16.42.1... Connected to 172.16.42.1. Escape character is '^]'. Welcome to Jumpdrive Shell! / # _
The jumpdrive runs in a ramdisk, i.e. does not need to reflash the phone’s image.
Aside of the test points, UART is also exposed over one of the M.2 slots and you can use a breakout board like https://source.puri.sm/Librem5/librem5-m2-breakout to access it.
Thanks, @dos, for pointing at this option.
I’d hesitate a bit, though, as i found that the antenna connectors are rated for 10 duty cycles, but perhaps i’m simply to anxious.
There is a flex breakout for the pine phone, a solution, that in principle could work for the L5 test points also.
From what I see in the schematics, UART1 is also exposed on the extension connector, so you could also attach a breakout board to that (I don’t think we have done one yet, but I guess it’s just a matter of time).
Thanks, i do have a breakout board for USB-C here and will look at the schematics…