1. 32
  1.  

  2. 5

    Experiences like this will prevent me from buying any more devices from PINE64. The hardware has great potential but because it doesn’t receive first-party support it’s always a battle to get something that makes full use of its potential. I wrote about my experience with it when I got mine in 2018. Since then I’ve found it’s an ok headless ARM test device running Arch Linux ARM but I will avoid getting any new PINE64 hardware (having also been sucked in by the pine phone and its keyboard).

    1. 7

      Honestly after trying several of those boards - odroid c4, rpi 3-4-400, radxa rock pi 4 and couple of pine64 (h64 and rockpro64) I like pine64 the most, it was the easiest to work with even though I’ve used OpenBSD that is not extermely popular. As any other chip rk3399 and others - they have their peculiarity but that comes not from potato vendor but just from lack of a proper standartization (dtb/uefi is a thing but still requires a lot of manual interventions.

    2. 3

      I recently went through most of this agony trying to get a RockPro64 to work with OpenBSD and a PCIe NIC, and I was ultimately unsuccessful. Super frustrating.

      1. 2

        PCIe on the rockpro64 is a lot less coherent than on amd64 systems, so drivers that don’t do dma syncs correctly will have problems. I recently fixed aq(4) so it works properly on rockpro64, though I haven’t committed some of that work yet. Which nic/driver were you using?

        1. 1

          It’s a dual-port Intel 82576

          1. 1

            I’m not sure if you’re still interested in having this work, but I posted a diff here:

            https://marc.info/?l=openbsd-tech&m=165645184229510&w=2

            this hasn’t been committed yet, it’s a bit of a hack and we still need to figure out how much of it we should do properly instead.

      2. 3

        It is all potentially fixable, but it takes a lot of time and gumption to push through. There’s a lot of pieces of things out there, and putting it all together can be quite a challenge.

        Nice writeup!

        1. 1

          The whole arm board/SoC thing is a mess now. I guess we need a powerhouse of the IBM in the early PC era.

          1. 5

            https://tow-boot.org/ does that. The recommended installation approach is to install that to your board’s SPI, which can then boot generic arm64 images.

            It’s used by ~most Linux mobile distributions, and allows the distributions to publish a single arm64 image.

            1. 2

              Oh tow-boot looks really good thank you for the link!

              1. 2

                It doesn’t support Rock64 yet, but the developer recently suggested it wouldn’t be much work, and they’d give it go, if others could help verify it: https://github.com/Tow-Boot/Tow-Boot/issues/151

                Consider offering to verify, if you’re keen!

          2. 1

            I setup a RockPro64 as a router using FreeBSD and a quad port PCIe NIC and it’s working great. Only issue I had was with the on board NIC being slow.

            1. 1

              How did I figure this out? Why, through the power of friendship! No seriously, I just asked my friend and she told me to do this and it worked. I don’t know where else you’d find this information on your own.

              It’s also listed in the documentation.

              There’s a number of ways to automate this, simplest of which is probably baking a boot script into the u-boot image.

              The simplest way is something like

              => env set bootcmd 'my awesome boot command'
              => env save
              
              1. 0

                Does that count as a rickroll btw?

                1. 1

                  Nah; it wasn’t audible.