Image | Orange Pi 5

[Renoria]

Creating an image request

Formal device information

• Device name | Orange Pi 5
• Official product URL | http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5.html
• GitHub resource URL | https://github.com/orangepi-xunlong
• Image download URL | http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-pi-5.html

Is the SBC officially supported by the Debian installer?

• SUITABLE FOR TESTING (WIP) https://www.armbian.com/orangepi-5/

If not, is a reliable 3rd party Debian image available for this SBC?

• Debian Bullseye provided by Orange Pi https://drive.google.com/drive/folders/1F2uc8v_EQnvsNrevDihwoymOJlFgM-dZ

[Joulinar]

let me link an older request for OrangePi #4309 (comment)
At the moment we don't have the capacity to create images for Orange Pi.

[danielpinto8zz6]

@Joulinar Is it possible to submit a PR to add orange pi 5?

[MichaIng]

Can you open a PR here, so I can see what you did?

With empty you mean completely empty or kernel missing? If kernel missing, I guess the condition to install the kernel package is not met, if it is completely empty, then I guess the boot partition was not mounted when dietpi-installer ran, so that everything was written to the root partition.

[danielpinto8zz6]

Here is the PR: #6098

Yes, you're right, I've exited on dietpi-installer, didn't tought it was needed

[danielpinto8zz6]

@MichaIng in the dietpi-builder, when the dietpi-installer opens, I don't see the orange pi 5 option, it's probably getting the dietpi-installer from remote,
Here's the commands I run: ./dietpi-build -m 80 -d 6 -o danielpinto8zz6 -b feature/add_support_opi5
Am I missing something?

[MichaIng]

it's probably getting the dietpi-installer from remote

Indeed => #6098 (comment) 🙂

[danielpinto8zz6]

@Renoria working build in case you want to test: #6099 (comment)

[MichaIng]

Images are read for testing on our server: https://dietpi.com/downloads/images/

[danielpinto8zz6]

Working fine 👍

[MichaIng]

@danielpinto8zz6
A new overlay rockchip-rk3588-opp-oc-24ghz.dtbo has been added, allowing overclocking to 2.4 GHz (obviously), which works on Orange Pi 5 as well. With the long overlay_prefix we currently use, it cannot be selected. Shall we shorten/revert to rockchip-rk3588 accordingly?

Another change done on this particular device was to adjust the boot script so that, if no matching overlay file ${overlay_prefix}-${overlay_input}.dtbo is found, it is looked for one named only ${overlay_input}.dtbo. That way also the ones with filenames starting with rk3588 (without leading rockchip-) can be selected, adding the full filename (without .dtbo) to /boot/dietpiEnv.txt. This basically is the approach I though of for ROCK 5B where several other filenames are used so that no single prefix can catch them all. But it also becomes messy, inconsistent and unclear how to apply overlays then. Another definit solution would be to remove the prefix completely and require users to add the full filename (without .dtbo) to /boot/dietpiEnv.txt. Gives most flexibility but also allows to apply overlays which are not compatible at all with the hardware. Usually simply nothing is applied then, but in theory the CPU could be driven with a voltage it wasn't designed for, the only case that could actually damage the hardware.

[danielpinto8zz6]

Hi @MichaIng

Having no overlay prefix at all could be a little harder to maintain I guess,
What you think?

[MichaIng]

Having no overlay prefix at all could be a little harder to maintain I guess,

For us it is easiest, one variable less to handle, lookup, apply to new SBCs etc. For admins it means more text to type and probably less certainty about which overlays are supported by this SBC. One argument to keep it aligned with Armbian is the README contained in the overlays directory. It is often hopelessly outdated, incorrect or incomplete, but we are not making it better with another deviation. I just see, the README for RK3588 is empty 😄.

Okay, for now I think rockchip-rk3588 is fine. It may anyway solve itself once a mainline kernel is available.

[danielpinto8zz6]

I also think rockchip-rk3588 is the best option for now