OpenBSD on Pinebook 1080p?

[ab1jx]

Alright, I'm thoroughly confused.  I used OpenBSD for 15 years but only on x86.  I'm looking at OpenBSD's INSTALL.arm64 and your post and wondering what goes where.

"/usr/mdec/pine64" where is that?  Inside the miniroot?  The OpenBSD directions talk about doing a dd of idbloader.img and u-boot.itb but is that after you dd the miniroot?  Where does the real installation end up relative to this?   Where do the files in the tarball's share/u-boot/pinebook go?  They replace files in the miniroot?

I don't think I ever used a miniroot, there was a file that was an image of a floppy, I either wrote that to a real floppy or made a CD to boot from it.  I'd put the install files in a partition of the drive I was installing onto, sometimes on the CD, or sometimes did an FTP or HTTP install from a local machine I'd set up for that.  I'd assume in this case that the installer won't have a driver for the PBP's WiFi.  So put them in a DOS partition on the SD card, shell out of the install and mount it?

[rogerroger]

Alright, I'm thoroughly confused.  I used OpenBSD for 15 years but only on x86.  I'm looking at OpenBSD's INSTALL.arm64 and your post and wondering what goes where.

"/usr/mdec/pine64" where is that?  Inside the miniroot?  The OpenBSD directions talk about doing a dd of idbloader.img and u-boot.itb but is that after you dd the miniroot?  Where does the real installation end up relative to this?   Where do the files in the tarball's share/u-boot/pinebook go?  They replace files in the miniroot?

No no, that's all fair. It is confusing. I figured out what I figured out with two sleepless nights in a row. OpenBSD's INSTALL.arm64 needs a editing once-over. It is correct as far as it goes but neglects specific very important details. And getting any of the details wrong just produces a black screen  

I'll show you exactly the commands that worked for me once I can reproduce and test them thoroughly, but I will explain the missing details first.

---

The very important thing to understand is that every ARM device (or "board" in the lingo) needs a custom bootloader -- it's not like x86 where long ago BIOS was invented to unify the boot API and the same bootloader could be installed on almost any machine. These are in an external package, not the base system, and are actually split in two packages: `u-boot-aarch64` (64 bit, corresponding to OpenBSD arm64) and `u-boot-arm` (32 bit ARM, corresponding to armv7). This is actually mentioned in INSTALL.arm64 but it's easy to miss and misleading:

 To do so first install the u-boot-aarch64 and dtb packages.

(misleading too because you don't need the dtb package for the pinebook, and it's not obvious that they mean "install on a separate probably-amd64 machine")

OpenBSD 6.5 and 6.6 have been designed with pine-a64, rock64 and rockpro64 in mind; the pinebook isn't officially supported yet (but 6.7 probably will! Apparently the devs have received their orders). Again this is in the docs but easy to miss and misunderstand:

The following machines are targeted by OpenBSD/arm64:

Allwinner A64/H5
Pine64 Pine 64/64+
...
Rockchip RK3328/RK3399
Pine64 ROCK64
Pine64 ROCKPro64

So you get the bootloaders by

Code:

$ doas pkg_add u-boot-aarch64
$ pkg_info -L u-boot-aarch64
Information for inst:u-boot-aarch64-2019.10

