> From: Slava Voronzoff <slava.voronz...@gmail.com> > Date: Wed, 24 Apr 2024 11:58:39 +0300
Sorry, but this is probaly bad advice: > Hi, Evan > > In situations like this (I too like to play with > not-very-mainstream/noname boards) I have little tricks: > 1. You can use official linux images to extract needed parts of data > (they all just DD-ble with some addresses) or just get it from the > booted system. What "official" Linux image? Vendors typically ship heavily modified ancient versions of U-Boot together with device trees that do not follow the device tree bindings used by upstream Linux. As a result, OpenBSD will not work very well, or won't work at all. So my advice is to use U-Boot from OpenBSD ports/packages. I've recently done quite a bit of work to update U-Boot versions for various SoCs and add more boards. If your board is not yet included, try to add support for it by starting from a similar board that is supported. For some SoCs, U-Boot now provides a "generic" board configuration that should work for boards that follow the SoC vendor's reference design. In that case you probably need to manually load a device tree for your specific board to make it fully functional though. > 2. Most of the time simplest method is just boot from the official > image, drop to uboot, boot from OpenBSD usb flash and install on top > of SD with the official image. 99% sure OpenBSD will not rewrite > bootable needed parts of sd/mmc True. Even if you select the "(W)hole disk" option in the OpenBSD installer, the bootloader bits for most SoCs will remain untouched. The most notable exception here is the Raspberry Pi. > 3. Often you can find separate bootloader files near official images. > 4/ Also you can find/patch a dtb file and load it from OpenBSD's > bootloader with machine dtb <file.dtb> before loading OS (EXTREMELY > USEFUL!) One potential issue with this approach is that certain modifications to the device tree normally done by U-Boot are not applied in this way. Fixing that issue is on my list of things to do.
