Faulty DS418

Currently reading
Faulty DS418

Well, that's some progress at least, good job fellas!
Hi Ted you ok mate? Yes, well I said from day one the flash was corrupt, I tried my best to create one from an older DSM by positioning the three files from the extracted DSM in exactly the same Hex decimal locations as the original had them, using a hex editor, I wasn't sure it would work as I don't know enough about this side of things, I guess there is more to it than that, probably has to be assembled in such a way that check sums are correct or something, I just don't know. I am very interested to hear now how Ray is going to tell me how to turn it back into a 418, The 218 by the way is exactly the same machine with the difference being it has only two drives, the 418 four. so I guess the disk controler is different with different drivers, but this flash proved the pcb is ok and all we need it the correct flash for the 418
 
Hi Ray, I don't know if you missed my post, it's on page three saying my NAS work perfectly with the 218 file, I uploaded a log there too and asked how do I now make it back to 418 please? Bob
 
Well I don't know where Ray has gone, but if anyone is interested the NAS is fully working now and back in service.
First of all my thanks go out to Ray because the 218 flash file he gave me proved that it was just the flash that was corrupt and there were no other problems.
So with Ray abandoning me what did I do. The only way this was going to work was with a new flash file, and it had to be the correct one for the 418 as it would not recognize any disks were present with the 218 flash in it. I haven't got a linux PC but I had found some instructions as to how to build the flash file on a Linux pc, I don't know who wrote them, but whoever you are thank you very much. His instructions were for a much older model and I could see by looking at the original flash file read out of the chip that his Offsets were different to mine, So I took his instructions and inserted my own offsets,
How did I get around not having a Linux PC, well I have got a VU DUO+ Satellite receiver which is basically a Linux computer, so I rooted into it with Putty, copied the files from the PAT file to the User/Home directory and worked in there, gave the commands as listed below and constructed the file, including the vender.img which I would edit later.

when it comes to the very complicated instructions on how to add your serial number and Mac address, including having to compile a program written in "C" I just ignored that and when I had created the file I edited it with a hex editor and copied the original from the vendor offset to the end of the file and pasted it into the new one, saved the file, loaded it into flash and away she went.
I have included some pictures, the flash rom is the very small chip to the top right of the processors heat sink, you can see how I was working on it with the chassis out of the case and you can see on the monitor it is doing a DSM update and then you can see the Stat box showing it up and working. It's been an experience I can tell you.
Here are the instructions in case anyone needs to do it

You need to extract the three files from the version of DSM you are using for the 418, this will probably work with other models too, the files are
  • uboot_DS*******.bin: u-boot
  • zImage: kernel
  • rd.bin: initrd
The size of the flash chip on the DS418 is 64Mbit, so we need an 8MB large image. We first recall the flash layout to get the right offsets:

DS418
00000000:00100000 : "RedBoot"
00100000:003f0000 : "zImage"
003f0000:007ef000 : "rd.gz"
007ef000:007ff000 : "vendor"

Put those files in the directory you are working from then do all the following
Create an empty flash image of 8 MB size filled with zeros: $
dd if=/dev/zero of=flash.rom bs=1024 count=8192
Copy the uboot image to the beginning of the file not truncating the rest: $
dd if=uboot_DS418.bin of=flash.rom conv=notrunc
Now copy the kernel image at the right offset. dd cannot directly use hexadecimal values.These have to be converted by the shell:$
dd if=zImage of=flash.rom bs=1 seek=$((0x100000)) conv=notrunc
Next is the initrd image: $
dd if=rd.bin of=flash.rom bs=1 seek=$((0x3f0000)) conv=notrunc
Now insert the vender data into the flash image:$
dd if=vender.img of=flash.rom bs=1 seek=$((0x7ef000))

Now notice that I have the adding of the vender img file at the end of the list, this was because after creating the file with no information in it as described below, I was just going to delete that area from the file and copy and paste the information from the original flash read from the chip, I only used it as a place holder, if you haven't got it or it's too corrupt to read you will have to do as described now.

Now comes the vender partition. This is not provided in the download of the firmaware as this is unique to your DiskStation and written only once in the factory. It contains the serial number and the MAC address, which can be found on the sticker at the back of the case. The DiskStation will boot without the vender information, but without the MAC address it will assign a random MAC at each boot. This will annoy DHCP servers as they serve a new IP on every reboot. Automatic firmware updates and the DS Assistant rely on the MAC address as well.

