jock

@immS Since you have an X88 Pro board, try also to run again rk3318-config: your board has a particular different and rk3318-config should have told you to run the script again after reboot to let it autodetect the wifi and apply the necessary device tree overlays.

Well I stopped building and actively supporting the legacy image. The only missing thing is the NAND driver, for all other uses mainline kernel should be better.

@mikes123 run again rk3318-config, select again led-conf2 and then reboot again. It should appear wlan-ap6334 in overlays line in armbianEnv.txt

The question is absolutely relevant and very welcome. The answer is quite simple although: for historic reasons, those overlays are called led-conf but actually, during time and studies on the boards, they should be more properly called gpio configs or board configs: they deal with the peculiarities of the specific boards and integrate the "base" device tree. The led-conf dtbs overlays don't necessarily carry the information about the wlan chip: the boards are designed to host several different wifi chips and the wifi chips are in turn designed to be "drop in replaceable". Wifi chips exchange data with the SoC via SDIO bus, but also have other pins for other essential purposes (power, reference clock, antennas, etc...). One of these pins is the enable pin. The enable pin turn on and off the wifi chip. It is like a button, which is in turn connected to a SoC GPIO pin that can be controlled by the software: the linux kernel can turn on and off this pin which will turn on and off the wifi chip. The problem is very simple: most boards use the same SoC GPIO pin to control the enable pin of the chip, but some others use another one, or swap its polarity. You need to tell the kernel which GPIO pin is the right one, otherwise the kernel just can't turn the wifi chip on and, in fact, the wlan0 device does not even appear to the system. The GPIO pin for this functionality is specific to the board design, hence it is described in the led-conf overlay. As an example, the boards with T066 marking needs such treatment (led-conf4, see here), but also other boards require it (I count at least three different configurations in those overlays, plus the base one). Using the right led-conf is usually enough to get the wireless appear and work, because the kernel can turn on the wifi chip, poke the SDIO bus for the device id and load the right driver. In some other cases, there is the need for a supplementary dtb overlay to get full functionality for the wifi chip: rtl8723cs/rtl8703bs is right the case to get also the bluetooth working, because it requires some other bits for complete configuration. Normally the rk322x-config script deal with this automatically. You may need to run it a second time after reboot to complete the configuration though, in case in the first run it was unable to detect the wifi/bluetooth chip.

@Tiago Barsan rtl8703bs uses the 8723cs driver, which is already included in regular armbian images. Perhaps you need to select the right led-conf from rk322x-config script for your board, which is unknown because you didn't wrote and didn't post photos of it.

@mikes123 Hello, first of all you need to choose led-conf2 from rk3318-config to enable the proper led/gpio configuration for you X88 Pro board, then reboot. This is an essential, one-time only configuration that you should not change later for any reason. Try to connect with this setup. If you still have problems with wifi, consult the first page in the paragraph "special hardware" and follow the instructions there

Perhaps you're having the same issue with ddr memory frequency mentioned in @SpellKilleR above. Perhaps it is time to go back to the slower but safer 333 mhz ddrbin 🤔

Hmmm, no, it's not norma, you should get 333Mhz there if you use the 333mhz ddrbin. The blue board is IMHO having somehow unstable and the higher frequency of the DDR can indeed cause that. If you are on the new "main" branch of armbian, perhaps there is an issue with the cache. You may try rebuilding the images doing ./compile.sh ARTIFACT_IGNORE_CACHE=yes KERNEL_GIT=shallow EXPERT=yes and try and see if it creates an image with the proper ddrbin. It would take considerably longer times than usual cache-based compilation because it will rebuild the whole u-boot and kernel.

@SpellKilleR Hello! First of all, you should use one the included overlays suitable for your board to get better functionality using rk3318-config script. If I remember correctly, there should be an overlay for a95x board (but I can be wrong) with everything already in place. About the missing boot from the second board and inability to do debugging via serial port, it looks to me the missing SMD components you are referring to are very near the serial pads. Usually those components are small resistors, you can get the serial functionality just shorting them in place of the resistor and you will ready to go. I have half an idea about the bad behaviour of the rk3328_f2 board that can be related possibly to the ddrbin command rate or frequency rate: in some cases, the 667 mhz frequency at startup is not happily accepted by some boards. Since you're pretty able to compile your own images, you may try changing the ddrbin in this file with the 333 Mhz version (just swap 666 with 333) and try again. PS: the big plastic package near the ethernet port is not a chip, it is a set of coils (a transformer, actually) to raise/reduce voltage to transmit and receive the signal over the wire. The real fast ethernet LAN controller is inside the SoC

