fabiobassa

Hi again KSilva,
 
Using RKDevTool (RKT) for bringing back the box alive, and flash an android image:
UNPLUG the box, and do NOT plug it now. The Power will come from USB. You can switch RKT in english by editing config.ini and changing Selected=2 (use an 8bit editor such as VSCode). Start RKT, connect the box. If you hear a Windows DingDong, you have won, and you see "LOADER Mode" or a "MASKROM mode" in RKT. In that case you can plug power so that the box stays in that mode and go to 6). Otherwise you have to put the chip in one of those modes. The best thing is Loader (ie. Rockchip) mode. With Rockchip/Android (opposed to Armbian) with a normal flash image (at least if the bootloader is not erased), you can enter this mode by pressing the "Rockchip button" while connecting the USB. This button is usually located behind the audio jack, you can use a wood toothpick (cut both ends as it hurts...) for that. This is NOT the case if there is an Armbian image; in that case, the only way to enter loader mode is to interrupt the boot from the serial console (BTW, RK/android is 1500000000-N-8-1 (yes, 1.5MB/s), Armbian is 115000-N-8-1) If this does not work, the MASKROM mode is your last resort.  The hardware of the chip automatically enters this mode at boot if the flash is erased or not accessible. Technically, the flash is a serial memory accessed synchronously using a clock line, so the trick is to short this line to ground while connecting the USB. Most boxes have some pads for that, or the PCB can receive a Nand memory in a QFP package; in that case you have to short pins 8 and 9 with the small screwdriver and a good magnifier (see here for a video). Unfortunately, typically now the emmc chips use BGA packages, and I had to throw away a bricked box where I could not find the clock line on the PCB (or maybe the DRAM was dead... ) You have to be perseverant, as it does not work  each time, but eventually you will be rewarded by a Windows DingDong!. This is where we can help with the pictures of your PCB. In either mode, select "upgrade firmware" tab, load the android image from disk with the "Firmware" button (you have to wait 20seconds for the firmware to be decoded), erase the memory, and flash the firmware. If you boot in Armbian mode, unfortunately the toothpick trick does not work, and the only way to enter LOADER mode is to interrupt the boot from the serial line, and from the u-boot monitor in RAM, erase the u-boot in flash so that when rebooting, it enters LOADER mode. You can find details here  (mmc erase 0x4000 0x2000)
 
If you enter Maskrom mode, and don't want to burn a complete image, but at least a bootloader, so that it is a lot more easier to enter back loader mode with a toothpick.
 
I recommand that you bring back your box alive with stock firmware before installing Linux.
 
Unfortunately, your box has NO sdcard, and that's a pity as it helps A LOT. Next time, buy a box WITH AN SDCARD!
I was in the same case, and was not able to flash an u-boot allowing the box to continue booting on USB, as described in the 1st post. So I had to flash images directly in emmc, which is not good in case of problems,
 
In order to install LInux on such a system, it is best to switch from Windows to Linux as I have not found a way to burn an Armbian image with RKT, and use rkdeveloptool, got from here . This is a CLI program, of lower level, which is agnostic about what it burns. There are instructions how to use it in the 1st post.
 
Just a remark which costed me a few hours of headscratching: when being in Maskrom, the ONLY command accepted is to download a bootloder (rkdeveloptool WL bootloader.bin). ONLY after that you can use the other commands.
 
Jock, Fabiobassa, balbes150 and others have done a tremendous job in creating armbian images, and the multitool, and they work most of the time. But I had a couple of boxes (called T96 Mini) where even the old (4.4) kernel panicked (serial console is mandatory to see what's going on...). In that case, fabiobassa was kind enough to help me install manually an even older kernel manually using RKT, but this is a complex process and the resulting system is NOT very stable, so I don't recommand that. 
 
Just FYI, I have standardised now on those 2 boxes (Q96 HOME 4K and V88 4K - beware, rhe 4G/32G is in fact a 1G/8G!!!) which, despite having a small memory, have 4 usb (enough for a WIFI dongle and some USB SSD), and are perfect as small headless Linux servers with the 4.4 kernel, and extremely stable :
stress-ng --sequential 0 runs for 24H without crash, but it is a good idea to add a small heat-sink on the processor as it throttles speed above 105C celsius...)
 
