jock

Yes. true! Thanks for reporting, I need a definitive solution for that

Well for what I see, even cpu-intensive threads which do a lot of memory pressure will keep kswapd kernel thread very busy, no matter the amount of memory the board has. My first thought goes to heavily taxed network routing jobs with gigabit ethernet interfaces, for example. In fact I often see kswapd very busy on regular x86 machines too.

This looks very interesting, kswapd is essentially a cpu hungry process in nearly most common tasks that move memory around, glad to hear there is interesting work on to bring down cpu usage and make page swapping better. I would like to bring the patches in for some kernel and see if things would improve for light/medium desktop workloads. Anyone has some experience about?

USB ports are just not able to deliver such amount of power a disk drive requires. USB 2.0 specifications rate the current that may flow through an USB port is at most 0.5A, USB 3.0 should be raised up to 0.9A. Nonetheless, tv boxes usually have a much lower power rating for such ports just to drive "simple" and lightweight peripherals like usb sticks or wifi dongles. Notebook HDD drives require much more current than 0.5A during spin-up, so often they can't even start rotating. Stressing the circuitry with too much current requirement also leads to voltage drop, so instead of 5V you will probably see less than 4.5V over the line, which is by far outside specs. That causes the spin-down issue. I really doubt you got a real 5V 4A power supply: such a PSU should have very thick cables and be quite heavy. Even if your PSU is really capable of delivering 4A, everything in the middle from the PSU to the hard drive should be capable of sustaining such current (ie: there should be a negligible resistance in the path, due to Ohm's law), and this is just not true because traces in the tvbox are tiny and there are current limiting chips to avoid such high currents passing around on purpose.

If the kernel crashes then you have no other way than attach a serial adapter to the board UART to log continously, in the hope the kernel says something before the freeze happens.

If you don't provide any kind of detailed log, screenshots, pictures and details of the board there is little help to give. For the rest, there is the appropriate thread for rk322x tv box boards.

Yes, the packages changed names because the armbian master branch current kernel now is 5.15. In theory, switching between kernel flavours is flawless, but it is something I don't suggest to do. Remember that the whole rk3318 is still experimental, and keeping up with the kernels may break the system, so people upgrading kernels should be aware on how to restore the system is something goes bad.

Did you run rk322x-config from xfce? You may need to make the terminal window larger: rk322x-config uses dialog application, which doesn't work if it can't write characters in the available window space. sorry, you can't see what? If you mean 6051p, support for mainline kernel should "imminent", as soon as current kernel is going to be switched to 5.15 by armbian core team. Honestly I don't know if the kernel has been compiled and upstreamed with recent patches for 5.10 kernel, that's something happening automatically. The images I provided there use the armbian built packages to keep them aligned to official releases, so there may be the need for a bit of patience (or switch to edge kernels) for 6051p.

@vitaliy.burkut most of the work has done by @awawa, so credits goes there too

Effectively the headers file is misaligned, I need to build and upload new images and packages to keep all of them aligned. Anyway, currently the kernel is 5.15 though. By the way, installing the deb kernel packages alone already installs the kernel with bcm43342 support in (plus you need the firmware files as above). edit: debian bullseye and deb packages have been aligned to kernel 5.15.25

@Antoxic I just remembered that a board similar to yours was already spotted in the past and a lot of work was done to support it. It's from @MX10.AC2N and the pictures are at page 15 of this thread. Nonetheless he has a MXQ_RK3328_D4_A V1.01 board, yours is MXQ_RK3328_D4 V1.3. There can be subtle but important differences. @MX10.AC2N board houses a rk3328 chip and not a rk3318. Moreover, if you could extract the dtb from the original android image, or provide the original firmware I can take a look into to understand what are the hardware characteristics of your board. I guess your board is probably housing an rk3328 because it looks like it has a proper RK805 voltage regulator under the smaller heatsink, which is not common on rk3318 boards.

