jock

I got it, I don't remember if it is v2.0, but perhaps it is a v1.4; anyway it works flawlessy on my case, it has a specific led-conf because it carries the rk805 pmic that is required to make operational before trying to raise cpu frequency

@Felipe Muniz I don't think it was a good idea to change the NAND. AFAIK, eMMC can be switched with no real software issues, but NAND chips in my opinion are way thougher because they require a software layer (the FTL) to work correctly. The proprietary NAND driver contains the FTL routines for a bunch of vendors and specific parts, so IMHO you can't put any bigger/better part and expect to work out of the box. You may boot in maskrom mode, upload a recent loader and see if rfdeveloptool/rkflashtool detect the nand parameters correctly (size, vendor, page size, ecc bits, etc...),otherwise I would not expect it to work in any way.

Hello, sure it won't harm other boards, but your specific problem may be due to slow voltage regulation from low to high frequency state. 0.025v increase is very minimal that may not solve your stability issues in all cases, but just enough for a limited stress testing. I'm not minimizing your finding, but perhaps the matter may be investigated a bit if you're curious you can: 1) raise the voltage only of the one or two lower frequency bins (600mhz and 800mhz) and then run the stress test and see if you gets issues 2) run the tests with "stock" voltages blocking the cpu to the highest frequency (cpufreq-set will do the job) What I have seen on different boards is that some of them have a "lazy" power regulation that takes too long to raise the voltage to reach the right level, so when there is the frequency shift, it just gets unstable.

I will never stress out that THESE issues reported by you are the exact reasons to chose a properly supported Single Board Computer from the officially supported list and not buy crap like supercheap tvboxes. If you don't have the time, will and skills to solve troubles, tvboxes may end up being a large source of frustration. The very same problems are the main reason tvboxes are NOT OFFICIALLY SUPPORTED and NOT ENDORSED by Armbian project; tvboxes are just a community effort to have fun with them and avoid some waste, but the mileage can vary greatly. Here are the FAQs

Not sure what this sentence means: did you try to install the multitool on the internal flash? Why?!? If I understand correctly, you have been able to run once the multitool regularly, do the backup, and then something wrong happened so the board does not boot anymore?

I don't think it could be really useful to inspect dtbs, the problem is elsewhere. The guy has to options: 1) erase the internal flash and forget it, then run armbian from sdcard 2) throw the thing in the trash bin and buy something reliable and supported

Because you have to change it in /sys/class/leds/working with the behaviour you'd like

Indeed if network manager does not work, the ethernet won't get an IP automatically. Perhaps the ssv6051 driver makes the network manager crash? (you may try to blacklist the driver). The ssv6051 driver is the same as legacy, but some things have been necessarily changed to work on mainline kernel. In your case, it is not just a problem of the detection of the chip, but there is some kind of communication issue because the driver can't read the efuse from the chip (that, in fact, is the reason of the bad detection).

Not until a sample happens to arrive in my hands

Impossibile, perhaps you did not follow the instructions correctly (ie: erase the internal eMMC first) ssv6051 driver is crap, in your particular case for some reason is not able to detect correctly the chip version and indefies it as ssv6051q, instead it is ssv6051p, but I don't know the reason. For the ethernet part, it usually just works in the uttermost majority of situations, there has never been the need to do adjustments on any board, so it sounds strange that on yours it does not work.

Yes, this is exactly the way I suggest to take confidence with the system: erase the internal flash to zero (does not matter if NAND or eMMC) to remove any trace of Android; then use Armbian from sdcard to bring up the system, experiment with rk322x-config to setup the board correctly so, in case of mistake, just plug the sdcard in a PC and revert the error; install packages, services, reinstall armbian from scratch with another kernel or rootfs (Debian bullseye, bookworm, Ubuntu Jammy LTS, latest Ubuntu, etc...) and do all your own experiments on the sdcard. When finally you notice that the base system is stable with the proper led-conf and you're happy with the software setup, transfer it to internal flash or install armbian on internal flash with multitool. Also, IMHO, boards with NAND have much better use with external sdcard than internal flash, since NAND are supported only with ancient 4.4 kernel and they still are problematic. Keep them erased and live easier with external sdcard.

@ercans probably the eMMC is gone and is in read-only mode: multitool or other tools write to eMMC, the eMMC says "ok!", but actually nothing is really written. That's a common condition when flash memories break. Your chances are: 1) short circuit the eMMC clk pin forever 2) desolder the eMMC from the board (<--- you have to be very skilled for this) 3) substitute the eMMC with another one (<--- you have to be very very skilled for this) you may also try to use dd from multitool command line shell and see if you can zero-fill the emmc or at least the first few hundred sectors to force boot from sdcard.

