Leaderboard

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. A roadmap Lets first address why this week is less exciting: we spent most of the time testing various scenarios and tracking hidden-yet-missed bugs. This is most likely the second to last round of updates before we release a beta version. The beta version can be used in a day-to-day testing and should be free of dangerous crashes (ok, maybe except that strange kernel lookup - we're looking into it). In the beta some features may still be missing but overall we're already testing a few instances and it's looking good We don't have an official roadmap as someone here asked. However, this is the rough list of things we want to address in that order: Custom drivers support*: there's a hack discussed here to add drivers to a ramdisk. However, this isn't a sustainable solution for many reasons. Mainly the reason is a very limited size. The current ramdisk, especially on systems without compression, is almost at the limit and on slower systems can crash with even a few megabytes more added to it. This seems to be especially unstable on v7 Linux v4 kernel. The solution we're working on will simply include modules on the partition which are loaded in pre-boot and copied to the main OS partition on boot. Naturally from the perspective of the user it will involve simply adding a line to user_conf and dropping a file in "custom". For people digging deeper it will be also much easier as this involves no repacking: simply mount the partition and drop more files in and they will be copied 1:1 and loaded as needed. Full SAS support*: while cheap HBA cards are great and something we actually will recommend for home builds (as they're cheap, stable, and offer 4-6 ports), LSI is king for bigger arrays. We want to make sure these are working as intended making both DSM and Linux happy (which isn't easy in v7 ;)). UEFI support*: there are board which cannot boot in legacy mode. We want to fully test this and offer an official UEFI support in the RedPill. Add support for newest revisions of the OS to 918+ and 3615xs* Step-by-step instruction*/**: essentially we want you guys to help us test not only the code but also a guide It will be published alongisde the beta version. We will prepare it in a form of a GH page so that we can easily incorporate feedback (as we cannot edit posts after ~1h). After we resolve problems with it we will go ahead and publish an RC version on the main forum so that it becomes an official version released for usage by less experienced folks who still want to poke around the OS. Integrate build process into the main repository**: @haydibe is doing an AMAZING job here and we cannot thank him enough. As we discussed with him before we want to incorporate the docker directly into the redpill-load repo and enable LKM builds on GH, so that everything is automated and synchronized as soon as we publish an update. Small fixes: add native support for CPU governor, fix CPU detection to match the model (as some things on v7 react strangely if the CPU doesn't match the model), fix various internal code-smells in the kernel code Add support for GPU acceleration: in short we want to explore adding platform like DVA3221 AMD support: let's just say we aren't fans of Intel recently We want to add a model which natively supports AMD CPUs Work on making mfgBIOS LEDs/buzzers/hwmon stuff more real or at least publish an interface which can be used by others to add an arduino or similar. Things marked with * are aimed to be done by the beta release. Things marked with ** we are HOPING to get done before the beta but we cannot promise Fixed I/O scheduler not found errors Many people reported these, and we finally found some time to look at them. Fixing them should fix the disk scheduling and improve performance in some scenarios. All in all you shouldn't ever see them from now on. Commit: https://github.com/RedPill-TTG/redpill-lkm/commit/aaa5847c589b84783471f9a600eeb12fbf2dc31c Hardware monitoring emulation One of the big features boosted by syno in v7 is central monitoring. However, with that it looks like in v7 the hardware monitoring and things around that has changed a lot from v6. In short v6 allowed for things being out of whack here and there with the hardware sensors while v7 assumes all sensors are in order... and when they're not things break unexpectedly. For example that bug with General tab not loading in Info Center was just a tip of an iceberg. It was just a symptom of a MUCH MUCH bigger issue. If you do "cat /run/hwmon/*" on a DSM loaded with Jun's loader you will get: # cat /run/hwmon/* { "CPU_Temperature": { } } This isn't going to fly on v7. The Info Center is just the beginning of problems. High scemd usage at times was also caused by the lack of hwmon emulation (which again, wasn't strictly needed on v6). After painstakingly analyzing the synobios.h from the kernel and toolchains while also scratching our heads at how one of the drivers for ADT chip (fan controller on a real DS) was modified we think we've nailed it: # cat /run/hwmon/* { "CPU_Temperature": { "CPU_0": "61", "CPU_1": "61" } } { "System_Fan_Speed_RPM": { "fan1_rpm": "997", "fan2_rpm": "986" } } { "System_Thermal_Sensor": { "Remote1": "34", "Local": "32", "Remote2": "34" } } { "System_Voltage_Sensor": { "VCC": "11787", "VPP": "1014", "V33": "3418", "V5": "5161", "V12": "11721" } } The output above comes from a 3615xs instance. On 918+ you will see only CPU_Temperature and hdd backplane status as physically 918+ does not monitor anything else. You can read more about that in the new document in the research repo: https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/hwmon.md All values above are fully emulated as on a VM we have no way of reading them and on a real hardware the only standardized one which we can pass along is the CPU temp (as voltages and thermal sensors vary widely between motherboards). We have a "todo" to make CPU temperature real on bare metal. The ugly part, which forced us to change the LKM build to require major version of the OS to be specified, is that syno changed so many things between v6 and v7 that they forgot to make proper headers. As you can see in the https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/mfgbios.md document they just like that moved two fields in the middle of the struct. You never ever do that. Not without at least some ifdef (which they did for other things). The issue is that change we've found is not present in all toolchains, it's not documented anywhere and we discovered it by accident by comparing files. There's really no sane way to detect that (we've tried really hard). This is why we were forced to add (ugly) requirement for v6/v7 to be specified while building the kernel module. If we find a saner way we will go back and make it automatic again. With the hwmon being emulated there are two VERY important things: you CANNOT disable "supportsystemperature" and "supportsystempwarning"! The hack someone posted here with sed - https://gist.github.com/Izumiko/26b8f221af16b99ddad0bdffa90d4329 - should NOT be used. We cannot stress this enough. Anyone who used it and keeps the installation MUST put "supportsystemperature: yes" and "supportsystempwarning: yes" into user_config at least for a single boot. This is because these values (with =no) are now baked into your OS partition and you MUST fix them to the default "yes". As the loader script doesn't have them specified anywhere it will not touch them anymore. you CANNOT disable ADT support. This comes back way to the Jun's loader and deleting "supportadt7490" on 3615xs. If you're not installing from scratch on a new disk but playing with the same on you MUST put "supportadt7490: yes" to your user_config at least for one boot. Commits: https://github.com/RedPill-TTG/redpill-lkm/commit/72cb5c3620711bcabcfe6e1c67ebfbeca6f7e6bf (mfgBIOS structures v6/v7 changes) https://github.com/RedPill-TTG/redpill-lkm/commit/16adab519d6c4cc604e3fb680fb041e8ddd2167e (HWMON definitions) https://github.com/RedPill-TTG/redpill-lkm/commit/7d95ce2ec7d35493227196be58bbd2c7ca2704f8 (HW capabilities emulation) https://github.com/RedPill-TTG/redpill-lkm/commit/014f70e7127abdf28b47fe58f35086296b5d78ca (HWMON emulation) https://github.com/RedPill-TTG/redpill-load/commit/78c7bf9f903a73d51013a859f590c09ee835f8e7 (remove legacy ADT hack) Fix RTC power-on bug On 918+ the scemd complained about auto power-on setting failing. Now this is fixed and scemd no longer triggers an internal error state. This was happening when OS was sending an empty schedule. Commit: https://github.com/RedPill-TTG/redpill-lkm/commit/80a2879aae23d611228c8791b35e237bfa0ec7a8 Add support for emulated SMART log directory This is an internal change in the SMART emulation layer. Syno uses slightly out-of-spec approach (again, hello v7 mess) and assumes all disks implement one of the ATAPI functionalities which is actually optional. This may actually cause some real disks to fail as well on a real v7 so they will probably eventually fix it themselves. For the time being we did it in RP. Commit: https://github.com/RedPill-TTG/redpill-lkm/commit/278ee99a4dcb8fb8f025915118e7df93824e9bfc ------------------------------------------------------------------------ Today's update is rather short as HWMON layer took us a ton of time to properly research and figure out how to actually do it. There were literally 5 different implementation until we got it right. That being said the forum deleted our responses to comments which we were typing here so we will write them again... but probably tomorrow morning. We will try to sit together tomorrow morning (ok, developer's morning ;)) and write responses again. @WiteWulf Can you try deleting the line with "register_pmu_shim" from redpill_main.c (in init_(void) function) and rebuilding the kernel module? You can then use inject_rp_ko.sh (lkm repo) script to inject it into an existing loader image or rebuild the image. With that you shouldn't have PMU emulation anymore (so the instance can be killed in ~24-48h) but we can see if it's kernel panicking.

@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 included, debug messages included - test: fully stripped with only warning & above (no debugs or info) - prod: fully stripped with no debug messages See README.md for usage. redpill-tool-chain_x86_64_v0.10.zip

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://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/25426branch/apollolake-source/linux-4.4.x.txz/download", "sha256": "af815ee065775d2e569fd7176e25c8ba7ee17a03361557975c8e5a4b64230c5b" }, "toolkit_dev": { "url": "https://sourceforge.net/projects/dsgpl/files/toolkit/DSM7.0/ds.apollolake-7.0.dev.txz/download", "sha256": "d349fa644392d4cfab8191243ee38aaa32bd517208c144678e0c855cb5a619ea" } }, "redpill_lkm": { "source_url": "https://github.com/RedPill-TTG/redpill-lkm.git", "branch": "master" }, "redpill_load": { "source_url": "https://github.com/jumkey/redpill-load.git", "branch": "develop" } } I used the prod-v7 target, you can change it to suit your needs. (dev/test/prod)

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.]

