RedPill - the new loader for 6.2.4 - Discussion


Recommended Posts

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 by Vortex
  • Like 5
  • Thanks 1
Link to post
Share on other sites

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.

Link to post
Share on other sites
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))

Link to post
Share on other sites

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 😉

  • Like 2
Link to post
Share on other sites

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 by rok1
Link to post
Share on other sites
à 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.

Link to post
Share on other sites
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 by ilovepancakes
Link to post
Share on other sites
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 by flyride
  • Like 3
Link to post
Share on other sites

thank you @ThorGroup. really appreciated the effort.

 

22 hours ago, ThorGroup said:
  1. 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:
  1.  
  2. ... 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.

  • Like 1
Link to post
Share on other sites
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.

  • Like 3
Link to post
Share on other sites

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 by Vortex
  • Like 1
Link to post
Share on other sites
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.

  • Like 1
Link to post
Share on other sites
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.

 

Drive3_0.png

Edited by Hokey33
  • Like 1
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.