tommy

@fangis It is not a good idea to cut the stack trace in the middle when you want to do debug. Also put the log in a "spoiler" section to make easier to read the thread.
 
@mattmar I don't understand the part about the usb adapter: if are you using it to program the sdcard on the PC then it does not matter. If you're using it on the box, then it won't work.
Also I don't understand what does not boot: the multitool or the armbian image?
AIDA is not useful, as usual we need the serial output and photos of the board.

@TU-Student the reason why we often write .. read the first post .. is because someone has already wasted time and health trying to make everything work.
The reason why some boxes do not boot from the sd card is because there is an old bootloader or one that does not activate the sd controller at the boot stage (often vendor's choice).
So if you are unlucky, and multitool/armbian doesn't boot, the safest way is to delete the internal memory because in this mode (maskrom) the soc activates the sd card and starts the OS from there (99.9999999% of the time)
If you need a backup (of a system that for me is unusable) you can use the USB OTG cable method (with tools like rkdeveloptool or my fork of rkflashtool)
 
@fangis strange, the 6051p I think is the best supported chip. what's your problem?!

@mydeardiary hello, as @RaptorSDS said, rtl8723as and rtl8723bs are two different chips and require different drivers and firmwares.
rtl8723as driver is not in the linux kernel and looks like quite difficult to find a suitable driver.
 
Libreelec folks did some adaptation for the rtl8723au: https://github.com/dtechsrv/LibreELEC-AML/pull/24

@Mierscheid sorry for the late reply, but I didn't notice the post.
 
The image you installed is for another board called xt-q8l-v10, which is based on rk3288 but surely not the same board.
This is quite important, because each board, especially "high-end" boards like this, have their own design and usually have a different Power Management Integrated Chip (PMIC).
This is important because this little chip drives all the currents of the board, and if it is not configured right won't allow the board to work the right way.
 
There may be other differences that may break things, so it is not advisable in general to burn an image directly on the eMMC without carefully testing it via sdcard first.
The board can surely be restored to working state, but without UART logs is impossible to even guess where is the problem; surely bringing the board into maskrom mode (see this post) will allow you to use rkdeveloptool to erase internal flash and force the board to boot from sdcard (either multitool or directly an armbian image).
 
I guess you already tried to boot the multitool from sdcard without success, this makes me think that the u-boot installed on eMMC has issues or does not even boot, which is bad enough to guess you need to bring the board into maskrom mode and do a manual intervention.
 
The maskrom mode link I posted above is for rk322x, but actually it works exactly the same because eMMC chips have all the same pin layout. Once you keep the short the emmc clock pin to ground, you are "clock gating" the emmc and in practice it excludes it from the system just like there is no eMMC at all. When you unshort the pins, the eMMC will start working again.

Announce:
 
Hello, I want to announce that Community Supported Configuration (CSC) board images are now built again by Armbian servers on a weekly basis!
This means that you can now download images for CSC boards (including xt-q8l-v10) browsing from https://github.com/armbian/community
 
Images are built from trunk, GPG-signed and SHA-sum is provided.
 
Feel free to donate if you find this useful and wish to offer support to the Armbian developers and maintainers.
 
Enjoy!

No idea, it may work or may not work, surely some hardware will differ and this may cause major or minor issues. You should ask the vendor/manufacturer for software support.

It happens on my board too (HK1 Max, the rounded one) that sometimes, after the board locks-up for some reason, it does not reboot and nothing is printed on the serial.
This happens with android too and I have to power cycle another time the board to let it boot correctly.
 
An important thing for debugging is that if you try to boot from eMMC, you don't keep the uSD inserted in the slot, otherwise the kernel may decide to use the rootfs from the uSD.

Hi @tommy, the board you have should be a quite regular board and thus should work out of the box with no particular problems.
 
It is weird that booting from uSD works fine and booting from eMMC does not; you should be more precise in describing the issue and maybe posting the serial log would be much more helpful than the original android output.
 
Well these boards and not really designed to do such jobs. Sure there is still room for speed improvement, since at the moment all the rk3318 boards are running with RAM at @330 Mhz, which is rather low, because of a couple of issues that needs to be sorted out yet.

@elbuit - if nothing else works, this should usually work to get the device tree from a running android: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
 
best wishes and good luck - hexdump

Thanks jock for this post. I was able to unbrick my device. I now have successfully installed Armbian on my device and loves its performance by following this post.
 
My device is called Ninkbox N1 Max RK3318. I was trying to look for a firmware suitable for my device but I am unable to find the exact one. I tried asking support from their main website but to no avail. So I tried installing different firmware on my device with almost the same chips until I ended up bricking the device. Unfortunately I already bricked the device before landing into this post so I was not able to backup my original firmware. For some unfortunate twist of fate I also have those BGA chips with no exposed pins. Upon further examination there are two round copper at the back of the board where the BGA chip sits. After burning the image on an SD card I tried shorting the round coppers with a piece of staple wire and it gave me the Multiboot window.
 
I am writing this for those other people who may have the same device as mine and is looking to setup Armbian or probably trying to unbrick their device.
 
This is my EMMC Chip
https://drive.google.com/file/d/1J5E8OGBUOV_sdQ0VF0glIt4t6yhRKxrr/view?usp=sharing
 
The picture of my device
https://drive.google.com/file/d/1J2Ha8nUhA5hhXne_vqHdyzLBOlxCWcMV/view?usp=sharing
 
The round copper at the back of the board to short
https://drive.google.com/file/d/1J-X_9Y4jKr8u87lEosGkBmtpwjdxGsFb/view?usp=sharing
 
My device desktop after successful install
https://drive.google.com/file/d/1J5hkfP7A4U5r6xO7P9Zgv8ArpjUmZJ0g/view?usp=sharing
 

Updated images!
 
Armbian and Multitool images have been updated with various enhancements:
Multitool compatibility has been increased Split single device tree in base and overlays: each board can activate different device tree overlays to fit the specific configuration (eMMC DDR/HS200, alternate SDIO bus for Wifi, etc...) Add rk3318-config script to easily configure options via menus; just run it as sudo rk3318-config Add full support for AP6334 (and various clones) Wifi and Bluetooth Add support for AP6330 Wifi and Bluetooth (yet untested) Issues so far:
Lima driver acceleration has been disabled in X.org for the moment. It gave issues I need to investigate I2S subsystem has some problems that needs to be fixed, as result no sound can be produced for both HDMI and Analog outputs

You can do cat /sys/kernel/debug/gpio to get a brief map of the gpios registered to the kernel.
Usually there you find the leds, buttons and regulators. Other gpios are not present there because they are bounded to devices and not exposed to the kernel.
 
You can then control the pins using the kernel sysfs interface: in the directory /sys/class/gpio there are a couple of files (export and unexport) and a number of directories (gpiochipXXX) that can be used to make the GPIO pin exposed to userspace.
Gpiochip directories are the GPIO banks, and the trailing number in directory name is the pin 0 of that bank (called the base).
If you run:
echo <pin> > export where <pin> is the base gpio bank summed with GPIO pin number, a new directory gpio<pin> appears where you can control the direction of the pin and the state.
 
The main problem is that if you want to control a GPIO it must not be bound to a device, thus you need to remove it from the device tree. Removing leds and buttons from device tree is generally very safe, removing GPIOs from other devices can lead to system malfunctioning of some sort, HDMI included.
 

That is not maskrom mode, lsusb is telling you a wrong information.
You are in rockusb mode, which is provided by u-boot and allows limited operation.
 
To enter maskrom mode from rockusb mode, you need to get rkdeveloptool from rockchip github repository and run rkdeveloptool rd 3

@chinhhut
Will try to explain you what loader is with an analogy: in normal pc you have bios and master boot record. Well, maskrom is bios and is contained in the soc itself, loader is a sort of master boot record and it enables the emmc and ddr.
You can have a look here
http://opensource.rock-chips.com/wiki_Boot_option

 

I did extract it by a working firmware using a tool that unpacked the whole firmware. Try to google for RK3xxx_firmware_tools_5.23.1_by_SergioPoverony.zip and leave alone that github since it is just one piece of the puzzle. The detailed infos how to get a working loader are in the rockchip instructions

 

Of course and the command would be rkdeveloptoo rl 0x0 etc etc etc ( try rkdeveloptool -h to get the help)
But if you are lucky that works multitool, well that is the easiest way to clone and clone back

@chinhhut
Glad you got success .
Don't forget to put a like that helps @jock and myself in community reputation
 
 
 

@chinhhut

Try these steps:
1) push the little switch inside the hole while inserting a male-male cable into the otg
2) on another linux machine you should have now a new device (lsusb will help you) and you can run rkdeveloptool
3) rkdeveloptool ld should List Device
4) rkdeveloptool rd 3 should Reset Device into mode 3  ( maskrom )
5) rkdeveloptool db MiniLoaderAll.bin ( of course from your path) should upload a temporary loader to recognize the internal emmc
6) if all is successfull until now you can rkdeveloptool wl 0X0 yourimage.img . This should flash the internal emmc .

