Jump to content

gurzixo

Members
  • Posts

    5
  • Joined

  • Last visited

Reputation Activity

  1. Like
    gurzixo got a reaction from dale in CSC Armbian for RK322x TV box boards   
    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.
     
     
     
     
     
  2. Like
    gurzixo got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    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. Like
    gurzixo got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    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!
  4. Like
    gurzixo reacted to fabiobassa in CSC Armbian for RK322x TV box boards   
    @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
  5. Like
    gurzixo reacted to jock in CSC Armbian for RK322x TV box boards   
    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.
  6. Like
    gurzixo reacted to fabiobassa in CSC Armbian for RK322x TV box boards   
    that is for android 3.10.xxx and we are on kernel 4.4.xxx and yes .. we already have that too
  7. Like
    gurzixo reacted to fabiobassa in CSC Armbian for RK322x TV box boards   
    @rlukas210

    yes your board is well known and also quite good supported.
    I am happy and satisfied it is working now
  8. Like
    gurzixo reacted to jock in CSC Armbian for RK322x TV box boards   
    Keeping android on emmc is not supported because requires some additional steps and a different bootloader arrangement.
  9. Like
    gurzixo got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    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...
     
     
     
  10. Like
    gurzixo got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    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
     
     
  11. Like
    gurzixo reacted to fabiobassa in CSC Armbian for RK322x TV box boards   
    @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
  12. Like
    gurzixo reacted to jock in CSC Armbian for RK322x TV box boards   
    @gurzixo hello. Yes, your board is doing absolutely weird things.
    This is a rare situation I yet have to understand why it happens. I have a board with rk3228a that runs for days without any issue on legacy 4.4 kernel, but crashes immediately with messages similar to yours if I use the mainline kernel.
    I tried almost everything I could think about on that board to solve or at least mitigate the issue, but with no success.
     
    If you could extract the DTB, it would very helpful for clues that may explain what is happening.
    The multitool DTB is a very basic DTB that should work on all boards, it is designed to be very compatible and usually works on most boards without complaints; the only testing thing I can imagine is to disable the vdd_log and vdd_arm regulators and removing/disabling the cpu operating frequency table to avoid frequency scaling.
     
    I already did such experiments on my rk3228a board, but it did not improve stability at all, suggesting the issue is probably elsewhere.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines