Does the article seem AI-written/assisted to anyone else?
Some parts that stood out to me:
> A phone camera is not a single device. On Qualcomm SoCs, the capture path is a chain:
> The bus register base moved from 0xa00 to 0x1800, and encapsulating that offset shift accounted for most of the work.
> It gated the AHB register bus used by the whole camera complex, including the CCI. Without it, register accesses silently returned zero.
> With the wrong numbering, CSIPHY programmed a lane mask with lane 0 missing, and the PHY never locked.
> This was the main bug. Frames arrived at the right rate and size, and buf_done fired, but every pixel was zero. [...] The data path delivered frame timing, but not pixel data.
> Changing the register value from PLAIN64 (0xa) to 0x0 turned the all-zero frames into real images: the maximum pixel value was 255, the full colour-bar pattern appeared, and the violations stopped.
Sorry if not, but it seems like so much uses AI nowadays.
It is almost certainly AI-written. Very odd writing style, also the repo README is Claude-generated.
have fairphone looked into supporting GrapheneOS? what exactly is missing there other than "it's not Pixel"?
yes, yes, I know the usual song and whistle. That's why I'm saying "other than It's-Not-Pixel"
I'm asking for details
That's a pretty concrete list so it's unclear to me what you mean. They're also going to support some of the upcoming Motorola phones so it's not just pixels.
I think the short answer of what they'd need to do in a practical way is to release a phone that uses one of the latest Qualcomm processors (those have the required hardware security features), make sure they have at least 5 years of driver support and commit to keeping the phone up to date, allow for relocking the bootloater (they might already do that). And I think that's basically it, the Graphene project would be able to take things from there.
Realistically given that they tend to source older/weaker processors for reasons related to their goals it's unlikely they would source a processor with the required security features for their next model, but that's just a guess.
Fairphone hasn't talked about GrapheneOS at all, instead opting to be in bed with Murena and /e/os, so I doubt they've even bothered to read the list of hardware requirements. They didn't bother with the Fairphone 6, which was released barely a year ago.
>GrapheneOS smearing Fairphone as not secure in 3..2..1..
GrapheneOS would love to support more devices, that "smearing" is explaining that a company doesn't make secure devices, which is completely correct criticism.
Fairphone for various reasons is not able to or willing to achieve the hardware requirements. It's not easy to create some of the worlds most secure devices.
GrapheneOS smearing Fairphone as not secure in 3..2..1..
I wish all smartphones were as easily repairable as Fairphone. The entire battery care stack would become unnecessary.
It would take extensive work to achieve the hardware requirements and the capability for an OEM that isn't able to develop their own chips with Memory tagging enforcement (mte) which the Snapdragon 8 Elite used in the upcoming Motorola phones will have. It won't be cheap and it won't be easy.
Google has set the bar high with their security features.
I wish one day I could do cool stuff like that. Kudos!
Good to see this! Love Fairphone!