DISCLAIMER: very " dangerous" approach , be ready to have the opportunity to short the emmc clock pin to ground to go back into mask rom
 
MiniLoaderAll.zip

@fabiobassa @jock I've followed your guide and got success. Thank you so much.
root@mybox:~/rkdeveloptool# ls 99-rk-rockusb.rules Makefile.in RKComm.h RKImage.h RKScan.h cfg configure.ac main.cpp CMakeLists.txt Property.hpp RKComm.o RKImage.o RKScan.o config.h.in crc.cpp main.o DefineHeader.h RKBoot.cpp RKDevice.cpp RKLog.cpp Readme.txt config.ini crc.o parameter_gpt.txt Endian.h RKBoot.h RKDevice.h RKLog.h aclocal.m4 config.log gpt.h rkdeveloptool Makefile RKBoot.o RKDevice.o RKLog.o autom4te.cache config.status license.txt Makefile.am RKComm.cpp RKImage.cpp RKScan.cpp boot_merger.h configure log root@mybox:~/rkdeveloptool# ./rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x320c,LocationID=101 Loader root@mybox:~/rkdeveloptool# ./rkdeveloptool rd 3 Reset Device OK. root@mybox:~/rkdeveloptool# ./rkdeveloptool db MiniLoaderAll.bin Opening loader failed, exiting download boot! root@mybox:~/rkdeveloptool# ./rkdeveloptool db /root/MiniLoaderAll.bin Downloading bootloader succeeded. root@mybox:~/rkdeveloptool# ./rkdeveloptool wl 0X0 /root/Armbian_21.11.0-trunk_Rk3318-box_bullseye_edge_5.14.14_minimal.img Write LBA from file (100%) root@mybox:~/rkdeveloptool# ./rkdeveloptool ---------------------Tool Usage --------------------- Help: -h or --help Version: -v or --version ListDevice: ld DownloadBoot: db <Loader> UpgradeLoader: ul <Loader> ReadLBA: rl <BeginSec> <SectorLen> <File> WriteLBA: wl <BeginSec> <File> WriteLBA: wlx <PartitionName> <File> WriteGPT: gpt <gpt partition table> WriteParameter: prm <parameter> PrintPartition: ppt EraseFlash: ef TestDevice: td ResetDevice: rd [subcode] ReadFlashID: rid ReadFlashInfo: rfi ReadChipInfo: rci ReadCapability: rcb PackBootLoader: pack UnpackBootLoader: unpack <boot loader> TagSPL: tagspl <tag> <U-Boot SPL> ------------------------------------------------------- root@mybox:~/rkdeveloptool# ./rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x320c,LocationID=101 Maskrom  

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.
 

