DSM-G600, DNS-3xx and NSA-220 Hack Forum

There is easier way to install Debian: http://www.cyrius.com/debian/orion/d-link/dns-323/ (for revision A and B)
You need a serial connection only if something goes wrong.

Grunt, as I know - there is no compilled working kernel for rev.C1 for Debian... but with your serial connection you can contact with guy from http://www.cyrius.com and ask for help with compilling such kernel, I think.

Isildur wrote:

Grunt, as I know - there is no compilled working kernel for rev.C1 for Debian... but with your serial connection you can contact with guy from http://www.cyrius.com and ask for help with compilling such kernel, I think.

Great, I'll do that. I guess that serial access will help providing usefull information, and I'm used to compiling. Glad to help

I can use the NAS with OEM firmware for a while, and leave a hard drive on server:  SCSI hard drives can be turned off from software, so I can boot from local HD, then mount filesystems from NAS (NFS feature will be enough), then turn off SCSI drive.

SCSI drives won't be in oil, I will put them upper to the Sun. Anyway, this won't solve my problem, because:
- I will need more than 74 GB, and don't want to buy large (and expensive) SCSI drives,
- server will run night and day, and may have to write stuff (web logs, mails) on disks, so I cann't turn off SCSI drives. And I'm sure that SCSI drives doing some scratch all night and day would take my girlfriend away.

So, I need to have filesystem away from server.

oxygen wrote:

tbh. I dont think thats a great idea.
1. the dns-323 is way to slow to operate as bootserver.

That doesn't really matter: I won't reboot my Sun every hour, the idea is to let it run 24 hours a day. I can suffer a 10 minutes wait on each power failure.
And there is a chance that I will use SCSI drives for boot sequence, it will make config very easier. /boot on SCSI drives, everything else on NAS.

2. the dns-323 is neither quiet nor cool, when the hdds run 24h (which they will, because of open nfs handles)

Don't worry about that: I got a cupboard far away from sleeping room.
There is now an x86 box running in it, 24 hours a day, and I don't listen it.
I cann't put the Sun it this cupboard, because the Sun is a bit too long (a few centimeters, why do they make cupboards so tight?), and would release too much heat.
I've thinked about putting the Sun in vertical position, in a oil container, and making the oil running into a external radiator.. woooo, too much complicated.
Anyway, if noise and heat are OK with a Athlon 64 X2, they will be OK too for a NAS.
NAS in the cupboard, Sun + oil somewhere else, and Ethernet wire between them.

3. see the previous posts concenering rev. C

This is a good way to contribute, then. I'll be sure to own the really first DNS-323 rev C1 running Debian B)
I'm impatient to discover the rev C1 through serial port

so you'll ask what to do else? why not get a SSD for your sun box? no problem with oil. and it's fast.

An Ultra 160 SCSI SSD device? My banker said "NO".

oxygen wrote:

