Jump to content
XPEnology Community

TinyCore RedPill Loader (TCRP)

pocopico

By pocopico
in Loaders

 Share

Recommended Posts

huskyg Newbie

huskyg

Posted
Posted

hi all, 

 

so ive got a i5 4300 cpu 8gb ram lenovo laptop where i am trying to install ds920+ or ds218+ . the loader build goes all the way o issues. but when i try to download and install the DSM it gets to the restarting your NAS 10 minutes countdown than at the end of the countdown it comes back with saying unknown error and i can start to upload DSM manually again, but i will get the same error.  

 

if you guys have an input i would apprecaiate it. 

 

 

Link to comment
Share on other sites
Peter Suh Guru Master

Peter Suh

Posted
Posted
On 11/26/2023 at 12:07 AM, huskyg said:

hi all, 

 

so ive got a i5 4300 cpu 8gb ram lenovo laptop where i am trying to install ds920+ or ds218+ . the loader build goes all the way o issues. but when i try to download and install the DSM it gets to the restarting your NAS 10 minutes countdown than at the end of the countdown it comes back with saying unknown error and i can start to upload DSM manually again, but i will get the same error.  

 

if you guys have an input i would apprecaiate it. 

 

 

 

Please try my mshell.

We recommend the new model SA6400, which uses kernel 5.
Fast transcoding is also possible in Haswell.

https://github.com/PeterSuh-Q3/tinycore-redpill/releases/tag/v1.0.0.0

  • Like 1
Link to comment
Share on other sites
Peter Suh Guru Master

Peter Suh

Posted
Posted
10 minutes ago, alirz1 said:

Any chance we will ever be able to use nvme drives for dsm install? I would love to setup a xpenology on a hp 800 g6 mini pc.

 

 

My mshell supports nvme volume by default.
However, DSM cannot be installed on nvme alone.
At least one SATA disk must be used when installing DSM.

https://github.com/PeterSuh-Q3/tinycore-redpill/releases/tag/v1.0.0.0

Link to comment
Share on other sites
Chedda Newbie

Chedda

Posted
Posted (edited)

Hello all,

 

once again with a max disk issue. ESXi VM with an Fusion-MPT 12GSAS SAS3224 PCI-Express HBA passthrough. The backplane holds up to 24 disks. I'm running the latest DSM and everything is fine up to 16 disks. I have modified my userconfig to support 36 disks mentioned previously in the thread but no such luck.

 

Spoiler

{
  "general": {
    "model": "DS3622xs+",
    "version": "7.2.0-64570",
    "smallfixnumber": "1",
    "zimghash": "e16af54ff9cc37361d7b338ef760c64d60d75139ab63e4efdf5caa320176561c",
    "rdhash": "79de7b884413e751a50dd9d0603e0030ad3b70b3449ade913afcf6862e548401",
    "usb_line": "withefi earlyprintk syno_hw_version=DS3622xs+ console=ttyS0,115200n8 netif_num=1 pid=0xa4a5 earlycon=uart8250,io,0x3f8,115200n8 syno_port_thaw=1 mac1=001132D08152 sn=20C0SQRLPHYLE vid=0x0525 elevator=elevator loglevel=15 HddHotplug=0 DiskIdxMap=10 syno_hdd_detect=0 vender_format_version=2 syno_hdd_powerup_seq=0 log_buf_len=32M root=/dev/md0 SataPortMap=1 ",
    "sata_line": "withefi earlyprintk syno_hw_version=DS3622xs+ console=ttyS0,115200n8 netif_num=1 pid=0xa4a5 earlycon=uart8250,io,0x3f8,115200n8 synoboot_satadom=1 syno_port_thaw=1 mac1=001132D08152 sn=20C0SQRLPHYLE vid=0x0525 elevator=elevator loglevel=15 HddHotplug=0 DiskIdxMap=10 syno_hdd_detect=0 vender_format_version=2 syno_hdd_powerup_seq=0 log_buf_len=32M root=/dev/md0 SataPortMap=1 ",
    "redpillmake": "prod",
    "friendautoupd": "true",
    "staticboot": "false",
    "hidesensitive": "false",
    "usrcfgver": "0.0.6"
  },
  "ipsettings": {
    "ipset": "",
    "ipaddr": "",
    "ipgw": "",
    "ipdns": "",
    "ipproxy": ""
  },
  "extra_cmdline": {
    "pid": "0xa4a5",
    "vid": "0x0525",
    "sn": "",
    "mac1": "xxxxxxxxxxx",
    "netif_num": "1",
    "SataPortMap": "1",
    "DiskIdxMap": "10"
  },
  "synoinfo": {
    "internalportcfg": "0xfffffffff",
    "maxdisks": "36",
    "support_bde_internal_10g": "no",
    "support_disk_compatibility": "no",
    "support_memory_compatibility": "no",
    "maxlanport": "8",
    "netif_seq": "0 1 2 3 4 5 6 7"
  },
  "ramdisk_copy": {}
}