For the next step you will need the serial number and original MAC from the sticker and a hex editor (I use hexeditor). First we create an empty 64 kB vender partition: $ dd if=/dev/zero of=vender.img bs=1024 count=64 The MAC address is stored in the first 6 bytes and the 7th byte contains a checksum. The checksum is calculated by taking the sum of the bytes in the MAC address. The following C program can be used to calculate the checksum. The checksum is stored in an unsigned char, which is not large enough to store the total. It will flow over give the rest, which is larger than multiples of 256 bytes:
#include <stdio.h> int main() { unsigned char chksum = 0; int i = 0; unsigned char rgAddr[6] = {0x00, 0x11, 0x32, 0xFF, 0xFF, 0xFF}; for (i = 0; i < 6; i++) { chksum += rgAddr; } printf("Checksum: 0x%X\n", chksum); return 0; } The first three bytes are the Synology part, the last three bytes needs to be changed to your MAC address. Compile with $ gcc -o checksum mac_checksum.c This MAC example 00:11:32:FF:FF:FF will give a checksum of 0x40.

Insert these bytes into the image: $ hexeditor -b vender.img 00000000 00 11 32 FF FF FF 40 The serial number is written like this. For example:
SN=1350LAN009999,CHK=999
00000020 53 4e 3d 31 33 35 30 4c 41 4e 30 30 31 39 39 39 00000030 2c 43 48 4b 3d 39 39 39 Use an ascii to hex converter to generate the hex values. The checksum is calculated on next reboot automatically and can be inserted later. We use a dummy of 999 for now. Once u-boot is working again, you can flash the updated vender image from u-boot (see below how to do this). Now insert the vender data into the flash image:$
dd if=vender.img of=flash.rom bs=1 seek=$((0x7d0000))
The flash.rom image is now ready to be flashed onto the chip. The RedBoot_Config and FIS_directory partitions are not needed.

3. Flash the rom image to the new chip

Ok that's it guys. Oh! the little red PCB connected to the Disk stations serial port is a device called Bus Pirate, I used it to get the logs onto the PC and to mess with the Uboot menu, not that, that achieved anything.
 

Attachments

  • IMG_20221223_135059_MP.jpg
    IMG_20221223_135059_MP.jpg
    1.7 MB · Views: 73
  • IMG_20221223_135137_MP.jpg
    IMG_20221223_135137_MP.jpg
    7.4 MB · Views: 74
  • IMG_20221223_135149_MP.jpg
    IMG_20221223_135149_MP.jpg
    5.6 MB · Views: 72
  • IMG_20221223_152657_MP.jpg
    IMG_20221223_152657_MP.jpg
    3 MB · Views: 69
  • IMG_20221223_152730_MP.jpg
    IMG_20221223_152730_MP.jpg
    6.5 MB · Views: 68
What an absolute bloody nightmare! Mostly, what a crap design, that a system can do this in the first place, just through power loss! They (Synology) must know this, so why remove the files needed for recovery from their website? Arseholes!

Get a UPS, Bob, PDQ! :D
 
What an absolute bloody nightmare! Mostly, what a crap design, that a system can do this in the first place, just through power loss! They (Synology) must know this, so why remove the files needed for recovery from their website? Arseholes!

Get a UPS, Bob, PDQ! :D
I got this one a few days ago, the DS920 and the DS418 are both on it now mate, I would rather spend a couple of hundred on this than give it to those Synology bastards
 

Attachments

  • Powercool 1500va.jpg
    Powercool 1500va.jpg
    3.6 KB · Views: 13
I'm going to jump in here. I believe the OP said that he was 90% of the way towards reflashing when the power went out. I had this experience way back with an Asus motherboard, and since that time, I will ALWAYS connect the machine to a big UPS before doing any of these things. I have my DS 1821 connected to a REALY BIG UPS, which gives me surge protection as well. I have had motherboards bricked when doing a reflash when the power went out.
 
I'm going to jump in here. I believe the OP said that he was 90% of the way towards reflashing when the power went out. I had this experience way back with an Asus motherboard, and since that time, I will ALWAYS connect the machine to a big UPS before doing any of these things. I have my DS 1821 connected to a REALY BIG UPS, which gives me surge protection as well. I have had motherboards bricked when doing a reflash when the power went out.
Read the post four above yours
 