Files:
/usr/local/share/u-boot/a64-olinuxino/sunxi-spl.bin
/usr/local/share/u-boot/a64-olinuxino/u-boot
/usr/local/share/u-boot/a64-olinuxino/u-boot-sunxi-with-spl.bin
/usr/local/share/u-boot/a64-olinuxino/u-boot.bin
/usr/local/share/u-boot/a64-olinuxino/u-boot.img
/usr/local/share/u-boot/a64-olinuxino/u-boot.itb
/usr/local/share/u-boot/bananapi_m64/sunxi-spl.bin
/usr/local/share/u-boot/bananapi_m64/u-boot
/usr/local/share/u-boot/bananapi_m64/u-boot-sunxi-with-spl.bin
/usr/local/share/u-boot/bananapi_m64/u-boot.bin
/usr/local/share/u-boot/bananapi_m64/u-boot.img
/usr/local/share/u-boot/bananapi_m64/u-boot.itb
/usr/local/share/u-boot/firefly-rk3399/idbloader.img
/usr/local/share/u-boot/firefly-rk3399/u-boot
/usr/local/share/u-boot/firefly-rk3399/u-boot.bin
/usr/local/share/u-boot/firefly-rk3399/u-boot.img
/usr/local/share/u-boot/firefly-rk3399/u-boot.itb
/usr/local/share/u-boot/mvebu_espressobin-88f3720/u-boot
/usr/local/share/u-boot/mvebu_espressobin-88f3720/u-boot.bin
/usr/local/share/u-boot/mvebu_mcbin-88f8040/u-boot
/usr/local/share/u-boot/mvebu_mcbin-88f8040/u-boot.bin
/usr/local/share/u-boot/nanopi_a64/sunxi-spl.bin
/usr/local/share/u-boot/nanopi_a64/u-boot
/usr/local/share/u-boot/nanopi_a64/u-boot-sunxi-with-spl.bin
/usr/local/share/u-boot/nanopi_a64/u-boot.bin
/usr/local/share/u-boot/nanopi_a64/u-boot.img
/usr/local/share/u-boot/nanopi_a64/u-boot.itb
/usr/local/share/u-boot/nanopi_neo2/sunxi-spl.bin
/usr/local/share/u-boot/nanopi_neo2/u-boot
/usr/local/share/u-boot/nanopi_neo2/u-boot-sunxi-with-spl.bin
/usr/local/share/u-boot/nanopi_neo2/u-boot.bin
/usr/local/share/u-boot/nanopi_neo2/u-boot.img
/usr/local/share/u-boot/nanopi_neo2/u-boot.itb
/usr/local/share/u-boot/orangepi_pc2/sunxi-spl.bin
/usr/local/share/u-boot/orangepi_pc2/u-boot
/usr/local/share/u-boot/orangepi_pc2/u-boot-sunxi-with-spl.bin
/usr/local/share/u-boot/orangepi_pc2/u-boot.bin
/usr/local/share/u-boot/orangepi_pc2/u-boot.img
/usr/local/share/u-boot/orangepi_pc2/u-boot.itb
/usr/local/share/u-boot/orangepi_prime/sunxi-spl.bin
/usr/local/share/u-boot/orangepi_prime/u-boot
/usr/local/share/u-boot/orangepi_prime/u-boot-sunxi-with-spl.bin
/usr/local/share/u-boot/orangepi_prime/u-boot.bin
/usr/local/share/u-boot/orangepi_prime/u-boot.img
/usr/local/share/u-boot/orangepi_prime/u-boot.itb
/usr/local/share/u-boot/orangepi_win/sunxi-spl.bin
/usr/local/share/u-boot/orangepi_win/u-boot
/usr/local/share/u-boot/orangepi_win/u-boot-sunxi-with-spl.bin
/usr/local/share/u-boot/orangepi_win/u-boot.bin
/usr/local/share/u-boot/orangepi_win/u-boot.img
/usr/local/share/u-boot/orangepi_win/u-boot.itb
/usr/local/share/u-boot/pine64-lts/sunxi-spl.bin
/usr/local/share/u-boot/pine64-lts/u-boot
/usr/local/share/u-boot/pine64-lts/u-boot-sunxi-with-spl.bin
/usr/local/share/u-boot/pine64-lts/u-boot.bin
/usr/local/share/u-boot/pine64-lts/u-boot.img
/usr/local/share/u-boot/pine64-lts/u-boot.itb
/usr/local/share/u-boot/pine64_plus/sunxi-spl.bin
/usr/local/share/u-boot/pine64_plus/u-boot
/usr/local/share/u-boot/pine64_plus/u-boot-sunxi-with-spl.bin
/usr/local/share/u-boot/pine64_plus/u-boot.bin
/usr/local/share/u-boot/pine64_plus/u-boot.img
/usr/local/share/u-boot/pine64_plus/u-boot.itb
/usr/local/share/u-boot/pinebook/sunxi-spl.bin
/usr/local/share/u-boot/pinebook/u-boot
/usr/local/share/u-boot/pinebook/u-boot-sunxi-with-spl.bin
/usr/local/share/u-boot/pinebook/u-boot.bin
/usr/local/share/u-boot/pinebook/u-boot.img
/usr/local/share/u-boot/pinebook/u-boot.itb
/usr/local/share/u-boot/qemu_arm64/u-boot
/usr/local/share/u-boot/qemu_arm64/u-boot.bin
/usr/local/share/u-boot/rock64-rk3328/idbloader.img
/usr/local/share/u-boot/rock64-rk3328/u-boot
/usr/local/share/u-boot/rock64-rk3328/u-boot.bin
/usr/local/share/u-boot/rock64-rk3328/u-boot.img
/usr/local/share/u-boot/rock64-rk3328/u-boot.itb
/usr/local/share/u-boot/rockpro64-rk3399/idbloader.img
/usr/local/share/u-boot/rockpro64-rk3399/u-boot
/usr/local/share/u-boot/rockpro64-rk3399/u-boot.bin
/usr/local/share/u-boot/rockpro64-rk3399/u-boot.img
/usr/local/share/u-boot/rockpro64-rk3399/u-boot.itb
/usr/local/share/u-boot/rpi_3/u-boot
/usr/local/share/u-boot/rpi_3/u-boot.bin
/usr/local/share/u-boot/rpi_4/u-boot
/usr/local/share/u-boot/rpi_4/u-boot.bin
/usr/local/share/u-boot/sopine_baseboard/sunxi-spl.bin
/usr/local/share/u-boot/sopine_baseboard/u-boot
/usr/local/share/u-boot/sopine_baseboard/u-boot-sunxi-with-spl.bin
/usr/local/share/u-boot/sopine_baseboard/u-boot.bin
/usr/local/share/u-boot/sopine_baseboard/u-boot.img
/usr/local/share/u-boot/sopine_baseboard/u-boot.itb

