Jump to content
XPEnology Community

TinyCore RedPill loader (TCRP) - Development release 0.9

pocopico

By pocopico
in Developer Discussion Room

 Share

Recommended Posts

pocopico Guru Master

pocopico

Posted
  • Author
Posted (edited)
10 hours ago, Peter Suh said:


I increased the size of the 3rd partition of the USB stick to hold more pat files. Will this part be a problem?


Sent from my iPhone using Tapatalk

 

Well, thats not a problem but only if you change the third partition size.

Edited by pocopico
Link to comment
Share on other sites
pocopico Guru Master

pocopico

Posted
  • Author
Posted (edited)
39 minutes ago, Dreadnought said:

Is it now possible with the TCRP friend function to bring back the DSM native update function?

 

What fabio does and makes sence, is that he updates the DSM rss url to not point to example.com but to one of his repo file that gets the list of valid updates so that we can centraly somehow control the updates. I'm planning to do the same for TCRP. 

Edited by pocopico
  • Like 2
  • Thanks 2
Link to comment
Share on other sites
pocopico Guru Master

pocopico

Posted
  • Author
Posted

Well @Dreadnought it looks like there are some good news regarding the "automatic updates" if you want to try please add the following lines on your user_config.json on the synoinfo section :

  

 "rss_server": "https://raw.githubusercontent.com/pocopico/redpill-load/develop/rss.xml",
 "rss_server_ssl": "https://raw.githubusercontent.com/pocopico/redpill-load/develop/rss.xml",
 "rss_server_v2": "https://raw.githubusercontent.com/pocopico/redpill-load/develop/rss.json",
 "small_info_path": "https://example.com/null",
 "security_version_server": "https://example.com/smallupdate"

 

please verify your json syntax with jq . user_config.json before building a loader.

 

*** EDIT : 

 

You can always use @fbelavenuto repo as well 

  

"rss_server": "https://raw.githubusercontent.com/fbelavenuto/arpl/main/rss.xml",
"rss_server_ssl": "https://raw.githubusercontent.com/fbelavenuto/arpl/main/rss.xml",
"rss_server_v2": "https://raw.githubusercontent.com/fbelavenuto/arpl/main/rss.json",
"small_info_path": "https://example.com/null",
"security_version_server": "https://example.com/smallupdate"

 

**** EDIT2 : 

 

Just installed a physical DVA1622 and went from 42661 to 42962 by DSM update panel.

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

Peter Suh

Posted
Posted (edited)

@pocopico
The error log below is actually the one I checked through the serial port of my XPE.
NVMe cache was applied by adjusting the hexa value of libsynonvme.so.1 file of DS1621xs+.
Up to 7.1.0-42661, the cache was used without any problems.
After building with version 7.1.1-42962 of the TCRP friend loader and using the loader, the serial port repeats the following NVMe error log, does not receive an IP address and cannot do anything.
 

image.thumb.png.87e255f971f1d190660681d6351c3952.png

 

Reluctantly, I booted into the first USB TCRP menu prepared in the GNU grub menu.
The loader boot is OK and reports NVMe cache issues as shown below.
Cache is the problem
TCRP is just handing over
It doesn't seem like TCRP friends.
Any solution?

 

image.thumb.png.de758702e99360115a62e7812065ed13.png

Edited by Peter Suh
Link to comment
Share on other sites
pocopico Guru Master

pocopico

Posted
  • Author
Posted
3 minutes ago, Peter Suh said:

@pocopico
The error log below is the log that is checked through the serial port in my actual XPE.
The NVMe cache is adjusted by adjusting the hexa value of the libsynonvme.so.1 file of DS1621xs+.
This is the cache that was used without any problems until 7.1.0-42661.
7.1.1-42962 If you use the loader after building with friend loader, the following NVMe error log is repeated on the serial port, and you cannot do anything without receiving an IP address.

 

image.thumb.png.87e255f971f1d190660681d6351c3952.png


Inevitably, I booted to the first USB TCRP menu that was prepared in the GNU grub menu.
The loader boot is fine and reports a problem with the NVMe cache as shown below.
Although the cache is problematic,
TCRP is just handing over
TCRP friends don't seem to be.
Any solution?

 

image.thumb.png.de758702e99360115a62e7812065ed13.png

 

What is the patching methodology for libsynonvme.so.1 ?

Link to comment
Share on other sites
Peter Suh Guru Master

Peter Suh

Posted
Posted (edited)
13 minutes ago, pocopico said:

 

Yes i've read that at some point, can you please describe a bit more ? 

 

In the past, when applying the cache in ds918+, it was the way to edit libsynonvme.so.1 and use it, but it is not easy to find the guide on the forum.
In DS3622xs+, I just followed the guide below, which is an easier way, and it worked.
The same Broadwellnk platform
I thought the DS1621xs+ would work the same, but it didn't.

 

 

 

So I was forced to edit the old way libsynonvme.so.1 .
Editing was done by dolbycat himself and only the files were given to me.
He is also using the same model and cache as me,
The pci information is the same, so it was used as it is.

 

