fabiobassa

@Elmojo
I know is not fine answer to a question with another question but in this case
 
comes very natural ask  : why did you modded it ??? Just for fun ? You didn't have a defined purpose in trying linux ?

Anyway, just to answer , in my personal study case I have done on it:
voip pbx ( asterisk)
network nas
network firewall
pihole dns firewall
openvpv, wireguard and tinc vpn
home assistant
volumio
special ip cam monitoring and data acquisition

and I guess I could experiment more..... if only I would study more potential applications

@chinhhut

Try these steps:
1) push the little switch inside the hole while inserting a male-male cable into the otg
2) on another linux machine you should have now a new device (lsusb will help you) and you can run rkdeveloptool
3) rkdeveloptool ld should List Device
4) rkdeveloptool rd 3 should Reset Device into mode 3  ( maskrom )
5) rkdeveloptool db MiniLoaderAll.bin ( of course from your path) should upload a temporary loader to recognize the internal emmc
6) if all is successfull until now you can rkdeveloptool wl 0X0 yourimage.img . This should flash the internal emmc .

DISCLAIMER: very " dangerous" approach , be ready to have the opportunity to short the emmc clock pin to ground to go back into mask rom
 
MiniLoaderAll.zip

@Elmojo
I know is not fine answer to a question with another question but in this case
 
comes very natural ask  : why did you modded it ??? Just for fun ? You didn't have a defined purpose in trying linux ?

Anyway, just to answer , in my personal study case I have done on it:
voip pbx ( asterisk)
network nas
network firewall
pihole dns firewall
openvpv, wireguard and tinc vpn
home assistant
volumio
special ip cam monitoring and data acquisition

and I guess I could experiment more..... if only I would study more potential applications

Wouldn't it be easier to modify Armbian as you want it before installing it in the first place? I don't know how to do it, but example. Download @jock's Armbian, or compile your own. Modify the files on the .iso. write it to the SD card and install it on box 1 without the need to modify it later. Then do it on box 2, box 3, etc.

H96Max+ here.
 
Just installed following your instructions. Works amazingly well and was amazingly easy, particularly after having read around on other forums that for RK3328 there is no HDMI support and that I should have opened the box to get to the serial pins! Thank you all for this great work!
 
I am going to use the device as a micro server, so I am not testing any graphical desktop.  Quite happy to see that USB3, WIFI, Ethernet, all appear to work out of the box.
 
Have just a few questions to which someone having the same box may be able to answer:
 
1. What is the appropriate answers for the EMMC configuration in rk3318-config?
2. What is the appropriate configuration for the LED? I am puzzled by the fact that the led functionality seems to be better in the multitool than in the OS itself. In multitool the red led stays on and the blue one appears to flash to indicate activity. In the OS, the red led stays on all the time and the blue one stays off all the time.  The "conf3" seems to hang the machine at boot.
 
Furthermore, I have a question about the kernel packages.
 
- As instructed, I have put on hold the upgrade of kernel, kernel headers and dtb packages from apt. Is it expected that the official armbian kernel will include rk3318 and rk3328 support in the future? This seems important to me in terms of future maintainability of the box.
 
During the installation, I have dumped my firmware using multitool (an Android 8.something, if I remember properly). Would it be useful if I tried to extract the dtb from it, or is the dtb of the stock H96Max+ already well known to you?
 
A very minor suggestion from someone getting onto this great forum for the first time (hence something that could either be totally useless for naivety or maybe useful as representative of an initial impression, you judge). Threads regarding multiple boxes sharing the same fundamental hardware, such as this one may easily become very large and it is hard and trying to go through them it is sometimes hard to understand if something is general or if it refers to a specific box and if so which one.  Being able to tag the messages with the specific piece of hardware they are about would ease reading immensely.

@chinhhut @curse
The backup made by multitool (and rkdeveloptool) is per nature a full backup of all the physical eMMC sectors. It has no knowledge of the abstract structures like filesystem and files.
The compression gives back a more manageable file which is not the entire size of the eMMC, but up to a few gigabytes, depending on how much data is stored on the eMMC and how much compressible it is.
 
