seagate-blackarmor-nas
seagate-blackarmor-nas copied to clipboard
hn
Test on Seagate 440 NAS
Hi - I have a Seagate 440 NAS that I would like to try your latest codebase on. Happy to provide my findings here. Is there anything I should be checking beforehand?
Some thoughts:
- I do not have any information about the NAS 110 and 440, I never had access to the hardware. I think the motherboard/cpu is identical or at least very similar, but that's just a guess. The NAS 440 has more SATA and USB ports and an LCD display -- that might have an impact on the compatibility as well.
- My scripts are not specific to the NAS 220. Evgenis kernel patch and the u-boot bootloader might be the limiting factor here, at least they are labeled "nas220".
- There is a risk of bricking your device, especially if the u-boot bootloader does not start.
I suggest the following steps:
- backup flash (just in case something goes horribly wrong):
cat /dev/mtd0 > uboot.img
cat /dev/mtd1 > ubootenv.img
cat /dev/mtd2 > preroot.img
cat /dev/mtd3 > uimage.img
cat /dev/mtd4 > rootfs.img
cat /proc/cpuinfo > cpuinfo.txt
fw_printenv > ubootenv.txt
- try booting the kernel and debian installer from within the old seagate u-boot (without flashing the updated u-boot bootloader):
setenv bootargs console=ttyS0,115200
usb start
fatload usb 0:1 0x40000 uImage-dtb
fatload usb 0:1 0x800000 uInitrd
bootm 0x40000 0x800000
If the kernel and debian installer start without problems, try partitioning the hard disks, installing base system, packages etc. but do not execute my postinstall script. Maybe you also try to adjust the fan speed to check if the i2c bus works.
-
If everything looks good, reset the NAS and install everything as described in my howto (flash u-boot ... postinstall script)
-
good luck ;-)
Looking at your update on 440. I have one and lost the application that reset it. The problem here was that no new firmware was being developed. So, if it works, I will try also.
@gazcbm I tried here to put Debian 5. Its works fine, but, there is a problem that I didn't find the solution:
- LCD Freeze on Seagate Booting... -> But SO works fine. It initialized and you could use normally.
Although, some peoples said that is possible change a file to show the correct messages. I tried it too, but, unsuccessful. So, I reset the NAS to Original Firmware. Remember: I didn't use the NAND Flashing, only using U-boot.
@gazcbm do you have the application that reset the storage? The one on the Seagate website does not work at all... probably some problematic binary.
@condector Do you need to format a disk? I remember when my NAS did not want to start to start. So, I removed the HD, and I had used a software (don't remember its name), created a RAID array in Linux. So, I formatted using Diskpart. Put it on NAS and it worked.
I remember that the Error messages was: No System HDD found. So, problem solved.
But I tried it about 1 year ago and worked well. http://knowledge.seagate.com/articles/en_US/FAQ/3004en
No no, the disks are ok, the problem is that I want to factory reset my system, but the application that creates the URL using the MAC Address of the NAS not work anymore (the application on the Seagate web site).
I looked for it, but I didn't find.
Are you sure that NAS is Turn On? If you want, you could reset through the button on the back.
I found this link: http://www.tomshardware.com/answers/id-3549625/rebuild-reset-seagate-blackarmor-440-nas.html
is there the possibility to port this to BlackArmor SRN02D?
Here is the boot log: https://pastebin.com/30qvrtWT
@vrtlspd From a quick 1-minute check of the boot log I think it shouldn't be too hard to install a standard Debian GNU/Linux system on the BlackArmor SRN02D. U-Boot is located on flash, Kernel and Initramfs are located on SD card. You can start by stopping the U-Boot loader (Hit any key to stop autoboot) and printenv to further analyze the boot process. You can even try to boot a different kernel/initrd/rootfs via netboot for a quick compatibilty check of the hardware.
This project is for the "old" Blackarmor series and due to the big differences in hardware it does not make sense to include support for the "new" series.
Hi, I'm not very experienced with linux and changing kernels.
CPU works at 700 MHz (700/1/1) DDR2 Speed is 400 MHz Restoring RTC Hit any key to stop autoboot: 0 Whitney # Whitney # Whitney # Whitney # ? ? - alias for 'help' base - print or set address offset bcm - read/write bcm53115m register bdinfo - print Board Info structure bootelf - Boot from an ELF image in memory bootm - boot application image from memory bootp - boot image via network using BOOTP/TFTP protocol bootvx - Boot vxWorks from an ELF image cmp - memory compare cp - memory copy crc32 - checksum calculation date - get/set/reset date & time dcache - enable or disable data cache dhcp - boot image via network using DHCP/TFTP protocol erase - erase FLASH memory via parallel interface erase_spi - erase FLASH memory via serial interface ext2load- load binary file from a Ext2 filesystem ext2ls - list files in a directory (default /) fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) flinfo - print FLASH memory information go - start application at address 'addr' help - print online help icache - enable or disable instruction cache iminfo - print header information for application image loadb - load binary file over serial line (kermit mode) loady - load binary file over serial line (ymodem mode) loop - infinite loop on address range md - memory display mdio - read/write PHY register memtest_cns3000 - cns3000 RAM test mm - memory modify (auto-incrementing) mmcinit - init mmc card mtest - simple RAM test mw - memory write (fill) nm - memory modify (constant address) ping - send ICMP ECHO_REQUEST to network host printenv- print environment variables protect - enable or disable parallel FLASH write protection protect_spi - enable or disable serial FLASH write protection rarpboot- boot image via network using RARP/TFTP protocol reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage scsi - SCSI sub-system scsiboot- boot from SCSI device setenv - set environment variables tftpboot- boot image via network using TFTP protocol usb - USB sub-system usbboot - boot from USB device version - print monitor version Whitney # printenv ethaddr=00:11:22:XX:XX:XX netboot=0 bootargs=root=/dev/mtdblock0 mem=256M console=ttyS0 bootdelay=2 baudrate=38400 ipaddr=192.168.1.2 port=0 boardtest_state_memory=none model_name=whitney_2bay cpu_clock=700 mfgmodel=halfdome netmask=255.255.0.0 bootfile="/tftpboot/uImage" tftp_bsize=512 udp_frag_size=512 whitney_state=saved opid=Z11022623 hddlocation=C hddpn=1CH164-515 serialNo=NA6F0XP8 ethaddr0=00:10:75:XX:XX:XX ethaddr1=00:10:75:XX:XX:XX modelname=1BW5P3-500 serial_number=XXXXXXXXXXXXXXXXXXXXX tftp_serverip=192.168.32.4 serverip=192.168.32.4 tftp_path=halfdome/bootimage autoload=no netboot_cmd=dhcp;setenv serverip ${tftp_serverip}; tftp 0x4000000 ${tftp_path}/bootpImage; go 0x4000000; fw_zone=normal create_volume=pass mfgtest_state=final_tested_ok current_kernel=kernel1 num_boot_tries=0 rtclog=52779be6 stdin=serial stdout=serial stderr=serial verify=n
Hi
After successfully install on NAS110, I am now getting ready to do the installation on NAS400. Can someone guide me on how to keep the functionality of LCD and buttons on new installation?
Thanks LST
@luctrev I suggest to try to do the basic install first, to see if things work at all.
I think there will be ways to fiddle with the necessary IO pins for LCD and buttons if you have a running system.
I can't tell (from the above) whether anyone has actually had any success on a BlackArmor 440. The motherboard on mine seems quite different from the 220...I can't find any serial connector/pins to control the boot process. So, there's nothing to connect a FTDI232r to. There is an empty space (labeled CN4, if I recall) that has no pins--just two rows of five solder points where a connector might go. Maybe Seagate removed the serial interface connector to stop folks like us from hacking their systems? (I'm not eager to solder a new connector--not even sure what this empty space is intended for.)
Ideas? Has anyone else actually disassembled their 440 NAS?
I can't tell (from the above) whether anyone has actually had any success on a BlackArmor 440. The motherboard on mine seems quite different from the 220...I can't find any serial connector/pins to control the boot process. So, there's nothing to connect a FTDI232r to. There is an empty space (labeled CN4, if I recall) that has no pins--just two rows of five solder points where a connector might go. Maybe Seagate removed the serial interface connector to stop folks like us from hacking their systems? (I'm not eager to solder a new connector--not even sure what this empty space is intended for.)
Ideas? Has anyone else actually disassembled their 440 NAS?
Hi
Look here https://github.com/hn/seagate-blackarmor-nas/blob/master/seagate-blackarmor-nas.txt
-
Serial connector The following pinout has been published by user Mike Seeley github.com/mjseeley (BA440) on the Seagate Support Forum. It works for the BA220, too.
Please make sure to use a 3.3V cable (search for 'CA-42 USB'). A 5V TTL cable may damage your NAS permanently.
CN4
9|-X-0-|10 7|-0-0-|8 5|-0-X-|6 3|-0-X-|4 1|-X-0-|2Pin 1 - TX Pin 4 - RX Pin 6 - GND Pin 9 - VCC 3.3V
Baud rate 115200
@luctrev I suggest to try to do the basic install first, to see if things work at all.
I think there will be ways to fiddle with the necessary IO pins for LCD and buttons if you have a running system.
Hi @hn
When I upgraded BA400 to Debian 6, I saved the following files:
/etc/btn.poweroff /etc/init.d/S99lcm /usr/sbin/wixsendevent /usr/sbin/btn_monitor
But in case of a fresh install I don't know if it will work!
Thanks. I've seen that (and Googled around to find Mike's original post on the "Seagate Support Forum" (which seems to have been deleted some years ago)). My issue is that there are no "pins" at that location. Just solder spots. So I either need to solder in my own connector with pins or find some other way to temporarily attach the USB/Serial converter to the four locations. I was mostly asking whether any of the BA440 owners had the same experience and, if so, how they resolved it. I'm not eager to start soldering!
(I've attached a photo of the relevant portion of the motherboard...just to the right of the screw.
)
I think this is the right part. When I originally did the pin outs it had the headers. I just used jumper wires to hook things up. Now they have all those ftdi breakout boards. With all the activity on this it make me want to pull the two 440s I have out of storage to play with again.
@luctrev I think those utilitiy binaries you saved do not help that much because they likely do not contain code to directly access the hardware.
The fan speed can be set via I2C: https://github.com/hn/seagate-blackarmor-nas#additional-tuning. It is very likely that the buttons and LCD display are connected via I2C bus or dedicated IO pins as well. You may need to fork/patch the kernel DTS file (https://lore.kernel.org/patchwork/patch/529020/ ) to access them (or to get the kernel running at all, to access additional SATA ports, ...)
But that's just a quick guess. If you or someone else owns a BA440, just try to boot the kernel and basic system to see if things work at all.
@mjseeley (and anyone else with a BA440): I went ahead and soldered a header onto the board. Sure enough, connecting an FTDI USB/Serial device to pins 1,4,6, and 9 do, in fact, provide serial communication access to the device. If anyone's going to do the same, be aware that pin 1 is the one with the thicker border line in the corner. I quadruple-checked that, because I didn't want to accidentally fry the board.
I can provide some photos if desired (but it's not pretty--I used a "female" header that I had sitting around, so the connections are extra tall!).
Now to upgrade the firmware/OS...
No. It failed and the machine bricked. Now I’m trying to find some time to try to reload/reset the firmware via the JTAG interface. Maybe over the winter.
From: Ken-L [email protected] Sent: Monday, December 2, 2019 3:47 PM To: hn/seagate-blackarmor-nas [email protected] Cc: D. Scott Miller [email protected]; Mention [email protected] Subject: Re: [hn/seagate-blackarmor-nas] Test on Seagate 440 NAS (#5)
@LoonSongSoftwarehttps://github.com/LoonSongSoftware any progress on the firmware/OS upgrade?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hn/seagate-blackarmor-nas/issues/5?email_source=notifications&email_token=AEHXFITOQWTGICMTQKT26Q3QWVX3RA5CNFSM4GQFU5SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFU2ZIY#issuecomment-560573603, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEHXFIQJL232Y3OIJ2PFGDTQWVX3RANCNFSM4GQFU5SA.
@LoonSongSoftware what do you exactly mean by 'bricked'? The U-Boot bootloader does not start? Is there any serial output?
It’s been a while since I fried it. But my recollection is that the board didn’t have a the serial connector soldered on (like your photo). So I think I did make the connections (surface mount) and saw no signals.
But give me 24 hours and I’ll dig out the machine and refresh my memory.
From: Hajo Noerenberg [email protected] Sent: Monday, December 2, 2019 4:19 PM To: hn/seagate-blackarmor-nas [email protected] Cc: D. Scott Miller [email protected]; Mention [email protected] Subject: Re: [hn/seagate-blackarmor-nas] Test on Seagate 440 NAS (#5)
@LoonSongSoftwarehttps://github.com/LoonSongSoftware what do you exactly mean by 'bricked'? The U-Boot bootloader does not start? Is there any serial output?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hn/seagate-blackarmor-nas/issues/5?email_source=notifications&email_token=AEHXFITIFEH2EHRTFDHGKPDQWV3VXA5CNFSM4GQFU5SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFU5V6I#issuecomment-560585465, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEHXFIS2ZAA52ZBJ54LSX7DQWV3VXANCNFSM4GQFU5SA.
@LoonSongSoftware Bummer. Well... thanks for bricking your nas for the community. I'm interested to see what you come up with.
I've done some work on the 400/440 in 2015, which may or may not be useful to the discussion here.
From my paper notes attached to the device, I can see that back then I got a stock install of Debian Jessie running, but I ended up putting the device away because it randomly crashed and I did not have the time to debug it.
My notes are available at https://gist.github.com/bantu/d456865b91be6c99320b
Highlights probably include
- an unsubmitted u-boot patch at https://github.com/bantu/u-boot/compare/master...sg-ba-440
- an unsubmitted linux device tree patch at https://github.com/bantu/linux/compare/master...kw-ba-400-dts
It appears that in my setup, the kernel (and initrd and device tree) is loaded from the ext4 root filesystem held on an external usb drive. This should allow me to trivially make a backup of the system and to try to update to stretch and then buster.
@bantu thanks for sharing your work! This looks very promising, I've shared your links in my README. Maybe you or somebody else will find some time to finalize the patches (it's christmas again ... :)).
This should allow me to trivially make a backup of the system and to try to update to stretch and then buster.
I've updated from Debian Jessie to Debian Stretch to Debian Buster using the usual apt mechanisms without any issue. Device is now busy shredding SATA disks. Will update the gist shortly.