gounthar

@TaNGSoFT@gounthar Armbian has supported u-boot spi image since its initial support for rock5b. If you are using spi flash image from radxa wiki, you will failed to boot armbian because that is not a GPT image.  There are two ways to write the spi flash image from armbian to the spi nor flash:
1, Boot armbian from sdcard or emmc first, and use nand-sata-install to install the u-boot to spi flash.
2, You can download the u-boot deb file from the repo of armbian: https://mirrors.tuna.tsinghua.edu.cn/armbian/pool/main/l/linux-u-boot-rock-5b-legacy/linux-u-boot-legacy-rock-5b_22.08.6_arm64.deb. Extrat it using `dpkg -x linux-u-boot-legacy-rock-5b_22.08.6_arm64.deb`, and find the spi image file `rkspi_loader.img`, and write it to spi flash referring to radxa's wiki: https://wiki.radxa.com/Rock5/install/spi
Then use dd or ether to install armbian image to your NVME SSD.

Please don't misunderstand my question: I'm not asking for you to "hurry up and deliver the finished product so I can use it".
I do know how this game works, and I have seen evidence over the years of the colossal effort you put into this project.
You've done a great job, as usual, producing an image *THAT WORKS* (so well) in such a short time ... I'm very grateful.
It's because of efforts from you, and others in the Armbian project, that I get to use Debian on devices that probably wouldn't be supported otherwise.
 
I'm simply asking what is preventing us/me/you/everyone from using Bullseye with the kernel you've used for the Sid image?
Is there something in particular that's in the debian-sid (or armbian-sid?) userland that is required?
 
There are a number of things I'd like to try out on this board (headless), and running Debian-stable makes that a lot easier (eg: PHP) without having to containerise everything.

Yes, openjdk is available on Armbian Jammy. Actually it is from Ubuntu Jammy repositories. Default one is v11

I have been able to run armbian on a Samsung 970 Evo Plus 250GB SSD. Really nice...
 
It is though necessary to note that only a 5 Volt USB-C power supply is working with the Rock 5 Model B.

This is great so far, and I was able to get the image to work from the maskrom method to the eMMC.
 
Some things I've noticed:
 
- Video driver is the default software renderer, I've followed the steps here to use an alternative https://launchpad.net/~liujianfeng1994/+archive/ubuntu/panfork-mesa 
- That video driver seems to have some issues still, and does not feel very stable
- Chrome & FF will need some work to make use of the Mali video card, currently seems to be all software based render for the browsers 

It should work in both cases. I am running it from NVME. But with eMMC boot. SPI boot loader is broken.

https://www.armbian.com/rock-5b/

You'd better go with a fresh Armbian install. The Cubox-I image works for the Utilite Pro as well.
Just write the Cubox-i image onto USB or µSD card and modify the u-boot environment in a way mentioned above.
If you are afraid to render the Utilite Pro unusable, you can omit the saveenv command and try out the modified environment before you make the change permanent.
Before issuing the nand-sata-install command you should modify this shell-script in a way that u-boot can access the filesystem contents during boot.
 
Cheers
Uli

We are working with Amlogic and BayLibre to get to the root of the ethernet issues on mainline for Amlogic chips. We should have a resolution soon. One was caused by double poking a register in Designware's IP. There's a secondary issue we are looking into.

Yep, by now they are available in the store!
 
Too bad I had to move and been spending money like a drunken sailor buying things for the new place.  I might not have enough left now for a PBP. 

Greetings!
 
I have been trying out hardware video decoding recently, running Debian bullseye, kernel 5.15.53-rk322x and the lima open-source drivers on my RK3229. Here are my conclusions (working only on a virtual terminal):
Using Debian's default ffmpeg and mpv installation, I am only able to get up to 720p with few frame skips. That is using software decoding (--hwdec=no) and SDL for rendering (--vo=sdl). Trying to use DRM (for either software decoding and / or rendering) will result in worse performance. Atomic modesetting needs to be turned off (--drm-atomic=no) in order for anything to appear on my screen (or else, I just get a gray screen). I found this issue of yours (https://github.com/mpv-player/mpv/issues/8522) but it applies to the LibreELEC build. In my case (repo build), --drm-atomic=no needs to be turned on in order for the video playback to work, but it is of no use, since you get better performance out of SDL. --hwdec=rkmpp was also tried but performance differences weren't observed. When you say you built ffmpeg using LibreELEC's patches, are you referring to this? https://github.com/LibreELEC/LibreELEC.tv/tree/0e57a30916a3a88e0d4c595a5525d3c03156fcc6/packages/multimedia/ffmpeg/patches Using your version of mpv, everything works as supposed! Some notes: YUV420 video works very well but RGB video doesn't (both hardware and software decoding). I know it isn't common, I tried it because it could possibly be faster if the CPU didn't have to convert colors between formats, but it ended up being slower. I have tried to provide my help to the Armbian project previously, but what is needed isn't what I know how to provide. Though, I have an idea to help this community: maintaining ffmpeg packages that can take advantage of this hardware acceleration on these chips. This can be done externally of the Armbian project. What do you think of this idea?

