Thank you so much for your answer, Dorota. So, please, where I can find tech specs about sdcard to buy?
Is UHS-I 3 30 MB/s (200x) 50-104 Mb/s good for L5? Is it the top allowed for 2.0?
That depends on what you need the card for. I don’t think the SD controller can go as fast as 100Mb/s. UHS-I is the maximum supported.
So “microSDHC/microSDXC UHS-3 card” in purism shop is too much for L5 I suppose.
https://shop.puri.sm/shop/sd-memory-card/
(Although is into category accessories phone )
It’s not “too much” in the sense that the phone will work with UHS-3 cards too, and the phone will benefit from all the storage available on it.
@velano, see the community FAQ: https://source.puri.sm/Librem5/community-wiki/-/wikis/Frequently-Asked-Questions#214-what-kind-of-microsd-cards-does-the-librem-5-support
I checked the data sheet for the i.MX8MQ and all the USB controllers support both 2.0 and 3.0, but the issue is that there are only 2 of them. In the schematics, one is used for the USB-C port and the other is used for everything else (MicroSD, WiFi/BT, cellular modem and test points). I assume that the reason why the designers selected the USB2642, which only supports USB 2.0, is because the WiFi/BT and cellular modem only support USB 2.0, so the bus can’t operate at USB 3.0 speeds.
Oh, that might be it. Now I remember which controllers we ran out of - the MMC/SD controllers. One went to the eMMC storage, the other to the WiFi module.
FYI looking at an actual Librem 5, in software, I would say that the following are on the other USB
- uSD card reader
- modem card
- (maybe) Bluetooth
not WiFi.
If Bluetooth is on there then it certainly can’t use USB 3.0 speeds anyway.
The WiFi/BT in the Librem 5 is using SDIO and I2S, but there are also two lines (USB2_WIFI_DP and USB2_WIFI_DN) between the USB2642 and M.2 slot for the WiFi/BT card. Maybe those two USB lines aren’t used, but I assume that Purism connected them for some reason. Maybe Purism is keeping the possibility open for future WiFi/BT cards that need USB, or maybe Purism thinks that people will want to use other types of cards.
Since the USB2642 contains a USB hub, I wonder if Purism could have found a similar chip that supports USB 3.0 to allow high speed access to the microSD card, and then run its USB hub at USB 2.0 speed to connect to the cellular modem.
Both.
Since it’s modular (removable), as far as is reasonable, Purism shouldn’t restrict what M.2 card the customer can put in (although I would suppose that anything that uses PCIe / SATA via M.2 may never work e.g. even if you could find an M.2 storage device that physically fitted, it wouldn’t work).
Some customers may want a WiFi card that does not do Bluetooth. Some customers may have no need for either.
With the speeds I am seeing at the moment, I would be happy to see anything like realistically achievable USB 2.0 speeds, never mind about USB 3.0.
It would be cool if someone would do some benchmarking of the Librem 5’s microSD, using hdparm
and dd
, as described in this article and this one. It might give us some idea whether the USB bus is the limiting factor. For example, if the read speeds are 15 MB/s on a card that supports 50 MB/s, then the USB bus is probably not the limiting factor, since it should max out around 30-40 MB/s.
I’m sorry that I asked.
The read speed shouldn’t be slower than the write speed!
The RS9116 WiFi/BT on the L5 also has slow speeds. I wonder what is the bottleneck.
@amosbatto, here is another proposal (please check it), slightly changed, for microSD I/O performance testing on Librem 5. Only important thing before executing commands is that those need to be inside related (present) directory/partition (and for some kind of consistency my SDcard was formatted to ext4), therefore as first:
cd /media/USER/microSD_path
Today I’ve used count=2048
(perhaps 4096
would be ideal), yet quicker count of 512
will do as well. Note that for test_data files you’ll need su
rights to remove those (sudo rm test_XX_data
).
Just for coarse comparison results with the same HP mx310 UHS-I U1 100MB/s 64GB microSDXC card (only W and R commands changed to test_PP_data
) inside PinePhone were:
Write: 215.399 s, 10.0 MB/s
Read: 180.912 s, 11.9 MB/s
cd /
… to test_PP_eMMC_data
:
Write: 129.938 s, 16.5 MB/s
Read: 27.9539 s, 76.8 MB/s
That worried me too. The only thing that I can think of is that hdparm -t
is a rather short test (about 3 seconds?) for read, compared with dd
for the write, which under the specific test conditions was about 20 seconds. Maybe 3 seconds is too short to give an accurate result in this case. I couldn’t see any way of asking hdparm -t
to read more data.
It doesn’t get much better using dd ... if=test of=/dev/null
Using a 200MiB file, I’m getting 11 or 12 MB/s for read.
As a matter of interest, you can replace bs=1048576
with bs=1M
for less typing.
The conclusion seems to be that the read speed is severely hampered by something in the Librem 5, when the card itself is seen to be capable of close to the advertised speed (100 MB/s for my uSD card).
If we’re talking about the SD card, then results of tests that take such a short time will likely be skewed by the latency of resuming the reader from power saving mode.
are we talking about a LUKS encrypted microSD card here or is it left unencrypted ?
from my experience on the LMini-v1 on the desktop side if you transfer files between encrypted medium source and encrypted medium destination the speed penalty can be quite severe (like 30 MB/s where the SSD drive normally does upwards of 200 MB/s easily in most cases)
Well, whatever is the bottleneck on the Librem 5, the PinePhone is similarly limited in its microSD speeds.
I expected much better performance from the PinePhone’s eMMC. The read speed of eMMC 5 in other phones can be as high as 400 MB/s. I would be very grateful if someone would do speed tests on the Librem 5’s eMMC as well.
Definitely unencrypted in my case.
Already (partly) done. Follow my links.
Unfortunately not blindingly fast either.
I’m only seeing a speed test of the L5’s microSD. Did you do a test of the L5’s eMMC (the internal Flash memory) as well?