jock

Hello, hmm that's an error in that page: tv boxes cannot be maintained as official armbian boards, so there could not be official user support, help and debugging. Instead they are supported by community, so this forum is the place where support and development happens. Feel free to join and propose patches, ideas and advancements.

AFAIK normally the packages are configured to "conflict" when the same package is installed for another current/edge flavour. Ie: if you install the "current" kernel flavour, it first removes the "edge" or "legacy" kernel flavour and then installs the "edge" one. So in theory if you reinstall the "edge" set of packages, apt should automatically remove the "current" set. In theory. Anyway your mileage may vary, since the process is a bit "tricky" and may hang in every corner. Personally, I would go manual first removing the "current" packages and then reinstalling the "edge" packages just after to be sure all the files, symlinks and dtbs goes in the proper place. Anyway I'm in the process of rebuilding the images and packages for kernel 5.18.10, I think I will upload them in minutes...

I experienced this issue tons of times in the past while working on tvbox support, mostly it was happening after freeze/reboot during kernel boot. As far as I can remember I took a look and there was an armbian service which was rewriting armbianEnv.txt at startup (maybe to update usb quirks?), in fact the order of keys in armbianEnv.txt sometimes changes. I suspect that when, for a reason or another, the cache is not correctly wrote to flash, armbianEnv.txt gets corrupted. Recently it didn't happen anymore to me, to be honest.

@callegar@Willy Moto@MX10.AC2N Ok, I double checked the cpu voltage supply and effectively it seems that in the latest device tree I pushed it way too low... The original device tree of my box said 1.375v@1.3Ghz, the voltage in mainline kernel says 1.300v@1.3Ghz and I set 1.200v@1.3Ghz. That is very good for temperatures and power consumption, but maybe it is a bit too low for stable operations. I will rebuild the whole set of images, but in the meantime I updated the dtb deb package you can install that should fix issues: https://users.armbian.com/jock/rk3318/upgrade/linux-dtb-edge-rockchip64_22.08.0-trunk_arm64.deb

@t9097 Thanks for reporting the issues with USB3, I've been away this whole week for work and I will check as soon as I can. About the unstable system, well I didn't experience such unstable system on my Opi4 LTS, watched youtube and other videos without issues to be honest.

No, there is no easy way other than doing dd. As long as you have no issues if your cpu runs at 1.1 Ghz (actual 1.0Ghz...) there is no reason to blame DDRs at 666 MHz. I will double check the voltages and compare them against a previous edition, maybe the bug could be just there...

dmesg tells you the current command line. Whatever those command do is out of my reach.

Actually it looks like all the hints are pointing to such cpu voltage issue, but that patch is for kernel 5.15 but issues are related to kernel 5.18. Working for support for another board, I discovered a patch that was only in kernel 5.18 armbian patchset that was breaking rk3318/rk3328 PWM regulation (in turn it broke voltage regulation on our tvboxes that use PWM to modulate cpu and gpu voltages), but the latest compilation should already have that patch removed. I'll try to rebuild things and provide images and debs from scratch as soon as I can. edit: I forgot to add that the PWM breakage is not consisting with @MX10.AC2N experience, since he has an rk3328 board with "proper" voltage regulator chip (rk805) and thus does not use the cheaper PWM regulation for cpu voltage... 🤨

Reliability about what? You still didn't mention what you want to do with such hardware. Tv boxes are not reliable almost by definition, especially if you look into the basket of the cheapest ones. They are made with cheapest components available on the market, sometimes with scrap components that did not pass the conformance tests for "proper" products, sometimes with fake components too. If you need something reliable, it is much better to go and find a serious SBC officially supported by armbian; tv boxes can't be officially supported by armbian by statement because, as you can see, it is a hardware mess and sometimes poor board designs. What we do here is having fun reverse engineering things, but serious projects require serious hardware. About the last question, wireless is totally out of question if you need any kind of network stability

Well no, in my experience some wifi works very well and some others don't. Also take in consideration that the tv boxes have no public specs and no schematics. These are the cheapest general purpose hardware you can find on the chinese market and manufacturers put the cheapest hardware on the market on them, so supporting the huge variety of peripherals requires lot of reverse engineering. Tuning for "perfect" stability requires time, patience, knowledge and obviously the hardware at disposal to do tests and tests... Consider that I've never seen your board - never ever had any board with eMCP or esp8089 chips: it is quite an accomplishment letting it boot without major manual operations and/or special hardware.

Then it's very ok to me, as long as @SteeManalready has to move a significant amount of posts in the right location right now.

I'm not sure it is a good move. I mean, from a management point of view probably it looks like it is the right thing to do, but doing this could lead users into confusion and let them make lot of posts in the wrong places again like before? This should be much better now that every device has its own subforum, but the average user just does not understand what armbian means with "unsupported" or "CSC". I guess that there would be a TV Boxes subforum in the "unsupported" section. That could work for me. I'm not against the move, but the tvboxes subforum would indeed require other nested subforums (one per each vendor) as is it right now. The "overview" feature was indeed very useful, it's a pity to lose that IMHO, but I think we can survive its removal.

There is such 2734C chip, a google search would have confirmed that to you easily. The chipset under the hood is an ampak AP6334 which is in turn made of a couple of broadcom chips. The wireless part is a bcm4334. Probably your issue is not the dtb but the wifi chip firmware or, more in particular, the nvram /lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt which is not suitable for your board setup. The wifi depends on how the board is build for important things like reference frequency, antenna setup, sideband gpio, etc... If the nvram does not specify these params correctly, it will not perform well or will not work at all. The best thing you could do is mount the vendor partition of your Android firmware and search for a suitable firmware for your board or extract from the live Android system. Tthat could be easy but could also require various steps to get access to the partition, it depends and how the firmware is built. Otherwise you could look around in google, download new nvrams for bcm4334/ap6334 and try and see if they work for you. edit: BTW the wifi chip is fully supported by linux kernel and works wonderfully well on my board; when I say don't buy tv boxes if you want supported hardware I mean exactly this.

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