This project is not affiliated with OrangePi, it's my personal project and I purchased all the needed hardware by myself.
This is only bootloader image, the bootloader should work regardless of the distro you're using. However, some distros tend to hack their own u-boot booting scheme and does not follow U-Boot Standard Boot, including OPi's official images, and many of those popular "ARM-friendly distros".
So, unless you know the distro you would boot with these bootloader images stick to the mainline booting scheme, you should not rely on the images here. And if you insist on doing so, remember to adapt the booting configuration to the standard boot scheme.
If you're using my pre-built Arch Linux ARM images then the bootloader should work just fine, as I always follow the standard boot scheme.
You can download rkloaders for opi5 family from the nightly release page, they're built and pushed everyday and always contain the latest BL31, DDR and u-boot.
The downloaded images are compressed with gzip, and you'll need to decompress them before using them.
Vendor images (same image for SPI/SD/eMMC) and mainline SPI image are all 4MiB without compression. They should be stored at the beginning of your SPI/SD/eMMC, without offset.
Mainline SD/eMMC image is 13 MiB without compression (same image for SD/eMMC, both with -sd suffix), it shall be stored at the beginning of your SD or eMMC user area.
All of the images contain GPT partition tables and some reserved partitions in them to hint on areas not safe to allocate partitions on. But the partitions are only for hint and only needed on SD/eMMC. Erasing them is OK, as long as you keep the unsafe areas intact.
Specially, there are dedicated idbloader and u-boot.itb images that you'll only need if you want to partition the SD/eMMC by yourself and then assemble the bootloader image in place.
For mainline SPI and vendor SPI/SD/eMMC images (4MiB), the GPT table is like the following:
label: gpt
label-id: CDE728D2-D8FE-2F4D-A850-0700BE72F4B3
device: rkloader-vendor-v2017.09-rk3588-orangepi_5_plus-r31.7f7ff61a-bl31-v1.45-ddr-v1.16.img
unit: sectors
first-lba: 34
last-lba: 8158
grain: 512
sector-size: 512
rkloader-vendor-v2017.09-rk3588-orangepi_5_plus-r31.7f7ff61a-bl31-v1.45-ddr-v1.16.img1 : start= 64, size= 960, type=8DA63339-0007-60C0-C436-083AC8230908, uuid=60AFF2C4-E5DE-5545-88DE-D0EAAA507162, name="idbloader"
rkloader-vendor-v2017.09-rk3588-orangepi_5_plus-r31.7f7ff61a-bl31-v1.45-ddr-v1.16.img2 : start= 1024, size= 6144, type=8DA63339-0007-60C0-C436-083AC8230908, uuid=52AB3A99-3B2E-F84C-97A4-39FDD1788763, name="uboot"
For mainline SD/eMMC image (13MiB), the GPT table is like the following:
label: gpt
label-id: AEA227E4-03AB-4121-A080-89F4E98C57A9
device: rkloader-mainline-master-orangepi-5-plus-rk3588-r92661.d097f9e129-bl31-v1.45-ddr-v1.16-sd-emmc.img
unit: sectors
first-lba: 64
last-lba: 26590
sector-size: 512
rkloader-mainline-master-orangepi-5-plus-rk3588-r92661.d097f9e129-bl31-v1.45-ddr-v1.16-sd-emmc.img1 : start= 64, size= 8000, type=8DA63339-0007-60C0-C436-083AC8230908, uuid=87D7DE44-9EDE-468C-A5D7-C3D2F8598F6D, name="idbloader"
rkloader-mainline-master-orangepi-5-plus-rk3588-r92661.d097f9e129-bl31-v1.45-ddr-v1.16-sd-emmc.img2 : start= 16384, size= 8192, type=8DA63339-0007-60C0-C436-083AC8230908, uuid=9F496685-FAC8-4814-80C1-21589BE2537D, name="uboot"
As long as you don't create a new table, the existing partitions should prevent you from creating partitions on the unsafe areas.
In fact, these partitions are allocated way larger than their underlying data. For 4MiB, the actual unsafe area is only the first ~2MiB, and for 13MiB, ~9.3MiB. I created them larger than actual data for future-proof.
In other word, truncating the image, or re-creating partitions overlapping the existing partitions are both OK, as long as the underlying data are intact.
You should write the decompressed image into SPI, SD or eMMC, without any offset. For SPI, the image might seem larger but as the data is only 9.1MiB you don't need to worry about the truncated tail.
As long as there's at least one device containing rkloader then your device should boot, no matter it's the SD card, the eMMC, or the SPI flash. And as all of the opi5 family came with an on-board 16MiB/128Mb SPI flash, I'd always recommend using that for rkloader, to save space on your main system drive.
Check the user manual of opi5/5b/5plus if you want to write under another Windows/Linux device.
On the device itself, do it like follows:
- Zero-out the SPI flash before writing to it (
flash_eraseis from packagemtd-utils):flash_erase /dev/mtd0 0 0 - Write the rkloader image to it:
dd if=rkloader.img of=/dev/mtdblock0 bs=4K
Note that:
- Writting to SPI flash is very slow, ~60KiB/s, take patience
- The erase block size of the on-board SPI flash is 4K, you can omit
bs=4Karg but the default 512 block size would result in 8 writes to the same block for one 4K chunk of data, killing its lifespan very fast.
It's always recomended to write the rkloader before you partition the drive, as they contain partition hints on unusable space:
# sfdisk -d rkloader-3588-orangepi-5-bl31-v1.38-ddr-v1.11-uboot-70b68713.img
label: gpt
label-id: A56EECCE-C819-4B6A-9C8A-3DD2DA5A5581
device: rkloader-3588-orangepi-5-bl31-v1.38-ddr-v1.11-uboot-70b68713.img
unit: sectors
first-lba: 34
last-lba: 8158
grain: 512
sector-size: 512
rkloader-3588-orangepi-5-bl31-v1.38-ddr-v1.11-uboot-70b68713.img1 : start= 64, size= 960, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=ED109328-4281-42F8-9F41-E229F38C4973, name="idbloader"
rkloader-3588-orangepi-5-bl31-v1.38-ddr-v1.11-uboot-70b68713.img2 : start= 1024, size= 6144, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=2162DE6C-AE90-4808-BC19-570D524FCB48, name="uboot"
As such, just write the image to your target image, then allocate your partitions with 4 MiB / 8192 sectors offset starting from partition 3, and you're safe from corrupting the rkloader.
Your result partition table would be like the following:
# sfdisk -d /dev/mmcblk1
label: gpt
label-id: BB3FDB43-B5B7-4246-A919-BE81F982EE19
device: /dev/mmcblk1
unit: sectors
first-lba: 34
last-lba: 488554462
sector-size: 512
/dev/mmcblk1p1 : start= 64, size= 960, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=2AFE2EC3-BF29-4066-8287-E99F2C85EE09, name="idbloader"
/dev/mmcblk1p2 : start= 1024, size= 6144, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=6256FD76-DA9F-4DDE-B499-374B29A6B65B, name="uboot"
/dev/mmcblk1p3 : start= 8192, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=1B233D55-9FFA-44B7-BBDF-0DDA8B9E7C51
/dev/mmcblk1p4 : start= 212992, size= 488339456, type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE, uuid=3125F455-A424-44F0-ACD9-1843331FA001
Specially, mark your boot partition (in this case partition 3) as EFI system partition (type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, in fdisk it's part type 1 when using t command), so the bootloader would know to find boot configs/kernel/initramfs from it.
In your system, the partition would be mounted like this:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk1 179:0 0 233G 0 disk
├─mmcblk1p1 179:1 0 480K 0 part
├─mmcblk1p2 179:2 0 3M 0 part
├─mmcblk1p3 179:3 0 100M 0 part /boot
└─mmcblk1p4 179:4 0 232.9G 0 part /
This is not recomended as the partition table inside the rkloader image would overwrite your existing part table. But you should still be able to work around it as long as your partitions start after the fist 4MiB:
- Dump your existing partitions with
sfdisk -d:sfdisk -d /dev/mmcblk1 > old_parts.log - Write the rkloader
If
dd if=rkloader.img of=/dev/mmcblk1 bs=1M count=4ofis a disk image, also addconv=notrunc - Get the current partitions
sfdisk -d /dev/mmcblk1 > loader_parts.log - Modify the current partitions, append your existing partitions in
old_parts.logafter first two parts inloader_parts.log, to get your newnew_parts.log - Apply the new partition table:
sfdisk /dev/mmcblk1 < new_parts.log