Out of all of these,

Code:

/usr/local/share/u-boot/pinebook/u-boot-sunxi-with-spl.bin

works for the Pinebook and the Pinebook Pro. I don't know why there's two/three copies of u-boot in that folder and why -with-spl is the necessary one, but it is.

---

The next thing to understand is that -- I'm making some educated guesses here -- instead of using a partition table the pinebook (actually the proprietary Allwinner SoC that pine is built around) looks directly at byte 8192 (aka sector 16) on disk to find a bootloader and decide if it is bootable. So whether microSD, USB or the eMMC card, you need to use this magic-numberful invocation to get a bootable disk:

Code:

ftp https://cdn.openbsd.org/pub/OpenBSD/6.6/i386/miniroot66.fs
dd if=miniroot66.fs of=/dev/sdXc  # replace /dev/sdXc with your disk
dd if=/usr/local/share/u-boot/pinebook/u-boot-sunxi-with-spl.bin \
   of=/dev/sdXc \
   bs=1024 seek=8 # 8x1kB blocks = 16x512B blocks

In fact, even if that's all you do to a blank disk it will still be bootable, it'll just boot to the u-boot prompt (and then wait for instructions). That can still be useful, just to test out the hardware.

---

What this all means for installing OpenBSD is that you just need to make sure both the install disk and the final system both have /usr/local/share/u-boot/pinebook/u-boot-sunxi-with-spl.bin installed at sector 16.

It took me many hours of reverse engineering the linux pinebook builds and re-re-reading INSTALL.amd64 to understand this simple fact.

The provided miniroot66.fs is designed for RaspberryPis. Even once you modify it according to INSTALL.amd64 as above and boot it, the install script still fails because it only supports RaspberryPis and pine64+s (source -- see md_installboot).

So to get a working system you need to do dd surgery twice, that above on miniroot66.fs before and once on the final system after the install. I copied /usr/local/share/u-boot/pinebook/u-boot-sunxi-with-spl.bin to the same disk I put the install sets on and ran `dd` with it before rebooting out of the installer.

"/usr/mdec/pine64" where is that?  Inside the miniroot?  The OpenBSD directions talk about doing a dd of idbloader.img and u-boot.itb but is that after you dd the miniroot?  Where does the real installation end up relative to this?   Where do the files in the tarball's share/u-boot/pinebook go?  They replace files in the miniroot?

It's inside the miniroot but ignore that I even mentioned it. That's the packaged u-boot md_installboot uses if it detects pine64+ (source -- see "usr/mdec/pine64/"). I thought you could use it to do the second dd surgery but I was wrong.

