OpenBSD explicitly supports Pine 64/64+ and even ships the firmware to boot it with the install media. ROCK64/ROCKPro64 are also supported, but it's necessary to separately install an UEFI capable U-Boot. [0]
> Rockship (PinePhone) which is reversed engineered so only old SoC have support and it require massive effort from the community.
PinePhone has Allwinner A64. [0]
And Rockchip SoCs have a quite decent track record of not only supporting mainline linux but even running without proprietary firmware - as does their current top level SoC (RK3399, featured in Pine64's ROCKPro64).
But the point is your looking at a SoC with A53's, which is a 9 year old in-order design. Or for that matter, the rk3399's A72's which is a 5 year old design. That puts them at somewhere between an 6x->4x (geekbench) slower per core vs a modern smartphone depending on which benchmark you compare.
Then you add in the overhead of not being a mobile optimized OS, and your also burning massively more power.
The market share for these phones will remain geeks who want to have a more "open" phone and are willing to deal with a slow, buggy, inefficient device.
Frankly, this won't change until Qualcomm/etc decide to make their SoC's more open, so that smaller companies can build products like these without signing piles of NDAs and shipping android BSP kernels. But then again, that might cut into their business because they won't be able to deprecate 2 year old phones by simply refusing to provide security updates.
Most geeks would be better off picking up a year or two old phone and running lineageOs. At least the devices tend to work, even if they have a dozen or so proprietary blobs.
Yes, unfortunately you're right in that there's lots of room for improvement. Nevertheless I'd call the rk3399 a decent SoC, but then for me the fact that it runs without proprietary firmware is certainly more important than pure performance. What I'd really like to have though, is more RAM - I run my desktop on the rk3399. And I already use the PinePhone as a daily driver although I see that it's not there for most of the people.
But maybe this could not only change at the big vendors' whim, but also if more people express their wish for systems that are less locked in by changing their priorities.
> And Rockchip SoCs have a quite decent track record of not only supporting mainline linux but even running without proprietary firmware - as does their current top level SoC (RK3399, featured in Pine64's ROCKPro64).
Last time I tried, RK3399 was dog slow to boot on Pinebook Pro (only thanks to https://gitlab.com/DeltaGem/levinboot is this changing) and development once Google stopped doing it seems almost entirely stagnant. Just look at ATF history, or U-Boot history, etc.
Pinebook Pro doesn't suspend to ram to this day. Only whatever Google implemented for their chromebooks works.
U-Boot has no business taking > 1-2s to boot PBP. More than that is kinda ridiculous. I was shocked seeing it take 8s when I first booted Manjaro. (My allwinner boards boot in ~2s, and those are all way slower than RK3399) With some older levinboot version, PBP boots to initramfs FDE password prompt in ~4s [1]. It's probably even faster now. I wish it would take 2s to that prompt, because then I can open PBP, enter password right away, and then just do something else waiting for the desktop to load. But 3-4s is already pretty nice.
At least suspend to idle works as a sort of replacement for suspend to ram. PBP can stay for long enough in that state, so it's usable on the go even without suspend to RAM.
Haven't heard of levinboot yet, LGTM, thanks for the hint!
Where do you get your entropy from? Does levinboot provide some (enough?) to the kernel? Right now I delay booting via a sleep in the initramfs so that I have time to randomly press as many keys as possible to get crng initialized before cryptsetup is called. Configuring my U-Boot build to provide entropy to the kernel is still on my to do list, haven't looked into it yet and don't know whether it already does or not. At least last time I checked I observed that KASLR didn't work due to missing entropy (the artificial delay won't work here as KASLR happens way before calling init).
I like to build things from source, but I'd also like to hear more details about the problems encountered.
The whole tiers thing is first of all a chicken and egg problem. Which probably could be solved faster by keeping Drew invested. I also constantly have to fiddle with rust's lack of support for T2 (armv7-linux-musleabihf in the past and aarch64-linux-musl now, having given up on the former) and I agree that this aspect sucks and hinders adoption. And furthermore it defies one of rust's main goals, security: With something like ME/PSP having unrestricted access to whatever they want, why bother that much about memory safety?
> If you are familiar with work done in the FOSS community to procure devices with fully open firmware, the name Synopsys may ring a bell here. Synopsys is a company which sells IP blocks[...]. One of their IP block products is a DDR4 memory controller and PHY solution, which appears popular and which is found in a number of SoCs. It is however a known fact that Synopsys's DDR4 PHY requires a Synopsys-issued firmware blob to operate; therefore, chips which use the Synopsys DDR4 PHY inevitably have firmware blobs in their boot path
> Probably the most notable SoC containing a Synopsys DDR4 memory controller and PHY is the NXP i.MX8M series, which was for example selected by Purism to form the heart of their Librem 5 phone.
Is this (still) true? I just tried to find any binary blobs in U-Boot source tree [0], but didn't find any.
At least for some Rockchip SoCs (RK3399), which I assume also use Synopsys IP DDR PHYs, I know that it's not necessary to provide anything else apart from upstream U-Boot and Arm Trusted Firmware (ATF) [1]. And AFAICT current mainline U-Boot can initialize NXP i.MX8M's DDR PHY, too.
I've personally created a BSP and did board bring-up on a platform based on the NXP LS1046A (one of their ARM based QorIQ SoCs). That chip uses DDR4 and didn't require any blobs (aside from the Ethernet hardware). All of the memory controller registers were fully documented too. The DDR4 controller there was very similar to the DDR3 controller on their older T2080 PPC chip that I've worked with.
In fact, one of the most annoying parts of the board bring up was determining what data strobe delay values to use via a process of trial and error.
I'm not sure why NXP would use a different DDR4 controller for the iMX that requires a blob while their other chips don't.
Author here. It wouldn't particularly surprise me. If I had to guess why other NXP products didn't go with Synopsys, it might be related to the fact that the i.MX8M is intended to be suitable for mobile applications therefore support for LPDDR4 is more important. In fact Synopsys's DDR4 PHY can support both, I believe (IIRC) dynamically, with i.MX8M chips which can be used with either. There are other DDR PHY IP providers (e.g. Cadence) which don't require blobs. Plus these are probably separate business units.
I've confirmed the presence of these blobs in i.MX8M BSPs myself, as has Purism, see their blog post.
After digging through some resources on the web I now believe that this is indeed still true - at least I couldn't find anything to the contrary (apparently you have to provide the firmware blob outside of U-Boot, which then loads it at runtime). This probably means the Rockchip SoCs I was talking about don't use Synopsys IP for the DDR PHY (although they tend to use a lot of Synopsys IP for all kinds of other components).
I wonder how I could have missed that issue with the Librem 5 till now.
Author here. This is correct. There are other DDR PHY IP providers such as Cadence, which did not elect to require firmware blobs in their design. You could say that the Synopsys DDR4 PHY design is a little overengineered. I've confirmed the presence of these blobs in i.MX8M BSPs myself. See also Purism's blogpost discussing this very subject.
Thank you for all your efforts. The way you appear to have handled google's unjustifiable action is really impressive. Clearly that's one of the main reasons to be optimistic that matrix has a bright future - if I was in charge it certainly wouldn't. Due to incidents like this I simply ditched google completely. (OK, to be honest I sometimes watch videos on yt but without having an account.)
As you said it depends on the context, I agree, but thus the chances someone's using a generic query to find vendor independent resources like blogs are not zero. With regard to the given example "nrf wifi", I'd prefer DDG's results as I usually know the manufacturer of the hardware I work with but often search for solutions to problems in context of that hardware.
Furthermore depending on familiarity with domain names it's possible to deduce the manufacturer's website from GP's 9th result on DDG.
https://www.politico.eu/article/the-scandal-hanging-over-urs...