Re: Synology CS 407e: altboot fails to load installer.

[Frank Wille <frank%phoenix.owl.de@localhost>]

On Sun, 8 May 2011 16:42:14 +0200
Oscar Molin <oscarmolin%gmail.com@localhost> wrote:

> _MPC824X > go 1000000 debug
> ## Starting application at 0x01000000 ...

The "debug" option is only recognized by the NetBSD kernel. Altboot has
to be recompiled to include debugging output (see below).


> >> NetBSD/sandpoint altboot, revision 1.7 (Tue Apr 19 09:38:13 CEST 2011)
> >> Synology DS, cpu 265 MHz, bus 132 MHz, 64MB SDRAM
> [...]

You are using the debug version from /pub/NetBSD/misc/phx/sandpoint,
not 201105062100Z. That shouldn't make any difference for SKnet, but
it fortunately allows me to compare it with my DS-101g+.

The only difference I have seen is that the CS-407e got an additional
Satalink device at 12. The rest is completely identical, including the
PCI device revisions.


> MAC address 00:11:xx:xx:xx:xx
> PHY 0 (0141.0c25)
> 100Mbps-FDX

And you also have the same PHY and connect with the same media.
That's frustrating, as there is no obvious reason why it shouldn't work
for you.

Our SKnet chip is a Yukon-Lite. It has a config and chiprev register
which could be different, so I added a line to altboot which prints
something like:

config=93 chipver=b1

I would hope your output is not the same. Otherwise I'm running out of
ideas.

Additionally I reworked the PHY-reset code and extended the transmit
timeout.

I have compiled a test version for you which you can download at
  ftp://ftp.netbsd.org/pub/NetBSD/misc/phx/sandpoint/altboot_sk.bin.gz


> This xmit failed message I assume is a message from net driver,
> hopefully from the sk98 driver or whatever you have in altboot for sk.

Yes, it is. I wrote a minimal SKnet driver for altboot last year, based on
the kernel's sys/dev/pci/if_sk.c code, as there is no public documentation
available for this chip.

It happens in skg_send() of sys/arch/sandpoint/stand/altboot/skg.c.


> I guess the "xmit failed" is a failed transmission, possibly of the
> first dhcp request message?

I would bet it already happens with the first frame to be transmitted
(which could indeed be the DHCP request). Your driver doesn't send a
single byte.


-- 
Frank Wille