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

Yes looks like working like a charm. Now just need to find a good "how to" to install it...

I will look around for a how to; will post the url if success.

Ok great! Thanks; will try and let you know.
Did you took back your DSM G600 on tried it on it? Working good?

Hi,

I am the author of the NetBSD port and I found much valuable information on this site during development. Many thanks for that!

Of course, I am very interested in your experiences with it. You can always contact me when there are any problems. A detailed installation instruction will hopefully be finished this weekend.

Some weak points of the G600 port at the moment:
- LEDs can be controlled via /dev/satmgr, but altboot doesn't stop the power LED from blinking yet.
- The board and/or the SM8954A microcontroller do not offer any function to reboot or shutdown the system. Rebooting currently works by jumping through the firmware's reset vector.
- There is definitely a ST M41T80 RTC chip on the board. It should listen on address 0x68 of the I2C bus, but mine seems to be dead. Can anybody confirm that? What is wrong with the RTC? Does it work under Linux?

For installation a serial console is strongly recommended. You may be able to flash altboot from Linux, but you need the console for installation anyway.

What is loader.o?

sala wrote:

By default gentoo can't use rtc on dsm-g600. I haven't look much deeper,

Probably the chip was never working? But what a waste, to place a battery and a 32kHz oscillator on the board, just for an unused chip.
I scanned all adresses on the I2C bus, but found not a single device responding.

sala wrote:

I did just setup ntpclient since I did need one anyway because clock drift is horrible on this device using dlink kernel.

Yes, I did the same now.

sala wrote:

http://dns323.kood.org/dsmg600/howto:loader_o

Ok. I guess this won't work with altboot. The binary requires to be loaded and started at 0x1000000.
Even if it worked you still cannot install without a console.

sala wrote:

If one makes a tarball off from its installed version then other can extract it and jump in on using it.

You have to create a NetBSD disklabel and file system on your disk, before you can extract such a tarball. This may be possible by putting the disk into a second NetBSD/powerpc (or at least big-endian) system, e.g. a PowerMac, and prepare it sufficiently.
Is it possible to write to flash from the original Linux installation? Then this might be a theoretical solution to go without serial console. But when something goes wrong you're blind.

Gazou wrote:

Any chances that we could install it without the serial connector?

Provided you got a working NetBSD/sandpoint installation onto disk (e.g. created on a second NetBSD system), the only difficulty is to run altboot. Maybe it works by patching loader.o to load and execute altboot at 0x1000000.

sala wrote:

Now when I started to thinking back. Original firmware somewhat did make use of rtc by using rdc_rtc binary.

Hmm... how was it used? The attached rdc_rtc program is an x86 ELF binary. I doubt that it worked on the G600.

sala wrote:

Thanks for guide!

It still needs some improvements, but I wanted to commit it yesterday, before it takes another week.

sala wrote:

ppc version has eth0 and sysctl string in it....

That's interesting, indeed. I have disassembled the program, and as far as I understand it uses special ioctl() calls on an INET socket to access addresses in the I/O space. Something like:
  s = socket(AF_INET, SOCK_DGRAM, 0);
  ioctl(s, 0x89f8, arg);
  close(s);

The "arg" is a pointer to a structure with the following layout:
{
  char name[16];  /* filled with "eth0" */
  uint32_t ioaddr;  /* filled with an address in I/O space */
}

The addresses are in the range 0xfc003000 to 0xfc003010, which is where the 8245 I2C registers are located!

I have to read the disassembly more closely to analyze the I2C transfers. I also don't see what it has to do with eth0 yet.
Does no GPL source for this program exist?

This program does implement a complete I2C and M41T80 RTC driver. It accesses the usual RTC registers 1 to 7 at I2C bus address 0x68. It works identical to the NetBSD strtc(4) (M41ST84) driver (but without Watchdog and NVRAM).

That made me think. And indeed, after removing the battery from my board the RTC chip started working! But after another two or three restarts it was gone again, so there must be something which is confusing it.

I will investigate. But theoretically the RTC is working!

There was a small bug in the MPC824x I2C driver in conjunction with the strtc driver. Now everything is fixed. The RTC works fine.

I also fixed the external clock, which is 33.000 MHz, not 33.333 MHz, so the system time is precise now, even after running for days.

BTW, this means the MPC8241 is running at exactly 198 MHz, not 170 MHz as U-Boot erroneously prints.

sala wrote:

But I remember that altboot did print "IDE/SATA device driver was not found"

Hmm. This should only happen when your board has an IDE controller chip which is unknown to altboot.
Don't you have an ACARD ATP865 chip? PCI-vendor 0x1191, PCI-product 0x0008?
Otherwise it will fail and I would have to add your chip ID.

I have put a recent altboot onto our FTP server, compiled with DEBUG option, so it should generate some more information about your hardware:
http://ftp.netbsd.org/pub/NetBSD/misc/p … bug.tar.gz

sala wrote:

I was using altboot from here: http://nyftp.netbsd.org/pub/NetBSD-dail … tallation/

The 201104172300Z build has just finished and includes my latest changes.

sala wrote:

Btw, are these changes committed to trunk?

Yes, always. So the first official release with all the Sandpoint NAS ports will be 6.0.

sala wrote:

I'm still trying to get familiar with netbsd version tracking

For current snapshots you can use http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD, that's right.
Or you can checkout the source and build it yourself, which has the advantage that you can modify the source to find a problem  - and report it to me when fixed.