[
Well ok, that was missunderstandable.
You said the Sun will mount the filesystem over NFS on the DNS-323, that will really painful. ofc the booting process itself is not a big problem, but mounting the root fs over NFS will degrade the performance heavily.

That much?
Both NAS and Sun got Gigabit NIC, this may help. I can use NBD (network block device) for better perfs, too.
That would give:
- local boot,
- root over NFS,
- datas over NBD. "datas" including "/var/logs".
Seems correct


An important fact is that the Sun server will run behind an ADSL line, so when uploading data to the Internet, it will send at max 1Mb/s. In this case, a slow filesystem doesn't matter.
I may use it locally too, from the LAN, and there speed will matter. Will see.

Grunt wrote:

An Ultra 160 SCSI SSD device? My banker said "NO".

Thats a problem, i admit. an addon sata controller is not an option?

Can be, I got a PCI SATA controller. Will see.

Grunt wrote:

Serial hardware mod is rather tricky. Hope I will succeed.

It really is not that tricky. Take a look at the version with the TRS connector that I posted on the wiki. You can make a really neat connector that does not alter the stock appearance all that much.

It sounds like you are quite eager to try low level hacking on your version C device. I am trying to get a replacement U-Boot loader built for the DNS323. I only have a version B1 device. Would you be interested in testing it on your NAS?

At this stage, I'm not suggesting that you consider flashing it to your JTAG at all. My current code omits the low level init code required to actually bring up the CPU, DRAM, etc, and relies on the existing U-Boot to do all that for me.

To be quite honest, I'm not sure where the main differences between the B and C hardware lie. Both seem to be based on the 88F5182 (as opposed to the A which used the 88F5181 + separate SATA controller).

I guess the place to start is by chain loading my current boot loader from your existing U-Boot.

Out of interest, please run "help" at the U-Boot prompt (or "?" if "help" does not work), and post the results here? I'd be interested to know whether your U-Boot is as badly crippled as the B version is.

Grunt wrote:

Here you are.

Code:

Hit any key to stop autoboot:  0 
Marvell>> ?
?       - alias for 'help'
bootm   - boot application image from memory
cp      - memory copy
echo    - echo args to console
erase   - erase FLASH memory
loadb   - load binary file over serial line (kermit mode)
md      - memory display
printenv- print environment variables
run     - run commands in an environment variable
setenv  - set environment variables

Yes, that is basically the same as the B.

I need a couple more days to get my boot loader into a working state (I hope), and I'll post it somewhere for you to try.

Grunt wrote:

Edit:

RoganDawes wrote:

To be quite honest, I'm not sure where the main differences between the B and C hardware lie. Both seem to be based on the 88F5182 (as opposed to the A which used the 88F5181 + separate SATA controller).

It's a 88F5118-A2, just looked on the board. Do you want pics of some parts of motherboard?

No, I don't think it is necessary. Thanks, though.

Back

Bought another one, and done all hardware mods.
I now own a DNS-323 working good, with a DB-9 on rear panel, well integrated (at first look it seems to be OEM), level adapter in the box (under motherboard, isolated), and RS232 works fine.

\o/

Last edited by Grunt (2010-09-06 22:52:20)

---

Attachments:
DNS-323-DB9-rear.jpeg, Size: 29,883 bytes, Downloads: 172

RoganDawes wrote:

B1 or C1?

C1.

Grunt wrote:

@RoganDawes:
Could you remind me the URL of the firmware you built for rev C1, and the procedure to load it into memory without erasing original firmware, please?

Hi Grunt,

I haven't built a firmware for C1, just a mainline u-boot loader, which I have attached to this post.

Instructions on how to load it are available on the wiki on the u-boot page (http://dns323.kood.org/howto:uboot).

NOTE: Do NOT try to flash this over your existing u-boot. It does not include the low level init code, and will brick your device!

This version DOES support flash access, and is configured to save the environment in the first 8kB of the flash. It has some pretty usable default settings compiled in, though.

NB: This is the same space that the DNS323 uses for its settings (Minix filesystem). If you are not prepared to lose your device configuration, do NOT use the "saveenv" command.

That said, you should be able to configure the network interface, give it an IP address, TFTP files, etc. Additionally, you should be able to spin up the disks in your DNS323, and identify them, and theoretically, copy data from them into memory.

Let me know how you get on.

Rogan

---

Attachments:
uImage.bin, Size: 142,468 bytes, Downloads: 256

Grunt wrote:

Have tried a bit this evening: minicom doesn't seem to work for sending u-boot, and gkermit seems to be very limited.

Or else I don't wait enough, but sending 142 468 bytes at 115 200 baud should take about 9 seconds, right?

I'm using gkermit on debian, with no problems.

What makes you say it is very limited? Did you follow the instructions on the wiki?

Last edited by RoganDawes (2010-09-10 09:53:57)

Grunt wrote:

RoganDawes wrote:

I'm using gkermit on debian, with no problems.

Mine is not interactive, so I cann't send space, 1, then "loadb".
Lauching gkermit just gives its help, and back to shell.

Maybe am I doing something wrong?

I have no idea. What platform are you running kermit from?

Did you try my "console" script (that starts #!/bin/kermit)?

Did you follow the instructions on the wiki?

I didn't build U-Boot from emdebian sources.. would that work? I figure out that rev C is not well known so maybe not supported, right?

Nah, you don't need to build from sources, since the DNS323 support is not actually submitted to the mainline yet. i.e. you wouldn't have anything to build. Just trying the bin that I attached above was all I hoped for.

So I downloaded kermit, without "g", and used it.

It worked fine, and I see your bootloader is far better than the OEM one:

Code:

88E1116 Initialized on egiga0
DNS323B1> ?
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dhcp    - boot image via network using DHCP/TFTP protocol
diskboot- boot from IDE device
echo    - echo args to console
editenv - edit environment variable
erase   - erase FLASH memory
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
flinfo  - print FLASH memory information
go      - start application at address 'addr'
help    - print command description/usage
i2c     - I2C sub-system
ide     - IDE sub-system
iminfo  - print header information for application image
imls    - list all images found in flash
imxtract- extract a part of a multi-image
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
md      - memory display
mm      - memory modify (auto-incrementing address)
mtest   - simple RAM read/write test
mw      - memory write (fill)
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
printenv- print environment variables
protect - enable or disable 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
setenv  - set environment variables
sleep   - delay execution for some time
source  - run script from memory
tftpboot- boot image via network using TFTP protocol
version - print monitor version

I was very happy to see that. Great job!

Thanks! I did very little. Most of the work was done by Albert Aribaud, for the LaCie ED Mini V2.

Now it seems I can try to install Debian using a network boot.

Not so sure about that. Keep in mind that this boot loader is NOT persistent, and has to be loaded via kermit each time you boot the device if you want to use its functionality.

The regular Debian install process works just fine with the existing boot loader. It's what I did in the end, installing to a USB flash disk.

Just got a question.

I've seen from the WiKi that flash support is lacking, what is the trouble?
The procedure for installing Debian (the ugly way) ends with a

Code:

dd if=/root/initrd.uImage of=/dev/mtdblock3

Where /dev/mtdblock3 is flash, right? So, writing to flash is supported?

The wiki is actually out of date. The u-boot binary that I posted above DOES support writing to the flash. e.g. you can try "flinfo" to show the sectors, etc.

The problem was that the flash chip was connected using an unconventional method. To get U-Boot to recognise it, all offsets need to be doubled. That code is also not yet upstream.

Anyway, I now have the necessary connectors to finish the JTAG interface. I'm just trying to pluck up the courage to actually solder them on, and connect the JTAG adapter. I have not had good luck with JTAG in the past, frying a router irretrievably. :-(

Anyway, one of these days I'll give it a go. When I do, I'll let you know.

In the mean time, you can explore the functionality present, such as the network level stuff (e.g. set an IP address, try to TFTP a file from a server, etc, etc), and confirm that all the high level stuff works.

My next step once the JTAG adapter is working is to try to build a version that will be able to boot the device from poweroff. Of course, I would not advise you to try it without a working JTAG adapter yourself.

Regards,

Rogan