Just my 2 cents, and welcome to the club!

@gurzixo
hello Michel , yes to ALL your questions except for
 
 
this is true for emmc. For nand since them charateristic the discussion is little little different, but let's assume is quite the same for our purpose:
It is good idea and safe approach DON'T TOUCH idbloader , the very very very first stage of loading something in ram and go modify starting from address 2000
Will follow a different approach for your board so please be patient some hours so i can give you more details
EDIT :
  this also is half half correct: the sd card will do the job if there is a uboot and a trust ALSO in sd card at right places . It will happena " jump" from the internal uboot to sd uboot and then continue bootng from sd.
But don't worry we wil go back from scratch

that is for android 3.10.xxx and we are on kernel 4.4.xxx and yes .. we already have that too

@rlukas210

yes your board is well known and also quite good supported.
I am happy and satisfied it is working now

@rlukas210

yes your board is well known and also quite good supported.
I am happy and satisfied it is working now

@jock @fabiobassa hi after a long time!
I have spent many hours, tried several times, blá blá blá
After all, i got my board to work both with USB, and tried with Debian Image and nand was booted Fine!
 
I would like to give a huge thank you to you and everyone who could make this possible! 😁😁😁
 
edit:
 
I can't attach the images here, but in the link below has the proof and the df output
https://drive.google.com/folderview?id=1VJeOQczDYVTannltNl4cq0wk6WtvWokI
One more time, a big thank for u'all!! 

Hello @gurzixo, most of your observations are true, I will add some precisations to make things more clear as long as I see you like having things tidied up
 
 
The box is surely intended by rockchip to run under Android, but tools are definitely OS-agnostic. Also the tools given by rockchip are intended also for other SoCs that are publicized and sold and supported for use in Linux (like rk3288, rk3399 and rk3328).
Not exactly. Armbian is a set of scripts and patches that allows building Debian-based (so Debian, but also Ubuntu) images capable to boot on several ARM-based Single Board Computers (SBCs). Since ARM device does not have a standard way to boot and does not have a BIOS like x86 system, there is the need to support each SoC/board in its own peculiar way. Once you install Armbian, you have a full Debian (or Ubuntu) on your system, with some extra packages that make life much easier.
Loader mode: right!
Maskrom mode: right also, but the chip enters maskrom mode also when it does not find a valid bootloader in both internal and external flash memory, or using rkdeveloptool rd 3
 
True. This page is the official rockchip documentation with the official way to handle things.
Clearly the most important thing is to put a valid loader at sector 0x40 of internal or external flash, otherwise the SoC does not boot at all.
You can of course alter the flow at any point, for example the idbloader can be made of rockchip blobs (ddrbin + miniloader) or can be made of full opensource software (U-boot TPL + U-boot SPL).
If you use the rockchip blobs, you must of course put the things in the locations proposed by them, but in reality there is still a large degree of freedom.
The DTB exists because these boards don't have a Plug and Play bios, so devices and peripherals cannot be autodetected by the kernel, but must be described somewhere. The DTB describes the devices of the board: where they are mapped in memory, whose interrupts, dmas, gpios they use, and so on. This way the kernel drivers knows how to devices.
The "compatibility" of the DTB is determined by the kernel version: since the kernel drivers are modified during time the way to describe the resources trivially changes too, and so the DTB needs to be adjusted.
Kernel 3.10/3.14 are waaay too old and so many things changed, so it is totally a bad idea take a dtb of such version and
bring it to kernel 5.10 or whatever.
 
No, according to the rockchip boot page, the very first loader is ROM code in the SoC. It is going to do these steps:
check sector 0x40 on internal flash memory for a valid second stage loader and run it if possible check sector 0x40 on external flash memory for a valid second stage loader and run it if possible resign itself and go in maskrom mode No, absolutely.
Putting the multitool on the internal eMMC is pointless, since it is an utility to easily install Armbian on eMMC using an sdcard.
Just substitute the armbian image you want in place of multitool.img at step #4 and you're done.
Also step #3 should not be really needed, because the armbian image already contains all the proper things at the right places.
The storage map is just the default way to arrange partition proposed by rockchip when all their blobs are used, but as I said there is wide degree of freedom. Partitions also are often intended as "location where to place things", and not always proper partitions in the partition table.
Armbian, for example, has just a single ext4 partition because all those partitions are definitely not needed and I don't use the rockchip blobs at all except for the very first DDR memory initializer.
Multitool image, by contrast, uses the rockchip blobs but has two real partitions, and u-boot image and trust image are just at the "right places".
 