I can see the disks in the array when loaded into tinycore OS and ssh'd in. So I know the disks are there but DSM can't see past 16. I have 19 disks in the chassis.

Edited by Chedda
Link to comment
Share on other sites
gericb Advanced Member

gericb

Posted
Posted
26 minutes ago, alirz1 said:

Is there any benefit of switching from a 918+ xpenology setup to SA6400? 

I think I can see, aside from the great news @Peter Suh  regarding the "Fast Transcoding" which at the moment, I assume to be HW, even though the system is built with an AMD by default, is that it's kernel should support 12 Cores and 24 Threads.  So depending on your chosen hardware platform to build your NAS, your 918+ might support less than what processor is actually capable of. 🤞🏼  It also supports up to 32GB of ECC (don't know if required) RAM.

 

https://kb.synology.com/en-nz/DSM/tutorial/What_kind_of_CPU_does_my_NAS_have

Link to comment
Share on other sites
alirz1 Super Member

alirz1

Posted
Posted

I don't think the model limits you to the actual number of cpus that be used by the system. Sure dsm might display all the CPU/cores but does that mean the rest are not being used?

My 918 is built on a 6core, 12 core CPU. TOP only shows me number of cpus to be 8. I already have HW transcoding.

So wondering if the move to SA6400 would be beneficial 

Link to comment
Share on other sites
gericb Advanced Member

gericb

Posted
Posted (edited)
4 hours ago, alirz1 said:

I don't think the model limits you to the actual number of cpus that be used by the system. Sure dsm might display all the CPU/cores but does that mean the rest are not being used?

My 918 is built on a 6core, 12 core CPU. TOP only shows me number of cpus to be 8. I already have HW transcoding.

So wondering if the move to SA6400 would be beneficial 

Well it's definitely been mentioned here by several people, that the DSM Kernel is hardcoded for the numbers of supported cores/threads, based on model.  Of course, maybe that is just. visual thing, in the Info Center, maybe in reality, it uses all there is available, this, I can't remember for sure.  I'm on a 920+ which is also build on a 6 Cores / 12 Threads CPU. The 920+ officially is stated to support 4 Cores / 4 Threads, per the link.   So if I am remembering the hardcoded support issue right, then we'd like both benefit to the SA6400.  Interestingly, my Info Center is showing 6 Cores / 8 Threads.  🤔 I too also already have perfectly running HW Transcoding.  Assuming there are no draw-backs from this model. 🤠 

Edited by gericb
Link to comment
Share on other sites
alirz1 Super Member

alirz1

Posted
Posted
4 minutes ago, gericb said:

Well it's definitely been mentioned here by several people, that the DSM Kernel is hardcoded for the numbers of supported cores/threads, based on model.  Of course, maybe that is just. visual thing, in the Info Center, maybe in reality, it uses all there is available, this, I can't remember for sure.  I'm on a 920+ which is also build on a 6 Cores / 12 Threads CPU. The 920+ officially is stated to support 4 Cores / 4 Threads, per the link.   So if I am remembering the hardcoded support issue right, then we'd like both benefit to the SA6400.  Interestingly, my Info Center is showing 6 Cores / 8 Threads.  🤔 I too also already have perfectly running HW Transcoding.  Assuming there are no draw-backs from this model. 🤠 

