fabiobassa

@elbuit cool, thanks!
Your board has a nice ap6255 wifi chip, looks life a fully fledged awesome board!
 
The original dtb is always welcome, as usual if you feel that something is not working as expected report here and we will see what can be done (I suspect bluetooth is the worst offender  )

Thanks for reporting!
 
rk3318-config script should have been integrated into the image, but I checked and you're right, it's not there!
I have to check why the script has not been included in debian image, but in the meantime you can download it from here , give the execution rights and execute it.
 
Could you please post photos of the board?
Thanks!
 
 
 
 

It is all thanks to you, @jock and other people from this great forum. The desktop experience is noticeably better then rk3229, 
OpenOffice Calc starts in 6s, GIMP in 13 (afer reboot), this forum page reloads in 10s in chromium. It feels a bit laggy but still very usable. 
On the other hand, working via vpn on remote windows desktop is just comfortable. I'm considering to use it as cheap, preconfigured box for remote employees in the next covid wave.

My board is equipped with 4GB RAM, 64 GB emmc. Armbian Focal current is correctly discovering those resources. Although wifi chip supposed to be AP6334/BCM4334 is realiy an AP6330/BCM4330

@ArkhanLK

I met @jock on the net quite TWO 2 years ago , when  I started this adventure with 322x boxes and for some LONG time my question was always the same:
how obtain a good desktop experience and at the same time a good harware acceleration for playing videos on this boxes and infamous mali 400 driver.
The answer is not so nice : at the state of the art OR you have a decent desktop, OR you have good videos. Both is still problematic.
To have full video HW acceleration in some manner is needed switch off the desktop and go on GBM driver. And also I suspect you cannot use exynos driver on your board.
An old attempt done by rockchip itself to have a satisfactory both xorg and video experience was made on debian 9 stretch and modded gstreamer and MPV player
This is how xorg.conf looks like:
name of the file : 20-armsoc.conf
content :
 
Section "Device" Identifier "Mali FBDEV" Driver "armsoc" Option "fbdev" "/dev/fb0" Option "Fimg2DExa" "false" Option "DRI2" "true" Option "DRI2_PAGE_FLIP" "false" Option "DRI2_WAIT_VSYNC" "true" Option "SWcursorLCD" "false" EndSection Section "Screen" Identifier "DefaultScreen" Device "Mali FBDEV" DefaultDepth 24 EndSection
but i repeat this worked on old debian 9 stretch rootfs and allowed play decent videos ( but losing the mouse control for a while...   )

And this APART of broken dm greeter, that is another problem

Instead of using Volumio or Daphile, I installed Armbian_21.05.1_Rk322x-box_buster_legacy_4.4.194 to a MXQ Pro box. The box was shipped with Android 7, and I installed Devinfo to check if it is eMMC or NAND. It is lucky that my box equipped with eMMC, so I installed the OS easily. After that, I did some following steps:
1-     Run rk322x-config: I select CPU 3228B-1.4 Ghz, board 322x MXQ, wifi ssv6X5X
2-     Run nmtui to setup wifi connection
3-     Armbian-config: to add something such as infra red
4-     Set default sound card:
hai@rk322x-box:/etc$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: DWI2SHDMI [DW-I2S-HDMI], device 0: 100c0000.i2s0-i2s-hifi i2s-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: SPDIF [SPDIF], device 0: 100d0000.spdif-dit-hifi dit-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: DAC [USB Audio DAC], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: ANALOG [ANALOG], device 0: 100b0000.i2s1-rk3228-hifi rk3228-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
It means that my USB Audio DAC is card 2.
I revised /etc/asound.conf to make it contain only 2 lines
defaults.ctl.card 2
defaults.pcm.card 2
You can verify with alsamixer : it should display USB DAC as default.
5-     Install mpd and edit /etc/mpd.conf
…
# I will use usbstick to store the songs
music_directory         "/mnt/usb"
…
#you can set static IP for music server or add “any” as the address
bind_to_address         "any"
The other lines can be left as default
6-     Automount USB
Edit /etc/fstab to add the following line
 UUID=689E-CF4D /mnt/usb vfat defaults 0 0
