Leaderboard

Popular Content

Showing content with the highest reputation since 12/07/2020 in all areas

  1. The RedPill is back! As some of you may be aware a lot of research materials as well as the code for parts of the kernel module were pulled from GH. We're happy to report it's back and fully public! Before further ado we have a small sneak-peek of the current state: Repositories Both LKM code and the research materials are present in two repositories. Both are automatic forks from our internal serves and are updated few times a day. - RedPill LKM: contains the current version of the Linux kernel module source code along with implementation details description - D
    104 points
  2. Update time! This week the updates are going to be less exciting but nonetheless very important, and the first point talks about that in more details. THE BUILD HAS CHANGED - READ ME We're putting this as the first and in red so people see it. The LKM build now requires a version to be specified. We know this will break the @haydibe toolchain but we're sure he will fix it quickly as this is a small change. For reasons why read further. Also, if you used a hack to "fix" the Info Center on 3515xs make sure to read "Hardware monitoring emulation" section carefully.
    24 points
  3. Did anyone said drivers? You said you wanted drivers - we are delivering on the promise to find a way to get them to you. Today's release brings, what we believe is, a huge update to the RedPill as a project, and we hope to the community and the ecosystem around it as a whole. TL;DR We're introducing a decentralized extension manager into the RedPill project which is able to automate drivers installation. If you're a user, and we didn't screw up badly, just update to the newest release and nothing should change just yet. Soon you can expect your custom drivers to
    23 points
  4. Update time! Support for v4.4 kernel TL;DR: it now works with v4.4 After some of you took a stab at compiling the LKM for Linux v4.4 (presumably for DS918+ support) we did too. We didn't see any PRs besides a small patch from @jumkey (thanks!). However, the reality came to be much MUCH more complex, especially if we want to keep the consistent codebase for all kernels. So, it took 400 lines over 12 commits by 3 people: https://github.com/RedPill-TTG/redpill-lkm/compare/7f85cb2ceff44d6914135bf3841eb3cb2148af11...1abcbe13df39055dc8b925f74a00a75163157d60 However,
    20 points
  5. Let us first pull you from the dark - we just added a new repo to the collection. "We think you're gonna love it"[tm] RedPill Load Without further ado: RedPill Loader Builder Repo is live - https://github.com/RedPill-TTG/redpill-load It's a loader image generator which we worked on for quite some time. From the start we have to apologize for using BASH - it was a mistake and if you look into the code you will understand why What it can do for you? However, it works. In short, it automates the following process in "normal" mode: Checks if the
    19 points
  6. @ThorGroup thank you for the update! And indeed, I spoted and incorporated the new make targets into the new toolchain builder version Taken from the README.md: Supports the make target to specify the redpill.ko build configuration. Set <platform version>.redpill_lkm_make_target to `dev-v6`, `dev-v7`, `test-v6`, `test-v7`, `prod-v6` or `prod-v7`. Make sure to use the -v6 ones on DSM6 build and -v7 on DSM7 build. By default the targets `dev-v6` and `dev-v7` are used. I snatched following details from the redpill-lkm Makefile: - dev: all symbols
    18 points
  7. This update of the redpill_tool_chain helper is long overdue. From now on the name will be redpill-helper, as it realy is just a helper for redpill-lkm and redpill-load. You can find the redpill-helper v0.12 attached to this post. It now supports an "ext" action, which delegates the commands to the ext-manager.sh script inside a container. The extensions are cached on the host, thus extensions need to be added only once and will apply for all build profiles! This should put an end to the need to modify the script or to use the run action and add the extensions every
    17 points
  8. New release update! This is the biggest release to date and ESXi users will be especially happy to see it! SATA boot support for 918+ (and others) Remember how we said it's nearly impossible to add SATA boot support for 918+ as the kernel physically lacks the code to support SATA DOM on that platform? Well, we've said NEARLY impossible as we had an idea but didn't want to disappoint anyone if it failed. It didn't. With this release we're introducing a SATA boot support for platforms which natively lack the support for it. This is mainly aimed towards hyperv
    15 points
  9. It has been over a week but we're not slowing down! PMU emulation is here This was the biggest feature we were working on, which involved fixing many things around to actually make it stable. The current implementation keeps all the data internally. None of the requests sent by the actual OS needed to be responded to directly, as we shimmed mfgBIOS. However, the interface allows for a very easy plug-in of any hardware-based emulation of the PMU to emulate LEDs etc. The important part here this was one of the bigger roadblocks to make the implementation stable and actually know what
    15 points
  10. Status Update! Recently we were working hard in the kernel space to bring even more missing things and bring it into a more stable state. That meant we had little time to respond but we're blown away by the number of posts here! mfgBIOS shimming stability As we discussed here before there were moments where some BIOS functions weren't shimmed or there were flaky. This caused the OS to sometimes work correctly but sometimes fail the 24h test. Guess how easy was that to debug and fix However, we did it and now the mfgBIOS shimming should be almost bulletproof! RTC emul
    15 points
  11. Hello! TL;DR: We've developed a new loader for v6.2.4/v7+ which contains a way to install custom extensions/drivers/mods. We're looking for feedback of the extension manager & kindly asking for drivers to be made compatible with it. First of all, let us thank you guys for all the driver packages you were always preparing - we used them ourselves. As some of you may be aware we are developing a new loader called RedPill. There's a long thread in the developer's section of the forum: Today we've added a long-awaited functionality of custom drivers. We've chos
    14 points
  12. Update the toolchain builder to 0.6.0 # Inofficial redpill toolchain image builder - Creates a OCI Container (~= Docker) image based tool chain. - Takes care of downloading (and caching) the required sources to compile redpill.ko and the required os packages that the build process depends on. - Caches .pat downloads inside the container on the host. - Configuration is done in the JSON file `global_config.json`; custom <platform_version> entries can be added underneath the `building_configs` block. Make sure the id is unique per block! - Support a `user_config
    14 points
  13. Everytime when I think, there is nothing left to optimize on the toolchain builder someone commes around and finds something that makes sense to be added... Thus said, here is the v0.9 of the toolchain builder. - added sha256 cheksum for kernel and toolkit-dev downloads in `global_config.json`. The item `"download_urls"` is renamed to `"downloads"` and has a new structure. Make sure to allign your custom <platform version> configurations to the new structure when copying them into the `global_config.json` - check checksum of kernel or toolkit-dev when building the image a
    13 points
  14. Rest of the answers starting from beginning of page 84 and ending on page 86. ======================================================================== We will love to be wrong here but to our knowledge 918+ kernel does not have SAS functionality. These symbols are present in the kernel code but guarded by "ifdef MY_ABC_HERE" which presumably depends on the model/SAS support option. Eh... it is possible to emulate that. We know how technically. We can provide these symbols virtually in RP but it will require some digging to check what they should return. Since we
    12 points
  15. Seems I missed to test the bromolow-7.0.1 image... So this is the one that caused this mystery behavior. I disabled the build cache now by default - it can be turned on again in global_settings.json. Now "clean all" deletes all images, including the last build one. changes in v0.7.3 : - fixed usage of label that determins the redpill-tool-chain images for clean up - add `"docker.use_build_cache": "false"` to global_settings.json - add `"docker.clean_images": "all"` to global_settings.json (set to orphaned to cleanup everything except the latest build)
    12 points
  16. Continuation of questions starting from mid-page 37 (forum doesn't allow for more than 50 quotes per post): You cannot change that - that will require rebuilding of the kernel which isn't possible (as syno doesn't share compilable sources of the kernel). You theoretically can use mknod but this causes problems with v7 (synoboot used to be done this way on 918+). Stay tuned: we will figure this out Yeah, Linux and md doesn't care - only the DSM has some hardcoded assumptions for paths which we need to emulate
    12 points
  17. Hello, With @haydibe help and validation, here is the redpill_tool_chain v0.11 redpill-tool-chain_x86_64_v0.11.zip New feature : - Supports to bind a local redpill-lkm folder into the container (set `"docker.local_rp_lkm_use": "true"` and set `"docker.local_rp_lkm_path": "path/to/rp-lkm"`) Thanks @haydibe Tested with 6.2.4 and 7.0 both bromolow I can't test for DS918+ as I don't have the CPU for. But it should be OK
    11 points
  18. NOTE: This problem is consistently manifested when running as a virtual machine, but many have encountered problems with Synoboot devices on baremetal installs of 6.2.3 and under certain conditions, other 6.2.x versions. The fix can be implemented safely on baremetal installs. You can verify if you have the issue by launching SSH and issuing the following command: $ ls /dev/synoboot* /dev/synoboot /dev/synoboot1 /dev/synoboot2 If these files are not present, your Synoboot devices are not being configured correctly, and you should install the fix script. If synoboot3 exists that is ok
    11 points
  19. Thanks @ThorGroup for RedPill, and @haydibe for simple way to create image for bootloader with Docker. A little instruction how to use last version toolchain in macOS Big Sur 11.5.2 : 1. Install Xcode, Xcode command line tools, and Docker on Mac. Run Docker. Download last version toolchain, moved to Desktop and unzip. 2. Install HomeBrew in Terminal /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" 3. Instal jq and coreutils in Terminal brew install jq brew install coreutils 4. c
    11 points
  20. Update So a small update first: we've got the PCI emulation layer working! The PCI standard is truly an awful thing, which kernel developers found out too and put a fair warning on the top of their PCI docs: The world of PCI is vast and full of (mostly unpleasant) surprises. Since each CPU architecture implements different chip-sets and PCI devices have different requirements (erm, "features"), the result is the PCI support in the Linux kernel is not as trivial as one would wish. Linux doesn't have any high level APIs to add devices or buses. Because of this we h
    11 points
  21. So I leave 3 days on holidays and everyone forgets the rules... They are rather simple and stated just above the first post. All Off-Topic posts have been moved.
    11 points
  22. Hello! I am xpenology user. And I am an IT engineer who creates shell scripts as hobbies. Please understand that it is written by a google translate site. because i’m korean who is not fluent in English. I created a tool to change cpu information for Xpenology’s users. Modify the actual cpu name and cores of your pc or server. Howto Run ============================================================= 1. Download attached file on your PC (ch_cpuinfo.tar) (ch_cpuinfo_en.tar) / (ch_cpuinfo_kr.tar is file for korean) 2. Upl
    10 points
  23. Установка и настройка DSM на основе версии 6.2.3 Ну вот, муки поиска позади и вы пришли к эпохальному решению создать сервер на основе Хрени.....)))) Надеюсь, что подошли к этому шагу с долей познаний и оценили свои возможности. Данный мануал является общим, без акцента на частные настройки и особенности применяемого вами железа, такие как настройки БИОС_а и хардово-софтовые нюансы вашего железа. Процедура описана на основе последней возможной (на данный момент) для установки версии DSM. Но она применима и на ранние версии DSM 6 . Более древние уже не помню )))
    10 points
  24. We've got more progress notes. As with every update we have something big today too Revamped loading schema This seems like an implementation detail which isn't important at all. However, this change is a milestone in making the kernel module stable and robust. Previously we went with a naive (but working!) method of simply throwing "insmod rp.ko" into the first bash file loaded after the kernel passes control to the user space. Well, it does work but it has many problems, which aren't obvious at first: module loading is asynchronous (some things may overstep action
    10 points
  25. I incorparated the latest changes in the redpill universe into the toolchain builder: For 6.2.4 builds: the kernel sources are configured to be used by default. For 7.0 builds: the Toolkit Dev sources are configured to be used by default. # Inofficial redpill tool chain image builder - Creates a OCI Container (~= Docker) image based toolchain - Takes care of downloading (and caching) the required sources to compile redpill.ko and the required os packages that the build process depends on. - Caches .pat downloads inside the container on the host.
    10 points
  26. I have made some tests. - Get a Backup of my 2 Drives from DSM 6.2.3-25426 junLoader Machine. - Make a redpill loader for 6.2.4 and create a new machine (proxmox) - attach the backup hdds to the new machine and startup - It comes the assistant and i update to 6.2.4 - WORKS - After that i build the redpill loader for DSM7 and replaced the 6.2.4 in the new machine and startup - it will hang forever at "------------bootup-smallupdate" - So i patched out this part from linuxrc.syno.impl and startup again - Now it works an the DSM7 Migratio
    10 points
  27. I'm very, very close to starting to write up some detailed howtos and FAQs on this, but a few things are holding me back: - documentation is an arduous task, it needs to be kept up to date and that is time consuming. I'd need help - the current state of this project (still not officially a beta) is such that it could change significantly at any time and render that effort pointless (this is based on what TTG have said about the intended future of the project: GUIs, bootable images to discover drivers reqs, etc.) - TTG deliberately didn't provide step-by-step guides at this stage
    9 points
  28. When setting up an XPEnology system, you must first select a DSM platform and version. XPEnology supports a few specific DSM platforms that enable certain hardware and software features. All support a minimum of 4 CPU cores, 64GB of RAM, 10Gbe network cards and 12-disk arrays. When you choose a platform and the desired DSM software version, you must download the correct corresponding loader. That may not be the "newest" loader available. Each of these combinations can be run "baremetal" as a stand-alone operating system OR as a virtual machine within a hypervisor (VMWare ESXi is mo
    9 points
  29. Really ? Are you **** serious ? Could you please respect devs work ? could you at least read OPs posts ? you won't be spoon feed... we are not even in beta stage yet... [Removed unnecessary foul comment and edited post.]
    9 points
  30. Today we will break the tradition a bit and respond to all questions first. Since the forum has a limit of 50 quoted posts we have to split our response into multiple posts The last post will be with the actual code updates so if you're reading it and not seeing a post with updates - just wait - we're writing as you're reading this. ------------------------------------------ It's fixed in the today's relese [will be up on GH after the update post] The difference between synoinfo and cmdline is subtle but important. The synoinfo defines the pro
    9 points
  31. ... and the toolchain builder is updated to v0.5.2. Highlights: ´auto` action and the deactivated Docker build cache # Inofficial redpill toolchain image builder - Creates a OCI Container (~= Docker) image based tool chain. - Takes care of downloading (and caching) the required sources to compile redpill.ko and the required os packages that the build process depends on. - Caches .pat downloads inside the container on the host. - Configuration is done in the JSON file `global_config.json`; custom <platform_version> entries can be added underneath th
    9 points
  32. what do you prefer? crystal ball, tea leaves or throwing bones?
    9 points
  33. Hi all:) After a little bit of reverse engineering I was able to bypass the license checking mechanism introduced in DSM 6 successfully with a simple two line binary patch of synocodectool and therefore enable transcoding without a valid serial number[emoji4]. I wrote a little script to make it easier for everyone. For more information please check the github repo: https://github.com/likeadoc/synocodectool-patch HOWTO: 1. wget https://raw.githubusercontent.com/likeadoc/synocodectool-patch/master/patch.sh 2. chmod +x patch.sh 3. ./patch.
    8 points
  34. A quick update (we will write more tomorrow): the native mpt2sas driver works but it's present only on 3615xs platform. To activate it and make it working properly without any hacks just add this small extension: https://github.com/RedPill-TTG/redpill-sas-activator We also updated the kernel module to rewrite SAS => SATA ports so it should work with any off-the-shelf mpt2sas or mpt3sas driver.
    8 points
  35. A few compiled modules for DS918+ (4.4.180+). Most network drivers have been tested and work https://github.com/pocopico/4.4.180plus-modules
    8 points
  36. Thanks for your answer, it`s my fault..should have looked in the damn README.md. For those who run 7.0.1-RC, here is what you need to add to global_config.json: { "id": "apollolake-7.0.1-42214", "platform_version": "apollolake-7.0.1-42214", "user_config_json": "apollolake_user_config.json", "docker_base_image": "debian:10-slim", "compile_with": "toolkit_dev", "redpill_lkm_make_target": "prod-v7", "downloads": { "kernel": { "url": "https://source
    8 points
  37. .. and another update of the tool chain loader with fixed repo details for redpill-load and apollolake-7.0-41890 # Inofficial redpill toolchain image builder - Creates a OCI Container (~= Docker) image based tool chain. - Takes care of downloading (and caching) the required sources to compile redpill.ko and the required os packages that the build process depends on. - Caches .pat downloads inside the container on the host. - Configuration is done in the JSON file `global_config.json`; custom <platform_version> entries can be added underneath the `building_
    8 points
  38. Not an errors. Just Status notifiers/Commands goes to the PIC16F1829 According to: #define UART2_CMD_BUTTON_POWER 0x30 /* '0' */ #define UART2_CMD_SHUTDOWN 0x31 /* '1' */ #define UART2_CMD_BUZZER_SHORT 0x32 /* '2' */ #define UART2_CMD_BUZZER_LONG 0x33 /* '3' */ #define UART2_CMD_LED_POWER_ON 0x34 /* '4' */ #define UART2_CMD_LED_POWER_BLINK 0x35 /* '5' */ #define UART2_CMD_LED_POWER_OFF 0x36 /* '6' */ #define UART2_CMD_LED_HD_OFF 0x37 /* '7' */ #define UART2_CMD_LED_HD_GS
    8 points
  39. lot of links in the forum to dsm versions and udpates might not work from now on synology replaced the old system and also change the structure slightly old https://archive.synology.com/download/DSM/release/ new https://archive.synology.com/download/Os/DSM also the updates are now in the same area as the realeases
    8 points
  40. Hi, everyone, Thanks for you patience. A new ds918 loader support 6.2/6.21 is uploaded. whats new: uefi issue fixed. i915 driver updated. link https://mega.nz/#F!Fgk01YoT!7fN9Uxe4lpzZWPLXPMONMA (for DS918+) - v1.04b ---Beginning of addition by polanskiman--- link https://mega.nz/#!OV4gVKyZ!dCgfXx1bgAOyvbFwFiov3s7RSNoFuqnAcNmSllLoUiw (for DS3615xs) - v1.03b link https://mega.nz/#!zcogjaDT!qIEazI49daggE2odvSwazn3VqBc_wv0zAvab6m6kHbA (for DS3617xs) - v1.03b Please read this topic to know what loader to chose
    7 points
  41. After upgraded to DSM 6.2.2 and moments 1.3.2, the face recognition is empty , and concept category only has child. I found thus shoud be a bug of photo detection plugin. So, there is the way to fix it: 1. enable SSH, and disable Moments. 2. replace /var/packages/SynologyMoments/target/usr/lib/libsynophoto-plugin-detection.so with my attachment. 3. enable Moments. (maybe need to reindex.) everything is fine. Enjoy~ libsynophoto-plugin-detection.so
    7 points
  42. This post contains answers up to page 67. ====================================================== You should use extensions now and NOT modify any files manually. Please, do not modify the grub.cfg file. This isn't a supported method with RP and should not be used. You should add that option as an extra_cmdline in user_conf instead. That is... strange. We're adding it to our internal list as the disk test shouldn't randomly crash the pool This usually happens [on VMWare] when you use USB-boot and not SATA boot. VMWa
    7 points
  43. For test DS315xs with VMWare I add to global_config.json this lines: { "id": "bromolow-7.0.1-42214", "platform_version": "bromolow-7.0.1-42214", "user_config_json": "bromolow_user_config.json", "docker_base_image": "debian:8-slim", "compile_with": "toolkit_dev", "redpill_lkm_make_target": "prod-v7", "downloads": { "kernel": { "url": "https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/25426branch/bromolow-source/linux-4.4.x.txz/download",
    7 points
  44. Updated the toolchain image builder to 0.7 Changes: - Added DSM7.0.1 support (done in 0.6.2) - Added `clean` action that either deletes old images for a specific platform version or for all, if `all` is used instead. - Added the label `redpill-tool-chain` to the Dockerfile, it will be embedded in new created images and allows the clean action to filter for those images. The clean action will only work for images build from 0.7 on. It will not clean up images created by previous versions of the script. Use something like `docker image ls --filter dang
    7 points
  45. Compiled 7.0.1 with last BSP patch and works perfect https://drive.google.com/file/d/1CqqhO-TBdwOff0dH54iP-XPdrhzgvtNR/view?usp=sharing - Add UEFI support. - Deleted twice EFI folder. - Fixed SynoBoot_EFI place. - Compiled with last BSP Patch for 7.0.1. - Insmod efi_gop into EFI. - Tested with Baremetal and works fine (Astock 3455-ITX). - After installation (the reboot process can take 15-20 minutes) you have to install File Station manually: https://www.synology.com/en-us/support/download/DS918+#system (select DSM 7.0), find and download File Station SPK a
    7 points
  46. Here are bsp files for 7.0.1 for everyone who has problems with manual patching the vmlinux 7.0.1-42214.zip
    7 points
  47. For all of you that want a "redpill tool chain". Well, I created a make based project that creates a docker image with the toolchain for brolow or apollolake make targets `build_image_bromolow` and `build_image_apollolake`: - download matching toolchain and kernel version on the host before building the image - base image ubuntu:18.04 - sources of redpill-lkm fetched while building the image - sources of redpill-load fetched while building the image - A Makefile is added inside the image, that allows to generate the user_data.json based on container en
    7 points
  48. That's a lot of posts! You're quick and eager to test guys We're trying to sort out through the posts and it actually gets hard even at this stage to decipher bugs from questions while keeping each bug/missing feature flow separately. So in the future if you have obvious bugs with something exploding or not working on a specific platform but working on another etc please, can you add a ticket on GH? That way we can attach all files and screenshots for a given problem with all people reporting to a given issue. To make it simpler to separate and not create 101 topics at
    7 points
  49. this is kind of work in progress and not perfect for all scenarios but as synology now offers 6.2.4 in the DSM GUI as update (instead of 6.2.3 U3) more people might have that problem, some people tested that already here (https://xpenology.com/forum/topic/41473-dsm-624-25554-install-experience/) but i wanted to continue in a easier to find area and try to sort out problems and fine tune here in the tutorial and guides section there is the more complicated way of going back to 6.2.3, keeping all settings and data, that needs some experience in general and some linux skills and a eas
    7 points
  50. For those Linux newbs who need exact instructions on installing the script, follow this here. Please be VERY careful with syntax especially when working as root. If you have not turned on ssh in Control Panel remote access, do it Download putty or other ssh terminal emulator for ssh access Connect to your nas with putty and use your admin credentials. It will give you a command line "$" which means non-privileged In File Station, upload FixSynoboot.sh to a shared folder. If the folder name is "folder" and it's on Volume 1
    7 points