• Posts

  • Joined

  • Last visited

callegar's Achievements

  1. Hi, I need some clarification about the kernel packages in 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!
  2. @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 ;-)
  3. @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.
  4. 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?
  5. 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 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 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!
  6. Noticed that package armbian-bsp-cli-rk3318-box installs stuff to /usr/local/bin. I wonder if this is fully appropriate. According to debian guidelines, /usr/local should be left as a playground for the local administrator, so packages should not do things there. This is in the debian policy sect 9.1.2 "packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts" and "/usr/local and its contents are for exclusive use of the local administrator, a package must not rely on the presence or absence of files or directories in /usr/local for normal operation". I understand that this may be because rk3318 is not yet fully official in armbian, but being likely that rk3318-config does not name-conflict with anything else, I wonder if it could be possible to update armbian-bsp-cli-rk3318-box to install rk3318-config in /usr/bin or /usr/sbin rather than /usr/local/bin. Thanks for considering this!
  7. @Jock Regarding your reply on my H96Max+ RK3328 installation of Armbian Thanks for taking the time of a detailed response! > The behavior can be easily changed setting the appropriate trigger in /sys/class/leds/working/trigger file (see google for that, "working" is the name of the led). Thanks for this hint, I have now selected "generic" for the led config and trying this > Useful also are photos of the board to identify the signature and chips. I'll try to get the dtb out of the dumped firmware. The photos shall be more difficult, because the case has no screws and I'm a bit scared of breaking it trying to force it open. > I would like to merge soon, but it depends upon the compatibility reports that are posted here. Is there anyway to post an *enthusiastic* report? :-) Thanks again
  8. H96Max+ here. Just installed following your instructions. Works amazingly well and was amazingly easy, particularly after having read around on other forums that for RK3328 there is no HDMI support and that I should have opened the box to get to the serial pins! Thank you all for this great work! I am going to use the device as a micro server, so I am not testing any graphical desktop. Quite happy to see that USB3, WIFI, Ethernet, all appear to work out of the box. Have just a few questions to which someone having the same box may be able to answer: 1. What is the appropriate answers for the EMMC configuration in rk3318-config? 2. What is the appropriate configuration for the LED? I am puzzled by the fact that the led functionality seems to be better in the multitool than in the OS itself. In multitool the red led stays on and the blue one appears to flash to indicate activity. In the OS, the red led stays on all the time and the blue one stays off all the time. The "conf3" seems to hang the machine at boot. Furthermore, I have a question about the kernel packages. - As instructed, I have put on hold the upgrade of kernel, kernel headers and dtb packages from apt. Is it expected that the official armbian kernel will include rk3318 and rk3328 support in the future? This seems important to me in terms of future maintainability of the box. During the installation, I have dumped my firmware using multitool (an Android 8.something, if I remember properly). Would it be useful if I tried to extract the dtb from it, or is the dtb of the stock H96Max+ already well known to you? A very minor suggestion from someone getting onto this great forum for the first time (hence something that could either be totally useless for naivety or maybe useful as representative of an initial impression, you judge). Threads regarding multiple boxes sharing the same fundamental hardware, such as this one may easily become very large and it is hard and trying to go through them it is sometimes hard to understand if something is general or if it refers to a specific box and if so which one. Being able to tag the messages with the specific piece of hardware they are about would ease reading immensely.