NEW DSM 5.1-5004 AVAILABLE !!

[polcomp]

Nice! Great news!

we keep fingers crossed.

if you need some testers, let us know

[Dfds]

Happy to help test on either ESXi or N54L bare metal if needed.

[bmx30th]

System ready to test on AM1 platform

[Schmill]

AM1 ?

[derwoodbones]

I run a simple Pittance of a NAS but I would love to test when avail. System Dell Optiplex 755 4Gb Ram Wd Red WD40EFRX 4 Tb

[bmx30th]

@Schmill:

ASRock AM1B-ITX + AMD Athlon 5350 Kabini Quad-Core 2.05GHz Socket AM1

[HommiePeter]

Thank you all for the offers for testing, but the build first needs to boot correctly prior to make ik general available for testing on different hardware.

 

In that respects the test yesterday evening where a bit disappointing on my

a) ATOM 330N XPENOLOGY NAS the system booted but had no support for network and the keyboard did not work correctly

b) ICore 3 XPENOLOGY NAS the system only booted after disabling my USB 3.0 in the bios but after presenting the Diskstation login promt, it shows (after a couple of seconds) is say Shutdown System.....

 

Conclusion is that there is still some investigation to be done. Will look further this weekend.

 

Greetings

[jagwaugh]

@HommiePeter: I just checked sourceforge, they have now posted the 5.1 gpl and apparently changed the 5.1 toolchain. Perhaps the problems you had were related to something wrong in the 1st toolchain they posted?

 

Andrew

[HommiePeter]

@HommiePeter: I just checked sourceforge, they have now posted the 5.1 gpl and apparently changed the 5.1 toolchain. Perhaps the problems you had were related to something wrong in the 1st toolchain they posted?

 

Andrew

 

Andrew Thanks for the update i start will start downloading the new version and rebuild a new image based on the new versions.

 

Keep you posted....

 

Greetings

[Poechi]

-

Edited July 10, 2015 by Guest

[fatez]

any news?

[HommiePeter]

Sorry no positive news yet. Have been cooking some images but no success jet. Have currently a new kernel in the oven (according to the script from nanoboot).

 

Have also been looking at the synobios.ko but don't know here and what to change with regards the SetMicropId(). Text offsets do not seem to match..... puzzling

(any one suggestions ...)

 

Currently working with the patched version for branche 4458

 

any news?

[Jman420]

Sorry no positive news yet. Have been cooking some images but no success jet. Have currently a new kernel in the oven (according to the script from nanoboot).

 

Have also been looking at the synobios.ko but don't know here and what to change with regards the SetMicropId(). Text offsets do not seem to match..... puzzling

(any one suggestions ...)

 

Currently working with the patched version for branche 4458

 

Looks like Synology has changed the logic in SetMicropId() so the offsets have moved and the old byte signature is invalid. I'm not sure which register we need to get the Model Id into in order for it to be returned correctly. I don't have much experience or success with reverse engineering, but I've been looking at the objdump for it. Gonna experiment with some new patches later today.

 

A couple of pages back I posted a link to another thread with some details on what needs to be patched. Its probably a good starting point, but will need to be modified for the new file.

[HommiePeter]

Sorry no positive news yet. Have been cooking some images but no success jet. Have currently a new kernel in the oven (according to the script from nanoboot).

 

Have also been looking at the synobios.ko but don't know here and what to change with regards the SetMicropId(). Text offsets do not seem to match..... puzzling

(any one suggestions ...)

 

Currently working with the patched version for branche 4458

 

Looks like Synology has changed the logic in SetMicropId() so the offsets have moved and the old byte signature is invalid. I'm not sure which register we need to get the Model Id into in order for it to be returned correctly. I don't have much experience or success with reverse engineering, but I've been looking at the objdump for it. Gonna experiment with some new patches later today.

 

A couple of pages back I posted a link to another thread with some details on what needs to be patched. Its probably a good starting point, but will need to be modified for the new file.

 

Dear Jman240

 

i have also been looking at and comparing the synobios,ko exports 5.1-5004, 5.0-4458 (patched) and 4.3-3872(patched) still have not found any logic in which microcode needs to be chanced to trigger the right return values. Will look at your previous post. Would be good to share thoughts.

 

Greetings

[jagwaugh]

I am already in waaaay over my head. I am looking at the synobios.h file, There I find a typedef enum section which lists the values the bios accepts/expects including:

 

MICROP_ID_3611xs = 0x42, /* 'B' 3612xs is the same*/

 

and, at the bottom of this section:

 

MICROP_ID_UNKNOW = 0xFF,

 