@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.

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", "sha256": "af815ee065775d2e569fd7176e25c8ba7ee17a03361557975c8e5a4b64230c5b" }, "toolkit_dev": { "url": "https://sourceforge.net/projects/dsgpl/files/toolkit/DSM7.0/ds.bromolow-7.0.dev.txz/download", "sha256": "a5fbc3019ae8787988c2e64191549bfc665a5a9a4cdddb5ee44c10a48ff96cdd" } }, "redpill_lkm": { "source_url": "https://github.com/RedPill-TTG/redpill-lkm.git", "branch": "master" }, "redpill_load": { "source_url": "https://github.com/jumkey/redpill-load.git", "branch": "develop" } }, For Apollolake need to add this lines: It's very fast and easy make a build an .img for test, only need linux (In my case use Terminal on Ubuntu): 1. Install Docker sudo apt-get update sudo apt install docker.io 2. install jq & curl: sudo apt install jq sudo apt install curl 3. download redpill-tool-chain_x86_64_v0.10 https://xpenology.com/forum/applications/core/interface/file/attachment.php?id=13072 4. Go to folder and permissions to .sh cd redpill-tool-chain_x86_64_v0.10 chmod +x redpill_tool_chain.sh 5. If you want edit vid,pid,sn,mac: #edit apollolake vi apollolake_user_config.json #edit bromolow vi bromolow_user_config.json 6. build img #for apollolake ./redpill_tool_chain.sh build apollolake-7.0.1-42214 && ./redpill_tool_chain.sh auto apollolake-7.0.1-42214 #for bromolow ./redpill_tool_chain.sh build bromolow-7.0.1-42214 && ./redpill_tool_chain.sh auto bromolow-7.0.1-42214 then the file was in redpill-tool-chain_x86_64_v0.10/images 7. For VMWare I convert .img to .vmdk with StarWind V2V Converter, and then add to Virtual Machine like sata. Also, change ethernet0.VirtualDeb = "e1000" to "e1000e on file .vmx Thanks ThorGroup for the great work global_config.json

