Live data from Hacker News

OpenBSD 7.1 on PINE64 RockPro64

bsandro.tech

21–28 of 28 posts

Re: OpenBSD 7.1 on PINE64 RockPro64

#21

Earlier quoted context omitted.

> 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 versio…

"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.

Re: OpenBSD 7.1 on PINE64 RockPro64

#22

Earlier quoted context omitted.

"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 someh…

> 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
  [...]

Re: OpenBSD 7.1 on PINE64 RockPro64

#23

Earlier quoted context omitted.

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 someh…

> 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…

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.

Re: OpenBSD 7.1 on PINE64 RockPro64

#24

Earlier quoted context omitted.

> 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…

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.

Re: OpenBSD 7.1 on PINE64 RockPro64

#25
Thank you for this! I feel dumb. I've been using my RockPro64 as an OpenBSD router and I have wrestled with U-Boot to recognize my hardware. I didn't know OpenBSD came with U-Boot binaries, I've been compiling from source. I'll try the official binaries.

Re: OpenBSD 7.1 on PINE64 RockPro64

#26

Earlier quoted context omitted.

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?

Re: OpenBSD 7.1 on PINE64 RockPro64

#27
The very fact that pine64 exists at all is amazing. The amount of negativity regarding software support is just expecting too much from this company in its infancy. No it's not Apple. No it's not Samsung.

But at some point... A few OS upgrades in the future.. and it all suddenly works.

I love my Pinephone and Pinephone Pro. Most exciting tech company out there atm.

Re: OpenBSD 7.1 on PINE64 RockPro64

#28

Earlier quoted context omitted.

'"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.

Post reply on HN