OMV for ROCK64 (and other RK3328 devices soon)

  • Quote from tkaiser

    If you want to discard these messasges simply add a file below /etc/rsyslog.d/ (see in the already existing ones for example syntax)

    Thanks - that hides the problem at least!


    These messages look as if they are highlighting an incompatibility in the image.Is it true that rpi and armhf images should always run on the rock64 or is it more complicated that that?

  • I'm running OMV 3 (latest version) on the stable release (linux armhf jessie 0.5.15). It's all good and very stable.


    Anyhow, I do have a quite strange kernel error being logged when I change the name of a folder user SMB or AFP. The error in the syslog is


    kernel: Unhandled fault: alignment fault (0x92000021) at 0x00000000ab4930fe


    on my mac using SMB, I get an error dialog on my mac (finder) is reporting error -36 and the change folder name fails and the kernel error is logged to syslog

    on my mac using AFP, the change folder name is successful (no error in finder) but the kernel error is logged to syslog.


    Any ideas what could be causing this or how to troubleshoot?


    Thanks

  • @tkaiser - can you help me a little getting a RTC on i2c / GPIO working on my rock64?


    On a RPI you add the dts overlay commands to config.txt in /boot but I don't know how to do this on rock64 / OMV 4.


    The dt commands that I think are needed are below - just have no idea how/where to apply these settings during the kernel boot sequence on rock64.


    dtparam=i2c_arm=on
    dtoverlay=i2c-rtc,ds3231


    I checked with ayufan and he says that GPIO is configured and a RTC should just work but it doesn't.


    Any ideas?

  • On a RPI you add the dts overlay commands to config.txt in /boot

    Why do people refuse to understand that Rasperry Pi is no normal ARM SBC but proprietary crap?


    This config.txt thing is nothing related to Linux. It's read by the proprietary closed source primary OS (a RTOS called ThreadX) running on the primary CPU (VideoCore IV). There's ThreadX code that reads this stuff and then either directly manipulates the hardware (clockspeeds, turbo mode and so on) or in this case manipulates how a Linux kernel is later loaded. All of this happens not at the ARM cores (that are just guest processors on any RPi) at this stage but only on the VideoCore IV main CPU. So these RPi instructions to deal with this proprietary crap can't work on any real ARM SBC around.


    Wrt your RTC no idea, I never did anything GPIO related on any Rockchip board so far. Just questioning why you 'need' a RTC on a NAS anyway (that's always on and can use NTP)?

  • @ryecoaaron can you please upload OMV_4_Renegade.img.xz to https://sourceforge.net/projec…ngle%20Board%20Computers/?


    Libre Computer Renegade (also known as Firefly ROC-RK3328-CC) is a board similar to Rock64. Main differences: slightly faster memory (DDR4) and depending on where you live you might order it directly from Amazon or LoverPi.


    Performance as NAS with USB3/UAS storage just like any other RK3328 device with Gigabit Ethernet: awesome. Some more details: https://forum.armbian.com/topi…findComment&comment=57301

  • I purchased a 2GB renegade recently (had an amazon gift card). This is a very nice system. Using the latest OMV 4.x image, it is very stable. I have copied about 2 TB of data to it via samba and scp. Averaged in the mid 80s MB/s over samba (probably would've been faster without the VM middle man overhead) and about 45 MB/s via ssh/scp. Going to install docker on it for pi-hole for a trip I am taking. Should make a very nice portable server. Still wish they made this in odroid-hc2 format...

    omv 5.5.17-3 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.2
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • @ryecoaaron can you please also upload the new Armbian based image for Rock64: OMV_4_Rock64.img.xz


    Main differences to ayufan's releases:

    • Only available as arm64 variant (no armhf)
    • Uses compressed btrfs for the rootfs and also the usual OMV/Armbian partitioning scheme (one small ext4 with /boot on it and then a 7.3GB btrfs partition)
    • New armbian-zram-config and armbian-ramlog services installed (not active by default)


    In the meantime we implemented in Armbian keeping logs in RAM on a zram partition. But it's not active until the user does the following:

    Code
    systemctl stop zram-config
    apt purge zram-config
    reboot


    Only if the zram-config package is purged Armbian's new mechanism will take over. Will then look like this afterwards:



    This still needs some testing, is not available yet through normal Armbian repos and most probably it will be tweaked in the meantime. But once it's ready we should add to OMV's upgrade routine


    Code
    dpkg -s zram-config >/dev/null 2>&1 && (systemctl stop zram-config ; apt purge zram-config)


    This will then switch to the new method after the user in questions reboots the next time. But maybe adopting the whole logic for folder2ram and storing the the other stuff compressed in memory too is a better option.

  • can you please also upload the new Armbian based image for Rock64

    Uploading now.

    But once it's ready we should add to OMV's upgrade routine

    I will look at ways to fix this when I get back from vacation.

    omv 5.5.17-3 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.4.2
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • What is the difference between the two builds (ayufan v armbian) and will any new fixes/stuff from ayufan come across into the armbian setup?


    No important differences other than

    • Armbian will move to zram based swap while ayufan uses no swap at all (irrelevant for almost all OMV users)
    • Armbian defines the 1.4GHz cpufreq OPP by default while ayufan remains on 1.3 GHz for now (irrelevant for all OMV users)
    • Ayufan's images are better suited to boot from SPI NOR flash (this will take some time with Armbian). So with ayufan image you can even today burn u-boot to the onboard SPI NOR flash and then boot from a small partition on an USB drive (many people love this, I prefer good SD cards + flashmemory plugin + disabled monitoring --> I love my HDDs and let them sleep whenever possible)

    Armbian still relies on ayufan's kernel repo so once he changes stuff it will be in Armbian a bit later (though we use a slightly different kernel config due to trying to consolidate settings accross all +60 boards we support)


    In other words: choose any of them, it really doesn't matter for an average user which you choose. ayufan and me took care that everything you could find here in the forum (e.g. calling 'armbianmonitor -m' to monitor system health) will also work with his images.

  • Sorry If I have revived this old topic just would like to say that rc10 didn't work for me as well as for other users and I used rc9 armhf like the user from above, so hopefully, it will help for a future visitor of this post.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!