fabiobassa

@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!
 

@Alvaro Fernandez
bom dia Alvaro, yes forum limitation for new users .
@jock and me we suspect of a strange ddrbin ( in the idbloader) that isn't compatible 100% with some ddr . Nota all ddrs just few .
Jock is trying to assemble an image just for you for this RARE case , for your tests, but give him some time, please.

@Seth

Thank you so much for reporting the experience, so you used 0xccccccc for flashing idbloader !!!

Interesting I will do further  investigations. TY

@edouard_k

ty for sharing the original firmware, always interesting dig into them.
 

@Alvaro Fernandez
bom dia Alvaro, yes forum limitation for new users .
@jock and me we suspect of a strange ddrbin ( in the idbloader) that isn't compatible 100% with some ddr . Nota all ddrs just few .
Jock is trying to assemble an image just for you for this RARE case , for your tests, but give him some time, please.

@Seth

Thank you so much for reporting the experience, so you used 0xccccccc for flashing idbloader !!!

Interesting I will do further  investigations. TY

@edouard_k

ty for sharing the original firmware, always interesting dig into them.
 

@fabiobassa @jock
For further infos and helping more people would you be so kind to post some screenshots and a more detailled procedure !?
 
Hi again. so i got the box for about $13.00 online. it was marketed as an MXQ Pro 5G 4G/32G which was totally fake so i opened it and found out that is was just 1G/8G and that it was an RK3228. I tried backing up the firmware with rkdevtool in loader mode and only got about 0x0h to 0x10000h. i tried to write it back and it wouldn't boot anymore. I tried flashing it with armbian and rkdevtool and still no luck then i saw @qiheng's post (thank god he posted pictures) and copied his rkdevtool config and placed the box in maskrom using the pin short method. pinout is here. i just shorted clk to vss/gnd pin. and the flashing worked! Here are the pics of the board, it's marked R28-MXQ-00813, has DDR3 and 8GB flash. I also found the UART pins at the back of the board the 2 pads close to a bunch of capacitors under the cpu, the closest pad to the capacitors is the TX pin and the pad next to it is the RX pin, i just connected the gnd pin to power gnd. Here's the pic, green is tx and white is rx. uboot boots fine but it can't continue booting. i used legacy buster with 4.4 kernel. Orange led is blinking and i got the log below from putty.  Apparently, it can't find boot.env.
 