Indeed if you decompress it, you get the whole size of the eMMC, it is expected and it is advisable too. If it is not so, it means the backup process didn't went right.
 
Now should be clear there is a problem about the "blank" part: how we can know if a part is "blank" and not, for example, a piece of a file which just contains a long string of 0x00 bytes? This is crucial: if you say that you skip those parts which are, supposedly, blank, you may (and probably will) fail to restore files that contains long string of 0x00 bytes. You won't get 0x00s in those places, but you will instead find there the contents of the unwritten eMMC sectors.
 
So a full restore of all sectors is essential to restore the exact previous condition when doing a full backup.
 
One helpful thing that may be helpful here is to use the native page erase feature of eMMCs, which is the thing blkdiscard program do and is at the bottom of the famous TRIM feature: flash memories are divided into "pages", ranging from several kilobytes to few megabytes usually.
Erasing those pages using the discard command is very fast, much faster than zero-filling. You can erase all the pages of a whole eMMC in a few seconds, while zero-filling all the pages would require dozens of minutes.
 
Doing an erase with blkdiscard and then restoring the backup skipping the blank parts now becomes sensible!
There is an issue though: discarding pages does not fill them with 0x00 bytes, but with 0xff bytes, so the real blank parts now are not those which contains string of 0x00s but those which contains strings of 0xff bytes. Those may or may be not so common. Surely they are common in non-programmed sectors, but results may vary.
 
As a conclusion: restoring the whole count of eMMC sectors, despite being slower, is surely the simplest and most reliable way!

i'm intrigued, why do poor, elderly people need a linux server? 

!! DEPRECATED !!
Instructions in this thread are oudated and superseded by the new experimental APT repository for hardware video decoding ffmpeg.
Please refer to this thread from now on!
 
Hello, recent upgrades to armbian are regarding kernel 5.15.
I noticed that many v4l2 fixes and enhancements went into this release, so I decided to compile ffmpeg using LibreELEC patched version and mpv over it.
mpv turns out to be statically linked with ffmpeg, so I propose it here for people who is interested in cutting edge kernel and wants to do some tests.
 
This has been tested on Debian Bullseye and Ubuntu Hirsute on following platforms:
Rockchip RK3228/9 (kernel 5.10, 5.14) Rockchip RK3288 (kernel 5.14) Rockchip RK3318/28 (kernel 5.15)  
It should work on allwinner platforms too, but I didn't test it there.
Binaries are built by me on developing boards.
 
The binary for armhf is available here
The binary for arm64 is available here
 
Copy the binary into /usr/local/bin directory of your system (mpv-armhf for 32 bit systems, mpv-arm64 for 64 bit systems):
sudo cp mpv-armhf /usr/local/bin/mpv  
Install dependencies for Debian Bullseye and Ubuntu Hirsute:
apt install libass9 libbluray2 librubberband2 libsdl2-2.0-0 libva-drm2 libva-wayland2 libva-x11-2 libva2 libvdpau1 libx264-160 libx265-192 libxss1 libxv1 libfdk-aac2  
I have had issues with dependencies on Debian Buster/Ubuntu Focal, in particular libx264-160 and libx265-192 are not available there.
I Solved the issue downloading the packages from Debian Bullseye web page and manually installing them.
There may be the need for some other dependency depending upon your actual installation.
 
Run mpv in a virtual terminal (videos up to 4K) with this CLI:
mpv --vo=gpu --hwdec=drm --gpu-hwdec-interop=drmprime-drm --drm-draw-plane=overlay --drm-drmprime-video-plane=primary <video.mp4>  
Mpv can be run in X11 with this other CLI, but due to buffer copying it requires a good CPU - rk3228 and rk3328 won't even play 720p, rk3288 do 720p fine:
mpv --vo=gpu --hwdec=auto-copy --gpu-context=x11egl --gpu-hwdec-interop=drmprime-drm <video.mp4>  
This is an experiment and your mileage may vary a lot:
H.264 codec should be well supported around the boards; H.265 has more limited support VP8 should be generally supported VP9 seems to still require some work.

Update!
 
