JMCC

No prob, I was counting on the possibility of bricking it, but it was just a 20€ crappy device laying around. And it is not bricked after all, yet it works faster than factory with Armbian, and even have WiFi, which I didn't expect 😆
I'm on vacation and I don't have any USB-OTG cable here, so I cannot use the RK flashing tool. There is an option to create an "upgrade SD card", but it only supports cards up to 16GB, not bigger (WTH?), and also requires a reset button which seems not to be present on the device.
 
This also motivates me to spend some time finishing the media integration for Mainline, so I can at least use Kodi on this 😄
 

It would need a complete rework and recompile

Well, I don't even own a RPi, but here are some suggestions:
You mention several OS'es, but not Armbian. Have you tried Armbian? If not, that would be the first thing to do, specially since you asked here :) In your video, you show RISC OS, and apparently it is running a armv7 version. Could it be that 32-bit ARM OS's are working, but 64-bit are not? If this is the issue, then maybe you can try to build 32-bit Armbian image and see if it works. It could also be a device tree issue. Maybe you can extract the DTB from some of the OS's that are working, and try to use it with an Armbian image.

No, I don't own a Rock64. I only tried HW encoding on the Tinker Board (RK3288), and quality was quite acceptable.

@jock Thanks for the info. On a side note, I found a small bug: when making the emmc backup, if the resulting file is bigger than 4Gb it will just stop there (because of the FAT size limit) and you will get a broken backup.
 
Probably could be solved by splitting the backup, for example along these lines:
# Split backup in 2Gb parts, with two-character suffixes dd if=/dev/mmcblk1 | gzip -c | split -b 2000m - tvbox-backup.img.gz. # Restore the backup cat tvbox-backup.img.gz.* | gzip -dc | dd of=/dev/mmcblk1  

@jock Thanks for the info. On a side note, I found a small bug: when making the emmc backup, if the resulting file is bigger than 4Gb it will just stop there (because of the FAT size limit) and you will get a broken backup.
 
Probably could be solved by splitting the backup, for example along these lines:
# Split backup in 2Gb parts, with two-character suffixes dd if=/dev/mmcblk1 | gzip -c | split -b 2000m - tvbox-backup.img.gz. # Restore the backup cat tvbox-backup.img.gz.* | gzip -dc | dd of=/dev/mmcblk1  

@jock Thanks for the info. On a side note, I found a small bug: when making the emmc backup, if the resulting file is bigger than 4Gb it will just stop there (because of the FAT size limit) and you will get a broken backup.
 
Probably could be solved by splitting the backup, for example along these lines:
# Split backup in 2Gb parts, with two-character suffixes dd if=/dev/mmcblk1 | gzip -c | split -b 2000m - tvbox-backup.img.gz. # Restore the backup cat tvbox-backup.img.gz.* | gzip -dc | dd of=/dev/mmcblk1  

Yes, you can. Actually the choice to remove any Android code from the board is a deliberate choice by me 😝 but has some performance and compatibility reasons, since this way the user is in control of the ddrbin, miniloadloader/SPL and trustos.
 
The explanation is not exactly simple because these three pieces then cause unwanted behaviours, especially  the proprietary trustos does not allow rk3318 to run above 1.1GHz. I guess rockchip put an artificial cap because the chip can run fine at 1.3GHz or even overclocked at 1.5GHz. A pro of the proprietary trustos is that it allows DDR frequency scaling, that is not allowed by the opensource trustos, but to overcome this I patched the ddrbin to use ram at 667MHz with great benefits in terms of multimedia and general performance. If you run stock Android you are forced to use the "stock" ddrbin at 300/333 MHz because the rockchip boot always happens from internal flash... so it's a chain of issues and to avoid all of these hassles I prefer to erase Android and start fresh.
 
If you still want to go the "Android" mixed way, @hexdump wrote a document on his github on how to do, but I always forget the bookmark the link... That's still something that should be exclusive for the power user because that belong to the same class of those I explained above are around the corner.
 

THE MEDIA SCRIPT IS NOW DEPRECATED, IN FAVOR OF THE OFFICIAL MULTIMEDIA FRAMEWORK. PLEASE REFER TO THIS TOPIC:
 
 
And, for last,  the first version of:
The UN-official, UN-supported, UN-expected
RK3328 MEDIA TESTING SCRIPT
 