@IMakeTheQuestions a question about your board: are you sure it has a rk3228a and not a rk3128 ?

Perhaps those pads are just board placeholders for leds. The board is a total newcomer, so you have to post a high resolution photo of the other side too. multitool can let you make a backup of the original firmware, you can share it and then I can extract the DTB from there. The rockchip RK915A wifi chip is also a total newcomer in the scene, this is the first time I hear about It depends about what you want to achieve. the male to male cable let you do the same things multitool is able to (backup, flash image, erase flash, ...) but you have to do them manually using rkdeveloptool command line tool. Much of the information is shared here: https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/ in the section "Alternative backup, restore and erase flash for EXPERTS". You can indeed do a backup of the existing firmware and then erase the flash, then your board will boot from sdcard on which you could directly put armbian to see if it boot and works for you.

This is a totally new board design that has never appeared on the forums, could have different wiring. Very useful are: detailed image of the other side of the board (the uart pins may be there too) name of the wifi chip on the board original firmware and/or original dtb to inspect the output of the uart logs Also try this other "experimental" multitool image to see if it works for you

They can't, because some boards like the "old" nvram and some others want the newer

@stroma first page, one of the last paragraphs...

Too vague, please provide logs via serial adapter and photos of the board.

@SuperMaximus don't do full-upgrade until the driver is enabled in mainline armbian. I'm going to do merge the config bits right now, but I don't know when the next kernel update will be upstreamed to armbian repository. Could take days, or weeks. Perhaps @Igor may give a hint about. edit: yet consider that your board is not officially supported, because it is a Tinkerboard S R2.0; I'm not aware about the differences from the regular Tinkerboard S Rev 1.01. Support is best effort.

@Vittorio Mori Hardware video decoding is available since kernel 5.10 on armbian, thanks to libreelec patches, but the userland part is a bit worrysome. You can try with this, but it is a very old post and very old binaries that probably don't work on recent kernel because it is more than one year old. The problem is that ffmpeg never really stabilized the v4l2-request kernel api, thus you have to compile the libreelec patches version and then supply the static libraries to mpv to gain hardware video decoding via v4l2-request. I don't know if recent ffmpeg 6.0 release include working support for v4l2-request or there is the need to still use the libreelec patched version.

@SuperMaximus You have to wait a bit for the kernel config selection menu to appear, armbian has to patch the kernel and compile uboot first, then it will appear.

@SuperMaximus I attach the patch to the message, perhaps git does not like copy-paste from the forum due to space/tabs mismatch disable-vidconsole.patch edit: 8723ds is disabled in the current 6.1 kernel, perhaps it got disabled during the transition from 5.15. You can enable it by yourself choosing to show the kernel config initial compilation menus, and then finding the driver in the following tree: │ -> Device Drivers │ -> Network device support (NETDEVICES [=y]) │ -> Wireless LAN (WLAN [=y]) │ (1) -> Realtek 8723D SDIO or SPI WiFi (RTL8723DS [=n])

@SuperMaximus asus does not provide any specific info about the wifi chip, you don't provide logs nor details. It is very hard to do support this way and looks like a waste of time.

@SuperMaximus Well I just checked my Tinkerboard S which is rev. 1.01 and has a rtl8723bs wifi chipset that is working perfectly fine. Could you please verify your wifi chipset on your board?

@SuperMaximus A couple of questions: why do you say Tinkerboard S has no wlan0 in kernel 6.1? It was working last time I checked out (although with some incomprehensible performance drops) are you on legacy master branch or current main branch of armbian? also, whatever you have in your userpatches directory is only yours, since the directory is in armbian .gitignore and not committed into the repository 🤷‍♂️

@SuperMaximus Perhaps this is what you want: diff --git a/include/configs/tinker_rk3288.h b/include/configs/tinker_rk3288.h index bde7d72e6d..64c0781359 100644 --- a/include/configs/tinker_rk3288.h +++ b/include/configs/tinker_rk3288.h @@ -8,8 +8,8 @@ #define ROCKCHIP_DEVICE_SETTINGS \ "stdin=serial,usbkbd\0" \ - "stdout=serial,vidconsole\0" \ - "stderr=serial,vidconsole\0" + "stdout=serial\0" \ + "stderr=serial\0" #include <configs/rk3288_common.h>

Not a wise thing to do though