that table seems a bit inaccurate in a few places. Video out on USB-C is not limited to 1080p, cameras are not using MIPI CSI but parallel interface, not sure how to interpret meaning of 4 channels in the codec (it’s a stereo codec, so mostof the paths have 2 channels, L/R and number of inputs/outputs is way larger - in the range of 20 or so), also it’s not limited to 48kHz, but to to 192kHz.
Your link has “).” on the end.
Edit: Link has been fixed.
Thanks, corrected. Not my fault though.
Um, they must be talking about some other device. The L5 has both cameras on MIPI-CSI2 https://source.puri.sm/Librem5/linux-next/-/merge_requests/255
I asked megous to clarify what he means by a “parallel interface” on Hacker News.
The “2.7. Image In” section on page 10 of the A64 Datasheet calls MIPI CSI a “8bitYUV422 CMOS sensor parallel interface”, so I’m not sure if he is referring to that parallel interface or something else.
2.7. Image In
•Support 8bitYUV422 CMOS sensor parallel interface
•Support CCIR656 protocol for NTSC and PAL
•Maximum still capture resolution to 5M
•Maximum video capture resolution to 1080p@30fps
I see that I was mixing up inputs/outputs and channels for the PinePhone. The A64 supports 4 inputs and 4 outputs, but only two channels in the DAC and ADC. The DAC supports 8 - 192 kHz, but the ADC only supports 8 - 48 kHZ. OK, I’ll clarify that in the table.
This may be correct. Looking at the pin description on page 24 of the datasheet, it shows 8 data pins (CSI_D0 … CSI_D7) so maybe it really is interfacing with the camera via a parallel interface (at least as far as the receiving end is concerned). So calling it "CSI " is potentially confusing …
I suspect that the A64 is using the MIPI Camera Parallel Interface (CPI), but calling it the MIPI Camera Serial Interface (CSI). This is really confusing, but I am simply repeating what the A64 docs say.
Thanks for the suggestions. I added that info under “Battery” and “External Storage”.
storage microSD (SDHC, SDXC, max 2 TB), bootable
I would write like that:
storage microSD (SDHC, SDXC, max 2 TB), has first boot priority
I added Evergreen info and amarok’s Evergreen photos. I included Megous’ info on the PinePhone. I also added an “Included in the box” section to the table, with info on the Power Delivery charger
I left it as “bootable”, but linked to the PinePhone wiki that explains how to make it bootable, which I think will be less confusing.
two microphones? that’s an interesting info/spec.
Thank you for your valuable contributions to the community!
These instructions do not make the microSD bootable. It’s always bootable by default with the first boot priority. Pinephone always automatically tries to boot from it. If the boot fails, only then the eMMC will be tried. This is a very big distinctions between the two phones. In case eMMC dies, Pinephone will stays almost as useful as in the beginning, not so for Librem 5 (it’s almost like a planned obsolescence for th elatter, but it’s for technical reasons actually AFAIK).
It’s a link to instructions how to make a bootable microSD, which is what most people want. Most people aren’t interested in how to change the u-boot configuration files to make the eMMC have first boot priority.
True, but someone who wants to know that level of detail, probably also wants to know that the PinePhone doesn’t have the ability to boot from the USB port like the Librem 5, which makes it much faster to try out different configurations/distros on the Librem 5, because it takes longer to rewrite a microSD card, than altering files on a PC’s SSD/HDD. I think another row in the table is required to explain all these differences.
For that matter, I think it likely that the Kioxia chip on the Librem 5 has better wear leveling and block replacement than the Kimtigo chip whose documentation doesn’t even mention wear leveling or health reporting functions, which makes me question its long-term reliability.
Edit: I rechecked the Kimtigo documentation and see on page 20-21, there is some heath reporting and there is a TRIM command, so maybe it isn’t as bad as I thought.
Couldn’t there also be security implications of the default booting from the microSD card? Malicious software on eMMC could write it’s own bootloader to the card and get full control of the system. And the “obsolescence” part may also concern the users.
My links above in the update suggest otherwise.
I wonder why booting from USB OTG isn’t documented for the PinePhone. Is this an issue where PINE64 hasn’t enabled in the PinePhone hardware or is it a simple matter of changing a U-boot configuration file or did nobody document it in the PinePhone wiki? Hard to know, but I can’t list this as a feature until it is documented how to use it. I feel the same way about the Librem 5’s boot via USB. Right now Purism hasn’t documented it, so I’m not going to list it in the table, because it isn’t usable for normal people.
Every flashing sequence starts by booting u-boot on the phone via USB. The scripts needed to boot are available at https://source.puri.sm/Librem5/librem5-devkit-tools/. There’s even my PoC port of Jumpdrive that boots straight from USB: https://source.puri.sm/sebastian.krzyszkowiak/jumpdrive. I’ve learned how to do that myself all from the publicly available documentation and code
No need to rewrite a multidistribution SD card.
Concerning USB-OTG for Librem 5: Not yet