Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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!
  2. Boa noite KSilva! (I'm French, but I live in Algarve...) I was in the same case as you, knew nothing about those boxes and rochchip, but, with the STRONG help of fabiobassa, I have been able to resuscitate a few of thoses boxes, and at least for some of them, able to have a stable Linux. A few questions: - Are you "fluent" in Linux and windows, do you have a windows system available? - Do you have some experience in electronics, microprocessors and microcomputers? - Do you have experience with serial connexions? My recommendation for you: - grab a male-male A-A usb cable, a micro (I mean MICRO) screwdriver, and a high magnification magnifying glass. - Open your box, take good quality pictures of both sides of the PCB and put them on the forum. - The 2 next steps are: put the box either in Rockchip (ie. Loader) mode or in Maskrom mode, and try to connect a serial line to the box serial connection (1500000-N-8-1) to get console log, as this helps A LOT. (all cards have 3 or 4 plots for that: Gnd, Tx, Rx, Vcc . We can help you find that on the pictures; you will need a serial adapter, some thin wires that you have usually to solder on some pads and a com program - minicom works very well) - After that, you will have to flash some firmware using the USB to USB OTG cable. - Even if you prefer Linux (that'salso my case...), I suggest that you use windows for bringing back your box alive, as W tools are A LOT more complete, and also windows emits a sound when a new USB device is recognized, which helps a lot. This page explains the boot process. You can grab your stock firmware on this page . The archive of firmware contains RKDevelopTool.exe, which is used for flashing firmware. You can grab also some more Rockchip tools here Here are the main points that I understood: - Armbian and Rockchip/android firmwares are RADICALLY different, and their boot process are INCOMPATIBLE. Conceptually, they are similar, but takes very different approaches. - Let's detail the RK approach, which is very basic, unsophisticated and pragmatic. The image in flash contains the following elements at FIXED addresses, from bottom to top of flash: - A "partition table", (Parameter in RKDevTool) which indicates the addresses of the following blobs (with extension .img) - Loader, closed source called after reset by the HW of the processor. - The "trusted bloc", closed source, which performs some needed magic... started by the loader - The RK uboot, started by the trust module, which is similar to the BIOS for PC, and contains an interactive monitor, that you can start by entering a char on the serial console; otherwise it continues the boot. - The Device Tree Block (DTB, called "Resource" in RKDevTool)): this is a binary blob which contains all the details and parameters of the hardware. it is compiled from source, and is COMPLETELY INCOMPATIBLE with the Armbian DTB. This allows to have a standard kernel, which is the same for all boxes. - The Linux kernel, started by the uboot, with a command line indicating where in flash to find the DTB, the Boot partition and the root file system. - The Boot partition - The Root partition (called "System" in RKDevTool), containing the Linux userland. On android, there are other blobs, used for backup and recovery, in case something goes wrong. All those blobs are usually packed together by the above RK tools, to create a complete image. RKDevtool allows you to flash each of those blobs in a specific place in memory, erase the memory, do some low level tests or flash a complete image. I will detail some practical instructions on a next post.
  3. 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...
  4. 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
  5. Dear all, I have a few TV boxes, both amlogic and rockchip, and was able to install Armbian on many of them (with lots of blood, sweat and tears... Thanks a lot to Balbes150, Jock and Fabiobassa for all the superb work and the gold nuggets that they left in the various threads!!!). I am struggling now with a T96mini_V1.0 ( see https://pasteboard.co/JTEA7XS.jpg - I don't know why I can't insert pic in post...) which has an RK3228A (2G-16G). And has NO sdcard, I followed advice from the 1st post, but black screen... I want to use it as a headless linux server, so I don't care about media performance, but WIFI would be appreciable (see pic of chip: https://pasteboard.co/JTELgqj.jpg ) OK, so I found the serial console, soldered some wires, and saw a boot entirely in chinese... so no cues about dtb. I still have an android image that boots ok, so maybe I could extract DTB?. (Very) long story short, I was able to burn multitlool in emmc, and boot either from usb or emmc, but I get kernel panics every time (see below). I suspect that I have a wrong DTB, which does bad things... Here is the boot log, using a toothpick to boot the multitool image from usb: When booting from emmc, most of the time I have nothing after "Booting kernel, and sometimes some kernel traps. Any suggestions or pointers? Cheers, Michel
  • Create New...