Arglebargle

Members
  • Content Count

    7
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Arglebargle reacted to tkaiser in RockPro64   
    For testing purposes I always just grab a bionic or stretch minimal image from ayufan, then look for latest mainline kernel available and install it:
    apt-cache search kernel | grep -- '-4\.1' apt install linux-image-4.18.0-rc5-1048-ayufan-g69e417fe38cf reboot Mainline kernel was a requirement to use PCIe in the past but according to release notes that might have changed recently (by disabling SDIO). So you might want to test with both 4.4 and mainline...
     
    Edit: Don't forget to always check /proc/interrupts for the PCIe related IRQs and assign them to one of the big cores.
  2. Like
    Arglebargle got a reaction from tkaiser in RockPro64   
    Thanks! Pcie seems to be working fine on the most recent 4.4 kernel, the Intel nic I tested linked at 5GT 4x without issue.
     
    root@rockpro64:~# uname -a Linux rockpro64 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux  
    LnkSta: Speed 5GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-  
  3. Like
    Arglebargle reacted to Jason Fisher in Build ZFS on RK3328   
    After fighting with this with a few distros..  I am close here:
     
    1. First, go to your linux-headers directory (e.g. /usr/src/linux-headers-4.4.129-rk3328/) and:
     
    make scripts
     
    If that fails (classmap.h missing for example), there is a problem with the headers package.  You may need to manually edit scripts/Makefile and comment out the line with selinux -- there is a problem with the kernel config not matching the header deb in my case.
     
    # subdir-$(CONFIGS_SECURITY_SELINUX) += selinux
     
    2. From the same headers directory, verify that include/generated/utsrelease.h matches the full kernal name from: uname -a
     
    - My headers (from beta repo) had 4.4.129 as utsrelease.h and 4.4.129-rk3328 as the kernel version/release.  This causes modules to be built incorrectly and their vermagic to not match--you can use modprobe --force to get around this, but ill-advised to use that for more than a quick test with something like zfs.  My utsrelease.h now reads: 4.4.129-rk3328
     
    3. Edit /var/lib/dkms/spl/<yourversion>/source/configure and search for KUID, for lines that look like this:
     
    kuid_t userid = KUIDGT_INIT(0);
    kgid_t groupid = KGIDT_INIT(0);
     
    Erase those two lines, the test itself is broken on our environments.  Leave the lines surrounding it.  These appear twice in the configure script--remove both sets.   
     
    Now look for these lines:
     
    kuid_t userid = 0;
    kgid_t groupid = 0;
     
    Change them to:
     
    kuid_t userid;
    kgid_t groupid;
     
    (I filed a bug here https://github.com/zfsonlinux/spl/issues/653#issuecomment-333973785 )
     
    Now you can run:
     
    dkms build spl/<yourversion>
    dkms install --force spl/<yourversion>
    modprobe spl
    # should be no errors here, check dmesg otherwise
     
    dkms build zfs/<yourversion>
    dkms install --force zfs/<yourversion>
     
    When configure runs, you should now see:
    checking whether kuid_t/kgid_t is available... yes; mandatory
     
    Some notes:
     
    - I ended up switching to beta (sources.d) and doing an update/upgrade/dist-upgrade first because there were no kernel headers for the WIP rock64 image I installed.
     
    - If you use kernel 4.11.x you will need to use SPL/ZFS 0.7.x.  I am using the standard zfs-dkms/spl-dkms 0.6.5.9 packages for now..  install SPL and let it fail, then dkms install it after the steps above and then install the ZFS package.
     
    Just started with Armbian today .. in retrospect it looks like it has drawn me in..