jock

Hello, you may want to edit the device tree and turn off the mmc@... node where the sdio wifi chip is connected. You may find it easily looking for supports-sdio property, then switch status property do disabled

Added support for Debian Trixie (only for arm64)

No factory images here; I just tried an Armbian image with Ubuntu Noble and it worked flawlessy with XFCE, just need to disable the XFCE compositor to have full framerate.

UPDATE! Hello everyone, I'm glad to give a fresh update. After a couple of weeks and more or hard work, I finished the complete overhaul of the repository. It is now handled in a much tidier way. The result of this is a much easier support for new distributions as soon as they are published! I have just updated the instructions, since the old repository is no longer active; I suggest you to remove the old repository from you apt sources and install the new repository as described in first page. Packages for Noble Numbat are already available! Enjoy!💪

with mainline kernel, yes

I don't know if this is trolling or not. Let's assume it is not and the question is genuine. There is no hate against cheap chinese tv boxes, but there are many objective problems: no support: hell yeah, you can't say anything against this, at most you get the original firmware from the vendor, expect nothing more varying hardware quality: plenty of stories of hardware failing after few weeks/months. Lucky you your hundreds worked so far (I wonder what do you do to sell hundreds of those...) varying hardware in general: pain and suffer to support; you should at least say thank you to people here around that spend their time (that will not come back) to let you have a cheap tv boxes working with free and open source software (not to mention those who sell them...) no documentation: it means, mostly, that it takes huge amount of time and advanced skills to reverse engineer the thingies. Time is the fundament of a salary, skills are the multiplication factor of a salary. People here - all the people, starting from the heads of Armbian project down to the forum user answering to posts - give both for free, but no salary for us, despite the passionate efforts.

@CtrlValCanc the fix has just been mainlined: https://github.com/armbian/build/pull/7959, so future dtb packages will have the fix already included!

@CtrlValCanc glad to hear you got it working, prego! About the ethernet, if the hardware is really failing, you may want to try and set the port to 10Mbps instead of 100Mbps with ethtool; it won't give you a fast connection, but at least the device could be reached on the net for maintenance.

@CtrlValCanc try to substitute /boot/dtb/rockchip/rk3318-box.dtb file with the one I provide attached to this post, reboot and see what happens rk3318-box.dtb

Hello; multitool has the port 22 open and listening for ssh connections. If it does not show the open port, then it is either freezed or did not start at all. Regarding your A6 Mini board, which seems the only one with rk322x, it is not a board that we have encountered here on the forums, which is quite curious since the board marks a production date of 2018. Consider it to be a fake board. I have not exactly understood what is what, since you declare you have a 2/16 S905W board with fake specs and a 1/8 RK322x board with (supposedly) real specs, but they could easily be both fake. Looking on google for A6_Mini boards, I only see S905L devices. You also say LibreELEC boots, but you did not say on which of those two boards boots.

My fault, didn't notice the log in the previous post. I will look into them.

It is common for tv boxes that some devices don't work out of the box. Tv boxes are not officially supported and will never be officially supported in armbian mainly for the reason they carry wildly different hardware and it is not feasible to give any kind of official support, hence it is totally a community effort. The reason rk3318-config does not show any wifi chip is that the wifi chip is either connected to a different mmc bus, or the "power on" gpio pin is the wrong one. Inspection of the device tree from the original firmware will surely clarify what is going on. Your particular board (X88 PRO is known to have the wifi chip on the "alternative" sdmmc_ext bus. In your case you have to run rk3318-config for a first time, configure the board with led-conf2, reboot, run again rk3318-config (this time it should show the wifi vendor and device IDs), let it configure the proper device tree overlay, reboot again and you should finally be able to see the wifi adapter. About the ethernet problem, I see NO-CARRIER: either the cable is not connected properly or the ethernet port is faulty. dmesg log is always very appreciated for debugging.

@CtrlValCanc SP6330 is a clone of AP6330, which is a combo device based upon Broadcom BCM4330, you should select the right board in rk3318-box (X88 Pro B should fit your case) then reboot and then it should be detected and perhaps even work without more intervention.