so this has me wondering.... what if I change the

 

MICROP_ID_UNKNOW = 0xFF,

to

MICROP_ID_3611xs = 0xFF,

 

Would this mean that all machines that do not return a valid MICROP_ID would appear to be 3611xs (which is the same as 3612xs)?

 

Does that make sense? As far as I understand it synobios.ko is built from synobios.h, no?

 

Andrew

[Diverge]

I have no experience with this, but it might be a better idea to try to build what worked already (before 5.1), so you have a better understanding of what gnoboot/nanoboot did, and also have a good baseline. Once you get that working, then move on to figuring out 5.1. Again, I have no experience with building kernels. Just a suggestion based on troublshooting 101

[Vortex]

Here is the patched 5004 synobios. If it helps, but I doubt it... Anyway that should move you off the ground.

[Jman420]

Here is the patched 5004 synobios. If it helps, but I doubt it... Anyway that should move you off the ground.

 

Thanks Vortex. Much appreciated. It definitely puts us a step closer to getting 5.1 to work. I'm going to crack it open when I get back from lunch.

[djelusion]

Here is the patched 5004 synobios. If it helps, but I doubt it... Anyway that should move you off the ground.

 

me love you long time . too bad i dont have any extra media smart servers or else if you was in so cal i could literally give one at my expense if you was able to develop for that.

[jagwaugh]

Here is the patched 5004 synobios. If it helps, but I doubt it... Anyway that should move you off the ground.

 

 

My thanks as well. So far I am resisting the urge to PM you with so many questions about compiling the Kernel that you would be faster to just do it yourself.... so far.

 

Andrew

[HommiePeter]

Hi guys

 

i have now been compiling images with the newly published toolchains and branche code according to the nano boot script

 

https://github.com/sancome/DSM-5.0-4458_dsgpl-4418

 

I have also used the new patched synobios.ko that vortex published yesterday, but i still do not have a fully booting kernel.

 

The last message it shows is "Booting the kernel" it interacts with the available harddisks and than stops.....

 

Booting the same disks with an earlier working nano boot USB sticks also shows nog logging records in /var/log .......

 

Any suggestions ?

 

 

Greetings

[jagwaugh]

HommiePeter

 

A couple of questions:

 

1) are you using the two scripts in Sancomes repo? If yes, did you leave them as is, and modify/rename/resave the toolchain file to only include the /linux-3.x folder?

 

2) Does the 01 script run without any error messages, particularily in the sections where patching is done? The script is written for the DSM50 version. Did you modify the patch files and or the script? (This is where I am currently getting hung up)

 

3) What selections did you change in menuconfig? I was hoping BROMOLOW and devices>general>create DEVTMPFS and mount DEVTMPFS would be enough to get the device detection working properly again.

 

I am working on setting up and documenting creation and configuration of a Ubuntu VM, trying to write the documentation "forward looking" in the sense that it covers what to do when DSM6.0 comes out i.e.

download the toolchain, edit the script file to change the name of the tarball, modify the patch file in folder X changing blah blah to foo bar.

 

Unfortunately, it has been quite a while since I worked on this kind of stuff (think DEC PDP series and Motorola 4 bit assembler) - I recognize the rhythm, but the lyrics and hairstyles are largely incomprehensible to me.

 

Andrew

[HommiePeter]

Dear Andrew

 

i did the following

 

1) i extracted the the toolchain tar file and copied the /linux-3.x folder to the workspace folder that is needed by the Sancomes rep

 

2) i have adjusted the the 01-unzip-linux-3.x.sh script to work with the fact that a ./linux-3.x folder is already present. I there for extend the else clause of the second if statement with

else
       echo "\033[41;37m The linux-3.x folder already exists. patching existing \033[0m"
       cp -p ./xpenology/patches-linux-3.x/linux-3.x-xpenology-4418.patch ./workspace/
       cd workspace
       patch -p0 < ./linux-3.x-xpenology-4418.patch
       rm -f linux-3.x-xpenology-4418.patch
       cp -p ../xpenology/.config ./linux-3.x/
       cd ../

 

3) Executed than steps a (run ./01-unzip-linux-3.x.sh) and make commands (and not changing any settings in the menu config because the config settings are part of the sancomes rep so did not want to mess with that yet)

cd ./workspace/linux-3.x
make ARCH=x86_64 CROSS_COMPILE=../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- menuconfig 
make ARCH=x86_64 CROSS_COMPILE=../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- modules
make ARCH=x86_64 CROSS_COMPILE=../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu- bzImage 

 