Youn can find your usbstick UUID with sudo blkid
7-     The most difficult section is configuring infra red. Now lirc and /dev/lirc0 have been obsolate. We will have to deal with gpio_ir_recv (you can check with lsmod)
There are 2 steps here:
a-     Map the key name with keycode of your remote controller.
b-     Config a daemon to do the action you want while received the keycode.
At first, you should know which device is belong to your ir receiver.
hai@rk322x-box:/dev/input$ ll /dev/input/by-path/
total 0
lrwxrwxrwx 1 root root 9 May 21 21:17 platform-200a0000.hdmi-event-mouse -> ../event0
lrwxrwxrwx 1 root root 9 May 21 21:17 platform-30120000.usb-usb-0:1:1.2-event -> ../event2
lrwxrwxrwx 1 root root 9 May 21 21:17 platform-gpio-keys-event -> ../event1
lrwxrwxrwx 1 root root 9 May 21 21:17 platform-ir-receiver-event-mouse -> ../event3
In this case, /dev/input/event3 is my ir
And then I can run this command to check ir code:
hai@rk322x-box:/dev/input$ ir-keytable --device /dev/input/event3 -t -v
Opening /dev/input/event3
Input Protocol version: 0x00010001
Testing events. Please, press CTRL-C to abort.
1845.720102: event type EV_MSC(0x04): scancode = 0x113
1845.720102: event type EV_SYN(0x00).
^C
It will wait for you to push a RC button and show the code (0x113). After that, you can create a file to map keyname with keycode. I edited /lib/udev/rc_keymaps/samsung.toml
[[protocols]]
name = "samsung"
protocol = "nec"
variant = "nec"
[protocols.scancodes]
0x140= "KEY_POWER"
There are many *.toml files in the same directory, you can refer them to find the correct keynames.
Next, to make it consitent, you can edit /etc/rc_maps.cfg (its header guided you very clearly)
Add this line: gpio_ir_recv * /lib/udev/rc_keymaps/samsung.toml
 
Regarding step b, you should install triggerhappy.  
To config it is very easy. Just create a file under /etc/triggerhappy/triggers.d (any filename)
My file contains only one line: KEY_POWER 1 /usr/sbin/init 0 (use key power to shutdown the box)
 
Finally, you can test
sudo  ir-keytable -c -w /lib/udev/rc_keymaps/samsung.toml --device /dev/input/event3
Old keytable cleared
Wrote 1 keycode(s) to driver
sudo thd --trigger /etc/triggerhappy/triggers.d/ /dev/input/event3
 
If it can work well, you just need to reboot the box!
 
Important note: If you use MXQ as an audiophile music box, you must connect it to a linear power supply. Never use its equipped power adapter or any other pulse power supply.
 

armbian-config is not available in minimal installations, but you can install it via apt if you need it's configuration capabilities. It allows you to install software, desktop interface, configure timezones and locales, install Armbian to internal flash and lot's of other things. See the armbian documentation if you want further details.
 
You can do whatever you want with your box, you have a fully working debian linux box now.

good news, today I succesfuly compiled the openvfd driver.
This is my DT Overlay:
/dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { openvfd { compatible = "open,vfd"; dev_name = "openvfd"; openvfd_gpio_clk = <&gpio2 0x13 0x00>; openvfd_gpio_dat = <&gpio2 0x16 0x00>; openvfd_gpio_stb = <&gpio2 0x12 0x00>; openvfd_chars = [04 00 01 02 03]; openvfd_dot_bits = [00 01 02 03 04 05 06]; openvfd_display_type = <0x03>; status = "okay"; }; }; }; }; Driver is working without any changes.
 

Hello all nice people, let me do this post since I repute it very important.
There is a lot of people actively deploying things on rk 322x and rk 3318, some  media oriented things ( libreelec, kodi ) some desktop and servers applications.
Now.......it happens that @jock and my self are actively working on those two platforms because I was so lucky in the past to buy for really few bucks ( and i say FEW )  more than 50 different boards reputed faulty, and there were not, just wrong firmware.
But in this big STOCK of boards mostly were 322x ( 3228 3228a 3229 ) and ONLY ONE was 3318,and again I repeat just ONE 3318
 
So it happens that quite EVERY  question on 322x we can answer with sufficient level of accurancy, but on 3318 our experience is limited on HK1,  that is a circle box without display.
Every single help, every single uart log, bootlog any elselog is a mine of infos for us, in particular @jock , but at the same time is really hard provide you a satisfactory answer without debug info, our crystal ball is actually broken

Help us to help you providing as much infos possible and not just saying " it doesn't boot" because in that way is a hard stuff to solve.

