Hacker News new | ask | show | jobs
by drosan 1472 days ago
As marktangotango mentioned - the deal is roughly the same for all arm boards. Usually there is a lot of tinkering required, and boot process is convoluted and not standartized at all; and it is usually always up to the community to develop/adopt lots of that things.

Raspberry Pi feels more "polished" precisely because of that too - the active community means active project. And even then it is not free of hardware-backed errors and failing points.

Charging ICs are finicky things on its own - the risk of frying the board/device is always there.

So "landmines" are actually always present - get any random board like Radxa and try deviating even a little bit from "stock" GNU/Linux distribution and its outdated kernel, horrendous patches and binary blobs - and you'll get barely working hardware too.

In my experience the best outcome usually comes from developers being as open as possible; meticulously documenting and publishing everything related to the product, circuits and all.

p.s. Sheer manpower needed to fully QC and maintain at least PC-grade quality of circuitry of that level has to be comparable with said PC vendors employments, hundreds of people if not more. Pine64 and similar vendors operation is small, especially in comparison; they don't move product in that amounts.

p.p.s. being unable to boot from emmc on rk3399 device is new to me to be honest, if you drop by #pine64 irc channel on their server me and local folks can most certainly try to help with that.

2 comments

I vouched for this comment. And all your comments are [DEAD] aka shadowban. You likely did something to piss off the admins. Either protest or create a new account.

The problem that you bring up in a meta- way is that these are the consistent responses I get from the open source devs. And as much as I appreciate the OS devs doing the hard stuff, basic functionality and hardware defect repair should ABSOLUTELY be part of Pine.

For example, when the PP keyboard has a bad support for the pogo pins, this should have been stopped, recalled, and fixed correctly. Instead, nothing. The open source devs said to use paper to shim it https://www.reddit.com/r/PinePhoneOfficial/comments/svc38r/v...

I mean, what the hell? Im glad fellow harmed users found a way forward, but seriously this is only 1 issue that makes Pine a shitshow to deal with.

And "Charging ICs are finicky things on its own - the risk of frying the board/device is always there." dismisses the fact that if a company wants to sell a product, "NOT CATCHING FIRE OR RELEASING SMOKE" is like the baseline here. Worst yet, early PP keyboard adoptees weren't even told this was an issue. Leaflets were only included later. But still, this is a shit situation - you have 2 USB-C ports. There should ne no situation where 1 port = hardware destruction. Again, make the hardware right or don't fucking do it.

Feels more polished? I absolutely do not understand that, some of the more social media friendly Pi projects involve building cluster file systems with them. Seems very nitty gritty to me.

What's deviating from stock GNU/Linux? Adding a third party repo?

'"stock" GNU/Linux distribution'

GP is saying that deviating from whatever the vendor gives you will cause issues, and saying that most vendors will give you garbage.

Beyond how that is contradictory, are you saying that the vendor is providing a non-mainline version of Linux that can't be updated because the driver API will be broken upon update?

Or am I misunderstanding you?

Hardware-level stuff/embedded is outside of my area of expertise, but as I understand it you are pretty much correct.

You see this a lot with Android devices and custom images. There will be drivers that are only provided in the vendor blessed image, patches that are difficult or impossible to port to new versions of the kernel, etc.

Again, this is me looking in from outside. Most of my information has come from reading about other peoples experience with hardware, especially android devices but also other embedded chips.