Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Test on Seagate 440 NAS #5

Open
gazcbm opened this issue Jan 15, 2019 · 43 comments
Open

Test on Seagate 440 NAS #5

gazcbm opened this issue Jan 15, 2019 · 43 comments

Comments

@gazcbm
Copy link

gazcbm commented Jan 15, 2019

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?
@hn
Copy link
Owner

hn commented Jan 15, 2019

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 ;-)

@gazcbm
Copy link
Author

gazcbm commented Jan 18, 2019

Great thanks, just ordered a FTDI232r, will keep you updated

@condector
Copy link

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.

@jariojose
Copy link

jariojose commented Jan 31, 2019 •
edited
Loading

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

@condector
Copy link

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

@jariojose
Copy link

jariojose commented Jan 31, 2019 •
edited
Loading

@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

@condector
Copy link

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

@condector
Copy link

If you have this tool, I will really appreciate you know.

@jariojose
Copy link

jariojose commented Jan 31, 2019 •
edited
Loading

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

@vrtlspd
Copy link

vrtlspd commented Aug 6, 2019 •
edited
Loading

is there the possibility to port this to BlackArmor SRN02D?

Here is the boot log:
https://pastebin.com/30qvrtWT

@hn
Copy link
Owner

hn commented Aug 7, 2019

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

@vrtlspd
Copy link

vrtlspd commented Aug 7, 2019

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

@luctrev
Copy link

luctrev commented Aug 7, 2019

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

@hn
Copy link
Owner

hn commented Aug 8, 2019

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

@LoonSongSoftware
Copy link

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?

@luctrev
Copy link

luctrev commented Aug 26, 2019

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

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

    Pin 1 - TX
    Pin 4 - RX
    Pin 6 - GND
    Pin 9 - VCC 3.3V

    Baud rate 115200

@luctrev
Copy link

luctrev commented Aug 26, 2019

@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!

@LoonSongSoftware
Copy link

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

@mjseeley
Copy link
Contributor

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.

@hn
Copy link
Owner

hn commented Aug 27, 2019

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

@hn hn mentioned this issue Aug 29, 2019
Closed
@LoonSongSoftware
Copy link

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

@Ken-L
Copy link

Ken-L commented Dec 2, 2019

@LoonSongSoftware any progress on the firmware/OS upgrade?

@LoonSongSoftware
Copy link

LoonSongSoftware commented Dec 2, 2019 via email

@hn
Copy link
Owner

hn commented Dec 2, 2019

@LoonSongSoftware what do you exactly mean by 'bricked'? The U-Boot bootloader does not start? Is there any serial output?

@LoonSongSoftware
Copy link

LoonSongSoftware commented Dec 2, 2019 via email

@Ken-L
Copy link

Ken-L commented Dec 3, 2019

@LoonSongSoftware
Bummer.
Well... thanks for bricking your nas for the community.
I'm interested to see what you come up with.

@bantu
Copy link

bantu commented Dec 22, 2019 •
edited
Loading

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

@bantu
Copy link

bantu commented Dec 23, 2019

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.

@hn
Copy link
Owner

hn commented Dec 23, 2019

@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 ... :)).

@bantu
Copy link

bantu commented Dec 24, 2019

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.

@bantu
Copy link

bantu commented Jan 6, 2020

I ended up putting the device away because it randomly crashed

My device also behaves this way after updating to Debian Buster. I am not sure how to debug this problem.

@sharrq27
Copy link

sharrq27 commented Feb 6, 2020 •
edited
Loading

Any new developments on this? I have an old 440 I am very interested in trying this on, but I am a little out of my league and was hoping someone might be willing to help me through it. EDIT: Although now I see you had random crash on both Jessie and Buster. I misread that previously.

@LoonSongSoftware
Copy link

LoonSongSoftware commented Feb 8, 2020 via email

@LoonSongSoftware
Copy link

OK. I finally got around to digging out the NAS440 and trying again. Still no luck. Here are the symptoms:

  1. when the machine is plugged in to power, the display shows the row of blocks (typical for startup) and stays like that. The blue power light comes on. Pressing the power or reset buttons does nothing.
  2. if there's a serial connection (as described in README.md, but with nothing attached to pin 9 (+3.3v)), there will appear to be a serial connection, but no obvious data flow. (But I do get a few random bytes if I unplug the power (before the serial connection receives . Linux continues to see /dev/ttyUSB0, so the connection is sort of alive.)).
  3. if I do the same, but also connect the +3.3v to pin 9, I get slightly different behavior: the connection will drop (/dev/ttyUSB0 goes away) when power is turned off, and it doesn't appear in Linux until power is applied to the NAS. That makes it difficult to see if there's any data sent immediately upon NAS power-on, but I doubt it.
  4. The JTAG space is the same as for the serial port--no soldered-on connector. And I only see circuit board traces for GND and nSRST. That doesn't look like anywhere near enough to re-flash uBoot. So I'm not inclined to bother pulling out the soldering gun again.

