RedPill - the new loader for 6.2.4 - Discussion

ThorGroup · July 13, 2021

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
- DSM Research/Docs: hosts documentation for developers regarding the inner details of DSM boot process

While the dates and authors in both repos are anonymized, the history is preserved. Thus, your forks and PRs will work properly.

The Current State
As of now the DSM installs & boots properly (sort of, continue reading). We are currently working on a toolset for generating the loader image automatically so that testing new iterations is easier for people not familiar with full inner workings of the kernel component & the bootloader itself. The tool with instructions will be published in a separate repo.

The kernel module is currently missing the PCI-IDs shimming and RTC emulation. While the latter is most likely not crucial, the former must be implemented. However, it's not really straight-forward as naturally the kernel doesn't have a high-level API to lie about nonexisting hardware

The current revision of the LKM causes some errors to be sent to the PMU. If anyone in the community (@Vortex? @IG-88?) has an idea of what is the source of these we will be grateful for some pointers.

--R--R-p--R-4
-9
--R-r-K-8-3-8

As of now we're working on a robust PCI emulation layer. This isn't hard in theory but has many pitfalls if we want to do it properly and none of us ever studied inner workings of PCI on x86 As described in the PCI document in the research repo there are three methods. We picked the third one (full PCI emulation) as it allows for creation of devices which are indistinguishable from real ones. While this is the hardest to pull off properly, it doesn't rely on a hack but rather an official and documented Linux API.

Q&A

Who are you?
We're a group of passionates dating back to the (great) phreaking times. If you know where to look you will find us on IRC
Can I get involved in the development?
Yes! As this project took a lot from the community we strongly believe it should continue to be shared and developed under GPL. We greatly appreciate any PRs on GH.
I'm not a developer, can I help?
At this stage most likely not. However, we wish to have some testing version not too far in time. For various reasons we cannot (and not willing to) accept any donations. If you want to make us feel better leave a like and a good word for us, as naturally this isn't our full-time job :)))
Why is making the code public matters?
We believe that the code of the loader MUST be public. We aren't sure if the general community is aware of the degree of control the "loader" has over their box. Despite the name it is not just a load-and-leave situation. The majority of the loader code is active in the system for the whole time (you can check that by doing lsmod and looking for an entry which doesn't look like a proper module name but one or more random characters).
The kernel module can do literally anything you can as root... and more. It can read files, send them in the background somewhere, hide files from you, execute programs with higher-than-root privileges without showing them in any tools, use your CPU while showing 0% in htop etc... and the worst part is that you will never know that it happened (unless you're monitoring your device from the outside).

However, after this scary paragraph we can say two things: Jun's loader doesn't seem to do any evil things, and the actions any loader needs to perform in the system after the initial load are minimal (e.g. fake responses to "turn on HDD led"). We've also reviewed the code we cloned and it's a solid base.
Additionally, making the code open means anybody can tinker with it and adjust to new scenarios instead of relying to bit-patching a .ko.
What happened to previous repos? Are you crediting the previous author?
The author of the original code wishes to distance himself from the project and we are respecting that. That's all we know.
Do you/anyone have the code of Jun's loader?
We saw that there's some confusion on the forum regarding Jun's loader and why the work had to start from scratch. Neither the Jun's loader code nor any deeper implementation details regarding inner working of his amazing loader were ever shared with the public. We weren't able to obtain the code through our sources either. There's a good chance he never shared the with anybody.
Is Syno trying to block the loader?
While we cannot comment on any actions, we can surely talk about the code. The new kernel contains something which isn't present before 25556: https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/boot_params-validation.md
It is true that the "va not found" error triggered by the Jun's loader when used with >6.2.3 is indeed related to offsets which changed in the new build. However, the rabbit hole doesn't stop there. The new "boot_params" check doesn't seem to have any other purpose than detecting violation of the chain of trust. So did the new kernel build broke the loader intentially? Most likely not (it's probably a by-product of the new validation code present very early in the image) but why the boot params validation was placed in 6.2.4 in the first place? We leave the interpretation to the reader.
When we can expect a stable release? Will it work on v7?
We cannot promise any date for two reasons: 1) we can hit an unexpected roadblock (e.g. see errors mentioned above), and 2) we will like to test it and have it working on v6.2.4 and v7 as well (as of now v7 is available for selected devices only and from our tests it is not fully stable even on the devices it was officially released).
Some of the protections found in v6 were pulled from v7... but don't worry, they will be back as soon as they port them... it's a carrot and a stick situation.

