jock

@Luís Hansen sorry but I don't see an obvious reason. As far as I remember, even in the previous case the esp8089 was not detected on MXQPRO board. Indeed there is something wrong with the dtb, but even looking throughly at it I could not find the real cause. Having such a board in my lab could make it much easier to understand at which level the problem is. The fact that rk322x-config says "no wifi chip detected" means that the chip is not even exposed on the sdio bus; there could be multiple reason: the chip is turned off, there is a misconfiguration with the bus, etc... For example, these commands: cat /sys/bus/sdio/devices/mmc1:0001:1/vendor cat /sys/bus/sdio/devices/mmc1:0001:1/device should not fail and show you valid hexadecimal values to identify the esp8089 even if the driver is not loaded or not working, because they work as long as the hardware is detected by the kernel. So this the first problem that must be solved and honestly, since you say that doing trial and error with the variosu led-conf* overlays, you could try each overlay and report in which case the led-conf works.

No, there is no such thing. The only way to know what kind of memory you have is read the signature on the chips and look for the datasheet. But usually DDR3 shipped with these tvboxes are 667 or 800 MHz parts. You may try, but I have no reason to think that DDR frequency can in any way interfere with CPU frequency. That would be interesting since you have two different boards; often those with rk3328 have a power regulation chip and rk3318 have none, but you have to look to the boards PCB. Generally, choosing the right led-conf/GPIO pins configuration for the board is essential to get stability and functionality, but without A ) detailed photos of the board and B ) original dtb from Android it is impossible to produce suitable GPIO pin configuration. Now this kernel v5.18 looks like is having issues of which I don't grasp yet the nature of...

@Luís Hansen Of course you have no such overlays, you took an archived/obsolete image from August 2021

@Luís Hansen Maybe I spotted something wrong in led-conf6 device tree overlay. Please overwrite the existing /boot/dtb/overlay/rk322x-led-conf6.dtbo file with this one: rk322x-led-conf6.dtbo Then run rk322x-config, select led-conf6 and reboot. BTW dmesg log is helpful, armbianmonitor -u link is even better

@Willy Moto If you're stable with 1.1Ghz and DDR@667MHz there is no sense in downgrading to 333MHz; the issue is not the DDR neither kernel; the problem is the CPU@1.3GHz. I don't remember your board and the led-conf you were using, but for example @MX10.AC2N has exactly the same problem as yours. If you were using led-conf3 because your board has a regular rk3328 with the proper power regulation chip then there is some issue there: either the power regulator or the device tree overlay has some issues and needs to be fixed to let the CPU works stable at 1.3GHz.

@pakos96 from the dmesg you posted there is a problem with the sdio wifi too (device mmc1), so there is something wrong with your configuration which is disrupting the mmc controller as a whole. Can't say anything more, rk3318-config clearly says that those settings are for advanced users, may or may not work with your board and incorrect settings can prevent your system from booting. 🤷‍♂️ There are plenty of ways to access your current installation. A couple of them: boot another installation from USB or sdcard, or just use the multitool to do maintenance.

That should be right. Of course I can't be sure, but probably it is so. This is the right place to find the original device tree. Usually it is contained somewhere in the first 32 megabytes of the image. You can post it somewhere, I will try to extract it by myself, otherwiser binwalk utility should be able to extract it, or there is a tool @fabiobassa may hint you (I don't have the link) If the network device is there (wlan0) but it is not able to see the networks or not able to connect, the issue is probably related to the crystal frequency or the firmware (but this last one is unlikely) If the wlan0 device does not appear at all, then it is a matter of wrong bits in device tree. This is the general behaviour, but indeed something from device tree may also prevent the device from work. No, absolutely; that file is not in use during normal runtime.

Not enabling the eMMC items that break your installation. How to know which one breaks? Trial and error. A photo of dmesg | grep mmc2 could also be nice to what is going on.

@Luís Hansen First congrats for all the diving you had into the matter! About the ESP8089, there are some facts can help us giving a starting point: Your board is a MXQPRO_V72, there should be a led-conf right for your board in the list; stay stick to that, there is no sense in trying all the others The ESP8089 has a 26Mhz crystal (the other 24Mhz is for the SoC, all rockchip SoCs have a 24Mhz reference crystal so far), so using anything else will result in the chip to be unable to attach to an access point (will show the networks though) If the wlan device does not appear, it is something related to sdio bus and/or powering the chip (the pwrseq you can see in the dmesg), the original device tree can be useful to see if there is something wrong with that.