Yeh I’m wondering if there are less packages /apps available for the sa6400? Given its more enterprise nature?. If there aren’t any disadvantages I wouldn’t mind switching. It’s just a loader rebuild away otherwise.

Link to comment
Share on other sites
alirz1 Super Member

alirz1

Posted
Posted

So reading a bit more into this tells me that the SA6400 is an AMD based system and not Intel. So no Intel quick sync. But may have been added in by an extra add on or something? Seems like probably still best for me to stay on my 918 setup, where everything works and nothing needs fixing.

 

Link to comment
Share on other sites
Peter Suh Guru Master

Peter Suh

Posted
Posted
1 hour ago, alirz1 said:

So reading a bit more into this tells me that the SA6400 is an AMD based system and not Intel. So no Intel quick sync. But may have been added in by an extra add on or something? Seems like probably still best for me to stay on my 918 setup, where everything works and nothing needs fixing.

 

 

you're right. Synology's original specifications for SA6400 are based on AMD Epyc CPU. iGPU transcoding is only available on Intel CPUs.

 

You can see it as hacked to enable the use of Intel CPU in SA6400 and then transcode to Intel iGPU.

 

SA6400, the only model in XPE that supports kernel 5, is considered advantageous and suitable for new hardware of the 11th generation or higher.

 

There are continued reports of cases where 12th and 13th generation MOBOs, which did not work on XPE kernel 4 models, work on SA6400.

  • Thanks 1
Link to comment
Share on other sites
gericb Advanced Member

gericb

Posted
Posted
23 hours ago, Peter Suh said:

 

you're right. Synology's original specifications for SA6400 are based on AMD Epyc CPU. iGPU transcoding is only available on Intel CPUs.

 

You can see it as hacked to enable the use of Intel CPU in SA6400 and then transcode to Intel iGPU.

 

SA6400, the only model in XPE that supports kernel 5, is considered advantageous and suitable for new hardware of the 11th generation or higher.

 

There are continued reports of cases where 12th and 13th generation MOBOs, which did not work on XPE kernel 4 models, work on SA6400.

That being said... I've a great machine to test out this whole thing, a Dell XPS 8950 w/12th Generation Intel Core i7-12700K.  Throw in a couple of SATA drives, there are even 2 - M.2 2230/2280 slots for solid-state drives that could likely be used for testing caching. It's got a Killer E3100G Ethernet controller (10/100/1000/2500 Mbps) which may/may not be supported even though it's "Intel".

 

Do you know @Peter Suh if this controller is currently supported?

 

e3xw10x64.inf

 

PCI\VEN_10EC&DEV_3000&REV_03

PCI\VEN_10EC&DEV_3000&REV_06

PCI\VEN_10EC&DEV_3000&SUBSYS_30001A56&REV_06

PCI\VEN_10EC&DEV_3000&SUBSYS_384C17AA&REV_06

PCI\VEN_10EC&DEV_3000&SUBSYS_387817AA&REV_06

Link to comment
Share on other sites
Peter Suh Guru Master

Peter Suh

Posted
Posted
54 minutes ago, gericb said:

That being said... I've a great machine to test out this whole thing, a Dell XPS 8950 w/12th Generation Intel Core i7-12700K.  Throw in a couple of SATA drives, there are even 2 - M.2 2230/2280 slots for solid-state drives that could likely be used for testing caching. It's got a Killer E3100G Ethernet controller (10/100/1000/2500 Mbps) which may/may not be supported even though it's "Intel".

 

Do you know @Peter Suh if this controller is currently supported?

 

e3xw10x64.inf

 

PCI\VEN_10EC&DEV_3000&REV_03

PCI\VEN_10EC&DEV_3000&REV_06

PCI\VEN_10EC&DEV_3000&SUBSYS_30001A56&REV_06