cc for people who followed the original topic:

@AleAmadoC @alexku44 @Amoureux @Balrog @blindspot @Bobbenoster @Bobur @coolinx @dimcheff @Fede @FiberInternetUser @gadreel @ilovepancakes @impala_84 @intrax @jarugut @juud @kiwiuk @lemon55 @loomes @minigranis @NeoID @Nuno @Piteball @pkdick1 @pro_info @profet @rufik @s2k7 @scoobdriver @setsunakawa @smilenkovski @smileyworld @smoojay @snakefox666 @Snyaify @SpiRe @T-REX-XP @The Chief @toolazy @vasiliy_gr

Edited July 13, 2021 by ThorGroup

DrStorage · July 13, 2021

Great news. Thanks a lot for all your hard work.

Aigor · July 13, 2021

Cool!

Edited July 13, 2021 by Aigor

Vortex · July 13, 2021

4 hours ago, ThorGroup said:
The current revision of the LKM causes some errors to be sent to the PMU. If anyone in the community (@Vortex? @IG-88?) has an idea of what is the source of these we will be grateful for some pointers.
--R--R-p--R-4
-9
--R-r-K-8-3-8

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                 0x38 /* '8' */
#define UART2_CMD_LED_HD_GB                 0x39 /* '9' */
#define UART2_CMD_LED_HD_AS                 0x3A /* ':' */
#define UART2_CMD_LED_HD_AB                 0x3B /* ';' */
#define UART2_CMD_LED_HD_BREATH             0x3D /* '=' */
#define UART2_CMD_LED_USB_ON                0x40 /* '@' */
#define UART2_CMD_LED_USB_BLINK             0x41 /* 'A' */
#define UART2_CMD_LED_USB_OFF               0x42 /* 'B' */
// control by microp, echo J to ttyS1 to light on the 10G led, echo K to ttyS1 to turn off the 10G led
#define UART2_CMD_LED_10G_LAN_ON            0x4A /* 'J' */
#define UART2_CMD_LED_10G_LAN_OFF           0x4B /* 'K' */
#define UART2_CMD_SWITCH_MICROP_VERSION     0x4F /* 'O' */
#define UART2_CMD_LED_MIRROR_OFF            0x50 /* 'P' */
#define UART2_CMD_LED_MIRROR_GS             0x51 /* 'Q' */
#define UART2_CMD_LED_MIRROR_GB             0x52 /* 'R' */
#define UART2_CMD_LED_MIRROR_AS             0x53 /* 'S' */
#define UART2_CMD_LED_MIRROR_AB             0x54 /* 'T' */
#define UART2_CMD_TOGGLE_FAN_RPS_REPORT     0x55 /* 'U' */
#define UART2_CMD_SET_PWM_DUTY              0x56 /* 'V' */
#define UART2_CMD_SET_PWM_FREQ              0x57 /* 'W' */
#define UART2_CMD_BUTTON_USB                0x60 /* '`' */
#define UART2_CMD_BUTTON_RESET              0x61 /* 'a' */
// control by up, must echo u first! uP #1
#define UART2_CMD_FAN_FAILURE               0x66 /* 'f' */
// control by up, must echo EC1 first! uP #17
#define UART2_CMD_CPUFAN_FAILURE            0x67 /* 'g' */
#define UART2_CMD_RCPOWEROFF                0x70 /* 'p' */
#define UART2_CMD_RCPOWERON                 0x71 /* 'q' */
#define UART2_CMD_DISABLE_SCHEDULE_POWERON  0x72 /* 'r' */
#define UART2_CMD_ENABLE_SCHEDULE_POWERON   0x73 /* 's' */
#define UART2_CMD_DISABLE_FANCHECK          0x74 /* 't' */
#define UART2_CMD_ENABLE_FANCHECK           0x75 /* 'u' */
#define UART2_CMD_DISABLE_CPUFANCHECK       "EC0"
#define UART2_CMD_ENABLE_CPUFANCHECK        "EC1"
#define UART2_CMD_ENABLE_POWERBTN_WAKEUP    "SW1"
#define UART2_CMD_DISABLE_POWERBTN_WAKEUP   "SW0"
#define UART2_CMD_ALARM_LED_ON              "LA1"
#define UART2_CMD_ALARM_LED_BLINKING        "LA2"
#define UART2_CMD_ALARM_LED_OFF             "LA3"
#define UART2_CMD_SWITCH_LED_CONTROL        "M"  //Switch the led control between status and power
#define UART2_CMD_WOL_ENABLE                "l"
#if defined(MY_DEF_HERE) || defined(MY_ABC_HERE)
#define UART2_CMD_GET_UNIQUE_CMD            0x52 /* 'R' */
#endif