Thanks

 

Hello all nice people, let me do this post since I repute it very important.
There is a lot of people actively deploying things on rk 322x and rk 3318, some  media oriented things ( libreelec, kodi ) some desktop and servers applications.
Now.......it happens that @jock and my self are actively working on those two platforms because I was so lucky in the past to buy for really few bucks ( and i say FEW )  more than 50 different boards reputed faulty, and there were not, just wrong firmware.
But in this big STOCK of boards mostly were 322x ( 3228 3228a 3229 ) and ONLY ONE was 3318,and again I repeat just ONE 3318
 
So it happens that quite EVERY  question on 322x we can answer with sufficient level of accurancy, but on 3318 our experience is limited on HK1,  that is a circle box without display.
Every single help, every single uart log, bootlog any elselog is a mine of infos for us, in particular @jock , but at the same time is really hard provide you a satisfactory answer without debug info, our crystal ball is actually broken

Help us to help you providing as much infos possible and not just saying " it doesn't boot" because in that way is a hard stuff to solve.

Thanks

 

@Dragao, for better understanding - you have a two options:
 
1) Boot from external media (SD Card or USB key) - in this case you need only to write the distro image to the media and put it into box and boot. After booting you can run rk3318-config to configure additional devices (wifi, led, ...) In this case MultiTool is not required.
 
2) Boot from internal eMMC - in this case you can use MultiTool to flash the distro image to the internal eMMC, and boot.. Again you can use rk3318-config for further tuning.
 
Both options are described in the first post.
 
I think, you don't need to manipulate dtb/dtbo manually, also I think MultiTool do nothing with dtb/dtbo..
 

After 20 tries i finally managed to select the Erase option from the Multitool and it actually let me select the eMMC partition, but afterwards i restarted the box and now it doesn't boot anymore :/ wth

@gnusmag45
don't worry about english , me too I'n mot native.
Ok let' s see what @jock suggests about this emmc related problem
And PEOPLE don't forget to put a simple like  ( the heart icom ) to help good reputation of people here.

@gnusmag45 
read again the 3ad , all infos, you will see that  some boards came with NAND and not EMMC and I guess this is your case.
You should follow the STEP-NAND instructions instead and see if this fits to you

Sometimes disreputable manufacturers will modify the kernel in the android firmware to provide false information. (easy way to cut costs by not actually including the memory/storage advertized).

This was not helpful. The boot stucked at the same point - ALERT! UUID=bla bla bla does not exists.
I checked the USB key and really - the partition UUID was different than in the armbianEnv. I don't know how UUID was changed. Sorry for my mistake.
So I flashed the image to the USB key again an successfully booted from USB... (overlay was not necessary for boot).

Armbian project does not officially support nor maintains tv boxes. Armbian project maintains only supported Single Board Computer (SBC) devices. SBCs have stable hardware (kind-of), and are usually well-documented.
 
Tv boxes are another thing.
In the ideal world of the naked puffy angels chanting melodious high-tone songs, the organization you proposed would be perfect.
In our world full of crap, dirt and oil it does not work at all: every chinese tv box manufacturer buy chips at the lowest price point possible on the market and put all that crap and scrap on these boards. If you read carefully the first post (and I invite you to do it) the very same rk3318 is probably a scrap chip, and eMMC chips are often failing after a while, some because are faulty, some others fail because of crappy soldering (you can ask @fabiobassa how many faulty eMMC chips desoldered from these boards).
 
That's why Armbian does not officially tv boxes: it's a community matter, because keeping the things working with a huge hardware variety is just too difficult and very time consuming.
In a world were everything can fit onto these boards, having one image for each box is unthinkable; I preferred a more elegant solution that allows the user to download a single image with a basic configuration that (hopefully) boots on every board with the same SoC. Once installed, the system can be further configured by the user herself to enable all the features of the board, like higher cpu speed, wifi, bluetooth, eMMC higher speed modes, leds, buttons, etc... etc...
 
You won't find images of mine spread here and there on the forum, usually I publish images just on the first page of this thread and sometimes I prepare some special testing images for someone who has willingness to help the development progress. When everything will be stable enough, I will ask for merging to the main Armbian project, so the images will not be built and published anymore by me, but the Armbian server will build (and certify) them and they will be available in the official download page, but still totally backed and maintained by community efforts.
 
