jock

@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

@SuperMaximus probably you can disable the vop nodes in the device tree and there will be no video output. Another way could be to disable the video output in the u-boot configuration/header files (ie: remove vidconsole)

@stroma Hello, thanks for the photos, they will be useful at least to have an idea of the issue. Anyway did you try the experimental image with kernel 5.19.15 and libreelec patches? They have several HDMI/DRM fixes, perhaps they fix your case. Since the LE patches are not mainlined into armbian, you should then not upgrade the kernel. I quickly looked back and @Seth described similar issues you have had with his two boards.

Hmmm that's odd, I applied the same "fix" @ilmich applied on libreelec but it didn't work. The serial log output could have been very handy here; we will think about what could be wrong and maybe some other idea may pop up.

@rafaeldavid I actually don't remember what exactly we discussed about the last time, but surely R29 boards have this long-time HDMI issue I could not inspect because have no such board and noone provided one to study. For the clock issue, I don't remember if I suggested you to use the cpu-stability (both with 1.2 or 1.4 ghz max frequency) overlay and see if it makes any difference. What I could guess about is that there are some board whose power regulation design in "slow" to bring up voltage in time for the frequency change, so random crashes happens. The overlay will raise the lowest voltage from 0.900v to 1.100v, so the gap with max voltage (1.35v) is shorter. I have a board with such kind of issue right here, and that overlay made it work flawlessy.

Perhaps @Seth can give some advice.