And at the same time, the following processing is also being processed every time DSM is booted by the scheduler.
sed -i 's/00:03.0/00:1d.0/g' /etc.defaults/extensionPorts

Edited by Peter Suh
Link to comment
Share on other sites
pocopico Guru Master

pocopico

Posted
  • Author
Posted
3 minutes ago, Peter Suh said:

 

In the past, when applying the cache in ds918+, it was the way to edit libsynonvme.so.1 and use it, but it is not easy to find the guide on the forum.
In DS3622xs+, I just followed the guide below, which is an easier way, and it worked.
The same Broadwellnk platform
I thought the DS1621xs+ would work the same, but it didn't.

 

 

 

So I was forced to edit the old way libsynonvme.so.1 .
Editing was done by dolbycat himself and only the files were given to me.
He is also using the same model and cache as me,
The pci information is the same, so it was used as it is.

 

do you remember which files ? 

Link to comment
Share on other sites
Peter Suh Guru Master

Peter Suh

Posted
Posted
11 hours ago, pocopico said:

 

do you remember which files ? 

 

Exactly how I applied it as directed by @dolbycat below.

The setting method is to modify the address of nvme using WinHex in the libsynonvme.so.1 file in the /lib64 folder.


< How to find nvme address > 

udevadm info /dev/nvme0n1
udevadm info /dev/nvme1n1


< Note >
I attach the libsynonvme.so.1 file modified for my system.
After modifying it according to your own nvme address, follow the steps below. 

sudo cp libsynonvme.so.1 /lib64/libsynonvme.so.1
sudo chmod 644 /lib64/libsynonvme.so.1
sudo reboot

 

------------------------------------

  

admin2@NAS4:~$ udevadm info /dev/nvme0n1
P: /devices/pci0000:00/0000:00:1d.0/0000:03:00.0/nvme/nvme0/nvme0n1
N: nvme0n1
E: DEVNAME=/dev/nvme0n1
E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/0000:03:00.0/nvme/nvme0/nvme0n1
E: DEVTYPE=disk
E: MAJOR=259
E: MINOR=0
E: PHYSDEVBUS=pci
E: PHYSDEVDRIVER=nvme
E: PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.0/0000:03:00.0
E: SUBSYSTEM=block
E: SYNO_ATTR_SERIAL=
E: SYNO_DEV_DISKPORTTYPE=CACHE
E: SYNO_INFO_PLATFORM_NAME=broadwellnk
E: SYNO_KERNEL_VERSION=4.4
E: SYNO_SUPPORT_USB_PRINTER=yes
E: SYNO_SUPPORT_XA=no
E: TAGS=:systemd:
E: USEC_INITIALIZED=117104

 

Link to comment
Share on other sites
pocopico Guru Master

pocopico

Posted
  • Author
Posted
8 hours ago, Peter Suh said:

 

Exactly how I applied it as directed by @dolbycat below.

The setting method is to modify the address of nvme using WinHex in the libsynonvme.so.1 file in the /lib64 folder.


< How to find nvme address >
udevadm info /dev/nvme0n1
udevadm info /dev/nvme1n1


< Note >
I attach the libsynonvme.so.1 file modified for my system.
After modifying it according to your own nvme address, follow the steps below.


sudo cp libsynonvme.so.1 /lib64/libsynonvme.so.1
sudo chmod 644 /lib64/libsynonvme.so.1
sudo reboot

 

------------------------------------

 

admin2@NAS4:~$ udevadm info /dev/nvme0n1
P: /devices/pci0000:00/0000:00:1d.0/0000:03:00.0/nvme/nvme0/nvme0n1
N: nvme0n1
E: DEVNAME=/dev/nvme0n1
E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/0000:03:00.0/nvme/nvme0/nvme0n1
E: DEVTYPE=disk
E: MAJOR=259
E: MINOR=0
E: PHYSDEVBUS=pci
E: PHYSDEVDRIVER=nvme
E: PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.0/0000:03:00.0
E: SUBSYSTEM=block
E: SYNO_ATTR_SERIAL=
E: SYNO_DEV_DISKPORTTYPE=CACHE
E: SYNO_INFO_PLATFORM_NAME=broadwellnk
E: SYNO_KERNEL_VERSION=4.4
E: SYNO_SUPPORT_USB_PRINTER=yes
E: SYNO_SUPPORT_XA=no
E: TAGS=:systemd:
E: USEC_INITIALIZED=117104

 

I see, but libsynonvme.so.1 is not static at all. it will be overwritten after every update, how do you manage that ? 

 

 

can you please PM me the modified file libsynonvme.so.1 file and if you remember the original version ? I want to check it. 

 

Link to comment
Share on other sites
Peter Suh Guru Master

Peter Suh

Posted
Posted
8 hours ago, pocopico said:

 

I see, but libsynonvme.so.1 is not static at all. it will be overwritten after every update, how do you manage that ? 

 

 

I know that part too.
So after updating DSM to 7.1.1-42962 I copied the files again.
Oops...
With libsynonvme.so.1 in 7.1.0-42661
The libsynonvme.so.1 file of 7.1.1-42962 seems to be different.
I used the files from 7.1.0-42661 for 7.1.1-42962.
restore the file back to original
Let's edit the libsynonvme.so.1 file in 7.1.1-42962 again.
It's my first time doing this, so it might take some time.
I will report back the results from TCRP and TCRP friends.

