compent

I wanted to try this with the latest Armbian 24.8.1 Noble Gnome build for the Orange Pi 5 but there were errors when attempting to run sudo add-apt-repository ppa:liujianfeng1994/rockchip-multimedia, where errors indicated that the repository isn't compatible with this latest build. Err:9 https://ppa.launchpadcontent.net/liujianfeng1994/panfork-mesa/ubuntu noble Release 404 Not Found [IP: 185.125.190.80 443] Hit:10 http://armbian.tnahosting.net/apt noble InRelease Reading package lists... Done E: The repository 'https://ppa.launchpadcontent.net/liujianfeng1994/panfork-mesa/ubuntu noble Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.

If the question was "Can I dual boot different variations of Armbian from the same SSD", then, for the most part, this would likely apply to any combination of operating systems. At present there is no way (that I have seen) that dual boot from the same source can be achieved and I would say that any expectation that Orange Pi would develop such an option should be as close to zero as you can get. Whether any third party option will be developed is anybody's guess. Something like Pinn that is available for the Raspberry Pi would be nice but with the current state of OS development from Rockchip and OrangePi as it is, he prospect of something earlier than much, much later would be akin to expecting to get blood from a stone. As for posting on the Official Orange Pi forums, note that there is pretty much zero response from the company. The forums are choc full of spam and so the only responses that you will get are from the communities that post, which are rather small. There is more frustration on there, rathe than solutions and advances. So for now, the best dual boot option is to have one OS on an NVME and another on an SD card, where you have to insert or remove the card to be the determining factor to which OS you wish to use. I'm not sure that we will see any significant development in the RK3588 that will come close to match what is happening with the Raspberry Pi 5 until at least 2025, if ever. But if you really do need dual boot from the same source right now, you would be better off with a Raspberry Pi 5 or an X86 mini PC. I did see a video on YouTube a few months back from Firefly who were supposedly unveiling a multi boot OS option that seemed to be a variant of Petitboot that can be used on some AMLogic devices but nothing seem to have materialised but perhaps worth contacting them just to determine whether the option is actually going to roll out to their own RK3588 products.

@Khadas Having asked for the steps to be specifically listed, having now solved it yourself, might it be useful to others for you to list the steps that you took to obtain a resolution?

Dbosco Thanks, that worked and to the point where login was also automatic. I'm not sure if the updates broke anything because video and webgl performance testing in Chromium didn't indicate any performance increases.

A very worthwhile discussion indeed now that there seems to be some light being seen at the other end of the tunnel. I'm not so sure that the specific USB hardware support is now in place in it's entirety. For the past few days I have been testing all of the rolling releases for both 6.1 and 6.8 kernels and the results can differ from day to day. I fully understand that the nature of rolling releases is that there are all manner of changes made from day to day, so no complaints at all as I know that things can break. The fact that we do know that the USB hardware support does now have solutions does bode well and I would imagine that it will integrate into all builds very soon. In terms of the transitioning, pitfalls and remedies, I have come across an issue with a particular build type. This week I spotted a build that was of particular interest because of the panthor and amazingfated connections , the Orangepi5_jammy_vendor-boogie-panthor_6.1.43_kde-neon-amazingfated-oibaf_desktop.img, which is now at Armbian_24.5.0-trunk.416. Unfortunately I am unable to get it to load from any trunk build. It initially boots correctly and I go though the config routine to create login and passwords etc. But when things get to the actual desktop login screen, when logging in, the screen goes briefly black, with the mouse cursor popping up and a small white bar at the top left of the screen, before being returned to the login screen. No matter how many times I try, it will not complete the login process. I know that the password is correct because if I deliberately enter an incorrect password, it is rejected with a specific message to conform this. I did then attempt to login as root but even when entering the correct credentials created during the initial config process, the credentials were rejected as being incorrect, despite them being correct. Hopefully somebody else may have tested the same and can offer a potential solution to enable me to fully test and report back on this particular 6.1 build.

Very nice and with clearly laid out installation instructions.