lets'decode:

4 - Power LED on

9 - Status LED green blink

8 - Status LED green on

3 - Long beep (successfully booted)

R -GetMicroP (several attempts)

r - Disable Sched. Poweron

K - LAN10G LED off

p - RC power off (?)

- - is a delimiter

It would be great if these commands (GetMicroP is most important)

(together with /dev/ttyS1) were shimmed in the LKM!

Edited July 13, 2021 by Vortex

DaveD · July 13, 2021

Respect to everyone giving up their time to work on this 🙏

pigr8 · July 13, 2021

great, have my like! 👍

mcdull · July 13, 2021

Is the blocker only for baremetal? Can basic function work in QEMU?
Guess most baremetal can run qmeu and it is far more easy to maintain with virutal environment.

T-REX-XP · July 13, 2021

5 hours ago, Vortex said:

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                 0x38 /* '8' */
#define UART2_CMD_LED_HD_GB                 0x39 /* '9' */
#define UART2_CMD_LED_HD_AS                 0x3A /* ':' */
#define UART2_CMD_LED_HD_AB                 0x3B /* ';' */
#define UART2_CMD_LED_HD_BREATH             0x3D /* '=' */
#define UART2_CMD_LED_USB_ON                0x40 /* '@' */
#define UART2_CMD_LED_USB_BLINK             0x41 /* 'A' */
#define UART2_CMD_LED_USB_OFF               0x42 /* 'B' */
// control by microp, echo J to ttyS1 to light on the 10G led, echo K to ttyS1 to turn off the 10G led
#define UART2_CMD_LED_10G_LAN_ON            0x4A /* 'J' */
#define UART2_CMD_LED_10G_LAN_OFF           0x4B /* 'K' */
#define UART2_CMD_SWITCH_MICROP_VERSION     0x4F /* 'O' */
#define UART2_CMD_LED_MIRROR_OFF            0x50 /* 'P' */
#define UART2_CMD_LED_MIRROR_GS             0x51 /* 'Q' */
#define UART2_CMD_LED_MIRROR_GB             0x52 /* 'R' */
#define UART2_CMD_LED_MIRROR_AS             0x53 /* 'S' */
#define UART2_CMD_LED_MIRROR_AB             0x54 /* 'T' */
#define UART2_CMD_TOGGLE_FAN_RPS_REPORT     0x55 /* 'U' */
#define UART2_CMD_SET_PWM_DUTY              0x56 /* 'V' */
#define UART2_CMD_SET_PWM_FREQ              0x57 /* 'W' */
#define UART2_CMD_BUTTON_USB                0x60 /* '`' */
#define UART2_CMD_BUTTON_RESET              0x61 /* 'a' */
// control by up, must echo u first! uP #1
#define UART2_CMD_FAN_FAILURE               0x66 /* 'f' */
// control by up, must echo EC1 first! uP #17
#define UART2_CMD_CPUFAN_FAILURE            0x67 /* 'g' */
#define UART2_CMD_RCPOWEROFF                0x70 /* 'p' */
#define UART2_CMD_RCPOWERON                 0x71 /* 'q' */
#define UART2_CMD_DISABLE_SCHEDULE_POWERON  0x72 /* 'r' */
#define UART2_CMD_ENABLE_SCHEDULE_POWERON   0x73 /* 's' */
#define UART2_CMD_DISABLE_FANCHECK          0x74 /* 't' */
#define UART2_CMD_ENABLE_FANCHECK           0x75 /* 'u' */
#define UART2_CMD_DISABLE_CPUFANCHECK       "EC0"
#define UART2_CMD_ENABLE_CPUFANCHECK        "EC1"
#define UART2_CMD_ENABLE_POWERBTN_WAKEUP    "SW1"
#define UART2_CMD_DISABLE_POWERBTN_WAKEUP   "SW0"
#define UART2_CMD_ALARM_LED_ON              "LA1"
#define UART2_CMD_ALARM_LED_BLINKING        "LA2"
#define UART2_CMD_ALARM_LED_OFF             "LA3"
#define UART2_CMD_SWITCH_LED_CONTROL        "M"  //Switch the led control between status and power
#define UART2_CMD_WOL_ENABLE                "l"
#if defined(MY_DEF_HERE) || defined(MY_ABC_HERE)
#define UART2_CMD_GET_UNIQUE_CMD            0x52 /* 'R' */
#endif