Link to comment
Share on other sites
Peter Suh Guru Master

Peter Suh

Posted
Posted

@pocopico
exactly this time
After copying the original libsynonvme.so.1 file of 7.1.1-42962 to Mac
Edited as below through Hex Fiend app.

 

image.thumb.png.c6d6f6feccbb3fdcc6b23d484754c1a5.png


As per Dolbycat's previous guide
After copying it back to the /lib64 directory, TCRP has now confirmed that the cache works normally.

 

image.thumb.png.3b36b7035e693ce690f0013a37a6530d.png

 

 

However, the TCRP friend still does not recognize the NMVe cache.

 

image.thumb.png.7e3a743eca67c691fca891e65c2e51a7.png

Link to comment
Share on other sites
Dreadnought Super Member

Dreadnought

Posted
Posted
13 hours ago, pocopico said:

Well @Dreadnought it looks like there are some good news regarding the "automatic updates" if you want to try please add the following lines on your user_config.json on the synoinfo section :

 

  

 "rss_server": "https://raw.githubusercontent.com/pocopico/redpill-load/develop/rss.xml",
 "rss_server_ssl": "https://raw.githubusercontent.com/pocopico/redpill-load/develop/rss.xml",
 "rss_server_v2": "https://raw.githubusercontent.com/pocopico/redpill-load/develop/rss.json",
 "small_info_path": "https://example.com/null",
 "security_version_server": "https://example.com/smallupdate"

  

please verify your json syntax with jq . user_config.json before building a loader.

 

 

*** EDIT : 

 

You can always use @fbelavenuto repo as well 

  

"rss_server": "https://raw.githubusercontent.com/fbelavenuto/arpl/main/rss.xml",
"rss_server_ssl": "https://raw.githubusercontent.com/fbelavenuto/arpl/main/rss.xml",
"rss_server_v2": "https://raw.githubusercontent.com/fbelavenuto/arpl/main/rss.json",
"small_info_path": "https://example.com/null",
"security_version_server": "https://example.com/smallupdate"

**** EDIT2 : 

 

Just installed a physical DVA1622 and went from 42661 to 42962 by DSM update panel.

I tried your links from the redpill-load repo.

It's working great!

Direct at the first installation wizzard I am now able to install the latest DSM version.

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

pocopico

Posted
  • Author
Posted
2 hours ago, Peter Suh said:

@pocopico
exactly this time
After copying the original libsynonvme.so.1 file of 7.1.1-42962 to Mac
Edited as below through Hex Fiend app.

 

image.thumb.png.c6d6f6feccbb3fdcc6b23d484754c1a5.png


As per Dolbycat's previous guide
After copying it back to the /lib64 directory, TCRP has now confirmed that the cache works normally.

 

image.thumb.png.3b36b7035e693ce690f0013a37a6530d.png

 

 

However, the TCRP friend still does not recognize the NMVe cache.

 

image.thumb.png.7e3a743eca67c691fca891e65c2e51a7.png

 

What can i say ? If you dont share even with a PM the process i cannot help.

Link to comment
Share on other sites
pocopico Guru Master

pocopico

Posted
  • Author
Posted
6 hours ago, Dreadnought said:

 

Could there a problem when I first build the Loader the normal way with:

./rploader.sh build broadwellnk-7.0.1-42218 manual

and after that I executed: ./rploader.sh bringfriends ?

 

I've test the bringfriend process numerous times from scratch but, every case is a bit different. Even a missing user_config.json value can make a difference but should not have this effect. Im glad it worked at the end though

Link to comment
Share on other sites
Dreadnought Super Member

Dreadnought

Posted
Posted
26 minutes ago, pocopico said:

 

I've test the bringfriend process numerous times from scratch but, every case is a bit different. Even a missing user_config.json value can make a difference but should not have this effect. Im glad it worked at the end though

 

Now I am do the following:

  • add my extensions with ./rploader.sh ext broadwellnk-7.0.1-42218 add XY
  • ./rploader.sh build broadwellnk-7.0.1-42218 withfriend

this work directly without the need of an additional call of ./rploader.sh bringfriend

 

before I did the following:

  • add my extensions with ./rploader.sh ext broadwellnk-7.0.1-42218 add XY
  • ./rploader.sh build broadwellnk-7.0.1-42218 manuel
  • ./rploader.sh bringfriend
  • ./rploader.sh bringfriend (second time to get the correct boot loader entry)
Link to comment
Share on other sites
Peter Suh Guru Master

Peter Suh

Posted
Posted
3 hours ago, pocopico said:

 

What can i say ? If you dont share even with a PM the process i cannot help.

 

Regarding the process you're talking about, there's one thing I'm missing.

Perhaps the problem is with the m shell-only model called DS1621xs+.

Please check with the PM about the model selection related to the TCRP friend's NVMe cache test.

Link to comment
Share on other sites
  • Polanskiman changed the title to TinyCore RedPill loader (TCRP) - Development release 0.9

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