callegar

This is actually my problem. My kernel is an edge package (`linux-image-edge-rockchip64`). And if I start `armbian-config` and then go to System → Other (switch to other kernels), still I cannot find any kernel newer than 6.1.11. What should I look at? My impression is that the newer kernel get to the pre-built images but do not get at all to the apt repos. At least I am unable to find them in apt.armbian.com (stable). I can find newer stuff in beta, but now that 23.05 has stabilized, I was expecting to see 23.05 kernels in apt.armbian.com.

Just to make sure I have not messed up anything. For a long time I have not received any kernel update. Is the most recent kernel available via apt still linux-image-edge-rockchip64 23.02.2 corresponding to 6.1.11? Looks like the pre-built images get a much more recent kernel. Yet even if I switch the apt source lists for armbian to bookworm I still remain on 6.1.11...

Hi, would like to know whether there is experience in upgrading to bookworm from bullseye with these RK3318/28 boards. Notably I would like to know about upgrading without a reinstall from scratch. From the general armbian upgrade instructions (https://docs.armbian.com/User-Guide_Getting-Started/#how-to-upgrade-distribution-like-focal-to-jammy-or-bullseye-to-bookworm) I see that I should: Fire up armbian-config to freeze the firmware packages (if not frozen already, by selecting System and Freeze) Follow the generic upgrade instructions specific to debian Is this enough? Should I unfreeze the firmware packages afterwords? Others when it was time to upgrade from buster to bullseye suggested a slightly different procedure: apt update & full-upgrade Disable /etc/apt/sources.list.d/armbian.list all entries to stop armbian from upgrading Use normal debian upgrade steps -> Change release in /etc/apt/sources.list apt update & full-upgrade Restart, validate working system Update /etc/apt/sources.list.d/armbian.list with new release apt update & full-upgrade Is this any safer? They recommend making sure at least some working version of armbian-image-* armbian-dtb-* is installed before rebooting which seems reasonable, but is there any reason this might fail? Thanks!

Just installed them and they seem totally fine. A big thank you!!! When you ssh onto the machine you find it at 60°. With the 22.05 build I think it was at 61°, so maybe there is also a little advantage here. Also got rid of the previous `-current` dtb, kernel and headers packages. One final question: the correct u-boot to use is the one from the previous 5.15 branch, namely `linux-u-boot-current-rk3318-box_22.08.0-trunk_arm64.deb`, right?

Tried with that and the edge kernel packages. Now I have 5.18.6 and everything seems fine. Just one question: I now have both the -current and -edge kernel packages installed and the system boots the -edge kernel. I think I should remove the -current packages, right? Some armbian threads seems to state that switching kernel from legacy to current, from current to edge or the other ways round should be done with the assistance of `armbian-config` for the removal of the unused packages. I do not have such option in `armbian-config` though. Is it OK to just remove the -current packages?

Indeed, I found because a few people were reporting issues with 5.18, but at the very same time I was encountering quite similar issues on 5.15, which seemed to me a weird coincidence. I saw there is no similar patch for 5.18, so I thought that maybe that 5.15 patch was meant at porting into 5.15 some change that was already in built in 5.18 and maybe help at confining the search for the actual problem. I do not have enough knowledge about the inner matters, though. Is there some way to find out if a tvbox has aproper power regulation or not (apart from breaking that open)? In addition to that, should I also test the 333MHz idbloader? Is there an easy way to switch back and forth from the 333 and 666MHz idbloader? I've seen that changing the idboader is a matter of dd-ing a file onto the machine, but it is unclear to me which file is for 333 and which one for 666 MHz. Looking forward to the new build to test.

The relevant difference seems to be in the `board-tvbox-rk3318.patch` file that is updated also for the 5.15 kernel sources in the *22.08* packages. The latest git commit is "rk3318: use 666mhz ddrbin, reduce cpu and gpu voltages". It is unclear to me which part of it is playing badly with my board, whether the "use 666MHz" or the "reduce cpu voltage". I understand that both of them can lead to erratic behavior and code segfaulting (either because the CPU is operating incorrectly as its voltage is too low for the given frequency or because incorrect data is exchanged with the memory if the latter cannot work at 666MHz). My suspect is that the issue is with the reduced cpu voltage, since other users in this thread report instability and it looks like they "fixed" it by reducing the cpu frequency (that is finding a sweet spot wrt the voltage-frequency trade off at a lower voltage). Because reducing the CPU frequency is not all that desirable performance wise, I would like to ask about the reason for the cpu voltage reduction. Was the cpu incorrectly run out of specs wrt its voltage until 22.08 so that had to be fixed?

After more tests, what makes the difference is probably not the kernel (5.15 vs 5.18) but the dtb: with linux-dtb-current-rockchip64_22.08.0-trunk_arm64.deb and kernel linux-image-current-rockchip64_22.08.0-trunk_arm64.deb (5.15) the system does not boot, but with the same kernel and the former linux-dtb-current-rockchip64_22.05.0-trunk_arm64.deb the system works fine.

Another update. I have gone through the last two pages of the thread, and I think that what I was experiencing is quite similar to what other users @MX10.AC2N and @Willy Moto were experiencing: boot issues, gcc segfaulting. The notable difference is that I was experiencing them with a 5.15 kernel (the one from the 5.15 dir), not the 5.18 one, while I was using the `bsp` file from the upgrade directory. Now I have used multitool to downgrade everything to the 22.05 version and everything is back to normal, but I understand it is important to me to see if and how I can move forward in view of the mainstreaming of 3328 tv boxes. So I have started making some tests and the issue is definitely not `armbian-bsp-cli-rk3318-box_22.08.0-trunk_arm64.deb`. Installing that alone onto the bootable system keeps it bootable. Before I make more tests, I wonder about `idbloader.img`: if I install that, how do I revert that install?

I have killed my machine h96max+ with the latest update, looking for help to recover... - Looked for updated kernel, found it in usual place: https://users.armbian.com/jock/rk3318/upgrade/ - Noticed that stuff is marked as edge and that there is a directory `v5.15` with non edge stuff - Downloaded stuff from the `v5.15` directory that is stuff marked as current rather than edge as it seemed more conservative - Noticed the `bsp` file was not in the `v5.15` dir, got the one from the dir above as there is no *current* or *edge* mark on it (was this my mistake?) - Installed everything including the `linux-u-boot-current - used armbian-config to update the u-boot on the system System not booting anymore... What is the advice to try a recover? [UPDATE] I have probably succeeded in recovering the machine. However, what has happened is unclear to me. The kernel was oopsing and only by stopping the systemd boot I was able to get a prompt. From the latter trying to do anything was continuously resulting in applications segfaulting... Before I try again, @jockcan you please help clarify: - if the problem was in using a bsp file mismatched wrt the kernel I was using? - if I am expected to use the -edge or the -current kernel from 22.08?

Hi, I need some clarification about the kernel packages in https://users.armbian.com/jock/rk3318/upgrade/ I periodically update the kernel from there, but I have just noticed that the package names have changed. Now I have on my system both a set of packages marked as "edge" (the former ones) and a set of package marked as "current" (those right now on the link above, which deliver a more recent kernel). I would like to know: - if I should delete the edge packages - if having both installed may have lead to problems - if the current packages need to be put on hold just as it was for the edge ones or the name change is the index that official support has come - if the instructions on post #1 are still current (as they explicitly mention -edge packages). Thanks!

@jock Sorry for getting back to the thread with a lot of delay, my laptop broke down... So it should be possible to use your tree as a basis to patch the current mainline and compile it (provided that the patches still apply cleanly?) I'll look into the armbian documentation to see if this can be done in an automatized way when a new stable release for the kernel series comes out... Just in case there is a quick recipe, please let me have a pointer to it ;-)

@dam74The issue with rsyslogd is a symptom. On my system, I think I managed fixing the issue by setting also the SystemMaxFileSize option in systemd journald. Wonder if on a system with some good 32 or 64GB of resident storage having journal log meant to be permanent on zram is the right thing, though, given that journald already has volatile storage on /run.

Noticed that systemd journal fills up /var/log apparently ignoring the SystemMaxUse=20M using the bullseye image. Anyone else experiencing this? Is this an rk3318 bug and armbian bug or a debian bug?

Hi, after having successfully had my H96Max+ working for a few days now with a single major hiccup I would like to inquire about three items. The single issue that I encountered was a total freeze during intense activity on the SD card while copying files transferred through wifi. This copying is something that I could have done in a much quicker way but that I purposely did this way to stress the machine with a 2+ hours of continuous activity. However, because I had this single freeze, that did not happen again, it is difficult for me to say if this was due to some OS or hardware instability or maybe some external factor (e.g., a power fluctuation). It would be interesting to me to know if someone else experienced similar issues. I would like to know if RK3328 supports some form of hardware watchdog timer to be used with the watchdog daemon. I understand that once the machine is installed (thanks for the great work of jock and possibly others), maintaining the machine up to date and secure should be relatively easy, since most of the OS can be updated through the regular armbian repos. In my understanding the notable exceptions are the kernel packages at https://users.armbian.com/jock/rk3318/upgrade/ namely those that had to be put on hold wrt apt (linux-image-edge-rockchip64 linux-headers-edge-rockchip64 linux-dtb-edge-rockchip64). If I understand correctly, these can only get updated thanks to jock's effort because rk3318 is not part of armbian (yet). Having these packages depending on a single person best effort means on one hand that gratefulness to Jock is huge but on the other hand may also represent a potential issue. I thus wonder how difficult is it to re-build them by https://github.com/paolosabatino/armbian-build/tree/rk3318 and the armbian kernel tree, how much does the rk3318 diverge from the mainline kernel, how easily/frequently do the rk3318 patches break against newer mainline kernels and how difficult would it be to recover from a bad kernel (in case one tries to build and deploy a kernel for learning how to do it and something goes wrong). Thanks for any help!