­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 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:
Archived images - built by Armbian servers and GPG-signed: https://imola.armbian.com/dl/rk3318-box/archive/ Nightly stables - built from trunk by Armbian servers and GPG-signed: https://github.com/armbian/community Stables provided by me (unsigned): https://users.armbian.com/jock/rk3318/  
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
 
 

Sorry but I have to be sincere about this: I don't like the reasoning, I found it unethical.
 
Believe it or not, I don't receive any kind of money from anyone; Armbian team also does not receive anything from these no-name boards, instead has to pay electricity, bandwidth to host images and forums.
It is just courtesy of Armbian guys if all of this is possible, they ask nothing in charge; although Armbian does not officially support any TV Box - as clearly and boldly stated in the first posts of all my threads.
 
My role in all of this is just driven by passion and learning, not money. I decided to share my work and studies with others because I think that if other people does the same, the world will become a better and funnier place.
As you see, the learning curve is pretty steep, and trying to build an out-of-the-box working solution for boards whose specifications and datasheets are kept secret is a huge time wasting job.
What I expect in change is usually a "Thank you": most of the time it suffices.
 
Here I read, and I really hope I misunderstood the post, that someone is going to make business around this.
That's pretty ok to me: I do support tv boxes for passion. I also use Linux which is free and made by others for passion and work and I pay nothing to anyone; nonetheless I contribute to opensource the way I can.
 
