fabiobassa

Hi all,
 
I've a box with rk3228b, nand, ddr2 etc etc and I'm using it as mediacenter with Libreelec 9.2 installed on sdcard.
The box recognize the nand, but I had never been able to install the operating system in it (tried with rkdeveloptool, dd and others but without succes).
Until today, when I've discovered this beautiful tool called multitool
I had to make a few small changes (basically removed offset and gpt creation in the nand flash code), but it works great.
So my question is, it's possible to add an option to write a generic image, in order to make this tool more useful!?
 
Last question, I think that the libreelec bootloader has some trouble when boot from NAND, but it's strange, because I've readed that the multitool one shoud be the same. It's true, or there are some changes that I can apply and retry?!
 
 
Thanks for your hard work.
Michele
 
 
 
 
 

thanks @jock, meanwhile looking at your repo I stole a patch that fixes the boot from nand in my libreelec fork 
 
I have seen that this code has been inserted in recent kernels
 
https://github.com/torvalds/linux/blob/master/drivers/mtd/nand/raw/rockchip-nand-controller.c
 
so maybe in the near future NAND for rockchip should works?!

@markst I understand there is no blame, but the phrase"Technically, rockchip devices cannot be bricked" is followed by a detailed explanation about why this is true.
The whole paragraph is important to read, not just the first few words, in particular you can note:
 
 
Don't know, but it looks to me there are enough warnings

Thank you for the job. I run successfully on H96max rk3318, debian server on emmc
 
 
 

@Huafu
The ground (GND) pin is the most important pin, you must absolutely connect it if you want a reliable result, otherwise you can get varying results starting from occasional garbage, total garbage or even adapter breakage.
If you have a common regular USB serial adapter, +5V is not needed at all and must be kept disconnected.
 
All the three pins (GND, TX and RX) must be connected before giving power to the board and possibly with the serial adapter disconnected from the computer too.
Once the hardware setup is done, you can connect the serial adapter to the computer and configure minicom with the right parameters: usually it is sufficient to keep defaults and change baud rate to 1.5Mbps.
 
Finally you can give power to the board.
 

Hi all,
Little feedback, I tried installing CasaOs, CasaOS - A simple, easy-to-use, elegant open-source Family Cloud system
it works..
It may be useful for some of you.
Thank you to the entire IceWhale team for this sharing..
 
https://github.com/IceWhaleTech/CasaOS
 
 

@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