That never worked for me, also GPT partition table is also not really needed. You can use it to customize the various binaries locations, but actually I don't think you need to complicate things.
 
Indeed, when you're in maskrom mode the SoC is waiting for some valid code to run; it is not providing any service and no devices are initialized yet. The only command that works is rkdeveloptool db: only when you provide a valid loader (it is called usbplug in this case) the dram and emmc/nand subsystems are initialized and ready to be used.

I have a couple of questions:
- Is this storage map the one used by android, multitool, legacy and up-to-date armbian, or are they each using different maps?
- I found very few information about the GPT partition table, what to put inside and how to build the parameter_gpt.txt  file used by rkdeveloptool. Are there some pointers available?
 
I have also a strange thing: I am able to enter loader mode by wiping emmc, and everything works well (ie. test chip, read id, etc.). But when I enter maskrom mode, I have the correct PID/VID on USB, but all rkdevelop commands block (ie I have to press ^C to come back to shell).
This is the case either when I reboot by software (rkdevelop rd 3) or by hardware (ie. short emmc pins)
And when I reload multitool in emmc, it still gives kernel panic.
strange...
 
 
 

Thanks to all of you for your kind words! I also forget to thank all the other who helped
 
FYI I am French, 62, living now in Portugal, *soldered* my first computer (a Z80 Nascom ) at 19, and I have a good experience in embedded systems, electronics, network and system programming on various OSes.
 
@fabiobassa @Jock :
I tried to extract the dtb using PabloCastellano's extract_dtb.py, but it gave weird things. Thanks for your tool (I work on Linux and there was also a Linux version!). Using it with 2nd level decoding, and then using linux's dtc on Image/resource.img.dump/rk-kernel.dtb for my working android image gave:
 
But before taking the dtb route, I would like to fully reprogram this board from scratch, as I am sure that I did some mistakes somewhere.
especially:
GPT 0x63337df8 signature is wrong recovery gpt... GPT 0x63337df8 signature is wrong recovery gpt fail! At the beginning of the boot seems very bad!
 
I am new to those boards, knowing nothing from them 2 weeks ago, and the information is scattered in lots of places (is there a WIKI somewhere, as it is BADLY needed?), so this is what I understood:
The RK322X chips are done by Rockchip which assembles IP blocs licenced by ARM to make a SoC. ARM and the communauty provides compilers, linkers and the like. The box is intended by Rockchip to run under Android, and Rockchip tools are heavily biaised toward this environnement, with a lot of specific tools, and an old kernel (3.x and maybe 4.x). Armbian is a Debian distribution, adapted to run on Arm chips, which makes for a very diverse ecosystem, and follows the Linux track (new kernels, etc). Both environments do the same job, but there are many places where armbian and rk/android tools are not compatible. The box has a (set of) processors, RAM and flash plus various peripherals, some of them being integrated in the SoC. The flash can be Nand, or eMMC (which is nand plus a controller taking care of many details, including bad blocks and wear levelling). As seen from the software, flash is a linear vector of blocks (of typically 512K each) which can be R/W with only this granularity. All of them have a (usually hidden) serial line, that runs @ 115200 bauds, and gives lots of system information. Putting Linux on this box consists in reprogramming fully the flash, and this is done using an *image* (extension ".img"). It can be flashed using RK tools (rkdeveloptool for linux) directly on the chip through USB, or by crafting an sdCard which will do the job. The RK322X has 2 reset modes: Loader mode which allows only access to flash above 0x2000*0x200 maskrom mode which allows for full access. The chip enters maskrom mode when it cannot read flash; that can be accomplished  in a wild way by shorting pins 8 and 9 of the eMMC chip at boot (which is why RK322X chips are nearly unbrickable) The boot sequence is complex: Execution starts first with a miniloader (? at a certain offset in flash?) whose job is to load a 2nd level loader (?located at another offset in flash?) called u-boot. U-boot is based on Das U-Boot modified by many people. All of them are more or less compatible, with subtle differences. They have one thing in common, which is that a ^C on the serial line stops the boot and gives a CLI. The Job of uboot is to load the Linux kernel in memory, and start it using a command line with various parameters. One important parameter is the DTB, which indicates to the kernel (drivers) the hardware details. This is a binary blob (.dtb) compiled from various source modules (.dts). The armbian and android dtb are similar but not compatible. They can be decompiled by (mostly uncompatible) compilers (dtc in linux). Another important parameter is the offset in flash of various filesystems. Then he kernel starts... An image is the concatenation of various blobs according to a certain format. Armbian and RK images are NOT compatible, as they don't have the same numbers and type of blobs, and so require different sets of tools (?which ones?) Is the 1st-level loader (?located at offset 0 in flash?) part of the armbian image So, in order in order to *fully* reflash my box:
Manage to enter maskrom rkdeveloptool db rk322x_loader.bin rkdeveloptool ul rk322x_loader.bin rkdeveloptool wl 0 multitool.img Am I right or should I have missed something?
 