@TRS-80 - i would recommend a kukui = mt8183 chromebook - you can get them used for really cheap (around 100 $ or euro) and it looks like with v5.18 and a few patches on top nearly everything is working (except external display via usb-c and the webcams on some models - on most models the webcam is usb video class and thus even working) and you do not have to struggle with all the pain points of the pinebook pro like strange noises and a really lowest quality touchpad ...

I have been wanting to buy one for what seems like months (a year?) now and they have not been able to do a production run due to the supply chain shortages (mainly screens, apparently).  I follow them pretty closely, there was some hope maybe after CNY 2022 but then they announced no they could not source screens after all.
 
So your information is really timely @hexdump, thanks a lot for that. 

I made a guide after resolving the problem on my own after many not working guides.
 
 

I would like to do this.  I have a Orange Pi 3 LTS and a Orange Pi Zero 2 Plus.  I have plenty of SD cards and some time in the evenings to do this and it helps me out.  I also have a Raspberry Pi 4b 4gb, and plan on purchasing a RockPro64 soon and in the future a RK3588 system and a cheap RISC-V system.
 
Sorry, my github ID is NeoFax75.

Hi Folks
 
I am selling my KOBOL64. It is completely brand new. It has never been switched on, when I received it we had just bought a new house and we were busy with the move. I took it out of the box once to take a look and then got stuck into a renovation project at home and ended up forgetting about the NAS until recently.  My house renovations are not finished and I will not have time to tinker with this for many more months so am selling it. I have the extra SSD bay holder purchased?
 
I am located in Australia and can send anywhere.  
 
MORAL of the story, think hard before renovating your house and then consciously decide not to renovate. 
 
 

Nope, I do like Debian, but the laptop I got is very specific (Asus) and it looks like the only supported distros are Arch based.
 
Thanks a lot @hexdumpfor this detailed workaround.
I could go the arm laptop/chromebook route, of course. Most of my use will be web surfing and using my x86 Linux laptop through vnc, so I don't need a powerful laptop.
I tried to buy the PineBook Pro a long time ago, at the very worst moment (just when it disappeared from the store in fact). It never came back.

Do you have something against regular vanilla Debian?  As a long time Debian user myself, I would feel much more out of my depth on Manjaro, personally.

@gounthar - if you are looking for arm laptops for use with linux, then you should also consider arm chromebooks. best supported are the mediatek mt8183 based kukui and the snapdragon 7c based trogdor devices - nearly everything is working for them with mainline with only very few to no patches required and they are available used or new really cheap (by a factor lower than any other arm laptop option). both have 8 cores, 4gb (some 8gb) ram and 64+/-gb fast emmc. performance wise they are above odroid n2 level. if you can get (not easy due to supply issues) or build (there are a few docs with instructions online) a suzyqable you even get features like a serial console on a laptop which you usually never get. the build quality and reliability of such chromebooks is usually way higher as for average sbc's and with mainline on the above mentioned series you get: panfrost gpu support, working suspend/resume and power saving modes, working wifi, bt, sound and for most of them even camera(s). maybe have a look at cadmium: https://github.com/Maccraft123/Cadmium or my linux on arm chromebooks page: https://github.com/hexdump0815/linux-mainline-on-arm-chromebooks to get started.
 
the best supported other arm laptop is the a few years old lenovo c630 (not the chromebook version) and it is still missing some basic functionality here and there (sleep/suspend etc.). another option - the pinebook pro - is in a different performance and quality league (sadly downwards).
 
best wishes - hexdump

If the (one) disk is large enough, you could also dual boot.

If you already have grub, DD-ing partition will also work. But, yes, this hacking is not very user friendly and has to be sorted out.

This part is under construction. Its pretty much turnkey live build. If you plan to run it from USB, you just flash and run. I do this for two build runner machines where internal SSD is used for data storage (KVM images). Boot from USB is more then enough.
 
When I was installing Armbian on Threadripper I burned image to USB key, boot from another and DD Armbian directly to SATA boot drive. So I had a fresh start with auto expansion to that boot drive. Which is 64Gb SATA SSD. Those are viable workarounds for now ...

Take care of yourself and those around you. Best of luck. These things can wait. Cheers.

Not AFAIK, and also ISP camera support was planned but I am not sure of the current status. I think those are the two main points why someone would like to stay using legacy.
 
I wanted to do some standard packages for all distros in mainline, but I have been overloaded since some time ago, and I am not sure when will I be able to have a look at it. I will announce if it becomes ready.

The described steps are intended for the device, as it leaves the factory, multi-boot is not activated in the factory firmware, you activated it yourself. You have already changed the state of your device (activating multi-boot changes the contents of eMMC and SPI, and changes the entire logic of starting systems from external media, not allowing you to start systems with a new format). In fact, the primary "activation\inclusion of multi-boot" is the transfer of the "old" (which does not know how to launch new systems from external media) version of u-boot to SPI. Until multiloading is fixed to work with new launch formats, multiloading needs to be disabled. I have already written to the Firefly developers what needs to be fixed in the multiload so that it works with all systems (with new and old formats). The correction is simple (just a few lines), but so far there is no answer from them.