jock

@arcube101 Hi, this kind of problems usually is in the wifi firmware/nvram ballpark, except for on kind of software issue I experienced: check if wpasupplicant debian package is correctly installed in your system: that package was removed as a dependency from network manager in upstream packages, thus was not included anymore in the base armbian images. Installing it manually may solve the problem. Other than that, I have seen such kind of refusal when the crystal reference clock was set to a wrong frequency, but AFAIK on realtek chips you really can't se the reference frequency via driver option or nvram. Try the first suggestion and see if it works.

@moussa854 Hello, from the logs you posted it looks to me that the eth0 interface seems to be DOWN: ### ip addr: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet XXX.XXX.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 56:9e:45:d9:4d:b8 brd ff:ff:ff:ff:ff:ff

🥳🥳🥳

No, I mean the serial output logs. If you don't know what I'm talking about, read the rest of the thread or search with google.

Inference in which sense? An opencl load of some sort?

Paste the serial output logs here; without them, we're blind

Best hope is that it will go around 400mbit/s, more reasonably around 300/350mbit/s; surely you won't get anything near the full gigabit.

Nope. But you can put the compressed image and multitool will decompress on the fly

Hello, what do you mean exactly with: Also post the link given by armbianmonitor -u

NAND are not exactly easy beasts, if the multitool does not detect it anymore it is because the kernel rockchip driver does not detect it. It is difficult to say what happened exactly, we have spent hours and hours to figure out what was the behaviour of the nand driver and all the other proprietary software pieces of the puzzle. Also they are quite "fragile" pieces of hardware, and abusing of them can quickly destroy the cells capacity to work. In the past, people has restored the NAND functionality restoring original android images with AndroidTool for windows, or uploading particular bootloaders; you should look for such resources in this thread (or with google) because some procedures were described to do so I forgot to bookmark. For what me and @fabiobassa have seen, what seems to be an apparently random behaviour of the NANDs, in reality it is deterministic and can be understood. What we've found to be totally confusing was the fact that keeping anything attached to the board (HDMI, ethernet, keyboard, serial adapter, ... whatever!) can prevent the NAND from being detected after a reboot. Also remember to use the armbian image with the legacy kernel, those with mainline kernel miss the proprietary driver. Also you could post a dmesg log after booting such legacy kernel image to see what the driver has to say about NAND.

I think all the greetings go to @SteeMan that spotted the missing bits in some armbian configuration files

Well, maskrom mode is ALWAYS possible, there is no way except doing hardware damage to the board to break maskrom mode.

They ARE developed, and are pretty advanced too. The problem is that video acceleration in browsers is far from being a simple task. Consider that it is not so easy to have hardware accelerated videos even with regular x86

Hmmm, this is interesting, because I experience this also on rockchip 32 bit with kernel 6.1.11 revision. Perhaps we're hitting a kernel bug at this point

@gerotmf You could keep a ssh session with dmesg -w command running while you do the operations that freeze your board. This way you will immediately see kernel issues on dmesg log as soon as they appear, if there is any. After inspecting the dtb, I don't see anything really relevant that may causes crashes. You can run some benchmark/testing tools like openssl (using the "speed" benchmarking mode) or memtester to chek the ram. Also you may follow the instructions in this post to install an alternative bootloader with memories at 333 MHz (in place of the stock 666 MHz) and see if you get better stability.

Yes I made some precompiled images in the past, but they are not updated anymore because there are the "nightly" ones. I suggest you to go with nightlies, which are updated very often, even though they are not declared "stable" because they come with the "edge" kernel flavour. You can always switch to a "current" (ie: older kernel, considered "stable") kernel using armbian-config if you prefer. The only drawback with nightlies is that the userland comes with debian sid or latest ubuntu, which is not always an optimal choice (debian sid is way too edgy, for my tastes). Yes I am

@pakos96 That's right, the flashing leds are made on purpose to have a visual feedback that the kernel is alive. Once you setup the led-config suitable for your board, you can change the led behaviour writing to /sys/class/leds/working/trigger. You can even read that file to know which are the available triggers.