Michel
 
 

@gurzixo

Ciao Michel, welcome in this valley of tears lol lol lol
Well, another lovely board with no SD reader and this makes the whole story a bit complicated , but not impossible to solve.
Ant thank you so much for photos and serial uart log, this really helps

The kernel as you can see is starting and the kernel panic could be for wrong trust_os, wrong dtb, not mounting the root fs ,one only or all 3 causes lol
If you have original firmware you can extract the pieces and in particular dtb with this tool
RK3xxx_firmware_tools_5.23.1_by_SergioPoverony.zip
(google for it ) but I guess you have nothing of different from other boards with ddr3 and emmc

Let's wait @jock for further infos on how to approach at this rare study case but I can say to you for sure that it will boot

You are new so cannot post many posts in the first days , you must wait I believe one day for other post.
And don't forget to click a " like" ( the heart icon) for helping good reputation of authors
Where are you from if I can ask , and have you some skills on linux so it will be in some manner easier?
 
EDIT:

I attached a command line CLI only windows tool to extract pieces from a firmware , try it please
 
imgRePackerRK_106.zip

OHHHH and finally here it goes 

Bravo Alex, but more bravo Jock

@rlukas210

hello and welcome on this 3ad
would you be so kind to provide us some photos of your board , thank you so much !

And you are newbie so you must wait one day for replay ( forum rules    )

Erasing the NAND with rkdeveloptool was not a smart move, as you noticed right now the NAND is not detected anymore.
First of all, be aware that everytime you reboot the box, unplug the power cord and detach the serial connectors from the board if you have them attached: NAND boxes are very sensitive to even the lowest current.
As long as you tried both Armbian and LibreELEC, you should specify what image you did try: forget the mainline kernel images, they won't work with NAND because there is no driver. You must use legacy 4.4 kernel images.
 
From my point of view, as long as you erased the flash (thus removed the original idbloader), you may do something smarter and use the sdcard to understand if legacy kernel Armbian/LE boots from sdcard or not.
If it is not booting, you need to attach a serial adapter and take some logs because something wrong is happening and the kernel is not able to boot.
Note that probably you will need to erase the flash again if you installed a non working idbloader to make the board boot from sdcard without interferences.
 
Instead, if Armbian or LE are booting fine from sdcard, proceeding to restoring the NAND functionality can happen.
 
As @fabiobassa said, photos and signatures of the board as useful to understand if it is a known board or similar. I have an MXQ Pro 4K tv box right here and it looks similar to yours, but the commercial name is worthless since the board inside may be of a different revision with different components.