You will find everything you need to get the thing running on the first page of the thread, so read that carefully and, if you're not satisfied, steer away from tv boxes and search for a proper SBC.

I forgot to attach the serial logs..
serial_boot_internal.log serial_boot_USB2.0.log

­DISCLAIMER (PLEASE READ): everything you can find in this thread (binaries, texts, code snippets, etc...) are provided AS-IS and are not part of official Armbian project. For this reason not people from Armbian project nor myself are responsible for misuse or loss of functionality of hardware.

Please don't ask about support or assistance in other non-community forums nor in the official Armbian github repository, instead post your questions in this thread, in the TV Boxes forum section (hardware related) or in the Peer-to-peer support section (general linux/software related).

Thank you!
 
This thread is to give stable and mature long-term range support to rk3318/rk3328 found in many tv boxes in Armbian project as Community Supported Configuration (CSC).
The current work is mainlined into Armbian project, but your mileage may vary; most recent developments live on my personal fork on github -> here <-
 
Important notes: is just a personal opinion, but apparently widely supported, that rk3318 chip is not an official rockchip part. They probably are scrap rk3328 parts which have not passed conformance tests but are sold anyway to tv boxes manufacturers. They don’t reach the same operating frequency of the rk3328, have much higher leakage currents (and thus higher temperatures) and often the boards they are installed on are low quality with low quality components, in fact a very very common issue is the eMMC failure due to bad parts and bad soldering. So said, I personally suggest not to buy any rk3318 tv box, but instead find a properly supported SBC (Single Board Computer) if you need a reliable product. In the unfortunate case you already have such product, this thread may help you have some fun with them.
 
What works:
    • Works on RK3318 and RK3328 TV boxes with DDR3 memories
    • Mainline u-boot
    • Mainline ATF provided as Trusted Execution Environment
    • All 4 cores are working
    • Ethernet
    • Serial UART (configured at stock 1.5Mbps)
    • Thermals and frequency scaling
    • OTG USB 2.0 port (also as boot device!)
    • EHCI/OHCI USB 2.0 ports and XHCI USB 3.0 ports
    • MMC subsystem (including , SD and sdio devices)
    • Hardware video acceleration (fully supported via RKMPP on legacy kernel, support via hantro and rkvdec kernel driver on mainline)
    • Various WIFI over SDIO are supported
    • Full acceleration on legacy kernel and mainline kernel
    • U-boot boot order priority: first the sdcard, then the USB OTG port and eventually the internal ; you can install u-boot (and the whole system) in the internal and u-boot will always check for images on external sdcard/USB first.
 
Unbrick:
Technically, rockchip devices cannot be bricked. If the internal flash does not contain a bootable system, they will always boot from the sdcard. If, for a reason, the bootable system on the internal flash is corrupted or is unable to boot correctly, you can always force the maskrom mode shorting the clock pin on the PCB. The procedure is explained here for rk322x, but for rk3318/28 is the same.

In most of the rk3318/28 boards, shorting the clock pin is difficult or impossible because eMMC are BGA chips with no exposed pins. Pay double attention when burning something on the internal flash memory and always test first the image booting from the sdcard to be sure it works before burning anything in internal flash.
 
This is a list of posts where forum users have been able to spot the eMMC clock pin to trigger the maskrom mode:
H96 Max+ (board signature: RK3318_V1.4) by @Gausus X88 PRO 10 (board signature: X88_PRO_B) by @mathgaming HK1 Max (board signature YX_RK3318) by @Constantin Gatej Ninkbox N1 Max RK3318 by @enigmasphinx  
 
Partecipation and debugging:
If you want to partecipate or need help debugging issues, do not hesitate to share your experience with the installation procedure of the boxes.
In case of issues and missed support, provide as many as possible of these things is very useful to try and bring support for an unsupported board:
 
some photos of both sides of the board. Details of the eMMC, DDR and Wifi chips are very useful! upload the device tree binary (dtb) of your device. We can understand a lot of things of the hardware from that small piece of data; and alternative is a link to the original firmware (you can do a full backup with the Multitool); dmesg and other logs (use armbianmonitor -u that automatically collects and uploads the logs online) attach a serial converter to the device and provide the output of the serial port;  
Multimedia:
Mainline kernel: 3D acceleration is provided by Lima driver and is already enabled. Hardware video decoding: https://forum.armbian.com/topic/19258-testing-hardware-video-decoding-rockchip-allwinner/ Legacy kernel: If you need multimedia features, like OpenGL/OpenGL ES acceleration, hardware accelerated Kodi, ffmpeg and mpv you can take a look to this post  
Installation (via SD card):
Building:
You can build your own image follow the common steps to build armbian for other tv boxes devices: when you are in the moment to choose the target board, switch to /TVB/ boards and select "rk3318-box" from the list.
   