In case it wasn't clear from above, the only file in /usr/local/share/u-boot/pinebook that matters is u-boot-sunxi-with-spl.bin, and it doesn't replace any files; it's not meant to be part of any filesystem. It gets installed to the bootsector directly.

I'd assume in this case that the installer won't have a driver for the PBP's WiFi.  So put them in a DOS partition on the SD card, shell out of the install and mount it?

Perfect guess   . The WiFi is not working under OpenBSD. You need a WiFi dongle, or to settle for living the offline life. Give it 6 months (and maybe 50$ to the OpenBSD foundation), OpenBSD 6.7 will probably work a lot better on the PBP.

[ab1jx]

Nah, $5 USB wifi dongle, I've got several of them around.  But the drivers in the install images probably won't handle them either.  Most are Realtek, one is Ralink.  But USB is an issue here too.

That's a bunch of hocus-pocus to get it running.  But I once had a laptop with OpenBSD, Linux and Windows, Theo thought that was a bit much.

What's interesting in a greedy way is that I have 3 RPI 3Bs, an Odroid N2, a Rock64, and now the Pinebook Pro.  They all should be able to run this with different fiddling.  Sometimes I get tired of Linux and miss the simplicity of OpenBSD.  Linux can compile and run more stuff with less fiddling, usually runs faster, but it has all these hacks built onto it.

What this all means for installing OpenBSD is that you just need to make sure both the install disk and the final system both have /usr/local/share/u-boot/pinebook/u-boot-sunxi-with-spl.bin installed at sector 16.

I don't have a running OpenBSD machine at the moment.  I can probably swap hard drives in a laptop and boot an ancient version, but it will be amd64 or i386.  It's maybe most practical to set up one of the Pis first.  I have nothing that uses a disk, only SD cards.  Why I need 2 machines to work on one SD card I'm still trying to figure out.  I have 4 USB SD card readers.  BTW I figured out that when the spring contacts in the readers get flattened out so they don't work right, then you use the adapter to the bigger size SD, those contacts you can reach to re-tension when you need to.  But that's why I have 4 readers.

So you dd miniroot  and then dd the uboot into it with an offset, I was thinking mounting the miniroot rw and copying the files into it.  And when this boots it boots into the installer?  So I want to put the bulk of the install files (the tgzs) into a msdos or ext2 partition on the SD which I can get rid of later?  The miniroot and uboot are just to get the real installer running?  Certain files under DOS/Windows have to be the right sector offset on the disk (partition actually), that's why there's format /s and the sys command.  Can the installer deal with USB and an SD card in a reader?  Probably not.

[ab1jx]

I did (on a Pi)

Code:

dd if=miniroot66.fs of=/dev/sdb bs=1M                                        
dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8

And stuck the SD into my PBP. But when I power it up I see nothing of course. This isn't a VT-100 terminal that knows how to show ASCII text, it has to be turned into video first. Maybe the DTD can enable that, I didn't use it. Maybe a serial console would show what's going on. It could be sitting there in the install menu, I can't tell. Hmm.

[rogerroger]

Nah, $5 USB wifi dongle, I've got several of them around.  But the drivers in the install images probably won't handle them either.  Most are Realtek, one is Ralink.

The install kernel has all the drivers as the regular kernel. It is the regular kernel, as far as I know. So if your wifis work in the install kernel they'll work. I bet your dongles will work alright, OpenBSD has done a lot of work of the last decade getting those to work:

Code:

ral(4) Ralink Technology/MediaTek IEEE 802.11a/b/g/n wireless network device
rum(4) Ralink Technology/MediaTek USB IEEE 802.11a/b/g wireless network device
run(4) Ralink Technology/MediaTek USB IEEE 802.11a/b/g/n wireless network device
ural(4) Ralink Technology/MediaTek USB IEEE 802.11b/g wireless network device

(apropos ralink)

Code:

rsu(4) - Realtek RTL8188SU/RTL8192SU USB IEEE 802.11b/g/n wireless network device
rtw(4) - Realtek RTL8180L IEEE 802.11b wireless network device
rtwn(4) - Realtek RTL8188CE/RTL8188EE/RTL8192CE/RTL8723AE PCIe IEEE 802.11b/g/n wireless network device
urtw(4) - Realtek RTL8187L/RTL8187B USB IEEE 802.11b/g wireless network device
urtwn(4) - Realtek RTL8188CU/RTL8188EU/RTL8192CU/RTL8192EU USB IEEE 802.11b/g/n wireless network device