lets'decode:

4 - Power LED on

9 - Status LED green blink

8 - Status LED green on

3 - Long beep (successfully booted)

R -GetMicroP (several attempts)

r - Disable Sched. Poweron

K - LAN10G LED off

p - RC power off (?)

- - is a delimiter

It would be great if these commands (GetMicroP is most important)

(together with /dev/ttyS1) were shimmed in the LKM!

It will be greater when we can process it via the hook)) to fix fan speed or beep via the webui))

Eoghan · July 13, 2021

Looking forward to this release however I do have a question users on Juns loader will they be able to upgrade to redpill without the need of starting from scratch etc? Also if you planning on making a website for this release etc I can host it for you free of charge as a thanks from the community just send me a PM 😉

Huey_Pilot · July 13, 2021

This is realy great news. 😁😀🥳🤗

profet · July 13, 2021

So happy to read there is life in Xpenology yet...

Massive thanks for all your hard work!

ilovepancakes · July 13, 2021

@ThorGroup To echo everyone else thus far, thanks a TON for your efforts on this. Exciting to see the community and development for new versions still alive.

P.S. Really looking forward to a DSM v7 compatible solution, sign me up as a tester 😅

rok1 · July 13, 2021

Not sure what 7.0 will give us aside from some minor updates aesthetically and functionally. DSM 7 for my 1621+ still is only on kernel 4.4.180. To be able to use XPE 918+ with more current hardware we're going to need a newer kernel.

Edited July 13, 2021 by rok1

pro_info · July 13, 2021

à l’instant, rok1 a dit :

Not sure what 7.0 will give us aside from some minor updates aesthetically and functionally. DSM 7 for my 1621+ still is only on kernel 4.4.180. To be able to use XPE 918+ with more current hardware we're going to need a newer kernel.

Personally, what I expect from DSM 7 is the improvement in raid rebuild, "smart" bad disk detection, improved SSD cache management and access to Synology Drive 3.0 because v2 is still buggy as hell when using on-demand sync under windows... For the interface, of course, it's nice, but I rarely go on it, once everything is set up.

ilovepancakes · July 13, 2021

42 minutes ago, rok1 said:

Not sure what 7.0 will give us aside from some minor updates aesthetically and functionally.

The latest security updates and some features which actually do improve DSM. I agree a lot of v7 is fluff but is always nice to run on latest builds especially as they start introducing more new features and eventually 7.1, 7.2, etc.

Edited July 13, 2021 by ilovepancakes

flyride · July 14, 2021

4 hours ago, rok1 said:

Not sure what 7.0 will give us aside from some minor updates aesthetically and functionally. DSM 7 for my 1621+ still is only on kernel 4.4.180. To be able to use XPE 918+ with more current hardware we're going to need a newer kernel.

This is a bit OT, but we get what we get. Synology is selling you a 14nm 1st gen circa 2018 CPU as a new product. It's no mistake that older gen hardware tends to work better. And even if a platform were not supported under kernel 4.4.x, all Syno has to do is backport the kernel mods for that particular CPU/chipset/NIC and they could care less about other new hardware.

I don't think the objective of redpill or any other loader should necessarily be to be compatible with ALL hardware, particularly the newest stuff. It's great if it can work out that way, but I would consider a loader development a success if it could run on LIKE hardware, particularly if it can be emulated via virtual machine.

Edited July 14, 2021 by flyride

beatmech · July 14, 2021

thank you @ThorGroup. really appreciated the effort.