@CtrlValCanc hello! Yes there was an issue with latest u-boot and rk3318 devices: network interface could not be detected, hence its mac address could not be setup. The direct result is that, on every boot, the device receives a new MAC address and thus a new IP address each time. This is the pull request that fixes the problem and soon should go into repositories. In the meantime you could work around the issue setting a static IP address. Ps: congrats for the funny nickname

The environment has never been actually tested. Once it was saving and restoring it from a sector on eMMC, but then later changed to the "default" ext4 environment, but never tested even because older u-boot were used to corrupt ext4 partitions when trying to write to it.

@Enzo Esteban without logs it is impossible to give any hint

As said several times in this thread, the marketing name does not mean anything. You have to look to the silkscreen on the boards (or post some decent photos of the board on this forum), that tells you much more. leds-config are based upon that, and not about the marketing name, which is just a random placeholder, as you experienced by yourself. About the wifi chip, a driver for ssv6051p chip is available in mainline kernel (version 6.12), and is an attempt to fix the vendor kernel (version 4.4) driver by @ilmich and me and mostly it works. If you have another ssv6xxx chip, no luck, you won't gain any driver for mainline kernel and you have to restore to vendor kernel, which is way older, unmaintained and unsuggested. If rk322x-config does not detect any wifi chip, it is because the wifi chip is turned off and must be first turned on; that's one of the purposes of the led-config utilities. Beware that you have to reboot the board and run again rk322x-config to see if the chip has been turned on or not.

It won't work, openvfd is another driver and wants things a different way. Not to blame the author, but unfortunately openvfd is badly designed. tm16xx driver instead is very well designed, and is the way to go. 👌

The first thing that pops in my mind is that if the dtb for a board has been introduced with a naming convention (whatever it is), if you change the naming convention, it will mostly break the user installations when they upgrade the kernel/dtbs.

@ROOD what do you mean unavailable? I just downloaded a copy of it is perfectly readable

@ROOD see the first page and the paragraph "Special hardware"

Normally it should work this way: armbian bootloader (u-boot) priority was first to sdcard, then USB stick, and finally eMMC. Recently (months ago) I bumped to a newer version of u-boot and there was some people reporting that the priority somehow changed, but I had no time to check it by myself; so take that with a grain of salt.

@ROOD ok that's fine, yes default credentials are root:1234 You probably may go burning on eMMC, surely it won't brick and you should be able to run multitool or armbian on sdcard to handle maintenance if you need; I would anyway first configure the board with rk3318-config script and, when you found an optimized and stable setup, then burn on eMMC and replicate the setup

@ROOD good Important premise: when you short the pads you're actually excluding the eMMC from boot, so the SoC will boot from sdcard and, if there is no sdcard, then will go in maskrom waiting for something. Hence you have different options: burn the multitool on sdcard, then insert the sdcard and turn on the board with pads shorted. The multitool should boot and then you can erase the eMMC burn a good image (use the @otus links) onto the SDCard and boot (with pads shorted) Armbian from sdcard. Once booted, then erase the eMMC with dd (first 4 megabytes will sufficed) or with blkdiscard upload a loader with RkDevTool (or rkdeveloptool from Linux, without uploading a loader you won't be able to do anything; you should be able to find it in first page or somewhere in this thread, can't remember...), then erase the eMMC The first option seems the easiest to me. Once you erase the eMMC, the board will boot from sdcard and you can test a valid Armbian image. Obviously burn an image onto eMMC only when you're sure it boots from sdcard. You can get access to the TTL serial uart from the three aligned pins that lay between the LCD display and the USB 3.0 port, if you have a serial adapter of course. Also, don't trust too much the eMMC: these particular boards were affected by bad eMMC/soldering iron that often caused it to fail.

@Ian Goodacre yes I confirm you broke the dtb, and for that reason u-boot does not take the kernel from sdcard anymore, then tries other boot options (USB, PXE). You should recover the device tree to let linux boot again. Funnily enough, u-boot is able to pick up an IP address from DHCP 😅 This is the merge request where I fixed the Gigabit LAN port on RockPi-E, I understand that you already read about the merge request, perhaps the problem is similar to yours. BTW, the phy chip should be automatically recognized by the kernel code because each chip exposes some ID that can be picked up by the driver, so you should not worry about. If you still have issues, post the link returned by armbianmonitor -u or at least the dmesg log.