jock

@sermayoral if you search through this thread, you will see that box vendors are often altering the specs on purpose to fraud people, other time they are just coarse.

@http418 If you don't provide any logs, photos, description of the issue (you were talking about the loader before, now you talk about armbian dtb...) you will be banging the head for yet long time...

Nope, the cpu is 32 bits.

This is not for rk3188, but for rk3318. And no, you have to handcraft yourself the device tree for that or use the existing overlays to overclock the thing

Try this other bootloader: RK322XMiniLoaderAll_V2.51_spectek_en_ddr2_rd_odt_180703.bin Very useful tool to know what is going on. I suggest you to buy one or two or them.

@primoitt perhaps you should consult first page on "Multimedia" paragraph. The way to go on mainline kernel is, as suggested by @fabiobassa, use ffmpeg, but AFAIK you still have to patch it manually with some libreelec patches to let it work.

@mikes123 Actually I don't know what is going on with your wifi: the chip is detected regularly and the firmware is correctly uploaded. If you tried swapping the nvram as suggested and still does not work, honestly I don't know what else can be. Perhaps you could extract the firmware and nvram from your original firmware and try them.

@Ethanol6 Then I need the detailed UART serial output to help you with diagnostics, if the image boots from sdcard but not from emmc there is something going on.

@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.