22 hours ago, ThorGroup said:

I'm not a developer, can I help?
At this stage most likely not. However, we wish to have some testing version not too far in time. For various reasons we cannot (and not willing to) accept any donations. If you want to make us feel better leave a like and a good word for us, as naturally this isn't our full-time job :)))

then I will wait for the proper stage later on, for testing etc.

22 hours ago, ThorGroup said:

... we can say two things: Jun's loader doesn't seem to do any evil things, and the actions any loader needs to perform in the system after the initial load are minimal (e.g. fake responses to "turn on HDD led")...

after using the code for a while now, I also can testify for this statements.

rok1 · July 14, 2021

1 hour ago, flyride said:

This is a bit OT, but we get what we get. Synology is selling you a 14nm 1st gen circa 2018 CPU as a new product. It's no mistake that older gen hardware tends to work better. And even if a platform were not supported under kernel 4.4.x, all Syno has to do is backport the kernel mods for that particular CPU/chipset/NIC and they could care less about other new hardware.

I don't think the objective of redpill or any other loader should necessarily be to be compatible with ALL hardware, particularly the newest stuff. It's great if it can work out that way, but I would consider a loader development a success if it could run on LIKE hardware, particularly if it can be emulated via virtual machine.

You're not wrong of course, but hardware continues to improve and new features are no longer compatible. Since my 10th gen i3 wont work (plex transcoding, etc) I had to buy older stuff to get my desired outcome (4c/8t). That used i7-7700 and an older motherboard cost more than the i3-10100 and motherboard and it's technically slower.

I've been using Xpenology since 5.x, I use it instead of something like Unraid or OpenMediaVault because I have official Synology units and love the ecosystem. Folks like IG88 and others have done standout work getting us compatibility drivers for newer nics, HBAs, IGP etc for use above baseline installs.

Regarding virtual machines, I'm not a huge fan of using them. I like them in my OS for use, but not as the primary hypervisor with multiple OS or containers running off of them. If our only way forward for 6.2.4/7.0 is via VM so be it, but many users are not going to want to dig that deep to get it to work. Even ESXi 7.0u2 is not compatible out of the box and required some finagling to get a 2.5g driver installed on the z490 motherboard I attempted with. I finally gave up and decided to drop 350$ for a used 7700 cpu/mobo to run baremetal.

test4321 · July 14, 2021

Sounds like a CIA / FBI op.

UnknownO · July 14, 2021

Cool!So... now it can work on QEMU?
PS: I want to join the test

Vortex · July 14, 2021

I realize the @ThorGroupdid not understand the purpose of all the synobios_ops. Here's a complete list