Indeed it is a scrap chip, tvboxes are often made of scrap parts; so far I have seen that chip on other boxes with rk3318, this is the first time that wifi chip appears on a box with rk322x. By the way, the image you are using is ancient! You can take a newer image with legacy 4.4 kernel here (suitable for boards with NAND) and you can should use a recent mainline kernel image from here for the box with eMCP. Note that the mainline kernel image will also work flawlessy on boards with NAND, just the NAND flash won't be available and you will have to use an external SDcard for those boxes.

Probably your board is misconfigured with led-conf1, which are chiptrip brands. The two r329q boards should go with led-conf2 (rk322x-config tells you which led-conf to use with which board): The last board, which is unknown yet, perhaps may benefit from led-conf7 (R29), but your mileage may vary. Anyway, getting wifi properly detected with the right led-conf: 1) helps us to put your board in the list 2) prevents possible malfunction of other hardware If you pay attention (and please do!) to the Important paragraph in the above screen, it is clearly stated what is the purpose of the led/gpio configurations and what are the benefits of selecting the right one. As @RaptorSDS said, your wifi chip is a broadcom 4334, but there are several variants around so perhaps the driver is not able to correctly make it work; anyway if you get the ID of the chip in rk322x-config (as you already do), then you should be ok with the led/gpio configuration

When you have 4 cores, you can achieve 400% cpu usage; top reports it that way.

You would try an Ubuntu distro and enable the oibaf repository to get cutting edge mesa. Default mesa from debian and ubuntu is a bit older and does not contain specific fixes for mali-400/450 Oibaf repository is already set in /etc/apt/sources.list.d but the line is commented by default. Removing the comment and then running apt update && apt upgrade should do the trick. Also note that in X11 you may want to enable the vsync when possible, which turns out to perform much much better because with vsync on the driver will use page flipping, with vsync off will use buffer copy that reduces performances a lot.

Not the best choice, if you accept my opinion. Much better to use a proper SBC for those kind of tasks, perhaps something with rk3328 and a decent amount of eMMC, since HA is going to write its data series. On this particular board I don't even know if wifi is going to work, since it got a rk915a chip which currently is unknown.

It looks like u-boot is not able to detect the sdcard, the first part is missing because the bootloader uart speed is 1.5mbps and then u-boot switches to 115200kbps, but that's it, u-boot does not see the sdcard. The reason is unknown, and resides into the board internal wiring and it is not possible to debug that without the board at hand. It is still possible to boot from USB stick (with the multitool sdcard inserted): burn the multitool on as USB stick and put the legacy image there and the multitool on sdcard will do a trampoline to the multitool on USB stick.

Actually I forgot to update the first post: the FAT partition has now been changed to NTFS to overcome the 4GB maximum file size limitation of FAT32. I think I made a post about that, but forgot to update the first post. Sorry, I'm going to fix that right now! Despite that, the multitool works exactly the same as before.

Hello @lucat1, it is not the first time I see this board on the forums. I have never seen it, so I don't know which problem it could have, only the UART debug output could tell what is going on. Anyway, you should try to plug a male-to-male USB cable in the OTG port of the board and in your PC: if the board is in maskrom mode, you should be able to see the board from the PC using lsusb from Linux or AndroidTool from Windows. Once there, you can restore a previously made backup or erase the internal flash to force the board to boot from sdcard. If the board is not detected on your PC, try pressing the reset button behind the audio jack connector, and keeping it pressed for two seconds while giving power to the board and then try again with the male-to-male cable. Check the rk322x main thread on how to use rkflashtool/rkdeveloptool tools.

Seriously, are you thinking that thousands of log lines of the original android (I read kernel 3.10) are of any use? Paste the logs of the problematic boot, not when it goes well, damn!

Yes, of course; NAND also have a clock, shorting the clock pin has the same effect on eMMC and NAND devices. Still I haven't seen a serial log, without that, going further with support is a waste of time.

No guidance is possible without the serial logs; if people don't know what is going on, how can suggest you further steps? Next time buy an armbian properly supported SBC and you will have no troubles

We don't know! The board is new and it just does not work 🤷‍♂️ And please don't ask for solutions: proper serial logs, original device trees and firmware perhaps may help, but most we need the board in our hands to give the chance to support it.

­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 Hongtop H50 (board signature t98-3318-221-v11) by @GmP 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