Find your Backup ROM or download from WEB.
"4G-RK3566_userdebug_H96_Max_RK3566_11_20210810.1920.img"
"8G-RK3566_userdebug_H96_Max_RK3566_11_20210421.2051.img"
extract the image using the "windows" app or use it on "linux" app
Release Version v0.3 BETA
❎ No Video out (device tree bad arg)
❎ No Virtualization (kernel config)
❎ No Docker (kernel capability)
H96 MAX RK3566 Board V56
Kernel 4.19.219
Linux FIT Image Rockchip EMMC
Ubuntu 20.04 LTS
This image has been compiled without any standardization and should be used for experimental purposes only,
there is no guarantee of compatibility with your device
Download Link: DELETED FILE DUE DEPRECATED KERNEL4 👈
Download Link: DELETED FILE DUE DEPRECATED KERNEL4 👈
This FIT image needs to be flashed on the internal storage, this board don't have SD CARD Reader.
Just Press the RESET Button when connect male-male USB 2.0 (BLACK) to Desktop
MAKE Backup Rockchip Firmware emmc
Install Drivers, Driver Assistant Download
RkDevTool Download
Upgrade Rockchip Firmware eemc
Maskrom mode
Loader mode
when the Board Boot UP you will need to conect RJ45 LAN, Find the IP Addres on your PiHole, Firewall or Lan Router
and SSH to the ubuntu.
First BOOT COMANDS:
🏆 help to add this board in armbian standart, you don't need to be a programmer to help the community,
just need a copy of the V56 board and a x86 computer to compile new versions.
Base Parameters to build:
H96-MAX-Uboot-legacy.img
Partition-Parameter.txt
H96-MAX-8gb-MiniLoaderAll.bin
H96-MAX-4gb-MiniLoaderAll.bin
DTB + DTS + rockchip_defconfig
SDK Used into this Build:
SDK 4.19.219 LINUX to RK3566 H96 MAX
Rockchip boards are unbrikable
in a worse case you need to short the EMMC CLK pin to GND on the other side of the board
and upload the righ LoaderALL.bin File from a linux machine that you backup.
to connect the RK3566 on Desktop USB Maskrom Mode.
Extensions have no meaning in the Unix world, you can even rename that file with a ".exe" extension but it does not change anything. What counts is the data in the file.
The procedure requires that you first erase the eMMC with rkdeveloptool ef command; when done turn the box off, then turn the box on and you will be in MaskROM mode .
Once there, follow the steps from "Restore backup" paragraph in the link above:
you have to first use rkdeveloptool db command to upload a program to the SoC to program (no pun intended) the eMMC
you can skip the rkdeveloptool ul command (it was necessary for manual backups, not for multitool backups)
run the rkdeveloptool wl command
Maybe the serial is switched to 1.5Mbps; some firmwares use 115200, some others use 1.5Mbps and may show you garbled data.
On multitool and armbian by default I use 115200bps for compatibility.
Yes, both of these behaviours are expected.
The OTG port works as a power supply since it is supposed to be bidirectional. In fact when you do maintenance in maskrom mode you have not to connect the regular power supply but just the USB cable. Not all boards work this way though, but it looks like that both mine and yours behave this way.
rkdeveloptool does not let you do anything with the box in MaskROM mode because you first have to upload the famous program with rkdeveloptool db I talked above. Once you do that, then you can use the other rkdeveloptool commands (including ef, wl, etc...)
A lot of confusion comes from a fact: rockchip u-boot bootloader that is shipped with original firmwares, when stuck or when the reset button is pressed, provides the RockUSB mode, which is similar to MaskROM, but it is not the same! Unfortunately lsusb has no chances to recognize the difference and will tell you the board is in MaskROM mode, but it is not true. When you are in RockUSB mode, rkdeveloptool works without the bootstrap program because on the other side there is u-boot that is already answering.
Another very very important difference between MaskROM and RockUSB modes is that the latter does not allow you to write the whole firmware: it will skip the first 0x2000 sectors, not allowing to overwrite the bootloader part, plus it will shift by the same amount the image you're going to write on the internal flash. Clearly this breaks everything, because partitions will not be in the expected positions anymore.
To make the long story short: always operate on the internal flash when you're in real MaskROM mode.
To get into real MaskROM mode you have to:
erase the internal flash, or
gate the clock pin with the screwdriver/whatever trick
This is because the SoC on first instance tries to boot from eMMC. If it does not find a valid bootloader, then tries to boot from sdcard. If a valid bootloader is not there too, then stays there waiting in MaskROM mode waiting for an input from USB OTG port. No firmware/software has been loaded at this point, and that's the reason why you must upload the bootstrap program with rkdeveloptool db command before you can do anything else.
Yes, this is the problem I talked you about the differences on the boards: the kernel is stuck somewhere because the device tree tells about a hardware configuration but your board has a different hardware configuration.
If you burn the image on a sdcard, you can edit the file /boot/armbianEnv.txt and change verbosity=1 to verbosity=7 to let the kernel to show the whole log on the serial. This is of great help when you're debugging.
You may also try armbian images for the Asus Tinkerboard-S, which has the rk3288 SoC as well and share many similarities.
edit: you didn't say if you tried to just restore the backup with the multitool. Did you try? That's the easiest way to restore the backup...
the H96 Max RK3566 8GB (the very first at 8GB) doesn't even have a SD slot, u-boot nor any uEnv.txt it's a DSU https://developer.android.com/topic/dsu
dynamic software update that can be bypassed but it's totally alien to the solutions we (I) have thus far. I got them rooted though but replacing the OS is gonna be a tough candy
I too made a station image but M-2 (rk3566) not P-2 (rk3568) with the build script, fingers crossed. The RK tools doesn't differenciate 3568 of 3566 in the config files.