Some time ago I posted a link to the U-Boot file which is aptly named 3.5.9 https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/8451branch/hi3535-source/u-boot-mv-3.5.9.txz/download There is only one DS213 in it without either of the dates AMD mentions. I don't "think" programmers would have made a modification to the archive and not updated the desigby itangoii - uBoot
Thanks for jumping in Bodhi. After seeing his message I checked Synology web site and they have totally redone the archive and renamed directories. There are now a whole lot of broken links on the web. The archive also only goes up to 3.2.x with no 3.5. It will be interesting to see his response. I checked the files that we pulled from the good box and they are April release times.by itangoii - uBoot
This is interesting. I believe we were not aware of this. The flash we pulled from an operational DS213 was dated April and is what we tried to restore. May I ask where you got the other zimage and with what method you flashed? I did try to flash the zimage at one time but was unsuccessful. It could have been for this reason. Thanks.by itangoii - uBoot
I decided to start over and clean up my notes as well. I booted the good box ad dd the mtds'. Then after doing a hex edit on mtd3 fo correct MAC address and serial number I booted the bad box with kwboot and the usb. Logged into Debian with root and root then changed to the /boot directory. When trying to flash I got...... root@debian:/boot# flash_unlock /dev/mtd0 root@debian:/bby itangoii - uBoot
Interesting. I never would have seen that. Part of my confusion was that mtd2 is what is getting the crc error, but has never been touched before or after the good boot. Do you suppose mtd3 is causing a shift into the mtd2 area? I checked the properties on my windows work station and it to sees a discrepancy (see attached pic). I'll assume that's one of those Windows/Linux thingby itangoii - uBoot
this is the procedure I used and the boot after. It seems to go fine, but still fails with the loop of the ramdisk having a bad crc when booting which results in a loop. Can you see anything wrong? Thanks root@ubuntu20:/tftproot# picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0 picocom v3.1 port is : /dev/ttyUSB0 flowcontrol : none baudrate is : 115200 parity isby itangoii - uBoot
That's the problem, It did start up but then after restarting with a clean hard drive in it, it went into a boot loop. The box has started twice now on successful flashings but after a restart goes into a boot loop. Startup monitoring the console shows it gets through the first two mtds but fails with a bad crc on the third (mtd2). After that I flashed both ways with tftp and flashcp meby itangoii - uBoot
bodhi Wrote: ------------------------------------------------------- > itangoii, > > > I followed the revised post here. > > > > > https://forum.doozan.com/read.php?3,108294,111084#msg-111084 > > No you should not. Keep the log of what you did > successfully, and that will be used to update the > instruction. > > > If I'm notby itangoii - uBoot
Well, I'm smarter than people think I am ;-) #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; } In the above code change the FFs to the last three of your MAC address bby itangoii - uBoot
Good news. I've nailed down the serial number and MAC address. MAC address is the first 6 bytes of mtd3. The first 3 are vendor specific and would likely not change for Synology. The last three are going to be on the label on the box. More on that later. Serial number is in plain text starting at 33 and is 10 bytes. Back to the MAC, the seventh byte is a calculated checksum baseby itangoii - uBoot
I followed the revised post here. https://forum.doozan.com/read.php?3,108294,111084#msg-111084 That's why it seems odd that the kwboot works to proceed with the flashing, but the same ds213.mtd0 used in the flashing will just lock up the terminal with no output. Something came to mind, and I will have to read back on this tread. If I'm not mistaken we did get the box to boot oby itangoii - uBoot
bodhi Wrote: ------------------------------------------------------- > QuotePrintenv does show a ethaddr (which is a > MAC address, but does not match the label) setenv > ethaddr MAC-on-Label and then printenv again shows > that env gone from the list. > > Any log that you can post? What i posted above was the whole process except for the reboot after starting picocomby itangoii - uBoot
Well I had some time today to pursue this after alot of research on the MAC address and serial number. Serial number is in mtd3 and is about all that's there. I'm assuming the MAC is as well (easy to flash at the factory since those are the only two things that would need to be static and are on a barcode label on back) However, unlike the serial number it is not in plain text. a feby itangoii - uBoot
I found this on the Synology form a while back and looked it up again after seeing in the Synology software that the bricked box had the same serial and MAC as the one we copied from. I think I need to address that first. The serial and MAC are in MTD3. The serial was in ASCI and I could change it easily with a hex editor, but I'm not sure from this post how to come to the MAC address andby itangoii - uBoot
Well. I spoke too soon. After the box was up and running I installed the second drive and it would not complete the boot. I removed the drive and again it would not complete the boot, but the web interface indicated it had crashed and to remove the volume and re-install. I tried to do so, but it went into the same problem that started all of this in that the OS will download but give an erroby itangoii - uBoot
Congratulations! You have succeeded! ;-) tftpboot/sflash went smoothly and after a reset the box was discovered by the Synology software and allowed a fresh upgrade of the OS. After that, the web interface presented the normal login and indicated the box was healthy. When/if you have the time (no hurry) could you summarize what you found in all this? Will the user need to do the dump usby itangoii - uBoot
Sorry to take so long, it has been a tough couple of weeks but had some personal time this weekend. It also took some time to figure out and cobfigure the tftp server as information varies. I eventually got it pointed to the tftproot directory It seems to read fine, but writing ia not working with little or no info as to why. Marvell>> tftpboot 0x800000 ds213.mtd2 Using egiga0 deby itangoii - uBoot
bodhi Wrote: ------------------------------------------------------- > itangoii , > > I did not forget this topic, just too busy to > revisit it! I think we should move on to the > flashing with tftp approach to see if it is more > successful. No worries, I've been busy the last couple of weeks to. Thanks for hanging in there.by itangoii - uBoot
bodhi Wrote: ------------------------------------------------------- > itangoii, > > > > > I'll do the dump > > an ls-l on the files > > cp -a to the USB > > an ls -l on them on the USB > > > > change boxes > > > > try the flash > > and post console log of the whole process in > the > > same messageby itangoii - uBoot
OK bodhi, I understand what you need now. I'll do the dump an ls-l on the files cp -a to the USB an ls -l on them on the USB change boxes try the flash and post console log of the whole process in the same message. Anything to add to that process? Thanksby itangoii - uBoot
Sorry to take so long to get back to you, I needed to get caught up on work and personal responsibilities. Can you explain how to get the dump and flash activities sequential. I don't think it would be a good idea to swap machines while they are running with the serial port open. And also swapping the USB drive. Thanks.by itangoii - uBoot
I did post the flashing part above. The last post was a duplicate for the dump part you wanted to see. The two put together are the whole process.by itangoii - uBoot
I would have posted both but I have to reset the terminal to change boxes, This is the boot and dump part. 95 % [......................................................................] 97 % [......................................................................] 99 % [....................................] U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:42:03 -0700) ZyXEL NSA325 2-Bay Pby itangoii - uBoot
I tried the others with the same result. I then checked the files on the usb root@debian:/boot# flashcp -v ds213.mtd2 /dev/mtd2 Erasing blocks: 1088/1088 (100%) Writing data: 4352k/4352k (100%) Verifying data: 450k/4352k (10%)File does not seem to match flash data. First mismatch at 0x0006e000-0x00070800 root@debian:/boot# flashcp -v ds213.mtd3 /dev/mtd3 Erasing blocks: 16/16 (100%) Wby itangoii - uBoot
Well shoot. I went through the whole process including following the procedure to dump with the correct envs. 95 % [......................................................................] 97 % [......................................................................] 99 % [....................................] U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:42:03 -0700) ZyXEL NSA325 2-Bayby itangoii - uBoot
bohdi: I think you meant to say boot the bricked box in that second part.by itangoii - uBoot
bodhi Wrote: ------------------------------------------------------- > itangoii, > > You used an older set of envs. The latest we have > to kwboot with NSA325 u-boot into Debian USB is: > > https://forum.doozan.com/read.php?3,108294,109524#msg-109524 > > > > NSA325> setenv dtb_file > /boot/dts/kirkwood-ds212.dtb > NSA325> setenv mtdpartsby itangoii - uBoot
The conditions are different from what I understand. We did dd previously from the booted good ds213 and last time from being booted on the Debial usb. root@ubuntu20:~/kwboot# ./kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.2017.07-tld-1.nsa325.mtd0.kwb -p Sending boot message. Please reboot the target...- Sending boot image... 0 % [.........................................................by itangoii - uBoot
bodhi Wrote: ------------------------------------------------------- > I think we need to adjust the mtds backup > procedure a bit. > > In summary, instead of dumping in stock OS. We > should do this > > - kwboot the good box with NSA325 u-boot > and adjust envs to boot with USB. > - And do the dd dumping in Debian. > > And then restore them on theby itangoii - uBoot
bodhi Wrote: ------------------------------------------------------- > itangoii, > > Ignore mtd6 for now. It is not in the definition > (on purpose). All right then, I'll try flashing them in tomorrow. I assume you just want me to flash the first 6? Thank you.by itangoii - uBoot