jock

@MattWestB This is the dtb for kernel 6.1, it should work on your existing installation: rk322x-led-conf7.dtbo

@MattWestB Perfect, thanks! I see the eMMC is correctly detected and ethernet working too, so probably my sample is just defective.

@MattWestB Ubuntu or debian does not matter, the dtb depends upon the kernel version. The image above has kernel 6.5 (edge) and I ask to briefly test it as is, in particular look over hdmi, emmc and ethernet and report dmesg. Jiggling with dtbs over other kernels, or use multitool dtb on armbian (baaad!!! never do this!) is a hazard: it may work or may end up with a broken system and a broken system surely does not help anyone 😐

@MattWestB @Benedito Portela guys I appreciate your feedback, but please use the armbian image I gave from an sdcard and post the dmesg log if you can. Doing cut&paste over custom setups just makes me really confused. If you already have regular Armbian installed on eMMC/eMCP, just burn the new image on sdcard, plug the sdcard and boot the board. Your installed system won't be touched because sdcard boot has priority over internal flash. When Armbian is installed, boot priority is always sdcard, then USB stick, then internal flash.

UPDATE FOR R29-MXQ USERS! Hello, this is an update for those people who has R29 board and have suffered issues regarding stability problems and no HDMI output. I had the chance to have a board in my lab thanks to @Hudson FAS and something is moving! What's wrong with this board: Differently from any other known board, it has a specific GPIO pin to turn the HDMI on and off: discovering such GPIO required extensive trial and error, it was disguised in the original dtb as "power-hold" 😅 But the main problem with this board is that it has no power regulation for CPU, so it cannot run faster than 1Ghz. The default dtb shipped with Armbian and Multitool are set to run the CPU up to 1.2Ghz. For this reason, some (most?) unlucky R29 samples were totally unable to boot with the default configuration. I still need some help from community though: my sampl is able to boot and works stable but: emmc does not work ethernet does not work unless I downgrade the link to 10 Mbit/s I suspect my sample is damaged, but I need a feedback from other users to understand if there's something more in the dtb to discover or it is just my sample. Multitool you can download a fixed version from here. It should work flawlessy and HDMI should turn on with no problems. Armbian you still need to do some manual passages: Burn the multitool on a sdcard, run it on the board, make a backup of the original firmware then erase the internal flash to force sdcard boot. Store the backup on a safe place; if you wish, it would be appreciated if a copy can be shared here for further studies! Burn this Debian Bookworm minimal Armbian image on the sdcard, the try to boot the board. If you're able to boot, access via ssh, run rk322x-config, select your configuration options and select led-conf7 as GPIO configuration in the last passage, then reboot; you're done! if your board does not boot, mount the sdcard partition and manually add overlays=led-conf7 in /boot/armbianEnv.txt, then you should be able to boot Thanks!

@Aapo Tahkola I guess you have some other kind of problem (ie: stability problem), because such error should never happen on both slow or fast boards, as long as it does not happen on any board I have around.

Have a box with rk3528 here and did some work some weeks ago, mainly to get a kernel and multitool running on it. It works, but I didn't publish an image for it yet (only available in source code), plus my board does not want to boot from sdcard and had no time and no will to further study it better.

@Alex ThreeD Well I think that's a little of a mess there... the patch says rk356x fix, but actually it is doing something different and I saw that those hunks were also mentioned in the libreelec kernel patches for all rockchip socs (LE patches are my reference "Bible" about video and DRM). I made some test with other LE patches and they were fixing some other rk3399 configurations, but still there are plenty of them to be included (~40 patches) that is not a good idea to submit them yet to armbian rockchip64 branch. However, I think that if the patch was lost in transition, feel free to fix the thing, send a PR and I will approve and merge the fix 👍

@Alex ThreeDthanks for investigating this! I suspected some kind or problem like that, there are some bits that have changed in a function to validate the modelines. I don't know when I will be able to fix the thing, but perhaps it could ben enough to revert the function to previous behaviour

I can't repair the server, as like as the community images are not getting produced regularly. They are not under my control.

Mmmh, I think wireguard module backport has been removed from armbian from non-mainline kernels some time ago. Upgrading the legacy kernel is quite useless though, since it is frozen at the version supplied by rockchip and not anymore upgraded. Kernel headers should be already there as a separate package, so if you need wireguard you can still compile the backport yourself.

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