(apropros realtek)

Anyway, you could test easily fairly quickly by downloading amd64/miniroot66.fs, dd'ing it to a thumbdrive, and booting your regular laptop on it. If your USB dongles work there they'll work on the pine.

I don't have a running OpenBSD machine at the moment.

No worries. You can bootstrap from Linux too. When I was figuring it out I downloaded u-boot-aarch64 manually to Linux and unpacked it -- it's just a .tgz -- and got the bootloader out that way.

So you dd miniroot  and then dd the uboot into it with an offset, I was thinking mounting the miniroot rw and copying the files into it.  And when this boots it boots into the installer

Yes, precisely. Just try those two steps to see if it works and to confirm for yourself.   You'll get the blue dmesg lines pretty quick I bet.

So I want to put the bulk of the install files (the tgzs) into a msdos or ext2 partition on the SD which I can get rid of later?  The miniroot and uboot are just to get the real installer running?  Certain files under DOS/Windows have to be the right sector offset on the disk (partition actually), that's why there's format /s and the sys command.  Can the installer deal with USB and an SD card in a reader?  Probably not.

miniroot is the real installer. It's just a standard OpenBSD image with some apps removed ( like, no vi, for example ) but with a installer script added. pinebook/u-boot is the bootloader that adapts miniroot to a pinebook.

But the installer doesn't have the bulk of the content -- the tgzs. On i386 and amd64 there's install66.fs which contains the install script plus the sets; but that doesn't exist for arm64, so you *will* need a second partition to hold them. One option is to repartition your install disk once you've dd'd miniroot66.fs to it to add a second partition for the sets, which makes an elegant contained install disk; but a quicker option is to just use a second thumbdrive; a third option would mayyybe be to growfs(8) the miniroot66.fs filesystem and then loop mount it with vnconfig(8) + mount(8) and copy the install sets into it directly, but that would take some experimenting to get right.

And you should remember to include u-boot, specifically share/u-boot/pinebook/u-boot-sunxi-with-spl.bin, on that second partition.

If you can wait a couple hours, I'll have a exact instructions for you. But if you can't it's worth taking some time to experiment for yourself. If you just do the two-step dd from Linux you should have something that will at least boot on the pine, even if it's not a complete OpenBSD yet.

---

I did (on a Pi)

Code:

dd if=miniroot66.fs of=/dev/sdb bs=1M                                        
dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8

And stuck the SD into my PBP.  But when I power it up I see nothing of course.  This isn't a VT-100 terminal that knows how to show ASCII text, it has to be turned into video first.  Maybe the DTD can enable that, I didn't use it.  Maybe a serial console would show what's going on.  It could be sitting there in the install menu, I can't tell.  Hmm.

Hmm. Which u-boot-sunxi-with-spl.bin is that? Are you sure it's the one from share/u-boot/pinebook in this file: https://cdn.openbsd.org/pub/OpenBSD/6.6/...019.10.tgz ?

I didn't have to use the DTD or DTB files.

---

Wait, you used /dev/sdb? For an sdcard? On linux SD cards usually show up as /dev/mmcblk*. What did fdisk say about /dev/sdb?

[ab1jx]

It came from exactly https://ftp.openbsd.org/pub/OpenBSD/6.6/...019.10.tgz because I pasted the URL into a text file then did a wget -i on it, I keep the little text files.

Wait a minute, the url you posted is https://cdn.openbsd.org/pub/OpenBSD/6.6/...019.10.tgz, why does it have amd64 and aarch64 in it?  But I can try that one or at least do a cmp on them.

OK, they have different sha256 sums, I'll try it.  The date on yours is Dec 31, 1969, the other one too.  682536 bytes on both.

No difference in how they act.  But I did take a quick look at the dd man page because I never used the seek feature before.  The offset is the number you enter times the output block size so 8 * 1024.  I up-arrowed and copied and pasted the line into a file afterwards, it was
   dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8 
I used the same thing this time.  I'm used to the block size not being critical, but the offset is critical.

