I know it will be for Micro SD, but, will it use the USB 3.0 bus and will it take full advantage of UHS2 Micro SD cards?
MicroSD, no, and no.
4 Likes
can you saturate the full 480 megabits / s of usb-2.0 bus with ANY MicroSD today ?
as far as i know MicroSD doesn’t get sustainable R/W operations for more than 60 MB/s … they advertise 100MB/s on the high-end models but that’s just marketing …
anyway MicroSD is not for real Professionals it’s more of a convenient way to store large files in a VERY small space … but more than that ? … don’t think so …
1 Like
No, but then the USB bus is simultaneously being used for quite a few things (WiFi & 4g data AFAIK)… but I agree that the bus will probably not be the limiting factor here.
There are multiple USB buses. WiFi is using SDIO, so it doesn’t interfere. Not checking with the schematic, but I think there are 3 USB devices: the host connector, the modem, and the SD controller.
5 Likes
The datasheet claims:
The USB2642 offers a versatile, cost-effective andenergy-efficient hub controller with 2 downstream USB2.0 ports and a flash media interface. The flash mediainterface can support sustained transfer rates exceeding 35 MB/s.
So, USB bus speeds are the least of your concerns there.
3 Likes
While up to the USB2642 controller specs not 100% sure, can I count it will support UHS-1 microSD Memory Cards (flawlessly read: 90MB/s and write: 40MB/s, at maximum) with speed mode UHS104 (SDR104), likewise up to 8GB SDHC SLC or 128GB SDXC MLC? IMO, USB2642 SD Clock Limit of 48 MHz lives us with SDR50 and very max. write speed rates of 20MB/s (if using the conventional High speed bus interface and not the UHS-Ι bus interface). Can someone from batch Chestnut confirm READ benchmark from any UHS-I (Class10 and U1) microSD with hdparm -t /dev/mmcblk0? To make my question short, is it Librem 5 UHS-I compatible (fully compliant with SD3.0 specification) device or not? If YES, Thanks!
1 Like
Just hypothetically speaking, let’s say I have a 2 TB SD card. How much time would I need to write it at full speed?
20 mb/s:
(2 tb) / (20 (mb / s)) = 1.15740741 days
40 mb/s:
(2 tb) / (40 (mb / s)) = 13.8888889 hours
100 mb/s:
(2 tb) / (100 (mb / s)) = 5.55555556 hours
200 mb/s:
(2 tb) / (200 (mb / s)) = 2.77777778 hours
What to learn from this experiment?
- Probably I won’t just copy 2 TB at once
- 200 mb/s would be an acceptable speed for me - given that modern sd cards can reach 200 mb/s I think in case it doesn’t reach it in the librem 5 a sd card reader would be the thing to go and copy it with the pc first and then plug it into the librem 5
So let’s say I’ll just copy some music / 1-2 movies to the sd card, how much time would it take me?
20 GB with 20 mb/s?
(20 gb) / (20 (mb / s)) = 16.6666667 minutes
20 Minutes - that’s I would say a time that might even work in case I remember to put files there the evening before longer vacations.
This leads me to the question - can we just plug in the librem 5 to a linux desktop and mount the librem 5 to copy / paste files? Would be something convenient most users would need (ofc anyone of us here in the forums can aswell use scp or filezilla as the librem 5 can just run an openssh-server ^^)
2 Likes
from my personal experience even 64G SD-card is already a big compromise of data integrity. You need to be ready that you’ll be seeing data corruption more often than with smaller volumes. With such a poor integrity I can hardly find any use case for 2TB sd card.
2 Likes
Maybe no.
AIUI, if you plug a Librem 5 into a computer then the Librem 5 will identify as a USB serial port.
I have no idea whether it is possible to alter or extend that behavior. Ideally, it would also identify as one (eMMC disk) or two (eMMC & µSD) mass storage devices, providing that that can be done safely (maybe only possible with the µSD card). Failing that, it could expose MTP functionality, or similar.
(If and when tethering exists, that would be different again.)
So the next best option, for speed, is to take the µSD card out of the Librem 5, put it in your computer (has built-in SD card reader or use USB dongle SD card reader) and pre-load the content.
1 Like
Currently, the phone appears as this in lsusb - where the bus and device will vary, of course:
Bus 001 Device 005: ID 1d6b:0104 Linux Foundation Multifunction Composite Gadget
This lets you use it as a serial device and network adapter (RNDIS) so you can log in using ssh over the USB cable when things are configured correctly. I think it also supports some kind of mass storage but I’m not sure how convenient or reliable that is.
1 Like
Adding to what David said, yes. The USB device includes a network adapter, and I do this all the time with sshfs:
sshfs purism@10.42.0.44:. mnt/l5
There is a mass storage device currently exposed too (read-only and empty), but this will never be viable to use, because a USB mass storage can either be available to the phone or the workstation, but never both. See issue https://source.puri.sm/Librem5/Apps_Issues/issues/71
3 Likes
It could be made safe to expose the µSD card e.g. if it is quiesced and umounted on the Librem 5.
However that is why the MTP USB class exists. Is there or will there be support for that, or something functionally equivalent?
That depends on the outcome of the issue I linked. Feel free to help resolve it.
Don’t know whether I have the expertise to write any code to resolve it, certainly not until … one day I may actually have a phone!
That issue seems to be trying to cover all bases. I think we should separate out the network-based solutions from the others. Presumably network-based solutions (e.g. NFS, sshfs, WebDAV) can all be done via WiFi today or via the USB network adapter, provided that the necessary clients and servers exist. All network-based solutions ought to have adequate security in place. The network-based solutions can presumably be turned around the other way and run the server on the laptop/desktop and the client on the phone, if all you want to do is haul a heap of files across (which I think is what the originator may have intended).
I would like to put network-based solutions to one side because that it isn’t really what I had in mind. Maybe that needs a separate issue, which issue focuses purely on local USB-based solutions (which means mass storage or MTP, AFAIK).
What do you mean by “will never be viable to use”, given that the originator seems interested in the µSD rather than the eMMC?
In true Linux style though there should be lots of ways of achieving the same end goal. 
Fun future option: If you could boot from the µSD then presumably you could safely do something with the eMMC, which might also be a good way of doing a comprehensive, robust, simple backup or restore of the eMMC.
The question was not about SD: “can we just plug in the librem 5 to a linux desktop and mount the librem 5 to copy / paste files?”
Yanking storage that may be in use and having to wrestle it away from applications that are using it is not a “just” solution. Personally totally useless for me no matter how you slice it.
That’s correct and usually achieved by multiple people selecting and maintaining one each