struct synobios_ops {
	struct module	*owner;
/*01*/	int		(*get_brand)(void);
/*02*/	int		(*get_model)(void);
/*03*/	int		(*get_cpld_version)(void);
/*04*/	int		(*get_rtc_time)(struct _SynoRtcTimePkt *);
/*05*/	int		(*set_rtc_time)(struct _SynoRtcTimePkt *);
/*06*/	int		(*get_fan_status)(int, FAN_STATUS *);
/*07*/	int		(*set_fan_status)(FAN_STATUS, FAN_SPEED);
/*08*/	int		(*get_sys_temperature)(struct _SynoThermalTemp *);
/*09*/	int		(*get_cpu_temperature)(struct _SynoCpuTemp *);
	#if defined(CONFIG_SYNO_PORT_MAPPING_V2)
/*10*/	int		(*set_disk_led)(DISKLEDSTATUS*);
	#else /* CONFIG_SYNO_PORT_MAPPING_V2 */
/*10*/	int		(*set_disk_led)(int, SYNO_DISK_LED);
	#endif /* CONFIG_SYNO_PORT_MAPPING_V2 */
/*11*/	int		(*set_power_led)(SYNO_LED);
/*12*/	int		(*get_cpld_reg)(CPLDREG *);
/*13*/	int		(*set_mem_byte)(MEMORY_BYTE *);
/*14*/	int		(*get_mem_byte)(MEMORY_BYTE *);
/*15*/	int		(*set_gpio_pin)(GPIO_PIN *);
/*16*/	int		(*get_gpio_pin)(GPIO_PIN *);
/*17*/	int		(*set_gpio_blink)(GPIO_PIN *);
/*18*/	int		(*set_auto_poweron)(SYNO_AUTO_POWERON *);
/*19*/	int		(*get_auto_poweron)(SYNO_AUTO_POWERON *);
/*20*/	int		(*init_auto_poweron)(void);
/*21*/	int		(*uninit_auto_poweron)(void);
/*22*/	int		(*set_alarm_led)(unsigned char);
/*23*/	int		(*get_buzzer_cleared)(unsigned char *buzzer_cleared);
/*24*/	int		(*set_buzzer_clear)(unsigned char buzzer_clear);
/*25*/	int		(*get_power_status)(POWER_INFO *);
/*26*/	int		(*get_backplane_status)(BACKPLANE_STATUS *);
/*27*/	int		(*module_type_init)(struct synobios_ops *);
/*28*/	int		(*uninitialize)(void);
/*29*/	int		(*set_cpu_fan_status)(FAN_STATUS, FAN_SPEED);
/*30*/	int		(*set_phy_led)(SYNO_LED);
/*31*/	int		(*set_hdd_led)(SYNO_LED);
/*32*/	int		(*pwm_ctl)(SynoPWMCTL *);
/*33*/	int		(*check_microp_id)(const struct synobios_ops *);
/*34*/	int		(*set_microp_id)(void);
/*35*/	int		(*get_superio)(SYNO_SUPERIO_PACKAGE *);
/*36*/	int		(*set_superio)(SYNO_SUPERIO_PACKAGE *);
/*37*/	int		(*exdisplay_handler)(struct _SynoMsgPkt *);
/*38*/	int		(*read_memory)(SYNO_MEM_ACCESS*);
/*39*/	int		(*write_memory)(SYNO_MEM_ACCESS*);
/*40*/	void	        (*get_cpu_info)(SYNO_CPU_INFO*, const unsigned int);
/*41*/	int             (*set_aha_led)(struct synobios_ops *, SYNO_AHA_LED);
/*42*/	int             (*get_copy_button_status)(void); // for matching userspace usage, button pressed = 0, else = 1
/*43*/	int             (*hwmon_get_fan_speed_rpm)(SYNO_HWMON_SENSOR_TYPE *);
/*44*/	int             (*hwmon_get_psu_status)(SYNO_HWMON_SENSOR_TYPE *, int);
/*45*/	int             (*hwmon_get_sys_voltage)(SYNO_HWMON_SENSOR_TYPE *);
/*46*/	int             (*hwmon_get_backplane_status)(SYNO_HWMON_SENSOR_TYPE *);
/*47*/	int             (*hwmon_get_sys_thermal)(SYNO_HWMON_SENSOR_TYPE *);
/*48*/	int             (*hwmon_get_sys_current)(SYNO_HWMON_SENSOR_TYPE *);
/*49*/	int 		(*set_ok_to_remove_led)(unsigned char ledON);
/*50*/	int		(*get_sys_current)(unsigned long*);
/*51*/	int             (*get_disk_intf)(SYNO_DISK_INTF_INFO *);
};

Edited July 14, 2021 by Vortex

smoojay · July 14, 2021

On 7/13/2021 at 7:16 AM, ThorGroup said:

While the dates and authors in both repos are anonymized

Does the anonymization of dates really makes sense?

ilovepancakes · July 14, 2021

10 hours ago, flyride said:

particularly if it can be emulated via virtual machine

This is a great point and allows the most flexibility for running the project. I love running Xpenology on ESXi, I find it to be pretty darn stable 99% of the time. I hope future loaders/redpill continue to support a "Virtual" Xpenology/DSM option.

Aigor · July 14, 2021

It would be amazing if possible, add zfs filesystem support

Hokey33 · July 14, 2021

15 hours ago, pro_info said:

Personally, what I expect from DSM 7 is the improvement in raid rebuild, "smart" bad disk detection, improved SSD cache management and access to Synology Drive 3.0 because v2 is still buggy as hell when using on-demand sync under windows... For the interface, of course, it's nice, but I rarely go on it, once everything is set up.

There is a working Synology Drive 3.0 beta version for DSM 6.2.3 in the package center. I have installed it today.

Edited July 14, 2021 by Hokey33

RedPill - the new loader for 6.2.4 - Discussion

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites