Don’t know what I expected. At least some charging for the Librem 5. Nothing.
Maybe the USB-C port on the Librem 13 does not support Power Delivery (PD)?
Try a USB-C to USB-A adapter so that you can plug the Librem 5 into a USB-A (3.0) port on the Librem 13. That might at least get the Librem 5 900 mA, which should be enough to run the phone and charge the battery slowly.
Eliminate the obvious failure points - bad USB-C cable; chosen permutation of cable orientation (4 permutations) not working.
Regardless of charging, you would expect the Librem 5 to show up as a device e.g. maybe network over USB for tethering. lsusb should show something.
1 Like
The USB-C port on the Librem 13 is data only, it does not do PD. If you connect your Librem 5 to the laptop and run the command: lsusb what is the output?
lsusb shows nothing, even on a Fedora Live session.
I thought it was something related to Qubes, but not this time.
I am using the provided Librem 5 USB-C, which works when charging.
Have you tried any of the troubleshooting steps that I suggested above?
I’m sorry, I don’t have a USB-C to USB-A adapter currently.
Edit: Acquired adapter and it works. Charging, that is. Saw a block device but it didn’t show up with lsblk and the USB device only reported 1MB free.
Cable I have is probably made for charging anyway, and I wonder there isn’t a data transfer limit on certain USB-A to USB-C adapters, as well as USB-C to USB-C.
Charging, at least with this cable is really slow and after 12 hours battery was still roughly the same percent. Only one app was running with 3% usage in the background.
Here’s what I see connecting a Librem 5 to a vanilla USB-A 3.0 port (not on a Librem 13; and computer is running Ubuntu) via an adapter, using the provided USB-C charging cable.
Librem 5 shows up on the host as Bus 999 Device 999: ID 1d6b:0104 Linux Foundation Multifunction Composite Gadget (bus and device numbers will be different for you)
Librem 5 tells the host that
- it can do networking of some kind (two different kinds?) but interface does not come up automatically (that’s probably a config issue - don’t know which end)
- it has a 1MB disk (mass storage class) -
File-Stor Gadget- wouldn’t get much of a file system on that (doesn’t appear to have a partition table and I didn’t dare partition it
) - maybe this is /var/lib/mass_storage_dummyon the Librem 5
Librem 5 goes into charging mode (LED is red) but does not seem to draw anywhere near the right amount of current - current as reported is all over the place - and appears to tell the host that the Librem 5 is self-powered (rather than bus-powered). I would tentatively blame the Librem 5 for this behaviour i.e. if it wanted to charge from a USB-A 3.0 port then it isn’t saying the right things.
Shows up for me as sda (I have no other USB/SCSI/SATA disks on that computer)
I think this confirms most of your observations. So it looks as if neither the USB-C port nor the USB-A port will work for charging the Librem 5.
2 Likes
When not using PD, input current is limited to 500mA (unless overridden manually).
I’ve heard this too before, but why should it be necessary to test all four permutations? Shouldn’t the orientation be irrelevant since the connector doesn’t care about which way it is plugged? If orientation matters it feels a bit strange.
That’s a myth - the USB-C receptacle explicitly has to care about which way the connector is plugged into it in order to work properly since the USB-C plug pin-out is not symetric. That’s what the resistors on the CC pin are used for - a proper USB-C cable should have one only on a single CC pin so its orientation can be correctly detected and that the second CC pin can become Vconn (if necessary).
3 Likes
My answer to that would be: yes but there are a truckload of cheap and nasty implementations that don’t quite work properly - so if it doesn’t work one way, I would always try it the other way.
By definition I am connecting through an adapter - and the adapter didn’t cost me much.
One caution: when plugging my Librem 5 to a random computer, it takes quite a time (10 seconds? a bit more?) before it shows up. So if doing testing, patience is necessary.
Doesn’t seem to work for me though, looking at /sys/class/power_supply/max170xx_battery/current_now - is that the wrong thing to look at? and likewise lsusb -v on the host for the Librem 5 USB device didn’t show that it had asked for current. (I’m not worried by this. I normally charge using the supplied charger. I was just curious because of the OP’s problem - which maybe Purism should look at because obviously it would be better if Purism devices played nicely together.)
While you’re here … is /var/lib/mass_storage_dummy the right file for the 1MB disk that the Librem 5 advertises to the host and, if so, is it safe to reallocate it (while not connected to a host) to be a bit larger - and then put a partition on it and then put a file system on it - in order to make it useful for something?
I’m thinking maybe 100MB - 500MB and then after disconnecting from the host some kind of loop mount (is that the right term?) to copy files out of the storage onto the eMMC drive / uSD card. Of course scp / sshfs / SFTP generally over WiFi is easier but it’s good to have alternatives. 
1 Like
That one is the current taken from/fed to the battery, which when charging will equal input current minus power consumption clamped to maximum charging current. Input current limit can be found at /sys/class/power_supply/bq25890-charger/input_current_limit. Whether the descriptor claims that the device is self- or bus-powered is irrelevant.
Yes, at least at the moment - g_multi gadget will likely be replaced with configfs-based solution and mass storage may then be dropped by default, at least for now (but you’ll be able to bring it back by yourself of course if you want to actually use it).
1 Like
OK, that could be right then - because the phone is consuming too much relative to a modest maximum of 500 mA i.e. can’t really charge and a lot of the time is discharging (which is why I observed it bouncing around between small net discharge and small net charge, so could take “forever” to charge, which is also kind of what the OP observed).
OK, I might have a play with it but I won’t complain if it goes away by default with a future update.
Thanks for the answer. So the spec doesn’t say that devices should detect which orientation the connector is connected and compensate for that? It feel so strange that the spec would be written in a way such that you always had to try which way the connector should be plugged. I’ve checked my devices and there are not markings on the receptacles, so than would mean that there is not way to know which orientation is correct.
The device is supposed to detect the plug’s orientation and act accordingly - at least when everything operates correctly. What I meant is that there’s enough potential failure modes that reorienting the cable on both sides may actually help, so it’s worth trying.
2 Likes
It’s a bit similar to the change from ethernet requiring a certain number of crossovers between two devices to all ethernet ports being auto-detect. In the early days of auto-detect, some did and some didn’t, and some that claimed to do so were sometimes flaky, so if it didn’t work, it was always worthwhile throwing in a crossover cable to see whether that resolved the problem.
1 Like
If anyone else is playing around with this … I did mv on the existing file and created a new much larger file with the required name but in order for the Librem 5 to use the new file I seemingly had to reboot the phone. It is as if it latches onto that file at boot time (even though, for example, I couldn’t see it open with lsof). Not a drama but something to be aware of and I don’t know what the full implications of this might be e.g. if I had deleted the existing file or e.g. if I had extended it in place.