Serial baud rate is 115200
DDR Version V1.10 20190926 In ID:0xFFF 600MHz DDR3 Bus Width=32 Col=11 Bank=8 Row=14 CS=1 Die Bus-Width=16 Size=1024MB mach:4 OUT U-Boot SPL 2020.10-armbian (Dec 12 2020 - 01:47:28 +0100) Trying to boot from MMC2 I/TC: I/TC: Non-secure external DT found I/TC: Switching console to device: /serial@11030000 I/TC: OP-TEE version: 3.10.0-40-ga1d5c81f (gcc version 9.2.1 20191025 (GNU Toolc hain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #6 Wed Sep 16 21:36 :15 UTC 2020 arm I/TC: Primary CPU initializing M/TC: Not protecting region 1: 0x68400000-0x68600000 I/TC: Primary CPU switching to normal world boot U-Boot 2020.10-armbian (Dec 12 2020 - 01:47:28 +0100) Model: Generic Rockchip rk322x TV Box board DRAM: 992 MiB MMC: dwmmc@30000000: 1, dwmmc@30020000: 0 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** In: serial@11030000 Out: serial@11030000 Err: serial@11030000 Model: Generic Rockchip rk322x TV Box board Net: eth0: ethernet@30200000 starting USB... Bus usb@30040000: USB DWC2 scanning bus usb@30040000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found stopping USB.. starting USB... Bus usb@30040000: USB DWC2 scanning bus usb@30040000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Card did not respond to voltage select! Device 0: unknown device switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2909 bytes read in 3 ms (946.3 KiB/s) ## Executing script at 60000000 Boot script loaded from mmc 0 214 bytes read in 3 ms (69.3 KiB/s) 5694356 bytes read in 140 ms (38.8 MiB/s) 8771432 bytes read in 206 ms (40.6 MiB/s) 49812 bytes read in 7 ms (6.8 MiB/s) Failed to load '/boot/dtb/overlay/-fixup.scr' ## Loading init Ramdisk from Legacy Image at 64000000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 5694292 Bytes = 5.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 61f00000 Booting using the fdt blob at 0x61f00000 Loading Ramdisk to 67e91000, end 683ff354 ... OK Loading Device Tree to 67e1c000, end 67e90fff ... OK Starting kernel ... I/TC: Secondary CPU 1 initializing I/TC: Secondary CPU 1 switching to normal world boot I/TC: Secondary CPU 2 initializing I/TC: Secondary CPU 2 switching to normal world boot I/TC: Secondary CPU 3 initializing I/TC: Secondary CPU 3 switching to normal world boot  
I tried flashing kernel 5.9 minimal buster and i get this:
DDR Version V1.10 20190926 In ID:0xFFF 600MHz DDR3 Bus Width=32 Col=11 Bank=8 Row=14 CS=1 Die Bus-Width=16 Size=1024MB mach:4 OUT U-Boot SPL 2020.10-armbian (Dec 12 2020 - 01:48:33 +0100) Trying to boot from MMC2 I/TC: I/TC: Non-secure external DT found I/TC: Switching console to device: /serial@11030000 I/TC: OP-TEE version: 3.10.0-40-ga1d5c81f (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #6 Wed Sep 16 21:36:15 UTC 2020 arm I/TC: Primary CPU initializing M/TC: Not protecting region 1: 0x68400000-0x68600000 I/TC: Primary CPU switching to normal world boot U-Boot 2020.10-armbian (Dec 12 2020 - 01:48:33 +0100) Model: Generic Rockchip rk322x TV Box board DRAM: 992 MiB MMC: dwmmc@30000000: 1, dwmmc@30020000: 0 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** In: serial@11030000 Out: serial@11030000 Err: serial@11030000 Model: Generic Rockchip rk322x TV Box board Net: eth0: ethernet@30200000 starting USB... Bus usb@30040000: USB DWC2 scanning bus usb@30040000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found stopping USB.. starting USB... Bus usb@30040000: USB DWC2 scanning bus usb@30040000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Card did not respond to voltage select! Device 0: unknown device switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2909 bytes read in 3 ms (946.3 KiB/s) ## Executing script at 60000000 Boot script loaded from mmc 0 243 bytes read in 3 ms (79.1 KiB/s) 6017211 bytes read in 148 ms (38.8 MiB/s) 9681360 bytes read in 226 ms (40.9 MiB/s) 40937 bytes read in 6 ms (6.5 MiB/s) 410 bytes read in 5 ms (80.1 KiB/s) Applying kernel provided DT overlay rk322x-emmc-nand.dtbo 1286 bytes read in 6 ms (209 KiB/s) Applying kernel provided DT overlay rk322x-led-conf1.dtbo 232 bytes read in 6 ms (37.1 KiB/s) Applying kernel provided DT fixup script (rk322x-fixup.scr) ## Executing script at 600f0000 ## Loading init Ramdisk from Legacy Image at 64000000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 6017147 Bytes = 5.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 61f00000 Booting using the fdt blob at 0x61f00000 Loading Ramdisk to 67e42000, end 683ff07b ... OK Loading Device Tree to 67dcf000, end 67e41fff ... OK Starting kernel ... I/TC: Secondary CPU 1 initializing I/TC: Secondary CPU 1 switching to normal world boot I/TC: Secondary CPU 2 initializing I/TC: Secondary CPU 2 switching to normal world boot I/TC: Secondary CPU 3 initializing I/TC: Secondary CPU 3 switching to normal world boot Armbian 20.11.3 Buster ttyS2 rk322x-box login: iamgroot Password: Last login: Sat Dec 12 10:39:28 UTC 2020 on ttyS2 _ _________ ____ _ _ __| | _|___ /___ \|___ \__ __ | |__ _____ __ | '__| |/ / |_ \ __) | __) \ \/ /____| '_ \ / _ \ \/ / | | | < ___) / __/ / __/ > <_____| |_) | (_) > < |_| |_|\_\____/_____|_____/_/\_\ |_.__/ \___/_/\_\ Welcome to Armbian 20.11.3 Buster with Linux 5.9.14-rk322x No end-user support: community creations System load: 27% Up time: 0 min Memory usage: 5% of 960M IP: CPU temp: 63°C Usage of /: 8% of 7.0G [ 0 security updates available, 17 updates total: apt upgrade ] Last check: 2020-12-12 10:40 iamgroot@rk322x-box:~$ No wifi or x yet but it's a start. serial seems to freeze sometimes, maybe because of my cloned pl2303 usb ttl. maybe i should get a better usb to uart. after repeated reboots, i managed to run rk322x-config successfully. i don't know what the wifi chip, it's marked S9012 and when i searched for it only transistors came up. lol.

@Seth

very very glad to see your board is working, so happy !!!!!

For further infos and helping more people would you be so kind to post some screenshots and a more detailled procedure !?

And don't forget a " like" ( the heart symbol)  for  authors to help them in good forum reputation !!!



 

weeee! i got it booting. orange light blinks. flashed it in maskrom mode. flashed the loader from first post at 0xcccccccc and armbian image at 0x0. it worked. now i need to hunt for uart rx and tx pins. thanks @jock and @fabiobassa. i just hope i don't break the board while searching for uart pins.