Leaderboard

Popular Content

Showing content with the highest reputation since 08/26/2021 in all areas

  1. 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
  2. @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
    16 points
  3. 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
  4. 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
  5. 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
  6. 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
    13 points
  7. 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
  8. 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
  9. 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)
    11 points
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
    7 points
  15. 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
  16. 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
  17. 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
  18. I removed all platform versions from the global_config.json that did not point to the @ThorGroupredpill-load repository. Thus, there is no build-in <platform_version> for DSM7.0.1 anymore and you will have to add according settings to the global_config.json yourself. It proved to be impossible to keep track of all changes that happen arround redpill-load, and after all not everyone wants to have an optioniated configuration that uses a specific fork. changes:redpill-tool-chain_x86_64_v0.8.zip removed all platform versions that use redpill-load repostories other then the
    6 points
  19. Incorporated the addition from @taiziccf for chchia's apollolake-7.0.1-42214, and added @jumkey's bromolow-7.0.1-42214 from his develop branch. You guys are moving at an incredible pace redpill-tool-chain_x86_64_v0.6.1.zip
    6 points
  20. @Orphée As much as I agree that the user should make some efforts to read and understand, I advise you to tone it down and to read the rules. We are not here to bash people. You could have conveyed the same message without the aggression and foul language. I have edited your post accordingly.
    5 points
  21. 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",
    5 points
  22. "clean all" removed all images (last build + orphaned), but did only remove the build cache of orhaned images, but not the latest. Now "clean all" will clean the build cache for the last build image as well. re-uploaded with yumkey fix redpill-tool-chain_x86_64_v0.7.4_fix.zip
    5 points
  23. This post contains responses to questions from mid-page 47 only and was split due to forum's limitations. To see release updates jump to a post on the bottom of page 55: ---------------------------------------------- DO NOT use vanilla kernel sources to build modules for the DSM unless you know what you're getting into. We cannot stop you of course but you should know it's like playing with fire over a tank of gasoline. Let us explain. Syno, despite the version number attached in the kernel, modifies source heavily. So their 4.4.123 can be anythi
    5 points
  24. I guess we should open another thread for helping others to use the loader and to leave this thread for development needs. now this thread is flooding with operational issue.
    4 points
  25. may be @ThorGroup could enhance first topic with some extra info ? link to latest version of haydibe docker image ? how to get ride of the blank info center sudo su - root sed -i 's/supportsystemperature="yes"/supportsystemperature="no"/g' /etc.defaults/synoinfo.conf sed -i 's/supportsystempwarning="yes"/supportsystempwarning="no"/g' /etc.defaults/synoinfo.conf acpi throttle sudo su - root vi /usr/local/etc/rc.d/S99Powersaving.sh and insert according to number of core Script-content: #!/bin/sh echo powersave > /sys/devices/system/cpu/cpu0/cpufr
    4 points
  26. With respect, I'm not going to do that. As pointed out repeatedly elsewhere in this thread, this software/method isn't ready for general release yet and is only suitable for people who can follow the guides and assemble the software for themselves at this point. I've described everything I've done to get this far, or at least referenced and linked to other people's guides, so go and put it together yourself. If you can't figure it out this probably isn't ready for you yet. I'll be more than happy to do a full write-up when ThorGroup announce a release candidate or full release
    4 points
  27. Like i said i have compiled it and verified that the vmxnet driver works on DSM7.0/7.01 You should though put it in your loader /usr/lib/modules and modify linuxrc.syno.impl (of rd.gz) so it will be loaded during boot time. Best line number to add insmod /lib/modules/XXX.ko is 285 vmxnet3.7z
    4 points
  28. Thanx, will add it and repost. I should have tested it before *cough* Also, I missed out on that vscode highlighted the block as incomplete... The repost is attached. In case I miss out on those things: feel free to post the zip here, no need to wait for me. Update: deleted the attachment again -> look for 0.7, which has a "clean" action now to clean up old images.
    4 points
  29. 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
    3 points
  30. 3 points
  31. work with https://github.com/RedPill-TTG/redpill-load/pull/28 only tested on windows build-loader-win-amd64.exebuild-loader-mac-amd64build-loader-linux-amd64
    3 points
  32. I haven't followed the module compilation discussions in depth as my target environment (=proxmox) is supported out of the box. The build chain loader just follows the instructions of the respective git project, which made it easy to put into a dockerfile. Like I wrote before, I am not going to implemenet anything that needs to patch redpill-load sources on the fly. Those type of changes can be done in individual forks of redpill-load, you can simply point the repo url to your repo and be good. Everything else needs discussion via pm before I am able to descide wh
    3 points
  33. Oh boy, have I been sleeping!!!. I got some serious reading to do.
    3 points
  34. try this make CONFIG_VMXNET3=m CROSS_COMPILE=/root/build/apollolake-DSM-7.0-toolchain/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- -C /root/build/apollolake-DSM-7.0-toolkit/build/ M=`pwd` modules vmxnet3.ko
    3 points
  35. I have succesfully booted with a modified loader (DS3615xs) my old and brave ten years old Microserver G7 and installed 7.01. I thought that this would never be possible. I will share the loader for G7 once i have finished all tests.
    3 points
  36. Thought about it, but it's a rather expensive operation because no build would be able to leverage any sort of build cache. I am not sure how I feel about that Update: I hear you. Now there is a setting in `global_settings.json` that allows to enable auto clean, which does what you asked for. It is set to "false" by default and needs to set to "true" in order to be enabled. redpill-tool-chain_x86_64_v0.7.2.zip
    3 points
  37. Toolchain builder updated to 0.7.1 Changes: - `clean` now cleans the build cache as well and shows before/after statistics of the disk consumption docker has on your system. Bare in mind that cleaning the build cache, will require the next build to take longer, as it needs to build up the cache again. See README.md for instructions. Update: removed attachment, please use download 0.7.2 instead, which cleans the build cache as well.
    3 points
  38. This is what is said before, as I mentioned into other posts, virtualisation has a lot less hassle. On my first XPEnology build I bought a MB with the I-219v ethernet chipset which was not supported...my bad. I had to throw that board away and buy a new one with 2 ethernets I-211 and I-219 to make it work... As I expressed my opinion in another post and ThorGroup also commented on that, recent AMD leaks suggest that soon we will have 96cores/192treads CPU. With such a CPU as @taiziccf expressed in his own way you can build a lot more stuff than just a DSM. That 96 cores CPU can run a univ
    3 points
  39. I have manualy patched the vmlinux and made a loader for ds3615xs 7.0.1... it boots and i can install 7RC Version. Working so far. The Info Site in SystemControl is empty as in the beta 7 Version. Edit: 918+ is also working.
    3 points
  40. FYI I have tested redpill-DS3615xs_7.0-41222_b1629822564.img loader on baremetal - old HP dc7700, DSM succesfully installed from ds3615xs_41222.pat file and so far it seems to be working fine. Great work, developers!
    3 points
  41. DS3615XS Release Candidate 7.0.1 is now out .
    3 points
  42. Вначале хотелось бы выразить благодарность команде разработчиков нового загрузчика RedPill- @ThorGroup Thanks! Так же огромная благодарность за простой и понятный способ все быстро и удобно собрать и создать с помощью Docker - @haydibe Thanks too! Важно: Обращаю внимание, RedPill в данный момент даже не в стадии Beta, не рекомендую его использовать на хранилище с важными данными. На данный момент следует воспринимать эту инструкцию, как возможность поближе познакомиться с тем, что нас ждет дальше, и помочь разработчикам, в меру наших с вами возможностей, собирать статистику
    3 points
  43. I just migrated a 3 node vSphere cluster with vCenter to Proxmox. vSphere is definitly more polished and its fixed set of operations can be used almost completly from the web ui. Proxmox looks and feels less polished, and allows to configure the main subset of features that qemu/kvm provides from the ui - everything beyond requires the user to jump to the command line. I believe that qemu/kvm are so well hooked into the host's kernel, that the performance of vm guest's is astonishing well. Proxmox is more flexible then ESXi, especialy if you compare the "free" versions of both - wi
    3 points
  44. Scheduled power on function to my understanding at least, is a PMU function on a real Syno device. For the time being, we are emulating PMU at the software level but we are still missing the hardware to implement power on. It's in the roadmap, there is a line that says something about it. And here is a deeper explanation : https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/pmu.md
    2 points
  45. @fbittoun Il n'y a heureusement pas de tuto à l'heure actuelle... Il y a un outils mis à disposition par @haydibe (merci à lui) pour faciliter la compilation de l'image à l'aide de Docker. C'est actuellement amplement suffisant pour mettre en œuvre les tests. Si avec ce qui est fourni actuellement tu ne t'en sors pas, ne le prends pas mal, mais passe ton chemin, et attends une version considérée comme "plus stable" qu'actuellement. Ne cherchez pas de tutos tout faits, et n'en rédigez pas non plus pour ceux qui seraient tentés de le faire... Le développement n'est pas enco
    2 points
  46. Thought about it... but this is rather an addition to redpill, than XPE development, isn't it? I understand that you volunteer to push it to github? Be my guest Everyone is free to modify the sources, publish modifications here or push them to github. I claim no ownership of the toolchain builder - as such I would appreciate if my name is not mentioned in the github repo. I prefer to not leave my marks on Github with it... Update: I forget to mention that I uploaded the fix for 0.7.4 in the original post pointing to the development branch for apo
    2 points
  47. all good, i have rebuild my key with parameters set correctly and all booted super duper. for those going fresh don't forget to setup your gouvernor to powersaver again
    2 points
  48. from https://gist.github.com/Izumiko/26b8f221af16b99ddad0bdffa90d4329 "synoinfo": { "supportsystemperature": "no", "supportsystempwarning": "no" },
    2 points
  49. I just come to share my java port redpill-load with uefi support. Should wait for ttg to announce whether it can really support 7.0.1 some scripts maybe useful cd $LINUX_SRC export CROSS_COMPILE=/root/build/apollolake-DSM-7.0-toolchain/x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- make clean sed -i 's/bzImage: vmlinux/bzImage: /' arch/x86/Makefile make vmlinux -j4 # make some *.o inspire by UnknowO cp ../vmlinux_mod.bin vmlinux # vmlinux_mod.bin is already stripped of debugging and comments, strippe again should be ok make bzImage sed -i 's/bzImage: /bzImage: vmlinux/' arc
    2 points
  50. You are right, wasn't that hard after all. I have noticed the backup, but honestly don't like the idea of restoring someone elses backup. At the end it was as easy as adding a virtio network card, the usb controller and serial0 port, and manualy edit the vm's conf to add: args: -device 'qemu-xhci,addr=0x18' -drive 'id=synoboot,file=/var/lib/vz/images/XXX/redpill-DS918+_7.0-41890.img,if=none,format=raw' -device 'usb-storage,id=synoboot,drive=synoboot,bootindex=5' at the top of the vm config file: /etc/pve/nodes/zzz/qemu-server/xxx.conf Then used this
    2 points