Allen Briggs <briggs@canolog.ninthwonder.com> writes:
> * We loaded firmware off a CD-ROM:
> 	VPP PAL X5.48-82000101/0SF PAL X1.35-82000201 - Built 1-DEC-1994
> 	KN15-AA -V6.0-S7D2-I1DE-sV1.0 DECchip 21064 P3.0
>   This allows us to actually grab and boot the bootblock, but it fails
>   with:
> 	Loading netbsd...
> 	boot: boot device name does not contain ethernet address
> 
> 	Boot device name was "BOOTP 0 7 0 0 0 2 CORE-IO"
> 
> 	Your firmware may be too old to network boot NetBSD/alpha
> 	or you might have to hard code an ethernet address into
> 	your network boot block with setnetbootinfo(8).

Yah.  setnetbootinfo is what you need to use.


> * Thinking that the firmware might be too old still, we grabbed a newer
>   version off DEC's ftp site:
> 	VPP PAL V5.56-82000101/OSF PAL V1.45-82000201 - Built 25-SEP-1996
> 	KN15-AA -V6.9-S87A-I212-sV1.0 [...]
>   Using that, we get a similar error to the first: bad checksum on the
>   TFTP request (admiral is the alpha, amana is NetBSD/sparc--the trace
>   is from NetBSD/i386):
> 15:10:25.180739 admiral.rrinc.com.24010 > amana.rrinc.com.tftp: 27 tftp-#0 [tos 0x1] (ttl 30, id 2447, bad cksum 92fc!)
>   The alpha prints:
> 	AUDIT_BSERVER_FOUND
> 	? T_ERR_NI - RECIEVE_TIMEOUT
> 	84 FAIL

So, FWIW, i've heard that this has been attributed by some DEC folks
to "hardware bug," which is absolute bullsh*t.  (I ran into a similar
problem with new firmware on a 3000/300 when i was at CMU.)

It's not a hardware bug if a previous version of the software could
do the right thing.  8-)


>   The corresponding tcpdump trace from the previous ("Loading netbsd...")
>   boot is:
> 15:14:31.458121 admiral.rrinc.com.4858 > amana.rrinc.com.tftp: 27 RRQ "/boot.netbsd.alpha" (ttl 30, id 2447)



> * We also tried 7.0 (the only other version we found at DEC's ftp site).
>   Same result as with 6.9.
> 
> So, the 6.0 firmware looks like the best bet so far.  I tried to build
> and use setnetboot(8) on the NetBSD/sparc box--changing the byte order
> in a few places and adding in a couple of LLs (Kudos to Chris (I assume)
> for the u_intN_ts in that code).  The program appeared to work, but I
> got the same result from the boot block.  I tried using setnetbootinfo
> with and without the -f option.

setnetboot info should do the right thing.  The boot block just gives
the same message?  maybe the data's being stuffed into the wrong
location in the boot block...  you're sure you're using the 'fixed'
boot block?  8-)


> Does anyone have any ideas or suggestions?  If we need another version
> of the firmware, it would be nice to know where to get it, too.

the 6.0 version should be fine.  if you still don't have any luck,
e-mail me the info you need, and i can do the setnetbootinfo for you.


> If we can get this thing running, I'd like to take a little time to try
> to get the Turbochannel and CXT/SFB functional.  It's the only alpha that
> we have access to...

the TC should work.  I had an output-only driver for the SFB (could
print chars via the old wscons), but since I didn't have any input
side (didn't do the lk input bits, but i guess others have done much
of that since) didn't try to use it often, and i never updated it for
the new wscons code.  (dunno if anybody else has.)


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.
Plug: Get your official NetBSD-1.3.2 CDROM set today! http://www.netbsd.com/