This doesn't add up.... The toochain builder does exactly nothing to either support or prevent uefi, this is part of what redpill-load does. So far I understand your post as "the toolchain builder uses a redpill-load version that lacks the features that have been previously there". The toolchain can and will not influence how redpill-lkm and redpill-load work. Never did, never will!

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.sh Done:) If things go wrong simply restore the original file: ./patch.sh -r Cheers

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

🤣 I actually laughed out loud lol.

Let me quote from the README.md to answer that question:

It will be better for you then to wait for beta release.

First post on the first page of this thread: https://github.com/RedPill-TTG/redpill-lkm

BTW, in testing the kernel panic stuff I installed "Photos" to my machine and was pleasantly surprised to find the face detection is working 👍

@dhlsam. @toyanucciand everyone with nic issues on baremetal. A small suggestion I have to make, is to boot with a live Linux image and see what are the loaded modules for your system before looking to load a module. Modules with wrong magic number will not be loaded.

It happened randomly with a simple nginx container too... (BUG: soft lockup - CPU#1 stuck for 41s! [runc:19580]) And maybe this IPv6 "issue ?" too while starting docker.

Redpill does not output anything to the screen after this message. All further diagnostic information is output to the serial port. @ThorGroup *please* put a message on there saying there's no more output, like Jun's does

while in ssh with root run # depmod -a # modprobe atlantic verify module is loaded with # lsmod |grep -i atlantic If it didn't load do a # insmod /usr/lib/modules/atlantic.ko and verify again. If it doesnt load check dmesg output to see whats wrong

Uefi support is added only in jumkey`s branch. Only those who used the default configs to use jumkey`s branch for 7.0.1 RC had UEFI support in global_config.json. haydibe removed the lines for 7.0.1 in global_config.json from v0.8 and left only TTG`s github repos.

FYI, signatures aren't visible to users on mobile devices.

У меня их накопилось уже под 10 с рабочих НАСов и ни одну я не пробовал на домашнем: мало разве нормальных DDNS-сов?

Worked fine for my J3455-ITX - though I made my own Extra.lzma.. Powerdown and reboots are fixed too, good job! Should say that I needed to leave it for an awfully long time before getting a ping (and a couple of reboots).. But all was good eventually.. Attached my custom.lzma extra.lzma

I915 driver loop KP started at [ 72.061444] Download the extra here below. Change of this extra.lzma > - removed drivers i915.ko drm_kms_helper.ko drm.ko in usr/lib/modules - removed reference of this drivers in etc/rc.modules - removed the i915 folder in /usr/lib/firmware and edit/removed the i915 EXTRA_FIRMWARE in the /etc/rc.modules Installation > sudo -i echo 1 > /proc/sys/kernel/syno_install_flag mkdir -p /mnt/synoboot1 mkdir -p /mnt/synoboot2 mount /dev/synoboot1 /mnt/synoboot1 mount /dev/synoboot2 /mnt/synoboot2 Remove extra2.lzma and replace extra.lzma by the one in my sign in /mnt/synoboot2 Important > clean /usr/lib/modules/update/* - Be careful with the rm ! rm -rf /usr/lib/modules/update/* And reboot extra.lzma