@dale
since you are able to manage linux and linux command , you can enjoy yourself with a chron command too:
a simple bash script that in the morning at 8:00 ( or when is usefull for you) does a
echo default-on ( ot timer or heartbeat or cpu0 ) >>> /sys/class/leds/here_the_name_of_your_led/trigger  
and the at 20:00 ( or when is usefull for you) does a
echo none ( ATTENTION: none and default on " could be inverted as logical but you will realize it by yourself ;-) ) >>> /sys/class/leds/put_here_your_led_name/trigger  
If you are electronic skilled, too, you can even control something with a simple transistor and a relay attached to that led
 

@dale
 
ty so much for sharing your experiments. This helps  @jock and me to better understand behaviour of some boxes that haven't sd card reader , ddr3 and nand.
The u-boot legacy we realized have some difficult to proper initialize the usb: it's random failure so quite difficult to debug, maybe jock will investigate further or/and rewrite some pieces of code to proper start USB subsystem but this requires it's time. For now we are glad your board is functional

@Seth
ty for sharing the dtb and your experiences, too

@fabiobassa
well, i'm gonna tinker with it a bit more and post any progress. i put files there for others to use as reference just in case they encounter same problems as mine. cheers.
 
 
 

Hi @jock,
Play around with rockchip tv box is always such an interesting thing.
I tried to boot off usb drive with 3 types of image:
1) same with image flashed into NAND (buster legacy) --> Armbian could boot from usb drive
2) focal legacy image --> could not boot armbian just ignored the usb drive and booted right from NAND
3) Multiboot --> could not boot, armbian just ignored the usb drive and booted right from NAND
 

@dale
Glad everything is working . Later personally will investigate vwhy multitool doesn t work as expected 
And don't forget help good reputation of authors with a simple like, thanks !
 
@Seth
What exactly do you want to achieve now?
Maybe I missed something
 
 
 
 
 

@dale
Glad everything is working . Later personally will investigate vwhy multitool doesn t work as expected 
And don't forget help good reputation of authors with a simple like, thanks !
 
@Seth
What exactly do you want to achieve now?
Maybe I missed something
 
 
 
 
 

@hexdump
thanks. i managed to get device tree from android box. nice guide.
 
@jock
i got the dmesg, will upload tomorrow, i need some sleep.
 
@fabiobassa
box is working fine as headless super router at the moment, running soho dhcp, dns server/cache, squid transparent proxy/cache. will slowly try to improve it as i learn more about these little things. i remember, i used to install debian/pfsense on old p3 and p4 boards just to get a reliable mega router/firewall and run squid and squidguard on em. now i can do that at the fraction of the size and power consumption. Just when i thought those boxes couldn't get any wierder.
 
I found an s9012.ko in /lib/modules folder btw.

@Seth

no worries, feel free to ask as many info as we are able to explain
Consider that dtb isn't related only to rockchip so studying, understanding them will help ALSO with rockchip but not only with them ( also with allwinner, amlogic )
The kernels @jock compiled ( both legacy and main) are already optimized for having all out of the box in MOST cases but of course new devilish boxes can appear on market
I am sure your box will work

 

@Seth

what do you mean extract config from original firmware?
behaviour of led are defined in the dtb PLUS kernel : example I have my two leds one is just heartbeat and the other is emmc ( or cpu0 ) activity just because it remembers me a spinning hard drive. This is my PERSONAL approach in the dtb just an example
 
gpio-leds { compatible = "gpio-leds"; pinctrl-names = "default"; pinctrl-0 = <0x75>; blue { gpios = <0x3f 0x7 0x1>; label = "blue"; linux,default-trigger = "timer"; default-state = "off"; }; red { gpios = <0x6e 0x15 0x1>; label = "red"; linux,default-trigger = "cpu0"; default-state = "off"; };
Regarding hdmi it should work out of the box

as @hexdump said the original dtb would be great help

@Seth - it might be good to get the dtb from the box - in case no other way works, this approach so far worked for nearly every android tv box for me: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
 
good luck - hexdump

@dale

hello dale, would you try this loader and give us feedback , please
 
RK322XMiniLoaderAll_V2.47_spectek_en_ddr2_rd_odt_171127.bin

Good day @fabiobassa, I feel so dumb now. Re-reading the messages I found this one from @hexdump. Turns out, this was the key to make it work. I stupidly focused in more complex (for me) instructions. 
 
I have succesfully booted the device with Armbian, lacking wifi support. I found out that LibreElec loads the module for rtl8723bs and works fine. So now I'm looking into compiling that module for the kernel. Another thing I noticed is that the kernel "sees" only 1GB of RAM, not 2GB of RAM. But those are things I will try to workout once I manage (if I manage) to compile the kernel succefully .
 
Thanks again for your patience and dedication. If you need any information from my device let me know.
 
Once I get all working I would let you guys know!