@Slash402 actually, I don't even know if there is real fault in the hardware or 4 chips are fake or whatever... looking at the PCB there are 8 chips of 2 gigabits each, so they should account for a total of 16 gigabits = 2 gigabytes. Now 1 gigabyte is missing, but who knows why... the tricks and gimmicks of chinese cheap tv boxes are infinite. The original idbloader runs the memories at 666 mhz, it is a very nice bump in general performance against the 333 mhz of these other idbloaders, so I suggest to use the original one if it works ok for you.

@MattWestB beware that rk3318-config does not let choose DDR frequency, that's for rk322x. rk3318 requires proprietary trust os to enable the ddr scaling, but the proprietary os does not allow frequencies above 1.1ghz artificially crashing the system. For this reason, on rk3318 I'm using the mainline opensource trust os, which allows to run the cpu above 1.1ghz without issues, but does not support ddr scaling. That's it, closed source code 🙄

@Slash402 thanks for testing, as I suspected the issue is not in the software but in the hardware. This clarifies some other dubious cases that were raises in the rk3318 thread where other people was claiming similar issues. Sorry, but I think there is really nothing to do about 🤷‍♂️ Perhaps you could put the board in the oven, if there is a soldering issue... I'm not joking, it is a known trick to do cheap "reflowing" of the BGA chip soldering. Of course it can melt down the whole board...

You can check the dpll core clock in linux, it tells you the clock used by the dram controller. cat /sys/kernel/debug/clk/dpll/clk_rate It should tell you 666Mhz or 1333Mhz, I don't remember if it accounts for double-data rate or not (but I think not, probably will tell 666Mhz). edit: about the poor youtube performance, it is due to the fact that the cpu is not powerful enough, there is no hardware video decoding yet for videos in the browser and the graphics pipeline is not really well optimized for general purpose desktop environments.

Tested Asus Tinkerboard: Armbian_23.02.1_Tinkerboard_jammy_current_6.1.11_xfce_desktop.img.xz Most of the hardware seems to work pretty fine and the board is stable. Bluetooth adapter is not detected at all (perhaps some kernel config bits are missing? Need to check this...). I got a weird stack trace when launching the "Celluloid" application, but it seems more a kernel bug rather than anything related to armbian. An old 2Gb USB stick did trigger lot of weird USB errors, the stick works perfectly elsewhere, perhaps some compatibility issues. Overall, USB ports are working with other devices. Wireless performance is swinging from 1 mbps to 12 mbps, not really clear why, but connection is stable.

Tested OrangePi 4 LTS: Armbian_23.02.1_Orangepi4-lts_jammy_current_5.15.93_xfce_desktop.img.xz Armbian_23.02.1_Orangepi4-lts_bullseye_current_5.15.93_minimal.img.xz Bluetooth adapter is detected, but this time I was unable to pair with the usual audio speaker The rest seems to work pretty well

@Slash402 Okay, so here it is. I attach two "alternative" idbloaders, you can try both of them to see if something changes. I strongly suggest you to do these tests on a sdcard rather than emmc. If something goes bad on the sdcard, swapping it is easy. If something goes bad on emmc, you will soft-brick the board and need to force it in maskrom mode (it is not pleasant task to do). If you want to go the sdcard way, you will need to first erase the eMMC completely using the multitool, then just burn armbian on sdcard and boot the tvbox with the sdcard inserted. The devices are: sdcard = /dev/mmcblk0 emmc = /dev/mmcblk2 To backup the existing idbloader: dd if=/dev/mmcblkX of=idbloader.old bs=32k skip=1 count=4 (change mmcblkX with the device you choose, so mmcblk0 if you choose the sdcard way, mmcblk2 if emmc) To burn a new idbloader: dd if=idbloader-333mhz-1.16.img of=/dev/mmcblkX bs=32k seek=1 conv=fdatasync (again, change mmcblkX accordingly as above). then reboot and see if something changes. You can also try idbloader-333mhz-alt.img idbloader using the same command. idbloader-333mhz-1.16.img idbloader-333mhz-alt.img

I'm afraid there are no chances for more, if the kernel detects such amount, that's it. The one and only doubt I have is the "modded" 666mhz ddrbin in place of the "standard" 333mhz ddrbin could have some role in this. If you want I can give you a 333mhz bootloader and the instructions to quickly install it for a definitive test.