Hi, maybe I have formulated my word a way it gave way too many chance for misinterpretation. Sorry.
I did followed the way you described, but it resulted a non-booting board, only the U-boot SPL got loaded, but the u-boot (proper?) itself didn't managed to start properly. I have built an own uboot using OBSD with the correct DTB, but thats sadly didn't help either. I probably should have write this earlier. So far the only the uboot from the SDK can boot the board properly. This is an old rockchip vedored version from 2017 (with many backported patches), it uses extra scripts to prepare the u-boot image and juggles with binary blobs and fit-ing. I sadly was so far unable to replicate the setup with any newer u-boot. The uart log shows that the BL31/BL32/OPTEE tries to hand-over the control to u-boot, but it fails to emit any useful debug log over UART (eg. dead silence). I am currently analyzing what are the differences between the own-built and the vendor-ed U-boot image and try to rearrange the lego bricks accordingly. Definetely would be easier to use a fully supported board, but i have a bit of time at nights so i can hack and try things. Thanks for your support and have a great day! --Z-- Crystal Kolipe írta 2023. nov.. 19, V-n 16:56 órakor: > On Sun, Nov 19, 2023 at 10:38:57AM +0100, Mizsei Zoltn wrote: >> Btw: i have tried to flash the OBSD install image as you did in your article > > The method I described involved: > > * compiling U-Boot from source on an OpenBSD host machine. > * modifying the miniroot installer image and boot code to include the > packages for the base system on a separate MBR partition at the end. > * writing the modified miniroot image to the eMMC of the device. > * booting it and doing a regular installation of OpenBSD, overwriting the > miniroot image during the install, and using an MBR partitioning scheme. > > What you are doing seems to be completely different. > > I did not use vendor supplied U-Boot binaries, nor did I do any of the > preparation work or flashing of the eMMC from a Linux machine using special > tools for a proprietary protocol, nor did I use a GPT partitioning scheme. > > All of these things make the process more complicated and error prone, as you > have discovered. > > This board is not yet supported by the version of U-Boot in the OpenBSD ports > tree. The first step towards making it work reliably and in a way that you > have complete control over would be to compile the boot code from source on > an OpenBSD host. > > Unless you are quite familar with OpenBSD on arm devices, this is probably > not a good choice of project to be working on, and it would have been much > easier to have purchased an SBC that is actually known to run OpenBSD > already. -- --Z--