Yes, an adapter like that is fine; beware you need some basic soldering skills and your board must have accesible serial pads (usually marked with TX RX GND labels, in rows of 3 or 4 holes one after another) to get things done. If you don't feel acquainted with electronics mind your choices, but surely a serial adapter like that is always handy when you need to do some debug on various devices (tv boxes and routers mainly, but also televisions, decoders, phones, ...)

Mmmh so I guess I need to double check the led-conf3 overlay... maybe something subtle changed in kernel v5.18 and the overlay does not apply clean anymore. Thanks for patience! Also if you have a serial adapter, it could be useful to report the u-boot logging that may tell you if something is wrong with the device tree...

Ok so it looks to me that: kernel v5.18 idbloader 667 Mhz CPU at max 1.08/1.2GHz seems to work stable enough, right?

No, 1.2GHz is not enough; you must go below that value otherwise it is a useless test. Use 1.08GHz if you want a reliable test. BTW, on the datasheet the maximum operating frequency is expressed as 1.3GHz (Table 3-2, page 37):

AFAIR rk3328 is advertised a 1.5ghz part, but actually is 1.3ghz, I can be wrong, though. The suggestion to try 1.1Ghz is to understand if the problem is due to voltage regulators (the reason why it is very important for you to use led-conf3 overlay) or there is something wrong elsewhere. BTW you are now back to v5.15 or still on v5.18? Are you using 333MHz idbloader or 667MHz one?

@MX10.AC2N well, despite the openssl warnings, gcc is crashing with a segmentation fault... gcc comes with the ubuntu jammy, so if it crashes it's not a mistake of the update. Firefox being killed... don't know, maybe is due to unstable system, I don't see anything suspect in the logs you sent, either there are no segmentation faults and no out-of-memory process kills. May I suggest you to use 1.1Ghz device in rk3318-config and see if system works better?

@MX10.AC2NI see that you installed have several dkms modules, plus gcc is giving a segmentation fault and suggests to report the bug; can't say anything more, everything here seems not related at all with armbian and upgrade packages, the upgrade just triggered the dkms modules rebuilding, but the root cause does not seem to be related with the upgrade packages. The reason of the instabilities of the board should be investigated though...

@MX10.AC2N There seems to be this anbox driver module that is installed as a dkms module and it fails the module rebuilding. Now I don't know if it is due to some missing bits in kernel headers or the anbox driver module does something bad on itself, but you should try first to remove it from the dkms list (this guide may be helpfui) and then reinstall the packages; they should not give you errors. But yet, it looks like from the apt output that 22.08.0-trunk packages ARE already installed, so I don't understand the previous logs. If your box is still unstable, you may try to install the 333MHz idbloader, if you are still unstable, then you need to revert back to v5.15 because something is broken elsewhere. BTW, from memtester output, it looks to me that the DDR is not suffering the 667MHz clock, at least it is not completely broken but indeed there can be more subtle problems. You may also revert back to kernel v5.15 and keep the 667MHz loader, installing back only linux-image-* and linux-headers-* packages, but your mileage may vary.

OrangePI 4 LTS, tested: Ubuntu Jammy CLI kernel v5.15 Ubuntu Jammy XFCE kernel v5.15 All seems right fine 👍

It's the same as the other in the previous post, just has memory configured to start at 300 MHz instead of 660 MHz. That caused some incompatibilities in the past, in fact I always say myself that I need to change the loader in the first page and then always forget...

Wait, in maskrom mode what you can do is only uploade the loader with rkdeveloptool db command; it is essential to go further with any other rkdeveloptool command. I put here a couple of more loaders you can try and see if you get better luck. Also be aware that I suggest to use the rkdeveloptool binary provided by rockchip on github repository. rk322x_loader_v1.10.256_300_no2t.bin rk322x_loader_v1.10.256_2t.bin

