Posted by sandebert 8 hours ago
Fixing this is a noble goal but won't sell a lot of devices by itself. And it will only fix the one specific hardware configuration used by Flipper. This seems to be the only interesting part of the project and the actual hardware is otherwise completely uninteresting. Not sure how they expect to succeed here.
https://www.kickstarter.com/projects/getpebble/pebble-2-time...
This reminds me of that in a good way – a small Linux device that doesn't have to maintain a screen all the time (power) or focus on real-time but has physical buttons, connectivity, a microphone and a sealed case so it can be thrown in your pocket would be... an absolute dream.
Counter to some others here, I would buy this at whatever cost if it lived up to that intent!
Confirmed in the Dev Portal. https://docs.flipper.net/one/hardware/wifi-bluetooth
to add on to this: you can definitely make great UI's for small screens and unconventional controls -- Playdate [1] builds their UI around a physical crank on the device, and it feels fun to use it :)
The ambitious goals list is interesting because it reads like someone who's been burned by the exact problems they're trying to solve. Mainline Linux kernel support means they've dealt with downstream kernel hell. Pushing vendors to open binary blobs means they've fought with NDA-encumbered firmware. Building a custom GUI framework means they've tried to use existing ones and hit walls.
The co-processor architecture (MCU + CPU) is the smartest design decision here. It means you get real-time I/O handling on the MCU side without the latency and determinism issues you'd hit trying to do the same on a Linux userspace process. It's how serious embedded systems work, and it's why Flipper Zero was able to do things that a Raspberry Pi running Kali couldn't.
The part that concerns me is scope. Mainline kernel + open firmware blobs + custom GUI framework + hardware expansion system + co-processor architecture... that's five hard problems, any one of which could sink a company. The ask for community help makes sense but community hardware projects have a rough track record on delivery timelines. I hope they can keep the scope tight enough to actually ship.
I imagine you dump all the config registers of a running system, and then adjust everything that looks like some timing or drive strength parameter upwards till it stops working properly, downwards till it stops working, and then choose a middle value.
Do that repeatedly for every parameter pre-boot, and then use that config. Perhaps redo that every few hours or when the temperature changes.
Since this is an unencrypted binary, I'm sure it won't be difficult to reverse engineer. And it will definitely be open source sooner or later. But first, we'll try to convince Rockchip to open source it. Especially since the RK3576 has other proprietary parts, such as OP-TEE and some registers. Also it has a Cortex M0 core, which is also not documented.
Were blobs a big problem before?
However, the problem with binary blobs is that they are binary blobs: no sources, can't make changes, can't adapt them to work on a new system, can't audit them. Free folks have always argued that a computer will never be free if there are binary blobs in there
(well: the last part is not really true, there is always a way to have a custom firmware, or make an audit, but the manufacturer will do that only for elite customers. Not for open source folks.)