Now if your concern is missed support, don't ask community what can do for you and point out what community is not doing for your business; start thinking about what you can do for community that helps both community and your business.
In all of this long thread I don't know how many people donated to Armbian project - I'm not part of the official team.
But I'm totally sure that, except for the very generous board donations from @fabiobassa to whom all people here should as well be very grateful, I never ever received a penny or one board from anyone. And note that I don't ask boards as gratification - I already have several of them taking dust - but to study them. Nonetheless I am still here available for free support and for fun.
 
Asking me, or anyone else, to spend money to buy cheap crap and spend time reverse engineering that crap for your business is just unethical. It's parasitizing.
You need good Linux support for your tv boxes? Ask the manufacturers of those boxes, and see what they answer to you.
The problem about the "right price" is that the price can't be right if you don't include software developing and maintaining costs. Chinese tv boxes manufacturers are fetching "just working" Android distro into their products. If they would want to support a full linux environment, the price would be three or four times the actual price.
 
Want to talk about business?
Send a precise request to the developer of your choice (me included) and wait for a proper price quotation.
 
Want to do everything by yourself? You can.
Armbian developers spent hours to write proper documentation, available on docs.armbian.com. Source code is publicly available on github repository.
If you find it difficult navigate into, spend hundreds of hours lo learn things, as me and several others did, to raise your skills to keep up with your business.

Analog sound is not yet in mainline kernel, it works only on 4.4.
Hardware acceleration also is still partial on mainline kernel and it is in heavy work in progress by LibreELEC and kernel teams.
For multimedia features I suggest to stay on kernel 4.4 for now

@marshall sorry for taking so long in answering. At the moment I'm a bit busy and a bit tired too. Your issue seems to require more attention than expected, still could not figure out what is wrong.
From the log you posted I see something very odd: I don't see the eMMC card (mmc2), the sdio wifi chip (mmc1) is not detected at all and the sdcard (mmc0) has problems getting into high speed mode. This is the hardest combo ever!

I tested in terminal mode ,'$ sudo systemctl set-default multi-user" which has really good performance. Your cutting edge armbian can achieve PSX full 60fps speed in retroarch (however, in legacy, I use wrong parameter which seriously impact performance) and snes9x framerate improved. I really surprise it is faster than legacy in my case. Really great.

I tested in terminal mode ,'$ sudo systemctl set-default multi-user" which has really good performance. Your cutting edge armbian can achieve PSX full 60fps speed in retroarch (however, in legacy, I use wrong parameter which seriously impact performance) and snes9x framerate improved. I really surprise it is faster than legacy in my case. Really great.

@tommy
 
Thanks a lot for you images