Hacker News Reader

> Or that the rockpro64 is said to be able to boot with eMMC rather than microSD. But when you try to, it doesn't work. Back to microSD. Weirdly enough Ive heard some users whose boards DO work with eMMC. None of mine did. Again, since docu is terrible, I copied the command that works and didn't for me. Seems like bad hardware versions or something?

I would wager that you're simply running an old and incapable version of u-boot, or that you've somehow "misinstalled". My RockPro64 and my PineBook Pro - which is pretty much the same platform - boot from eMMC just fine. It cannot boot directly from the NVMe port, however.

Same. I “just” had to use a different u-boot version and eMMC booting works just fine now. The default won’t work for whatever reason.

"It cannot boot directly from the NVMe port, however."

My RockPro64 boots directly from NVMe.

I use Tow-Boot, and my initrd has the modules needed to boot NVMe.

You sure it's not booting kernel from eMMC, and the rest of the userland stored on NVMe? Admittedly it's been a while since I looked into this, but this was the closes solution available at that point. I'd like to get rid of the eMMC module entirely so the setup truly is "NVMe only" without having to keep the eMMC module around just for initrd and the kernel. Supposedly they can boot from the internal SPI flash somehow, and then "jump" to NVMe, but I don't know how.

> You sure it's not booting kernel from eMMC, and the rest of the userland stored on NVMe?

I'm sure, since my RockPro64 has no eMMC (I didn't order one, and I just checked that my eMMC slot is empty).

I have Tow-Boot installed on my SPI, which when booted jumps to the NVMe device.

My initrd has modules "nvme pcie_rockchip_host phy_rockchip_pcie" which are needed for Linux to detect and then mount the rootfs.

  $ mount
  [...]
  /dev/nvme0n1p1 on / type ext4
  /dev/nvme0n1p3 on /boot/efi type vfat
  [...]

That's great. Do you know where I can find instructions on how to flash Tow-Boot to the SPI and how to configure it?

Add.: never mind, I found that Tow-Boot has excellent documentation for the whole procedure. Thanks for the heads-up on Tow-Boot.

Tow-Boot is great, and slowly being adopted by distributions (typically mobile distributions) as the way to do firmware/booting on aarch64.

I'm a previous owner of a few Pine products but I just can't get even a little exited about any of their hardware anymore for most of the reasons you mentioned. Pine supporters will point out that their site claims they don't develop or support software and while that is actually true, their entire software stack is held up by a handful of people doing the work for little gratitude and no pay.

It's quite a shame how much better their hardware could be if they hired someone to do the in-house work for stable OS support on any of their devices.

> It's quite a shame how much better their hardware could be if they hired someone to do the in-house work for stable OS support on any of their devices.

Perhaps, but is there any company doing that for aarch64 devices?

The Pine64 development community are making cross-distro improvements to aarch64 support, e.g. Tow-Boot.

Drew Devault had a good commentary on it: https://drewdevault.com/2022/01/18/Pine64s-weird-priorities....

Side note: Drew's latest post depresses me.

A sizable portion of software that I use literally on a daily basis was written by Drew.

He has strong opinions, and has spoken overly aggressively in support of them in the past - but pulled a Torvalds, recognized he was doing poorly in that way, and improved.

On top of that, he's on a very short list of developers that I am reasonably confident will only write software that goes out of it's way to be user _respecting_, as opposed to user ambivalent.

E: Fix a typo

I read this as confirmation that "hardware is hard". Ie most of these premade SBCs have issues of this sort. The exception being the raspberry pi's generally. The alternative is designing and laying out the PCB yourself and with DDR3/4, that's a huge job (my understanding at least I've never done it myself).

It's not the PCB that is hard. It is interfacing with all the interface ICs, each having their own quirks and proprietary drivers, etc. At a certain point, reading data sheets becomes like filling out tax forms, extremely boring work.

That assumes you can even get access to the documentation. Some vendors are very bad about not giving up the necessary documentation to develop drivers, especially if you don't speak Chinese. Or they demand you sign a NDA before you can read the docs, and aren't interested in even talking with you if you aren't about to buy at least 150k chips in your initial order.

> And they even sell dead and irrecoverable (without soldering/hacking) on devices like the pinephone keyboard/battery.

This is such a shame too, because something that gives me a decent portable keyboard with Linux linked to mobile Internet, and proper Kernel mainline drivers meaning it's less likely to be abandoned after a year, was so enticing. But the same happened me - my P64 keyboard would connect but the battery wouldn't make pin contact with the phone, so charging the device was impossible without disassembly.

I understand it is low cost, but these rough edges impede enjoyment.

But, as an exception, I can say that the PineTime works wonderfully now. The PineBook Pro also is more or less functional with any Linux distro that targets it.

I like it because it's dev hardware. They publish schematics, and their stuff is cheap enough to buy on a whim.

There's an active community to get involved with on hardware hacking.

> And they even sell dead and irrecoverable (without soldering/hacking) on devices like the pinephone keyboard/battery. Or how dare you use the phone usb-c port when on the keyboard - if you do, you fry the charging chip and possibly the battery.

Yes, this was bad.

> Or that the rockpro64 is said to be able to boot with eMMC rather than microSD. But when you try to, it doesn't work. Back to microSD. Weirdly enough Ive heard some users whose boards DO work with eMMC. None of mine did. Again, since docu is terrible, I copied the command that works and didn't for me. Seems like bad hardware versions or something?

eMMC and NVMe booting is supported by the hardware. The firmware might not, but the firmware is writable, and the developer community is working on unifying this.

State of the art for Linux distros is to install Tow-Boot on your SPI flash, and then a UEFI OS.

I'm happy with all my Pine64 devices, have an original PineBook and a Quartz64.

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.

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.