[unoffical] LE-9.2/9.80-Images for RK3229/RK3228

    Hi,

    that's the board that I successfully booted from SD card using Legacy LibreELEC-RK322x.arm-9.2-devel-20200427220345-b7186bc-rk3229-hk1mini.img.gz image (first image I tried).

    Then I tried with Mainline LibreELEC-RK322x.arm-9.80-devel-20200228171244-cd590c7-rk3229-box.img.gz but it didn't boot (blank screen on HDMI).

    Board is definitely RK3229, has 8GB NAND flash and 2GB DDR3.

    Any clue where to start investigations ?

    many thanks

    The best thing you can do to investigate is getting the TTL serial up and running to see what happens during boot process. I see that unfortunately you have RX/TX/GND pads, which are a bit more difficult to solder than regular holes, but it is much better than nothing at all.

    These boards often are not what they say they are: we spotted several chips with "rk3229" markings that are in reality rk3228 chips.

    Indeed you have a NAND chip on the board, and be aware that it is not yet supported by mainline kernel, so if you installed the image with mainline kernel in the internal flash it will absolutely never boot.

    Hi Jock2, many thanks for your answer.

    Yes, I know it's a big mess with these boards.

    Imagine that my board was supposed to be an Amlogic S905W with 16 GB EMMC !

    So I didn't dare to flash the internal NAND and just played around with SD cards.

    By the way, I couldn't boot form multiboot either so I can't use Step-nand and for the time being I will stay with the legacy image on SD card.

    For those who have a similar board and are interested in original stock android firmware, I've made a full dump of android rknand partitions from an ABD root shell.

    Here is partitions layout:

    gianni253 multiboot not booting is quite a news to me. It should indeed boot and let you do maintenance, it is one of its design goals. Also it uses the legacy rockchip kernel, so there is something weird happening with your board.

    At this point the output of the serial is mandatory to do some decent debugging.

    @jock2 I tried multiboot (latest version) many times and with repeated power cyclings but no success.

    When I have time I will solder the 3 pins for jtag and make the serial debugging.

    BTW, should I set 5V or 3,3V as TTL level ?

    Quote from gianni253

    @jock2 I tried multiboot (latest version) many times and with repeated power cyclings but no success.

    When I have time I will solder the 3 pins for jtag and make the serial debugging.

    BTW, should I set 5V or 3,3V as TTL level ?

    3,3v should be fine, but it's not a jtag but a simple serial port.

    Be sure to burn the image on a perfectly working sd card with a proper sd burner like balena etcher, which is able decompress and verify written sectors automatically.

    If a led is blinking it means that the kernel is alive and you should see something on the HDMI.

    If the leds are turned off or dimmed it means something is wrong during boot.

    If the original firmware starts, either the box has a very old firmware or the sdcard is somehow faulty

    Ok, some serial debugging on my board.

    Stock android firmware on internal NAND:

    Boot from well tested Samsung 32GB SD card, multitool image written by Balena Etcher

    Red LED in on (solid light).

    Blue LED is off.

    Multitool image downloaded from Armbian thread CSC Armbian for RK322X TV Boxes - Rockchip CPU Boxes - Armbian forum

    Thanks for the log, but the one booting Multiboot is incomplete. After booting the Trust OS, Multiboot changes the serial speed to 115200 for broader compatibility.

    Indeed the Multiboot is booting, the red led solid light is a very bad indication of something gone wrong during the kernel initialization.

    Maybe there are useful kernel panic messages, but you should grab a log setting the serial to 115200.

    I connected network on the fly, when I realized it was trying to boot from network.

    gianni253 it looks to me that for some unknown reason, u-boot does not detect the sdcard. This is the first time I see such issue and the log is not detailed enough to say what is going wrong.

    Anyway I can suggest an untested workaround that maybe works: put the multitool (with the libreelec image in images folder) onto an USB stick too and boot with both sdcard and USB plugged in USB OTG port. Maybe u-boot will be able to detect the multitool in USB stick and finally boot from there.

    BTW, I'm not sure libreelec 9.2 images works when booted from NAND, I have a far memory that once I had it working, but have had to do some little adjustment Just tested, the V88II mars image works fine with NAND and should work fine with your box too (use the standard "Burn image to flash" Multitool menu option, select "Yes" when asked to skip idbloader burning)

    Edited 3 times, last by jock2 (February 28, 2021 at 10:52 AM).

    @jock2

    your guess was right, now with both sdcard and usb stick, mutiboot could finally complete boot process.

    Here's the log:

    Your next advice was to flash a Libreelec image (V88II mars) to NAND but have some questions:

    1) wouldn't it be wise to try to boot from sdcard first ?

    2) what's my way back to restore stock android ?

    3) according to "Quick installation instructions on NAND" on Armbian forum, shouldn't i choose "Burn Armbian image via steP-nand" ?

    gianni253

    ciao gianni, buongiorno, good morning.

    Trying to answer to your questions is not easy .Those rk322x boards comes in such great variety ( 3228 3238a 3229 nand emmc ddr2 ddr3 ) and each of those has a specific boot process. The "worst" ( let me use this term ) are 3228 ddr3 nand because they use a very specific idbloader ( very very first stage ) , a common u-boot and a very specific trust-os to get the dmc ( ddr scaling ) function on

    knaerzche did a great great job to cover most possibilities in booting on different platforms but still evil could happen

    1) yes the process tries to boot from sd first, then from usb ONLY if you use a modified uboot ( the one present in multitool ) .

    And then the process take in charge kernel and his drivers that finally recognize internal nand ( with emmc is easier)
    But if you erased everything well the boot process will follow other path because your nand now is an empty container

    2) grab your original android stock firmware and burn it with AndroidTool_Release_v2.67.zip ( google for it) . it is for window and it will put the right things in the right places ( idbloader, u-boot, trust etc etc ) and you will have android back on your box
    If you did a ADB backup You still need a piece called parameters.txt to " teach" the tool to put the various pieces in the right places.
    better flash WHOLE stock firmware.
    But why go back on android if you want to approach LIBREELEC ???

    about point 3 I suppose jock can answer better since the early stage of the boot process is similar on armbian and libreelec

    Quote from gianni253

    Your next advice was to flash a Libreelec image (V88II mars) to NAND but have some questions:

    1) wouldn't it be wise to try to boot from sdcard first ?

    2) what's my way back to restore stock android ?

    3) according to "Quick installation instructions on NAND" on Armbian forum, shouldn't i choose "Burn Armbian image via steP-nand" ?

    1) Indeed, it is much safer to try booting from sdcard first, but you should be able to do so just putting the LibreELEC image on and sdcard and plugging the cord; it should boot without any further procedure from sdcard. (Armbian instead requires some different setup because it uses a different bootloader arrangement)

    2) If you kept the NAND data as it was, Multitool backup and restore feature will let you backup almost entirely the content and restore will bring back Android in the very same state you left it.

    To add some further details, the NAND driver in 4.4 kernel will not let you backup the idbloader part of the NAND, which is the very first 0x2000 sectors, but it also does not allow to write those sectors, so tinkering with the Multitool is generally safe.

    As further info, not directly related to the answer, the idbloader is very important on NAND devices because it contains code specific for the NAND vendor, thus if you lose the idbloader, you NAND data probably becomes garbage. But once you do a backup from Multitool, the Android part of the firmware is safe.

    There is also a procedure that uses the AndroidTool for Windows that allows you to burn the original firmware from the image file, I don't remember quite well the procedure, but fabiobassa probably may help you there. Note that this procedure will do a factory reset, so you lose your existing data too.

    3) No, because the steP-nand procedure is just for Armbian. Armbian needs to be "relocated" some sectors farther on the flash memory because of the different bootloader I talked about in answer #1. LibreELEC does not need such relocation, thus can be burned as is: just remember to say "Yes" when the Multitool will ask you to skip the idbloader (ie: the reason I explained in answer #2: NAND kernel driver can't write those sectors).

    fabiobassa

    Ciao Fabio, hi Fabio,

    many thanks for your clear explanation about boot flow sequence.

    Well, I really would never go back to android unless something with LibreElec flashing goes wrong and I need to unbrick the device.

    I've learnt (and you confirmed this too) that cause this great variety of devices it's quite hard to develop a firmware that suits all situations and, for example, I have experienced that I can boot from MultiTool only in presence of both sdcard and usb stick (quite unusual, isn't it ?).

    The only backup I have right now is partitions backup taken with single ADB commands such as "dd if=/dev/block/rknand_system of=/path_to_sdcard/system.img".

    These backups came really handy to me when I needed to restore system partition after a bootloop or recovery partition after flashing a non working TWRP, but I miss parameter.txt so I want to follow your advice to take a FULL NAND backup to be restored using AndroidTool.

    Even after a long search, I couldn't find on the net a copy of my android stock firmware so I need to dump it from my board, something that can be reflashed by AndroidTool. But how can I take this dump ?

    jock2

    Hi Jock2,

    many thanks to you too ! I've learnt so much in these few posts !

    So you suggested Multiboot as backup tool for android stock and i will surely take a dump with this method.

    And thanks also for clarification that steP-nand procedure is just for Armbian so I will use MultiTool (with idbloadr skipping) to flash NAND.

    Hello! This is my first post here (english isn't my native langage).

    A friend of mine gave me a mxq-4k box (that's the only thing written on that box so I suppose it's not the pro version). It currently runs Android 7.1.2 and it can play Netflix but only on low resolution.. After some researches, I found that it may be possible to run Netflix on better resolution (1080p is what I need) using Coreelec + netflix addon.

    It appears my box has Rockchip rk3229 (I used Aida64 app). I tried A95XR1, V88Mars and MXQ 4K Pro images and always the same result:

    I use Rufus to burn image on my sd card and when I insert sd card into the box, no hdmi signal and the power led is blue. I tried to rename dtb file to dtb.img (I think that's what must to be done) but same result. I also tried with a terminal emulator app: su, then reboot update but it always ends with no hdmi signal and blue led.

    Maybe someone could help me? Is there something I did wrong? (noob here sorry) Or is it just my box is not compatible?

    Thanks.