I didn't sha the actual files, just the tgz files they came out of, those are different.  I see
622f71b6897412861e3ac11b5cdefcabdbf2b078d87216dfd5c6da1c1c1c852d on the amd one, 
1e9a2a7c0678d791031bb78180404110833b48d421fd3c7d84dff985306cbfae on the other.

[rogerroger]

https://cdn.openbsd.org/pub/OpenBSD/6.6/...019.10.tgz and https://cdn.openbsd.org/pub/OpenBSD/6.6/...019.10.tgz should be the same. I think. They contain (arm64 machine code) bootloaders, so it's irrelevant whether they're in the amd64 or arm64 or i386 package repos. I linked the amd64 version because I was working from an amd64 machine at the time, that's all.

...but you're right. The files inside are different. Weird. I'll try with both too on my end.

---

First, get my microSD card and plug it in to a Linux machine. Find the card's name with:

Code:

$ dmesg | tail
[ 3090.168574] mmc1: new SDHC card at address aaaa
[ 3090.174085] mmcblk1: mmc1:aaaa SU04G 3.69 GiB

Wipe it. For me it's /dev/mmcblk1 but double and triple check with dmesg/fdisk before continuing!

Code:

$ sudo dd if=/dev/zero of=/dev/mmcblk1
^C4137601+0 records in
4137601+0 records out
2118451712 bytes (2.1 GB, 2.0 GiB) copied, 961.379 s, 2.2 MB/s

Get the u-boot:

Code:

$ wget -q https://ftp.openbsd.org/pub/OpenBSD/6.6/packages/aarch64/u-boot-aarch64-2019.10.tgz
$ sha256sum u-boot-aarch64-2019.10.tgz
1e9a2a7c0678d791031bb78180404110833b48d421fd3c7d84dff985306cbfae  u-boot-aarch64-2019.10.tgz
$ tar -zxf u-boot-aarch64-2019.10.tgz
$ ls share/u-boot/pine*
share/u-boot/pine64-lts:
sunxi-spl.bin  u-boot  u-boot.bin  u-boot.img  u-boot.itb  u-boot-sunxi-with-spl.bin

share/u-boot/pine64_plus:
sunxi-spl.bin  u-boot  u-boot.bin  u-boot.img  u-boot.itb  u-boot-sunxi-with-spl.bin

share/u-boot/pinebook:
sunxi-spl.bin  u-boot  u-boot.bin  u-boot.img  u-boot.itb  u-boot-sunxi-with-spl.bin

Install it (and only it)

Code:

$ sudo dd if=share/u-boot/pinebook/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8
666+1 records in
666+1 records out
682536 bytes (683 kB, 667 KiB) copied, 0.525471 s, 1.3 MB/s
$ sync

Take the card out of the Linux laptop and put it into the pinebook. Press the power button. After a moment this appears:

Code:

U-Boot 2019.10 (Oct 12 2019 - 14:07:37 -0600) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pinebook
DRAM:  2 GiB
MMC:   Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000'
mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

In: serial
Out: vidconsole
Err: vidconsole
Net: No ethernet found.
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
Bus usb@1c1b400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 4 USB Device(s) found
scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
=>

That's without any OS installed. That's just U-Boot.

Now let's do it again with the installer. Put the microSD card back in Linux.

Code:

$ wget -q https://ftp.openbsd.org/pub/OpenBSD/6.6/arm64/miniroot66.fs
$ sha256sum miniroot66.fs
3017920329a1d5d70a0c86f2724056c4c91eaf18041639c1d05cd54dc9c9cd78  miniroot66.fs
$ sudo dd if=miniroot66.fs of=/dev/mmcblk1 bs=1M
33+0 records in
33+0 records out
34603008 bytes (35 MB, 33 MiB) copied, 7.92513 s, 4.4 MB/s
$ sudo dd if=share/u-boot/pinebook/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8
666+1 records in
666+1 records out
682536 bytes (683 kB, 667 KiB) copied, 0.834261 s, 818 kB/s
$ sync

Take the card out and put it in the pinebook and reboot (by holding the power button until it goes off, then pressing it again, in case that wasn't obvious)

This time u-boot will say

Code:

Found EFI removable media binary efi/boot/boota64.efi

and will jump into OpenBSD's boot(8). Here there's another missing detail that I forgot, but which was mentioned earlier in the thread. You MUST type at that prompt

Code:

boot> set tty fb0
boot> boot

otherwise the console goes to the serial port (com0) and you'll get a black screen. You have to type this every time you boot, but I'm hoping to make it permanent with /etc/boot.conf.

---

For good measure, I'll try with the amd64 package:

Code:

$ rm u-boot-aarch64-2019.10.tgz
$ rm -r share/
$ wget -q https://ftp.openbsd.org/pub/OpenBSD/6.6/packages/amd64/u-boot-aarch64-2019.10.tgz
$ sha256sum u-boot-aarch64-2019.10.tgz
622f71b6897412861e3ac11b5cdefcabdbf2b078d87216dfd5c6da1c1c1c852d  u-boot-aarch64-2019.10.tgz
$ tar -zxf u-boot-aarch64-2019.10.tgz

First, I'll clear the old bootloader by replacing it.

Code:

$ sudo dd if=share/u-boot/pinebook/u-boot.bin of=/dev/mmcblk1 bs=1024 seek=8
589+1 records in
589+1 records out
603409 bytes (603 kB, 589 KiB) copied, 0.218486 s, 2.8 MB/s
$ sync

Since this was a u-boot/pinebook bootloader, it did actually boot and get to the boot(8) prompt and I could even `set tty fb0`, however `boot` failed, it couldn't find any disks.

Then I replaced it again with the correct bootloader:

Code:

$ sudo dd if=share/u-boot/pinebook/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8
666+1 records in
666+1 records out
682536 bytes (683 kB, 667 KiB) copied, 0.233606 s, 2.9 MB/s
$ sync

and this one (once I `set tty fb0`'d again) work just fine.

---

I'd check into your dmesg. I'm pretty sure your SD card is not /dev/sdb. You probably just wrote the installer to the wrong disk. And did you `sync`?

[rogerroger]

[ TODO: describe creating a disk with the install sets ]


In the installer, once the install script is finished, I was able to finish the surgery with a bit of dense magic:

Code:

# (cd /dev; sh MAKEDEV sd0)
# (cd /dev; sh MAKEDEV sd1)  # the install disk doesn't come with /dev/*sdX* defined
# (cd /dev; sh MAKEDEV sd2)
# dd if=/dev/rsd0c bs=1024 count=666 skip=8 of=/dev/rsd1c seek=8
# sync
# reboot

This copies the u-boot directly off the install disk (sd0) and onto the target system disk (sd1) instead of using a file. A file would be more obvious but this works too.

And for the last step, reboot, pop out the SD card so that it *boots into the new system*, remember to run `set tty fb0` and `boot` at the `boot>` prompt, and then login and as root and

Code:

# echo "set tty fb0" >> /etc/boot.conf
# reboot

That should give you a fully booting and fresh OpenBSD laptop. Then it's just up to installing packages and configuring it like you like.

[rogerroger]

One last comment for the night: bizarrely, `startx` fails with

xf86OpenConsole: No console driver found

However, following @elewarr's tracks, `rcctl -f start xenodm` or `rcctl enable xenodm; reboot` Just Works. What gives? What's that about?

EDIT: answered my own question: it's a perms thing. `doas startx` works but `startx` under my regular user account doesn't. xenodm is started as root. I ran

Code:

ktrace X # let it crash
kdump | less

and scrolled down until I saw that it was trying to open /dev/ttyC0.

I did

Code:

chown $USER:tty /dev/ttyC0

because that's what my amd64 machine has (at least while I'm logged in on that tty?). Then `startx` gave a new error: "/dev/ttyC1: Permission Denied", so I did

Code:

chown $USER /dev/ttyC1

too, and after that `startx` worked.

..weird. I don't understand why.

Oh but the mouse is broken. argh.

[ab1jx]

I won't have time to do it for a few hours but what if I record the MAC address on one of those wifi adapters, then plug it into the pbp, power it up, look for that MAC address in my DHCP leases?  Might get me an IP address.  At least it might show if the machine's crashed or not.

Well, that didn't work, I don't see it in arp or in the leases.

I'm on a Pinebook Pro, Rockchip, 14 inch 1920x1080, delivered 1/13/2020, BTW, not 11 inch or older models.  So there both old and new models in both sizes I think.  This is closely related to a Rock64 Pro I think, but it's Rockchip, not Allwinner.