Well I don't know where Ray has gone, but if anyone is interested the NAS is fully working now and back in service.
First of all my thanks go out to Ray because the 218 flash file he gave me proved that it was just the flash that was corrupt and there were no other problems.
So with Ray abandoning me what did I do. The only way this was going to work was with a new flash file, and it had to be the correct one for the 418 as it would not recognize any disks were present with the 218 flash in it. I haven't got a linux PC but I had found some instructions as to how to build the flash file on a Linux pc, I don't know who wrote them, but whoever you are thank you very much. His instructions were for a much older model and I could see by looking at the original flash file read out of the chip that his Offsets were different to mine, So I took his instructions and inserted my own offsets,
How did I get around not having a Linux PC, well I have got a VU DUO+ Satellite receiver which is basically a Linux computer, so I rooted into it with Putty, copied the files from the PAT file to the User/Home directory and worked in there, gave the commands as listed below and constructed the file, including the vender.img which I would edit later.

when it comes to the very complicated instructions on how to add your serial number and Mac address, including having to compile a program written in "C" I just ignored that and when I had created the file I edited it with a hex editor and copied the original from the vendor offset to the end of the file and pasted it into the new one, saved the file, loaded it into flash and away she went.
I have included some pictures, the flash rom is the very small chip to the top right of the processors heat sink, you can see how I was working on it with the chassis out of the case and you can see on the monitor it is doing a DSM update and then you can see the Stat box showing it up and working. It's been an experience I can tell you.
Here are the instructions in case anyone needs to do it

You need to extract the three files from the version of DSM you are using for the 418, this will probably work with other models too, the files are
  • uboot_DS*******.bin: u-boot
  • zImage: kernel
  • rd.bin: initrd
The size of the flash chip on the DS418 is 64Mbit, so we need an 8MB large image. We first recall the flash layout to get the right offsets:

DS418
00000000:00100000 : "RedBoot"
00100000:003f0000 : "zImage"
003f0000:007ef000 : "rd.gz"
007ef000:007ff000 : "vendor"

Put those files in the directory you are working from then do all the following
Create an empty flash image of 8 MB size filled with zeros: $
dd if=/dev/zero of=flash.rom bs=1024 count=8192
Copy the uboot image to the beginning of the file not truncating the rest: $
dd if=uboot_DS418.bin of=flash.rom conv=notrunc
Now copy the kernel image at the right offset. dd cannot directly use hexadecimal values.These have to be converted by the shell:$
dd if=zImage of=flash.rom bs=1 seek=$((0x100000)) conv=notrunc
Next is the initrd image: $
dd if=rd.bin of=flash.rom bs=1 seek=$((0x3f0000)) conv=notrunc
Now insert the vender data into the flash image:$
dd if=vender.img of=flash.rom bs=1 seek=$((0x7ef000))

Now notice that I have the adding of the vender img file at the end of the list, this was because after creating the file with no information in it as described below, I was just going to delete that area from the file and copy and paste the information from the original flash read from the chip, I only used it as a place holder, if you haven't got it or it's too corrupt to read you will have to do as described now.

Now comes the vender partition. This is not provided in the download of the firmaware as this is unique to your DiskStation and written only once in the factory. It contains the serial number and the MAC address, which can be found on the sticker at the back of the case. The DiskStation will boot without the vender information, but without the MAC address it will assign a random MAC at each boot. This will annoy DHCP servers as they serve a new IP on every reboot. Automatic firmware updates and the DS Assistant rely on the MAC address as well.

For the next step you will need the serial number and original MAC from the sticker and a hex editor (I use hexeditor). First we create an empty 64 kB vender partition: $ dd if=/dev/zero of=vender.img bs=1024 count=64 The MAC address is stored in the first 6 bytes and the 7th byte contains a checksum. The checksum is calculated by taking the sum of the bytes in the MAC address. The following C program can be used to calculate the checksum. The checksum is stored in an unsigned char, which is not large enough to store the total. It will flow over give the rest, which is larger than multiples of 256 bytes:
#include <stdio.h> int main() { unsigned char chksum = 0; int i = 0; unsigned char rgAddr[6] = {0x00, 0x11, 0x32, 0xFF, 0xFF, 0xFF}; for (i = 0; i < 6; i++) { chksum += rgAddr; } printf("Checksum: 0x%X\n", chksum); return 0; } The first three bytes are the Synology part, the last three bytes needs to be changed to your MAC address. Compile with $ gcc -o checksum mac_checksum.c This MAC example 00:11:32:FF:FF:FF will give a checksum of 0x40.