This is the first release of the RK3328 media testing script. The script provides a functionality similar to its RK3288/3399 equivalents, except for the OpenCL related stuff, which is not supported by the SoC. So it includes:
Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@60 10-bit HEVC (the maximum supported by the SoC), and GLES 2.0 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi. A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional features, that have no big interest from the Armbian development prospective, but I find them interesting to play with: Chromium browser with support for Flash and DRM-protected commercial web video streaming (tested with Amazon Prime, should also work with Netflix, Hulu, etc.), and a simple Pulseaudio GTK equalizer using LADSPA.  
Here is a more thorough documentation:
 
 
 
>>> DOWNLOAD LINK <<<
 
Prerequisites:
You need a fresh Armbian Bionic desktop image with default kernel installed. 
 
Instructions:
Download the file above Untar it: tar xvf media-rk3328_*.txz cd media-script ./media-rk3328.sh  
Notes:
This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
Enjoy!

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.

It depends on which level we are talking. I assume AWS Graviton servers have a big team of paid staff to take care of both the hardware and the software, for example.
 
Now, if we are talking about $40 ARM SBC's, I think "hobbyists" and people in "playground mode" is a good way to describe the main public of those devices. If we also add "students", I think we have a complete description of the kind of use you can reasonably expect for that kind of boards, which the manufacturers make them for.  And, particularly, we describe the kind of people who willingly contribute to a project aimed to make an OS for these boards.
 
On the other hand, I consider absolutely unrealistic to expect the same level of support for such a project as you expect for one that is backed by a big company with a big staff. As unrealistic as expecting a group of volunteers, who spend their free time on the project out of good will and because they like it, to focus on a reduced number of boards they are not interested in, and only for the NAS use case, "just because I say so".
 
And it is not only unrealistic, but IMO also unnecessary. I find it hard to imagine a system administrator pulling an OPi Zero out of his pocket in front of the corporate board and saying "Hey, this is going to be our new support for the crucial data. Don't worry, it is going to run Armbian out of a Sandisk Extreme Pro, which has been proven to be the most reliable SD card in many forum posts".
 
----------
 
Now, focusing on our topic, I tried btrfs a couple years ago, attracted mainly because of the snapshots feature. But when I was trying to compile some software I needed, and discovered it was not even mature enough to allow creation of swapfiles on it, I just decided to go back to good ol' ext4. I haven't tried again since, maybe I should 

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.

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.

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.

First if all, if you want help you need to provide some basic information, like "armbianmonitor -u". Please read forum rules.
 
Second, are you sure you are using a buster legacy image, not "current"?

Is there any available log from the meeting? Sorry for not attending, Saturday afternoons are busy for me sometimes.

Reminder! The release meeting is happening this saturday 14:00 UTC+1 (which is 13:00 UTC or 8 am EST or 2 pm CET or 5 am PST (sorry california dudes) or 9 pm CST).
 
I will look through the Jira issues remaining today. Would be great if you could check them too and add the ones you have finished (or are planning to include in 22.02) to the release.
 
@Igor @Werner @TonyMac32 @martinayotte @piter75 @ning @Myy @balbes150 @sfx2000 @ebin-dev @chwe @gprovost @aprayoga @lanefu @5kft @JMCC @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @tony013 @rpardini @yang @adeepn

Go @lanefu!
Go @NicoD!

Go @lanefu!
Go @NicoD!

Hi all.
In this episode @lanefu explains what he does for Armbian, what gear he uses, and why. It is a must see video.
Enjoy
 
 

As stated above, you can install the packages from this link: https://users.armbian.com/jmcc/packages/kodi-mainline/arm64/
 
I am planning to build Kodi 19 packages and integrate them into the Armbian repos, but no ETA yet.

Yes, that makes sense. As a matter of fact, the legacy Kodi packages don't have any kernel dependency, it is only the meta-package for the whole multimedia framework that depended on the legacy kernel. The reason for that was that, if installed on a different kernel, it would break the system. But Kodi won't break anything by itself, so no kernel dependencies this time, I promise 

@balbes150 well, I decided to put the Station M1 with a small monitor in the kitchen. That gives me a reason to make new Kodi packages. Only problem is that it is still packed in some box lying around the house. Let's see if I can get hold of it anytime soon 

Good to know. Right now I am in the process of moving to another house, but I will check when I get the chance about Kodi 19

Hi all.
I've done a collaboration with @Igor, the creator of Armbian.
He shows and talks about the hardware that is used to maintain the project. Servers, boards, other electronics, ...
Enjoy!

More videos to come.