New testing minimal and xfce desktop debian images are available on first page!
Latest kernel 5.15: plenty of fixes and upgrades for hardware video decoding Initial (and untested) support for boards with sdcard on external controller U-boot v2021.07, should make USB2 boot more reliable To test hardware video decoding capabilities follow this link to a tutorial with prebuilt mpv binary and instructions on how to use it.

@zr111983

It seems the board is booting and hangs there for some reason. Let' s wait @jock suggestion

Where you from ? россия  or  украина  or any other cirillic country ?

H96 MAX  tv Box RK3318.
 I still can't boot from Armbian.
The download stops at this message. Maybe you know what could be the matter?

thank you very much for the answer

Руслан Зинеев
Привет , I used google translator to understand your post.
The uart speed is contained into the image : you can put the image on a sd and under folder  /boot you will find a config item.
but can you explain in english please exactly which is your problem ?
 EDIT: try to set your uart directly to 115200

you will lose initial infos but then you can follow ll the boot process
 

Руслан Зинеев
Привет , I used google translator to understand your post.
The uart speed is contained into the image : you can put the image on a sd and under folder  /boot you will find a config item.
but can you explain in english please exactly which is your problem ?
 EDIT: try to set your uart directly to 115200

you will lose initial infos but then you can follow ll the boot process
 

@mkultra
 
If you go to my post of 5 November you will find all the necessary instructions. You need upload a loader before doing anything
 
If you are tired or lazy to read the whole 3ad... Well...... that might be a obstacle...... ;-)

@mkultra

you must give the right path
e.g. rkdeveloptool db /home/mickeymouse/miniloaderall.bin acodrlying where you have your miniloader
 

@mkultra
 
If you go to my post of 5 November you will find all the necessary instructions. You need upload a loader before doing anything
 
If you are tired or lazy to read the whole 3ad... Well...... that might be a obstacle...... ;-)

@mkultra

It seems to me that the information you are getting is wrong, as @jockalready said to you. you have two possibilities:

1) if effectively you already are in MASROM it means that you HAVEN'T ANY MINILODER  into your board. Maybe some previous attempt erased miniloader
2) you reporting bad infos and the only method to understand in which mode you are is using rkdeveloptool and not the tool you are using ( flash tool)

Flash tool " speaks " to the board using some PRE-DEFINED partitions contained in a text file called rkparameter... infact the parameter " -p system " would tell to the tool to program ONLY the partition called " system".
That approach is wrong since we use gpt partitioning now so leave alone that tool and compile rkdeveloptool

@chinhhut
Will try to explain you what loader is with an analogy: in normal pc you have bios and master boot record. Well, maskrom is bios and is contained in the soc itself, loader is a sort of master boot record and it enables the emmc and ddr.
You can have a look here
http://opensource.rock-chips.com/wiki_Boot_option

 

I did extract it by a working firmware using a tool that unpacked the whole firmware. Try to google for RK3xxx_firmware_tools_5.23.1_by_SergioPoverony.zip and leave alone that github since it is just one piece of the puzzle. The detailed infos how to get a working loader are in the rockchip instructions

 

Of course and the command would be rkdeveloptoo rl 0x0 etc etc etc ( try rkdeveloptool -h to get the help)
But if you are lucky that works multitool, well that is the easiest way to clone and clone back

Hi @jock  I managed to run the image on my respeaker coreV2 board  added the rk3229-respeaker-v2-armbian-rev2.dtb to /boot/dtb  and  changed the fdtfile=rk3229-respeaker-v2-armbian-rev2.dtb in /boot - great work

And perhaps try with different SD cards. I first used some expensive recommended 64GB SanDisk card and nothing worked then I tried a "no-name" cheap 8GB card and it worked perfectly. I think it's up to luck when it comes to the SD cards. The recommended expensive cards might work more often than the cheap ones, but sometimes it's the other way around. 

@chinhhut
Will try to explain you what loader is with an analogy: in normal pc you have bios and master boot record. Well, maskrom is bios and is contained in the soc itself, loader is a sort of master boot record and it enables the emmc and ddr.
You can have a look here
http://opensource.rock-chips.com/wiki_Boot_option

 