Insert these bytes into the image: $ hexeditor -b vender.img 00000000 00 11 32 FF FF FF 40 The serial number is written like this. For example:
SN=1350LAN009999,CHK=999
00000020 53 4e 3d 31 33 35 30 4c 41 4e 30 30 31 39 39 39 00000030 2c 43 48 4b 3d 39 39 39 Use an ascii to hex converter to generate the hex values. The checksum is calculated on next reboot automatically and can be inserted later. We use a dummy of 999 for now. Once u-boot is working again, you can flash the updated vender image from u-boot (see below how to do this). Now insert the vender data into the flash image:$
dd if=vender.img of=flash.rom bs=1 seek=$((0x7d0000))
The flash.rom image is now ready to be flashed onto the chip. The RedBoot_Config and FIS_directory partitions are not needed.

3. Flash the rom image to the new chip

Ok that's it guys. Oh! the little red PCB connected to the Disk stations serial port is a device called Bus Pirate, I used it to get the logs onto the PC and to mess with the Uboot menu, not that, that achieved anything.
I´m so glad to read that you were able to fix the Diskstation. I got an used DS218 and I think i got a very simialar problem with mine. The powerbutton is just flashing blue, but I already established a serial connection.
I´ll try to follow your instructions, but I got one question left. How did you get the rom in your flash? Did you get the network working and used tftp or did you copied them by usb?
I´m really looking forward for your answer.
Sorry for my bad english and best regards from Germany,

Rouven
 
I´m so glad to read that you were able to fix the Diskstation. I got an used DS218 and I think i got a very simialar problem with mine. The powerbutton is just flashing blue, but I already established a serial connection.
I´ll try to follow your instructions, but I got one question left. How did you get the rom in your flash? Did you get the network working and used tftp or did you copied them by usb?
I´m really looking forward for your answer.
Sorry for my bad english and best regards from Germany,

Rouven
You should read the whe thread above, not just the last few posts. But to answer your question and do the work for you, I removed the memory from the pcb programmed it with a programmer and then put it back
 
Well I don't know where Ray has gone, but if anyone is interested the NAS is fully working now and back in service.
First of all my thanks go out to Ray because the 218 flash file he gave me proved that it was just the flash that was corrupt and there were no other problems.
So with Ray abandoning me what did I do. The only way this was going to work was with a new flash file, and it had to be the correct one for the 418 as it would not recognize any disks were present with the 218 flash in it. I haven't got a linux PC but I had found some instructions as to how to build the flash file on a Linux pc, I don't know who wrote them, but whoever you are thank you very much. His instructions were for a much older model and I could see by looking at the original flash file read out of the chip that his Offsets were different to mine, So I took his instructions and inserted my own offsets,
How did I get around not having a Linux PC, well I have got a VU DUO+ Satellite receiver which is basically a Linux computer, so I rooted into it with Putty, copied the files from the PAT file to the User/Home directory and worked in there, gave the commands as listed below and constructed the file, including the vender.img which I would edit later.

when it comes to the very complicated instructions on how to add your serial number and Mac address, including having to compile a program written in "C" I just ignored that and when I had created the file I edited it with a hex editor and copied the original from the vendor offset to the end of the file and pasted it into the new one, saved the file, loaded it into flash and away she went.
I have included some pictures, the flash rom is the very small chip to the top right of the processors heat sink, you can see how I was working on it with the chassis out of the case and you can see on the monitor it is doing a DSM update and then you can see the Stat box showing it up and working. It's been an experience I can tell you.
Here are the instructions in case anyone needs to do it

You need to extract the three files from the version of DSM you are using for the 418, this will probably work with other models too, the files are
  • uboot_DS*******.bin: u-boot
  • zImage: kernel
  • rd.bin: initrd