Sorry I wasn't more successful and don't have any great suggestions. I have lots of backups of the firmware and software, but I didn't anticipate not even getting uBoot to start. Fortunately, I was willing and able to withstand a bricked NAS440.

@sharrq27
Copy link

sharrq27 commented Feb 17, 2020 via email

@bantu
Copy link

bantu commented Feb 17, 2020

@LoonSongSoftware I remember successfully using the serial console back then. Here are some pics.

Board with cable soldered on
nas400-board-overview

Other end of cable connected to Raspberry Pi
nas400-serial-connector

@bantu
Copy link

bantu commented Feb 17, 2020 •
edited
Loading

If I remember correctly, the next step after connecting to the serial console was to "upgrade" to an "u-boot netconsole". However, I do not recall whether that applied only after the u-boot on the flash was updated or also before.

@LoonSongSoftware
Copy link

LoonSongSoftware commented Feb 18, 2020 via email

@flex4gh
Copy link

flex4gh commented Oct 28, 2021

Hi,
I got a Seagate BlackArmor 440, and I'm tring to install debian following the guide

https://github.com/hn/seagate-blackarmor-nas

Everything works well up to postinstall.
So I have some questions to understand if I did well and how to continue to complete the procedure.

  1. To execute blackarmor-nas-debian-prep.sh I coment exit 1 at line 49. It's right?

  2. During installation I received the message

No boot loader has been installed, either because you chose not to or because your specific architeture doesn't support a boot loader yet.
You will need to boot manually with the kernel on partition /dev/sda1 and root=/dev/sda1 passed as a kernel argument.
  1. I tried to modify blackarmor-nas-debian-postinstall.sh to work with ba440 but but gives me an error installing linux-image-marvell
Unsupported platform.
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

Anyway I tried to finish the procedure but, of course, give me error getting kernel

U-Boot 2017.11 (Jun 23 2021 - 17:38:36 +0200)
NAS 440

SoC:   Kirkwood 88F6281_A1
DRAM:  256 MiB
WARNING: Caches not enabled
NAND:  32 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0, egiga1
Error: egiga1 address not set.

88E1116 Initialized on egiga0
88E1116 Initialized on egiga1
IDE:   ide_preinit failed
Hit any key to stop autoboot:  3 ��� 2 ��� 1 ��� 0 

NAND read: device 0 offset 0xc0000, size 0x500000
 5242880 bytes read: OK

NAND read: device 0 offset 0x5c0000, size 0x1a3fff0
 27525104 bytes read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image!
nas440>

Can anyone help me complete the procedure in the right way?

@hn
Copy link
Owner

hn commented Oct 28, 2021

@flex4gh , see README.txt:

Support for the NAS 440 is currently alpha quality! Things are incomplete

Commenting exit 1 is not sufficient :) I'm going to try to push some more pending changes, but I can't tell you when I'll find time to do that.

@flex4gh
Copy link

flex4gh commented Oct 28, 2021

@hn I know that support for ba440 is allpha. That's not a problem for me.

I have time to work on this project.
If you explain to me what to work I can try to finish the procedure for ba440.

@hn
Copy link
Owner

hn commented Nov 3, 2021

@flex4gh I think it's worth trying with the latest patches. And ... even Bullseye works :)

Debian GNU/Linux 11 nas440 ttyS0

nas440 login: root
Password:
Linux nas440 5.10.0-9-marvell #1 Debian 5.10.70-1 (2021-09-30) armv5tel

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Jul 13 19:29:49 CEST 2021 on ttyS0
root@nas440:~# cat /proc/device-tree/model
Seagate Blackarmor NAS440
root@nas440:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye
root@nas440:~# cat /proc/cpuinfo
processor       : 0
model name      : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 400.00
Features        : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Marvell Kirkwood (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000
root@nas440:~# uname -a
Linux nas440 5.10.0-9-marvell #1 Debian 5.10.70-1 (2021-09-30) armv5tel GNU/Linux
root@nas440:~#

But remember: HDD slots 1 and 2 do NOT work

@hn hn mentioned this issue Nov 3, 2021
Closed
@YasinKocabas
Copy link

I appreciate your work. I have a Nas 440, I am not experienced on linux, so I want to try to use it when it starts working stable. I enjoy following your updates. I hope you succeed, thank you all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests