Thanks Kyle for explaining that to me.
1 Like
Thanks Kyle, Are you allowed to tell us how many Dogwoods Purism intends to ship? I know you don’t owe us those numbers. I think we would all like to see Purism have fantastic success and we’re all hoping the numbers are big or at least not small.
That depends on the nature of the I2C problem. If it requires a further hardware change then I would be hoping that Dogwood is small. Ah, the fun of developing a new phone from scratch. Just musing publicly. I don’t speak for Purism.
2 Likes
I know you cannot reveal batch size, can you at least let us know the percentage of Dogwood customers that gave 2nd confirmation for receiving it despite the issue?
If percentage is low, it will explain the lack of posts by such customers.
I don’t think that many people realize how hard it is to develop a new phone from scratch without a reference design from the SoC maker. Even a company like PINE64, which has a lot of experience in hardware design and has been working on A64 boards since 2015, has had problems producing its PinePhone. Data over USB-C didn’t work in its BraveHeart and CE: UBports editions. The 4000-4500 customers who bought the CE:UBports are stuck with phones that they can only fix by doing some delicate soldering. The A64 should support RAM running at 667MHz, but people report that it suffers crashes above 588MHz. The A64 should support 1.2GHz, but the PinePhone’s max speed is limited to 1.152GHz.
When Android phone makers buy a reference design for the Snapdragon, MediaTek Helio or UNISOC, they are unlikely to face any of these problems, because Qualcomm, MediaTek and UNISOC have already debugged their reference designs. Essentially, they bypass the need for the pre-Aspen, Aspen, Birch and Chestnut boards and they start at Dogwood with most everything already working. They certainly don’t have to figure out how to rewire the board to get DisplayPort instead of HDMI output, because all of today’s mobile SoC’s already have DisplayPort in the reference phone design.
They don’t have to help develop the drivers, so all the hard problems that Purism is facing with the DCSS video out, suspend-to-RAM and MIPI-CSI2 interfaces for cameras are already solved. They also don’t have to create the mobile desktop environment (DE) and adapt the source code of dozens of applications to use that DE.
This is why I get so annoyed at the reviews for both the Librem 5 and PinePhone, because most of the reviewers haven’t even bothered to look at the state of the mainline Linux drivers for the i.MX 8M and A64, so they have no clue about what the challenges are. They certainly haven’t bothered to think about why having 5 separate chips at 40-28nm node size might have a different kind of battery life than one integrated mobile SoC at 14-7nm.
18 Likes
You are right, we aren’t reporting batch sizes for the pre-Evergreen batches other than to say they are small (it makes little sense to have large batches pre-mass-production).
While we still haven’t heard back from all the Dogwood backers (those who don’t get back to us within a reasonable time will end up in the front of the line of Evergreen), so far of those who have gotten back to us a large majority opted to go to Evergreen, after we informed them about the stability issue we were working on.
While we are still working on tracking down the cause, our mitigation seems to be working well, at least for me. I haven’t had a crash ever since it was put in place.
16 Likes
@Kyle_Rankin, can I ask your personal opinion as a user, of the experience (and forgetting exactly how many mAh battery may have etc.)? Provided, that no huge surprices come up anymore, does Dogwood seem to be close to Evergreen on hardware?
1 Like
We have a post on Evergreen that will hopefully get published in a few days that should answer your question 
14 Likes
Two Dogwood owners
9 Likes
How are calls & texts working?
1 Like
I’ve not had the chance to test that personally. I don’t have a phone plan right now and likely won’t until spring.
1 Like
I will ask now since I know others will ask you eventually - can you tell us about battery life?
2 Likes
I’ve not actively tested it, but I can tell you it is only a few hours right now. I would assume 6 to 8 with the baseband and camrea/mic off. I can tell you I’ve passed out without with it at full charge and on that setting it was fully drained before I woke up. I can test it out tommorow, but seeing the progress they have made on it already I’d assume it will be longer before evergreen comes out.
1 Like
The most notable thing I’ve had to deal with so far has been the fact I had to use SCP to send files to it after setting up the SSH server myself. Not the worst thing I’ve had to do to send files onto a system before, but I was fairly shocked they have not gotten MTP working yet as far as I can tell.
1 Like
I’ve set up a shell script to print the battery %, the battery life in the less human readable form that it has, and the time in in a CVS file to share with you all, I’ve had it running a few hours with it as a cron job that runs every minute. Currently it’s at idle in lockdown mode. I’ll keep letting it do that for the next few hours then post the file here. I’ll likely collect it regularly like this for the next few weeks on different setting to see the current state of the battery. If you’ed like I can post the shell script when I post the CVS file.
EDIT: https://github.com/dylanlester-librem/Librem5-battery-data I had to use a github account I made on the fly to host the files as I could not upload them here directly.
13 Likes
Thanks for all the updates dylanlesterpvcs, it is very much appreciated, please keep them coming.
Connecting back to separate topic (Planning ahead: what and how to report on L5 when the time comes) close to this: could it be possible to add a column or two to that script for more info? Load average would give some indication how much use device is getting (for instance cat /proc/loadavg , all five or just the first and fourth) selected in the script. And maybe data transferred (total cumulative up/down or individually by method/radio)?
General thoughts on this continued in the separate data gathering thread…
@dylanlesterpvcs,
If you have a scale, I would appreciate it if you could weigh Dogwood. Birch and Chestnut weighed 230 grams, but Dogwood has a higher-capacity battery and added a back metal plate for better heat dissipation and a plastic plate over the M.2 cards, so I expect that the weight has changed.
It would be cool if you could post the output from these commands:
sudo dmesg
sudo apt install lshw
sudo lshw
sudo apt install sysbench
sysbench --test=cpu --threads=1 run
sysbench --test=cpu --threads=4 run
sysbench --test=memory run
sysbench --test=fileio --file-test-mode=seqwr run
sudo apt install lm-sensors
sensors
3 Likes
@amosbatto could not get sysbench even installed as it could not find it in the repos, as for lm-sensors, it returned an error when I tried to run it. THe output from dmesg and lshw along with anything that lm-sensors might have spit out in a file called request.md it is really a txt file. https://github.com/dylanlester-librem/Librem5-battery-data
1 Like
Thanks @dylanlesterpvcs.
It looks like lshw shows the temperature info, so lm-sensors isn’t needed.
I’m surprised that there is no sysbench package. Is there a hardinfo package? That has some basic benchmarking.
Looking at your dmesg log, I’m struck by how long it takes to bring up the Wi-Fi (11.6 seconds) and the cellular modem (18.9 seconds), but everything else seems to boot really fast. It looks like the GNSS still isn’t being used.
2 Likes