PCI\VEN_10EC&DEV_3000&SUBSYS_384C17AA&REV_06

PCI\VEN_10EC&DEV_3000&SUBSYS_387817AA&REV_06

 

According to the information below, your NIC is Realtek r8125.
I don't think there will be any problems with support.
https://github.com/PeterSuh-Q3/tinycore-redpill/blob/main/modules.alias.4.json#L12053

Link to comment
Share on other sites
gericb Advanced Member

gericb

Posted
Posted
10 hours ago, Peter Suh said:

 

According to the information below, your NIC is Realtek r8125.
I don't think there will be any problems with support.
https://github.com/PeterSuh-Q3/tinycore-redpill/blob/main/modules.alias.4.json#L12053

Really?  This is surprising to hear, given that Rivet Networks/Killer was acquired by Intel back in 2020.  It started out as Bigfoot Networks, then was acquired by Qualcomm in 2011, the got spun out to form Rivet Networks.  Qualcomm provided some great ASIC building capabilities, to the product line while they had it.  Rivet then later was known to be partnering with Intel and Realtek on various parts offering a standard version under the normal brand or the Killer version with additional network detection and shaping capabilities.  I could be missing something, but it would appear all the modern drivers come from Intel.

 

I'm wondering if my previous provided Hardware/Compatible ID (not captured real-time from a running OS) might therefore, be incorrect.   In a couple of references, I am reading this might be based on the I225v chipset.  Given the acquisition path Rivet Networks went though, I shouldn't be surprised if somehow Intel acquired a Realtek designed part.

 

Are you able to glean any info from the current driver download from Intel?

 

https://www.intel.com/content/www/us/en/download/19779/intel-killer-performance-suite.html

 

Thank You

Link to comment
Share on other sites
Peter Suh Guru Master

Peter Suh

Posted
Posted
Really?  This is surprising to hear, given that Rivet Networks/Killer was acquired by Intel back in 2020.  It started out as Bigfoot Networks, then was acquired by Qualcomm in 2011, the got spun out to form Rivet Networks.  Qualcomm provided some great ASIC building capabilities, to the product line while they had it.  Rivet then later was known to be partnering with Intel and Realtek on various parts offering a standard version under the normal brand or the Killer version with additional network detection and shaping capabilities.  I could be missing something, but it would appear all the modern drivers come from Intel.
 
I'm wondering if my previous provided Hardware/Compatible ID (not captured real-time from a running OS) might therefore, be incorrect.   In a couple of references, I am reading this might be based on the I225v chipset.  Given the acquisition path Rivet Networks went though, I shouldn't be surprised if somehow Intel acquired a Realtek designed part.
 
Are you able to glean any info from the current driver download from Intel?
 
https://www.intel.com/content/www/us/en/download/19779/intel-killer-performance-suite.html
 
Thank You


Is this enough evidence?

https://devicehunt.com/view/type/pci/vendor/10EC/

https://linux-hardware.org/index.php?id=pci:10ec-3000-1462-7c34


Sent from my iPhone using Tapatalk
Link to comment
Share on other sites
gericb Advanced Member

gericb

Posted
Posted
3 hours ago, Peter Suh said:

 


Is this enough evidence?

https://devicehunt.com/view/type/pci/vendor/10EC/

https://linux-hardware.org/index.php?id=pci:10ec-3000-1462-7c34


Sent from my iPhone using Tapatalk

 

Sure, based on the 10EC, I would agree that it's obvious.  Given the whole merger path and development partnerships that Rivet had, it then begs the question, who's maintaining the driver development, Intel or Realtek.  Is Intel really relying on Realtek to regularly release driver updates, for a product line they own...messy to be sure.

 

Latest release combo driver pack from Intel, which includes the E3100G is 10.10.2023  Realtek on the other hand is 11.28.23  Sadly, the package was no help either.

 

Thanks for your detective feedback!

IMG_1011.jpg

Link to comment
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.

×
 Share
Go to topic listing
×
×
  • Create New...