@MX10.AC2N Honestly I don't know what you exactly did with those commands... I see that you installed the upgrade packages manually with dpkg (it is better to use apt, as suggested), then you reinstalled back armbian rockchip64-current package via apt, as I see in your nala log: ... linux-dtb-current-rockchip64 (22.05.0-trunk) -> (22.05.3) linux-headers-current-rockchip64 (22.05.1) -> (22.05.3) linux-image-current-rockchip64 (22.05.0-trunk) -> (22.05.3) ... but this shows that you never really had the manual upgrades really installed. You should have 22.08.0-trunk installed, as stated during manual installation with dpkg): (Reading database ... 188694 files and directories currently installed.) Preparing to unpack armbian-bsp-cli-rk3318-box_22.08.0-trunk_arm64.deb ... Unpacking armbian-bsp-cli-rk3318-box (22.08.0-trunk) over (22.05.0-trunk) ... Preparing to unpack linux-dtb-edge-rockchip64_22.08.0-trunk_arm64.deb ... Unpacking linux-dtb-edge-rockchip64 (22.08.0-trunk) ... Selecting previously unselected package linux-headers-edge-rockchip64. Preparing to unpack linux-headers-edge-rockchip64_22.08.0-trunk_arm64.deb ... Unpacking linux-headers-edge-rockchip64 (22.08.0-trunk) ... Preparing to unpack linux-image-edge-rockchip64_22.08.0-trunk_arm64.deb ... Unpacking linux-image-edge-rockchip64 (22.08.0-trunk) ... Setting up armbian-bsp-cli-rk3318-box (22.08.0-trunk) ... Setting up linux-dtb-edge-rockchip64 (22.08.0-trunk) ... Setting up linux-headers-edge-rockchip64 (22.08.0-trunk) ... So now I don't really know what is your current setup. I published again v5.15 kernel packages: https://users.armbian.com/jock/rk3318/upgrade/v5.15/ but, if this does not fix, consider to restore a backup if you did any.

@MX10.AC2N ok, you didn't tell if you installed the 333MHz idbloader or not... Also notice that you are overclocking the rk3328 with 1.4 and 1.5ghz speed bins...

Hello! Yes, fortunately there is something you can do. Here I supposed you have eMMC and not NAND, if you have a NAND chip, things are more complicated I may just guess what's wrong with your board, so I am not 100% certain, but probably your problem is a DDR Memory that does not support 2-cycles (2T) Command Rate. 2T Command Rate is the default for most of the DDR memories installed on rk322x boards, but there is a very small minority that just want 1-cycle Command Rate (1T) First of all, try this other loader: rk322x_loader_v1.10.256_no2t.bin and see if it gets uploaded correctly. A serial adapter connected to the board would be very welcome to see the log messages from the very first boot process, but I guess you don't have such tool. If the upload process goes well, my theory is probably right. You can now use rkdeveloptool ul rk322x_loader_v1.10.256_no2t.bin to upgrade the bootloader in the eMMC. This should be enough to let the multitool boot again. You can start again with multitool, install again the image and then do not shutdown the box, but use the multitool menu item "Change DDR Command Rate" to set Command Rate to 1T; then you can shutdown and see if the image now boots. Of course you can even restore the original Android image you took with multitool: just unpack the backup and then write with rkdeveloptool wl 0x0 <filename> edit: I will never stress enough the fact that images should be first tested via sdcard before being burnt in eMMC, as I always suggest to do in instructions.

@MX10.AC2N @Willy Moto Ok I managed to compile just the idbloader that does the DDR initialization to 333 MHz. This is the binary with the 333MHz ddrbin: idbloader.img And you can install from the box itself on the eMMC (should be suitable for @MX10.AC2N, mmcblk2 should be the eMMC, but please verify!) installation doing: dd if=idbloader.img of=/dev/mmcblk2 bs=32k seek=1 && sync Or you can boot into multitool (this should be the case for @Willy Moto) and do the same via shell. Of course you need to transfer the file on multitool FAT partition, boot with multitool and then mount the FAT partition manually via shell.

@Willy Moto @MX10.AC2N I have the suspect that the issue may be related to memory clocks. I thought it was safe to bump yo 667Mhz since DDR memories are commonly 667 or 800 MHz on our boards. I will provide a binary bootloader that could be overwritten to restore 333MHz memory clock, so we can at least isolate if the problem is the memory clock or the v5.18 kernel. I'm writing this message right from my box and it is working just fine, it's uptime is 2 days and has survived a full kernel compilation and various firefox sessions. A way to detect if there are memory issues can be installing memtester package via apt and running it with memtester 512M to at least verify that memory clocks are safe. @MX10.AC2N please also verify that you stiil have rk3318-box-led-conf3 overlay in /boot/armbianEnv.txt: that was essential to make your box stable. I have no reason to believe it has been removed, but in case it needs to be reinstated.