The size of the flash chip on the DS418 is 64Mbit, so we need an 8MB large image. We first recall the flash layout to get the right offsets:

DS418
00000000:00100000 : "RedBoot"
00100000:003f0000 : "zImage"
003f0000:007ef000 : "rd.gz"
007ef000:007ff000 : "vendor"

Put those files in the directory you are working from then do all the following
Create an empty flash image of 8 MB size filled with zeros: $
dd if=/dev/zero of=flash.rom bs=1024 count=8192
Copy the uboot image to the beginning of the file not truncating the rest: $
dd if=uboot_DS418.bin of=flash.rom conv=notrunc
Now copy the kernel image at the right offset. dd cannot directly use hexadecimal values.These have to be converted by the shell:$
dd if=zImage of=flash.rom bs=1 seek=$((0x100000)) conv=notrunc
Next is the initrd image: $
dd if=rd.bin of=flash.rom bs=1 seek=$((0x3f0000)) conv=notrunc
Now insert the vender data into the flash image:$
dd if=vender.img of=flash.rom bs=1 seek=$((0x7ef000))

Now notice that I have the adding of the vender img file at the end of the list, this was because after creating the file with no information in it as described below, I was just going to delete that area from the file and copy and paste the information from the original flash read from the chip, I only used it as a place holder, if you haven't got it or it's too corrupt to read you will have to do as described now.

Now comes the vender partition. This is not provided in the download of the firmaware as this is unique to your DiskStation and written only once in the factory. It contains the serial number and the MAC address, which can be found on the sticker at the back of the case. The DiskStation will boot without the vender information, but without the MAC address it will assign a random MAC at each boot. This will annoy DHCP servers as they serve a new IP on every reboot. Automatic firmware updates and the DS Assistant rely on the MAC address as well.

For the next step you will need the serial number and original MAC from the sticker and a hex editor (I use hexeditor). First we create an empty 64 kB vender partition: $ dd if=/dev/zero of=vender.img bs=1024 count=64 The MAC address is stored in the first 6 bytes and the 7th byte contains a checksum. The checksum is calculated by taking the sum of the bytes in the MAC address. The following C program can be used to calculate the checksum. The checksum is stored in an unsigned char, which is not large enough to store the total. It will flow over give the rest, which is larger than multiples of 256 bytes:
#include <stdio.h> int main() { unsigned char chksum = 0; int i = 0; unsigned char rgAddr[6] = {0x00, 0x11, 0x32, 0xFF, 0xFF, 0xFF}; for (i = 0; i < 6; i++) { chksum += rgAddr; } printf("Checksum: 0x%X\n", chksum); return 0; } The first three bytes are the Synology part, the last three bytes needs to be changed to your MAC address. Compile with $ gcc -o checksum mac_checksum.c This MAC example 00:11:32:FF:FF:FF will give a checksum of 0x40.

Insert these bytes into the image: $ hexeditor -b vender.img 00000000 00 11 32 FF FF FF 40 The serial number is written like this. For example:
SN=1350LAN009999,CHK=999
00000020 53 4e 3d 31 33 35 30 4c 41 4e 30 30 31 39 39 39 00000030 2c 43 48 4b 3d 39 39 39 Use an ascii to hex converter to generate the hex values. The checksum is calculated on next reboot automatically and can be inserted later. We use a dummy of 999 for now. Once u-boot is working again, you can flash the updated vender image from u-boot (see below how to do this). Now insert the vender data into the flash image:$
dd if=vender.img of=flash.rom bs=1 seek=$((0x7d0000))
The flash.rom image is now ready to be flashed onto the chip. The RedBoot_Config and FIS_directory partitions are not needed.

3. Flash the rom image to the new chip

Ok that's it guys. Oh! the little red PCB connected to the Disk stations serial port is a device called Bus Pirate, I used it to get the logs onto the PC and to mess with the Uboot menu, not that, that achieved anything.
You did a fantastic job! my hat off to you. I know this is late as I just spotted it now. I got so sick that day, I wasn't online for a week. Ended up in the hospital. My true apologies. As I never abandon anyone. I just was out of it. LOL! But congrats Wedgehog. Good Job Bud!
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

  • Question
Hey all. I have had a DS218j for a few years which has a single JBOD volume comprised of a 4 tb disk and...
Replies
0
Views
922

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top