@Antoxic ok so your board is apparently ignoring sdcard because most probably the sdcard is wires to an alternative bus. Did you read this post from @fabiobassa? It is mentioned in the first post under section "Multitool does not boot" and contains instructions and a miniloader to flash the armbian image directly onto the internal eMMC, which is the only way to go on your board. If it does not work, I'm afraid the only other option is to understand what is going on with a serial adapter.

deb packages and instructions for upgrading the kernel only on running system are available on first page, but you also need to put brcmfmac43342-sdio.bin and brcmfmac43342-sdio.txt in /lib/firmware/brcm directory (take them from here). Note that it is preferred to do a backup before you do such upgrades

@Antoxic ah ok I understand. Well, as @fabiobassa says, the uart is essential to understand what is going on with your box and why it does not accept the miniloader. Also you didn't tell what is the current state of your box: * does it boot with android or it doesn't boot at all? * when you plug the multitool, android boots and ignores completely the sdcard, stays stuck at boot or boots Android normally? * still, do you know, for sure, if it is a 3318 or a 3328? (don't consider the rk3328 signature on the board) From what you said in the previous posts, I see that you are able to run rkdeveloptool rd 3 without error messages, am I right?

You didn't pay attention: it is not "mine", I pointed to a binary provided by rockchip itself from the rockchip github repository, no need to compile by sources, because sources are broken and resulting binary does not work. I don't have any loader for rk3328/rk3318, don't know where you pick up that one. Surely you can try something official from rockchip from here (rk322xh is old name for rk3318/rk3328), but I still don't understand why you need such procedure, multitool is not sufficient for your purposes?

This specific rkdeveloptool compiled by rockchip never failed me, newer versions compiled from sources by myself gave me some headaches in the past. Are you also sure that your box is a rk3328 (and not a rk3318) ? Note also that there is no 3328A (nor B), the one @MattWestB was talking about is 3228A, which is a different chip. Another thing: if your box, as you claim, is really locked somehow, you could have stepped in a very rare rk3328 box. @hexdump referred about some tv boxes with encrypted bootloaders. Mostly they are amlogic tv boxes but, AFAIR, there are few locked rk3328 boxes too (some of his instructions and repositories are here: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.rk3328-no-sd-boot/rockchip-u-boot).

@Antoxic Ciao! Did you try to run rkdeveloptool as superuser also?

It happens on my board too (HK1 Max, the rounded one) that sometimes, after the board locks-up for some reason, it does not reboot and nothing is printed on the serial. This happens with android too and I have to power cycle another time the board to let it boot correctly. An important thing for debugging is that if you try to boot from eMMC, you don't keep the uSD inserted in the slot, otherwise the kernel may decide to use the rootfs from the uSD.

Hi @tommy, the board you have should be a quite regular board and thus should work out of the box with no particular problems. It is weird that booting from uSD works fine and booting from eMMC does not; you should be more precise in describing the issue and maybe posting the serial log would be much more helpful than the original android output. Well these boards and not really designed to do such jobs. Sure there is still room for speed improvement, since at the moment all the rk3318 boards are running with RAM at @330 Mhz, which is rather low, because of a couple of issues that needs to be sorted out yet.

Can't suggest anything specific to be honest, anything which is linux friendly (atheros? ralink?) should be just fine. If there is the need to enable the kernel module there will be no problems.

No, it is not possible. Never heard about such "shut down" problem, I don't think it is hardware related if you don't mean that the box powers off.

That's un unknown chip, from an unknown manufactuer and AFAIK there is no driver for that chip, so no way to go with that wifi

Hello! I'm sorry but I don't provide legacy images anymore for rk3318 from a long time. In fact there are images only for "edge" 5.15 kernel, which will become "current" mainline kernel in a couple of weeks. The patches for legacy kernel are almost dismissed because everything is moving towards mainline. Is there a particular reason you need legacy kernel?

@vhick @cnupy Sorry for the issue, I discovered that the images I built were strangely missing the bootloader. I'm rebuilding and will upload the images in a few minutes, hopefully these new images will be ok: I just tested the bullseye current minimal and it works fine, I guess the others will be fine too...

No, you had to run it from multitool to see if the filesystem was corrupted. If you reinstalled the system there is no use for such command.