Jump to content
XPEnology Community

D_G_B

Rookie
  • Posts

    9
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by D_G_B

  1. Note that, to have a working local display, you must have an Intel CPU that has an integrated i915 compatible display controller(ie: UHD610, etc)... This means anything that is 4th Gen (Haswell) or newer. The built in drivers support up to 9th Gen, and backported drivers support 10th and possibly 11th Gen CPUs... 12th Gen CPUs do not have a compatible display controller. AMD APUs are not compatible. see this post:
  2. Yes, satamap is not used for DVA1622... But the DeviceTree is built when the loader is built... Reboot your machine into "configure loader"... run .menu.sh, rebuild the loader and then boot the loader. This will rebuild your DeviceTree file and allow your additional drive to be visible to DSM... You are experiencing this because, unless your BIOS supports hotswap and it is enabled for all SATA ports, the DeviceTree builder will only see SATA ports that have a drive connected. If your motherboard supports hotswap and it is enabled when you build the loader, you will then not need to rebuild the loader when you add a drive.
  3. You are running on an AMD motherboard with an AMD CPU. This combination is not compatible with the broadwellnk platform that you are trying to use. What you will want to do is go to your BIOS and make sure that the SATA controller is set to AHCI mode and hotswap is enabled if available (otherwise, make sure you had HDs connected to all usable SATA ports). Then build a loader for the V1000 platform, which is for the AMD systems. The broadwellnk platforms use SataMap and DiskIdxMap... The AMD platforms use DeviceTree... Be aware, the integrated GeForce 7025 graphics controller will NOT be usable.
  4. Unfortunately, the DVA3221 drivers do not work. They will not work due to missing components in the linux kernel. Checking other forum threads, this seems to be a known and ongoing issue.
  5. No. The DVA3221 pat does NOT include the i915 drivers. The DVA1622 pat has the i915 drivers and does not include the nVidia drivers. The DVA3221 pat has the nVidia drivers and does NOT include the i915 drivers. @blackmanga has compiled the i915 drivers for the 10gen cpus (and should work for older), and i'm testing it on a DVA3221 install right now. I'll let you know how it goes....
  6. Just to add to my previous post... I checked out the repost of the drivers by @blackmanga a few days ago... The ds920 files now have stripped versions available. My previous method of updating the modules archive with dummy files was due to the unstripped drivers being too large to be embedded into the loader. With the stripped drivers now available, they can be embedded into the modules archive. To add the real drivers into the modules archive, do the following 1) before you boot your machine into ARPL, prepare a FAT formatted USB stick with the drivers: a) Download the i915_920_7.0_stripped.7z from the link posted by @blackmanga is post #109 of this thread b) extract the files to the root of a FAT formatted USB stick c) eject the USB stick 2) On the machine you have booted with your ARPL USB stick, change directory to the modules directory: cd /mnt/p3/modules 3) extract the modules from the geminilake archive: mkdir tmp;gunzip geminilake-4.4.180.tgz|tar -C ./tmp -xf - 4) copy the drivers onto the ARPL machine a) Insert the FAT formatted USB stick with the drivers b) determine the device identifier for the USB stick FAT partition: dmesg|grep -e ' sd';tail -n1 The line of output will contain the identifier for the usb stick - IE: "[ 2679.003829] sdc: sdc1" would mean the device identifier is sdc1 c) mount the USB stick FAT partition: mkdir /mnt/drivers; mount /dev/sdc1 /mnt/drivers note: replace "sdc1" with the identifier you determined in step b d) copy the drivers onto the ARPL USB stick cd ./tmp; cp /mnt/drivers/*.ko . 5) create the new modules archive and replace the original archive: tar -cf ../drivers.tar *; cd ..; gzip drivers.tar; rm geminilake-4.4.180.tgz; mv drivers.tar.gz geminilake-4.4.180.tgz 7) clean up and return to the ARPL directory: rm -rf ./tmp/; umount /dev/sdc1; rm -rf /mnt/drivers; cd /opt/arpl/ Note: replace "sdc1" with the identifier you determined in step 4)b Then complete the build steps is the previous post. Note: remove the drivers USB stick before booting your updated loader After the loader is updated, it is possible (with an edit to the /opt/arpl/model-configs/DVA1622+.yml file to remove the blanked out update server addresses) to install DSM completely from the xpenology machine... The first boot of the loader will take several minutes, then display a message to 'plug in a keyboard on DVA1622 and press "Enter" to install surveillance station'... Press enter... It will then say "the local installation will take about 6 minutes. Do not shut down your device"... It is not accurate... It will may take more or less than 6 minutes... let it do it's thing and eventually the screen will go blank for a bit and the machine will reboot... the reboot will bring up the DVA1622 splash screen for several minutes and then display the local installation screen... It will take much longer than 6 minutes... leave it be and let it complete the installation... Eventually, the "Welcome to DSM 7.1" screen will appear, and you can complete the DSM installation. It will ask for the device name, username and password, then load the local DSM Surveillance Station desktop. To edit the configuration file to allow for standalone installation: 1) Exit the ARPL menu 2) Edit the model configuration file: nano /opt/arpl/model-config/DVA1622+.yml 3) delete all lines (Ctrl+k) in the [synoinfo] section EXCEPT the line that starts with "buzzeroffen" 4) Save the file using (CTRL+x). Press "y" when asked if you want to save the buffer. 5) run ./menu.sh 6) rebuild the loader
  7. Just for information purposes: The DVA1622 DMS pat file includes the original i915 driver files. They will work for 2nd Gen to 9th gen Intel CPUs, but not for 10th gen CPUs. So, the situation I ran into is: Baremetal, Asus H410m motherboard, Pentium Gold G6400 (Comet Lake) CPU, DVA1622-7.1.0-42661u3, ARPL loader. 1) When the system boots, the original i915 driver files load, but do not get activated because the IGPU is not compatible. 2) Since the DVA1622 uses a geminilake CPU and the DS920+ is also a geminilake platform, I try the patched files for the DS920+. Of course, because the original drivers are loaded, the new drivers fail to load. 3) run the rm_modules.sh script. Original driver files are unloaded. 4) run the in_modules.sh script. Patched modules are loaded. The screen spring to life and loads the local display software and eventually (a minutes or so later) presents a login screen on the local display. So far, so good... Here is where the issue show up... 5) copy the required driver files to the /usr/lib/module directory. (The firmware files are already installed ad part of the DVA1622 install) 6) reboot the machine. Machine reboots and loads DSM, but the screen does not change from the ARPL boot screen. 7) SSH into the machine to discover that the original i915 drivers are loaded and inactive. It turns out that, although the patched drivers are installed, they are not used. The boot process loads the original drivers that are embedded in the initial ramdisk in the loader rather than the drivers installed on the DSM on the HD. The Solution... remove the original driver files from the loaders ramdisk: 1) boot ARPL using the "configure loader" option. Run the menu.sh script and go to the update menu 2) If you are running ARPL less that 0.3-alpha3, update arpl. (if you need to reboot, do so and restart) 2) update MODULES then exit the menu back to the shell prompt 3) add dummy drivers to the modules archive. (details given below) 4) run menu.sh 5) Build the loader 6) Boot the loader. As the driver files that are embedded in the loader are now empty files, the loader is not able to load the original drivers, and the boot process will load the drivers installed on the HD when udev or eudev starts. The machine will now load and use the patched drivers, and will operate like a real DVA1622. To add the dummy drivers into the modules archive, do the following 1) change directory to the modules directory: cd /mnt/p3/modules 2) extract the modules from the geminilake archive: mkdir tmp;gunzip geminilake-4.4.180.tgz|tar -C ./tmp -xf - 3) create the empty driver files: cd ./tmp; touch backlight.ko; touch drm.ko; touch drm_kms_helper.ko; touch fb.ko; touch i2c-algo-bit.ko; touch i915.ko; touch iosf_mbi.ko; touch video.ko 6) create the new modules archive and replace the original archive: tar -cf ../drivers.tar *; cd ..; gzip drivers.tar; rm geminilake-4.4.180.tgz; mv drivers.tar.gz geminilake-4.4.180.tgz 7) clean up and return to the ARPL directory: rm -rf ./tmp/; cd /opt/arpl/ One final thing to mention... When I first created the loader, I used the default LKM (dev)... After the first boot (when all the packages have been downloaded and installed and the DSM image on the HD is stable)... The boot process is excruciatingly slow.... The H410M/G6400 combo in my machine took 289 seconds (almost 5 minutes)... The development LKM does a LOT of logging... an OBSCENE amount of logging, and that significantly affects performance. SO... Once you have set up your machine and are sure that it works... rebuild the loader with the production LKM... It does more modest logging and is significantly fasted... My machine now takes 96 seconds to boot... BTW... Big thanks to @pocopico and @fbelavenuto for all the work on the loaders and @blackmanga for providing the patched driver
  8. I did not realize that. My apologies.
  9. The DVA1622 image does not use satamap... It uses DeviceTree... You may need to make a custom DeviceTree file for your laptop. You might want to try ARPL as it will build the file for you (Sorry @pocopico - your loader is still awesome!) Also, DMS has issues with M.2 SSDs that share a port with the SATA controller on the motherboard. You may need to either disable the M.2 in bios (f possible) or remove the SSD to get DMS to run. The DVA1622 DMS image has drives for an Nvidia GTX 1650 graphics card. The Geforce 940 in your system may be causing a kernel panic and the reboot. You should be able to disable the Nvidia card in bios to eliminate that possibility (DMS can't use it anyway).
×
×
  • Create New...