Prebuilt images:
Nightly stables - built from trunk by Armbian servers and GPG-signed: https://github.com/armbian/community  
Multitool:
Multitool - A small but powerful image for RK3318/RK3328 TV Box maintenance. Download it from here  
Quick installation instructions on eMMC:
Build or download your preferred Armbian image and a copy of the Multitool; Burn the Multitool on an SD card; once done, place the Armbian image in images folder of the SD card NTFS partition; Plug the SD card in the TV box and plug in the power cord. After some seconds the blue led starts blinking and the Multitool appears; OPTIONAL: you can do a backup of the existing firmware with "Backup flash" menu option; Choose "Burn image to flash" from the menu, then select the destination device (usually mmcblk2) and the image to burn; Wait for the process to complete, then choose "Shutdown" from main menu; Unplug the power cord and the SD card, then replug the power cord; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt. On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run rk3318-config to configure the board specific options Run armbian-config to configure timezone, locales and other personal options Congratulations, Armbian is now installed!  
Despite the procedure above is simple and reliable, I always recommend to first test that your device boots Armbian images from SD Card.
Due to the really large hardware variety, there is the rare chance that the images proposed here may not boot. If a bad image is burned in , the box may not boot anymore forcing you to follow the unbrick section at the top of this post.
 
Quick installation instructions to boot from SD Card:
If you are already running Armbian from eMMC, skip to the next step. Instead if you are running the original firmware you need to first erase the internal flash; to do so download the Multitool, burn it on an SD Card, plug the SD Card and power the TV Box. Use "Backup flash" if you want to do a backup of the existing firmware, then choose "Erase flash" menu option. Build or download your preferred Armbian image; Uncompress and burn the Armbian image on the SD Card; Plug the SD Card in the TV Box and power it on; Wait for 10 seconds, then the led should start blinking and HDMI will turn on. The first time the boot process will take a couple of minutes or more because the filesystem is going to be resized, so be patient and wait for the login prompt; On first boot you will be asked for entering a password for root user of your choice and the name and password for a regular user Run rk3318-config to configure the board specific options Run armbian-config to configure timezone, locales and other personal options, or also to transfer the SD Card installation to internal ; Congratulations, Armbian is running from SD Card!  
Tutorial - How to install Armbian on your TV Box (by @awawa) :
https://www.hyperhdr.eu/2022/01/tv-box-mania-i-part-x88-pro-10.html
A note about boot device order:
With Armbian also comes mainline U-boot. If you install Armbian, the bootloader will look for valid bootable images in this order:
External SD Card External USB Stick in OTG Port Internal  
The Multitool does not boot / How to burn image directly on eMMC:
 
Some boards have the sdcard attached to an auxiliary (called also sdmmc_ext or external) controller which is not the common one.
Forum findings declare that those boards are not able to boot from sdcard with stock firmware and they neither do in maskrom mode: the stock firmware always boots even if you put the multitool on sdcard.
 
In such case, burning images directly on eMMC is the only way to have a working Armbian installation.
You can follow these instructions by @fabiobassa to burn images directly on eMMC:
 
https://forum.armbian.com/topic/17597-csc-armbian-for-rk3318rk3328-tv-box-boards/?do=findComment&comment=130453
 
Notes and special hardware:
Script to change DDR memory frequency here Wireless chip AP2734, SP2734, HY2734C and similars: they are clones of AmPAK AP6334 which is combo wifi + bluetooth of broadcom BCM4334/B0 chips. You may need a special nvram file, instructions by @paradigman are here  
Critics, suggestions and contributions are welcome!
 
Credits:
@fabiobassa for his ideas, inspiration, great generosity in giving the boards for development and testing. The project of bringing rk3318 into armbian would not have begun without his support! @hexdump for his precious support in early testing, ideas and suggestions
@MX10.AC2Nfor his patience in testing mxq-rk3328-d4 board support
All the rockhip64 maintainers at Armbian project who have done and do most of the work to support the platform
 
 

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.
 
 
 
 
 

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