I did extract it by a working firmware using a tool that unpacked the whole firmware. Try to google for RK3xxx_firmware_tools_5.23.1_by_SergioPoverony.zip and leave alone that github since it is just one piece of the puzzle. The detailed infos how to get a working loader are in the rockchip instructions

 

Of course and the command would be rkdeveloptoo rl 0x0 etc etc etc ( try rkdeveloptool -h to get the help)
But if you are lucky that works multitool, well that is the easiest way to clone and clone back

@chinhhut
Will try to explain you what loader is with an analogy: in normal pc you have bios and master boot record. Well, maskrom is bios and is contained in the soc itself, loader is a sort of master boot record and it enables the emmc and ddr.
You can have a look here
http://opensource.rock-chips.com/wiki_Boot_option

 

I did extract it by a working firmware using a tool that unpacked the whole firmware. Try to google for RK3xxx_firmware_tools_5.23.1_by_SergioPoverony.zip and leave alone that github since it is just one piece of the puzzle. The detailed infos how to get a working loader are in the rockchip instructions

 

Of course and the command would be rkdeveloptoo rl 0x0 etc etc etc ( try rkdeveloptool -h to get the help)
But if you are lucky that works multitool, well that is the easiest way to clone and clone back

Yes, I'm looking into.
I read your previous messages and as far as I remember you have two three problems:
- HDMI is not working
- eMCP flash is not working
- only one led is working
 
The first two are unexpected problems. If I remember correctly @marshall also had an eMCP board. He had a problem with SDIO, but eMCP flash is working fine.
You instead have a problem with eMCP flash, which is pretty unusual, strange and worse.
 
Could you please try this libreelec image and tell me if you see anything on HDMI? Armbian uses the same libreelec HDMI timing patches, thus we could discover if the problem may be related to those patches. You can just burn the image and sdcard, plug it in and ti should boot. If possible, please post dmesg output you get over serial too (don't remember if baud rate is 1.5Mbps or 115Kbps)
 
About the development process on testing armbian images, there are some things that I want to make clear:
we need to do several tests, it may be a slow process and results are not guaranteed you should already be able to put Android back on the board with rockchip tools in case you want to go back accept the very remote risk to brick the board The plan is to first erase completely the internal eMCP flash, either using rkdeveloptool for linux of the rkdevtool for windows. For the former tool, instructions are in the paragraph Erase the flash memory in the first page of the thread.
Once flash is erased, the board always boots from sdcard. sdcard is far easier to use for testing.
 
First of all, try both the legacy 4.4 and current 5.10 kernels and see if results are the same. dmesg log is always appreciated, even better is to paste the link produced by armbianmonitor -u
Images can be downloaded from armbian download page, just use a suitable burner tool like balena.etcher or whatever you prefer to burn the image on the sdcard.
 
This are two overlays to use for your board. They should provide at least working leds, hopefully the eMCP flash should work too.
This overlay rk322x-led-conf7.dtbo is for legacy 4.4 kernel.
This other overlay rk322x-led-conf7.dtbo is for mainline 5.10 kernel.
 
Use one or the other In dependency of which kernel are you testing.
The overlay must be put in /boot/dtb/overlay directory of armbian installation and must be activated adding a line overlays=led-conf7 in /boot/armbianEnv.txt file.
You should be able to do that with no hassle directly on the sdcard.
 
I hope this fixes led and eMCP flash problems. It is improbable that anything changes with HDMI. For that problem I need to know if the libreelec image is working right for you or it isn't.

@chinhhut

Try these steps:
1) push the little switch inside the hole while inserting a male-male cable into the otg
2) on another linux machine you should have now a new device (lsusb will help you) and you can run rkdeveloptool
3) rkdeveloptool ld should List Device
4) rkdeveloptool rd 3 should Reset Device into mode 3  ( maskrom )
5) rkdeveloptool db MiniLoaderAll.bin ( of course from your path) should upload a temporary loader to recognize the internal emmc
6) if all is successfull until now you can rkdeveloptool wl 0X0 yourimage.img . This should flash the internal emmc .

DISCLAIMER: very " dangerous" approach , be ready to have the opportunity to short the emmc clock pin to ground to go back into mask rom
 
MiniLoaderAll.zip