EDIT: failure;

I compiled TF-A from https://github.com/TrustedFirmware-A/trusted-firmware-a for BL31 and got ROCKCHIP_TPL from https://github.com/rockchip-linux/rkbin.

I compiled them and got a sort of warning-alike that OP-TEE is missing but I am not sure how to deal with it.

I have tried to compile it (I am not cross-compiling here) but I got error that I do not have GCC ARMHF compiler.

Nevertheless, the message after compilation that I wrote about sentence ago did also say that basic functionality still is there so I assumed it will boot at least something.

DietPi images have tools have option to flash boot loader to SPI, It uses files from https://dietpi.com/apt/dists/all/orange … ietpi1.deb for that operation.

I moved those files from their original place somewhere else and copied ones I compiled with same name in their place.

I tried to flash it with that tool(not its fault since flashes from (*deb file mentioned above) files from have never failed), result is corrupted boot loader. Although this is not my first time.

So what I with to ask now as it is related to this process, how to update U-Boot boot loader correctly, preferably with 'dd'? This topic confuses me, I am not very well-versed in it.

That disk image file has 2 partitions:

Device       Boot   Start     End Sectors  Size Id Type
/dev/loop0p1 *      32768 1875967 1843200  900M 83 Linux
/dev/loop0p2      1875968 1878015    2048    1M  c W95 FAT32 (LBA)

The disk image file also has a u-boot bootloader in the first sectors, from 16 and up to where the Linux partition starts, plus of course the MBR first section.

So you copy over sectors 16-32767 onto your SD card so as to reuse that boot loader, like

dd if=$IMGFILE skip=16 of=$SDCARD seek=16 count=32752 conv=notrunc

Next you copy the content of the /boot directory of the Linux partition filesystem into your boot partition at top level, plus set a link /boot -> . so that u-boot can find files with a /boot/ prefix, while you still may mount that partition as /boot in the target filesystem.

Next you need to change the rootdev setting in boot.cmd (and re-wrap it into boot.scr) to be the decrypted filesystem device, something like /dev/crypt_fs perhaps. That device node will be created by initrd in its cryptsetup step.

That decrypted filesystem could well be a Devuan root filesystem. You would add a mounting of the boot partition on /boot to /etc/fstab so it is ready for kernel and/or initrd upgrades.

Note that the Image link and the initrd.img link are used in boot.cmd to be the applicable kernel and initrd to use during boot. Esp. if you want to use a different initrd you need to change that link.

You can change to use sysboot instead of load+load+load+booti and then refer to kernel and inird versions in extlinux.conf, but you will then need to first determine which dtb is in use, and be sure that there is no overlay. Perhaps it's easier to stay with booti while sorting out the decryption.

I have changed the boot partition's filesystem to ext4 (I am not sure how clear I am coming across, but just to be sure: [MMC] mmcblk0 --> mmcblk0p1 (ext4), mmcblk0p2 (LUKS) with f2fs type underneath).

I do not possess a serial cable at the moment, but I also own an SD card on which I have flashed and succeeded with https://dietpi.com/downloads/images/Die … xie.img.xz and https://github.com/manjaro-arm/opi-3b-images/releases .

Both make the system ext4-based, and it always makes them 'vanilla' without any things like ZFS, LUKS, etc. (that means that there is only one partition that is both boot and root, marked as bootable).

The Manjaro image had only extlinux.conf as its boot option, and the DietPi image had only boot.scr as its boot method. I prefer extlinux; it seems simpler.

Is there anything else I could do?
EDIT:I also see option of doing U-Boot over UEFI...It would make things easier probably(?)

It would be helpfull to get recipe for https://dietpi.com/apt/dists/all/orange … ietpi1.deb , there is also Armbian mirror with this mirror.sjtu.edu.cn/armbian/pool/main/l/linux-u-boot-orangepi3b-edge/

Perhaps it assumes an initial type FAT boot partition, which wouldn't be unusual. That would at least have boot.scr for booting, and usually that will also contain kernel and initrd. Or for example, if your u-boot supports the sysboot command you may use that for an extlinux boot from a differt, type ext partition, which then would contain the extlinux.conf configuration file as well as kernel, FDT and initrd.

(EDIT: added mentioning of FDT = Flat Device Tree, aka DTB = Device Tree Blob)

Ideally you get a serial cable for the box so you can see u-boot logging.

But my suggestion is that you first set up your box with an initial FAT partition for boot.scr, The command to use in boot.cmd would be like this

sysboot mmc 0:2 ext4 0x7ffff000 /boot/extlinux.conf

where mmc is the drive type (for sdcard), 0:2 identifies the boot sdcard, partition 2, ext4 indicates the partition type, and it's then followed by the pathname of the configuration file.
You'll then need to mkimage that into boot.scr.

EDIT: The argument 0x7ffff000 is the load address for the extlinux.conf file, and you must choose a RAM address within your actual RAM. High up in your RAM is good.

The second partition can be a single partition for everything, i.e. boot and root filesystem. Note that I've used ext4 rather than ext3, but that's only because I'm incredibly modern Though you might have better luck telling sysboot it's an ext2 even if it's an ext4, or perhaps use ext3... whichever.

EDIT: actually, you want rootfs to be encrypted, so then you'll need 3 partitions...

What I did:

I used file from linux-u-boot-orangepi3b to update bootloader,factory one is from 2017.

I made a Devuan system with the help of debootstrap using the default variant, version ceres, and I added DietPi mirrors (because they have a kernel that fits my board). I installed cryptsetup, the kernel, Wi‑Fi-related packages, added firmware blobs to /lib/firmware, and compiled booster for the initramfs tool.

I wrote boot.cmd and compiled it to boot.scr, and also wrote extlinux.conf (because I had seen one of the Manjaro ARM images boot on my board; it didn't have the syslinux package but also no boot.scr).

The bootloader still doesn't recognize the partition; there was no blinking LED. Debian system from DietPi has no problem booting, I wish DietPi images had a LUKS option.

I also tried converting the fully LUKSv2 partition to LUKSv1 to see if this was a problem, since the first article I saw was https://u-boot.org/blog/unlocking-disks … rint=print ; but I later found https://u-boot.org/blog/unlocking-moder … 2-support/ when digging through their blog, so this was not a problem by itself.