4) I copied and rename the synobios.ko for branche 5004 of DSM 5.1 (thanks to vortex) to the folder /xpenology/synobios/synbios-synology-5.1-5004.ko

 

5) i have adjusted the 02-build-img-file.sh to include the synobios (patched 5004) file.

 

6) Started to build the first image (became root and executed sudo su -) before starting the script 02-build-img-file.sh

The script completed successfully although the patching gave somethings an error

  patching file rd-orig/etc/rc
  Hunk #1 FAILED at 479.
  Hunk #2 FAILED at 542.
  Hunk #3 FAILED at 561.
  Hunk #4 FAILED at 612.
  Hunk #5 FAILED at 636.
  Hunk #6 FAILED at 673.
  6 out of 6 hunks FAILED -- saving rejects to file rd-orig/etc/rc.rej
  patching file rd-orig/etc/rc.network
  Hunk #1 succeeded at 76 (offset 3 lines).
  Hunk #2 succeeded at 90 (offset 3 lines).
  Hunk #3 succeeded at 115 (offset 3 lines).
  Hunk #4 succeeded at 313 (offset 3 lines).
  Hunk #5 FAILED at 962.
  1 out of 5 hunks FAILED -- saving rejects to file rd-orig/etc/rc.network.rej
  patching file rd-orig/etc/rc.subr
  patching file rd-orig/etc/rc.volume
  patching file rd-orig/linuxrc.syno
  Hunk #1 succeeded at 1 with fuzz 2.
  Hunk #2 FAILED at 33.
  Hunk #3 succeeded at 48 (offset 2 lines).
  Hunk #4 FAILED at 166.
  Hunk #5 FAILED at 276.
  Hunk #6 FAILED at 316.
  Hunk #7 FAILED at 343.
  Hunk #8 succeeded at 318 (offset -50 lines).
  Hunk #9 succeeded at 353 (offset -46 lines).
  Hunk #10 FAILED at 410.
  6 out of 10 hunks FAILED -- saving rejects to file rd-orig/linuxrc.syno.rej

 

Burned the image on my iMac to an USB disk (according explenation in the WHO TO section of this site) and booted the image with the results mentions earlier

 

Because i linked the outcome of the first boot result to the errors during patching in the build image script. I therefor simply deleted (put an # in front of it) the patching rules in the build image script. And builded a second image and burned it to the USB stick again but the outcome of the result was the same

 

Also adding vid=0x0EA0 pid=0x2169 in the kernel commands in grub.conf and menu.lst did not change the outcome of the boot process. So my conclusion so far is that the patching errors are not causing the current boot result (not saying that the need to be corrected of curse). Strangely the orginale scrip op sancome contained an error in coping the synobios the wrong (non existing) file and the the kernel booted completely till the login prompt...... will reinvestigate further but tips and suggetions are of course welcome

 

Greetings

 

I know its al a bit straight forward but you got to start somewhere.

[Jman420]

We need new patches for the linux-3.x source files. So far I've been going through by hand to verify all the diffs in the patch file. I've already come across changes to the libata-core.c file which would completely break the patches that we have.

 

Old Lines 7414-7421

int (*funcSYNODeepSleepEvent)(unsigned int, unsigned int) = NULL;
EXPORT_SYMBOL(funcSYNODeepSleepEvent);

#ifdef MY_DEF_HERE
int (*funcSYNOSendEboxRefreshEvent)(int portIndex) = NULL;
EXPORT_SYMBOL(funcSYNOSendEboxRefreshEvent);
#endif

 

New Lines 7414-7421:

EXPORT_SYMBOL(funcSYNODeepSleepEvent);
int (*funcSYNODiskRetryReport)(unsigned int, unsigned int) = NULL;
EXPORT_SYMBOL(funcSYNODiskRetryReport);

#ifdef SYNO_SATA_EBOX_REFRESH
int (*funcSYNOSendEboxRefreshEvent)(int portIndex) = NULL;
EXPORT_SYMBOL(funcSYNOSendEboxRefreshEvent);

 

Patch for Lines 7414-7421:

 int (*funcSYNODeepSleepEvent)(unsigned int, unsigned int) = NULL;
EXPORT_SYMBOL(funcSYNODeepSleepEvent);

-#ifdef MY_DEF_HERE
+#if (defined(MY_DEF_HERE) || defined(XPENOLOGY))
int (*funcSYNOSendEboxRefreshEvent)(int portIndex) = NULL;
EXPORT_SYMBOL(funcSYNOSendEboxRefreshEvent);
#endif

 

Going to keep digging. Will post updates as I find anything to aid anyone else's efforts.

[Poechi]

-

Edited July 10, 2015 by Guest