I tried Armbian_24.5.0-trunk.257_Orangepi5_noble_vendor_6.1.43_xfce_desktop.img but the USB port is still not accessible. The fact that there is a solution available is of course good though and will no doubt find it's way into new builds.

@Igor As Android is based upon Linux, I would have thought that a manufacturer bringing a newer kernel would bring things closer to mainline support. I could no see any release of the kernel so far, so wonder how you can know what the new SDK does and does not bring. Based on Rockchip's rather chequered history, I can certainly empathise with your views, so little would surprise me with regards to their business practices. But regardless of the angles of view, things are still clearly headed in the right direction, with your work also clearly being rather pivotal.

It boots fine into a desktop but sadly the USB-C does not yet work. Although I could plug a keyboard into the top USB 3 port, if I attempted to plug in any USB wireless dongle, for a mouse/keyboard combo, nothing is registered. I can confirm that the vertical USB port does not work either, although not surprising since it is directly linked to the USB-C. Definitely a step forward though and I have no doubt that when Rockchip release their 6.1 SDK in the next few weeks, we should see easier OS implementation.

Anything with it's own 2.4Ghz USB dongle should work because the wireless connectivity happens outside of the Orange Pi board sphere. I have a variety of them, from the Logitech 400 to the cheapest of the Rii style clones. So my own focus would be on which device has the best battery usage and which keyboards and trackpads etc seem to have the best tactile inputs, which is where carrying out some YouTube reviews will likely give you more ideas of which ones may suit your tastes and needs.

I can quite understand the frustrations of @Paulo da Silva, even though, it is not the board that is the issue, but the company, Orange Pi, who are next to useless and absent when it comes to support. They show that they are essentially, only box shifters. Whilst the (very useful) process specified by @vandyman, seems easy, when it comes to changing the boot to NVME, the menu options are written in such a manner that it can be confusing to know exactly which specific option to use. And even then, to then decide to want to boot from USB, the options have to be changed again, which then renders NVME null unless the process is run yet again. In terms of a solution, based on the line from @royk, 'With the Orange Pi 5 plus I didn't even had to update the bootloader to make it boot from NVME', this would indicate that Orange Pi corrected the boot process for the Plus model, so why not do the same for the prior 2 models? The original bootloader boot process should have been simple. 1. MicroSD card 2. USB (any port) 3. MVME That, IMO, would have satisfied most users needs and removed the frustrations. You could still have options in the config for people to modify that for their specific purposes but having an easy to understand base of priority boot ports was always the way to go. So why didn't they do it? Was it because, not unlike their vaunted and much touted Orange Pi OS, which is half baked and (still) half finished, they only put half the effort in to shove the board off the shelves? All evidence would suggest so. But with a complete absence of them making any comment, we may never know. Bottom line right now is that all real efforts are coming from and will have to continue to come from communities and users. Forget Orange Pi the company as they are nowhere to be seen in any useful and practical terms. It is somewhat ironic that they have (and were the first), to obtain Platinum support and yet there is no evidence that I can see that they have provided Armbian any service that could be seen to be even close to what might be considered such. All the promise of Orange Pi the company has become rather tarnished, following them taking an instant and decisive lead in the RK3588 SBC arena. I am sure that with time we will see more maturity for the SOC and I/O over time, which was always to be expected with a new product but as far as this vendor is concerned, they won't ever get any of my money again because they have shown what they are at a base level. If a company said hey, we are a box shifter, then you know from the start what you are going to get but when they tell you that their new product and OS combination will change everything and then doesn't even come close , how can they ever be trusted?

RK3588 isn't supported by Libreelec yet though.

There does seem to be some movement on Kodi being able to play X265 (which I believe also encompasses those with HDR) correctly. https://github.com/batocera-linux/batocera.linux/issues/9182 I'm not exactly sure what the specific github meaning of 'planned' is but I would guess that it is an indication of action being in the works.

So what are the implications for this decision? Can we be optimistic that if RK3566/68 SOC's are to get mainline kernel support then the RK3588 will also get it? Or are we looking at another SOC that will essentially remain stuck in limbo because of a stalled manufacturer kernel development?

Thank you.