[9fans] bootalphapc

[Ben Huntsman]

I'm working with some of the Alpha sources, and could use a bit of insight. For starters, the bootloader is called "bootalphapc", as opposed to "bootalpha", which leaves me wondering, is this only for AlphaPC-style Alpha systems, or should it work on AlphaServers and the larger systems as well?

Also, is there a technical reason that it must boot from a network, as opposed to from a CD or floppy? After all, the SRM firmware is fully capable of booting from such things...

Thanks in advance!

[Geoff Collyer]

The Plan 9 port for the AlphaPC is only guaranteed to work on AlphaPC
164s. I have a 164LX and Plan 9 worked on that until some months ago,
when interrupts from the PCI bus stopped working. DEC continued its
trajectory from the PDP-11 through the VAX to the Alpha of excluding
more and more of the sorts of things you'd need to get a machine
booted from what it considers to be <sound of trumpets> Architecture
and calls them <sound of razzberry> Implementation-specific. Having
granted themselves licence, they then went hog-wild and build lots of
systems with wildly varying Implementation bits. Andrey made a quick
attempt at getting the AlphaPC port to run on an Alphaserver. It
didn't work, didn't look easy to make work, and he couldn't devote
much time to it.

The Plan 9 alphapc boot code uses the SRM firmware for the actual I/O,
which may be why it's so slow. If you're willing to write the code,
it ought to be possible to boot from other devices. Getting
documentation on the firmware is likely to be the tricky part.

[George Michaelson]

NetBSD Alpha loyalists are.. well loyal. If there is a frob, they are likely
to know about it.

It might be hateful, but would booting or boot-strapping via a NetBSD kernel
initialization phase maybe be the way to go? You could acquire control of a
machine in a tolerably well initialized state that way.

I don't mean to imply they know any more than anyone here, more that they do
seem to be tenacious, and have squirrelled away a wide variety of the hosts,
the proms/srm revisions, tech notes etc.

http://www.netbsd.org/Ports/alpha/

-George

[Ben Huntsman]

My thoughts also. Using the *BSD Alpha bootloader to boot a Plan9 kernel shouldn't be impossibly difficult. I also did scrounge up a very excellent piece of documentation on SRM, and even acquired the OSF Palcode, which may be of assistance.

As for Mr. Collyer's post, do you remember what didn't work and/or why for the AlphaServer port?

Thanks again!

>>> George Michaelson<g...@apnic.net> 7/1/2004 9:36:05 PM >>>

[andrey mirtchovski]

> As for Mr. Collyer's post, do you remember what didn't work and/or why for the AlphaServer port?

i got the kernel loaded via the usual means (srm+bootp) but could get
no interrupts working for the ethernet so i couldn't mount the file
server... (i.e. i got it up to 'root is from:')

andrey

[Ben Huntsman]

>i got the kernel loaded via the usual means (srm+bootp) but could get
>no interrupts working for the ethernet so i couldn't mount the file
>server... (i.e. i got it up to 'root is from:')

Dumb question, I'm sure, but did you have the EBSDK? I know it contained netbooting code...

[andrey mirtchovski]

no, i had nothing of the sort (EBSDK) :(

andrey

[j...@plan9.bell-labs.com]

Fixing problems like that is not usually too difficult,
by looking at the *BSD code as has been mentioned.
Jean Mehat <j...@ai.univ-paris8.fr> did it recently for one
of the Alpha DECstations.

There is a wealth of information out there about the
hardware and how to make it work. It's a pity the companies
who bought the pieces of Digital didn't inherit their
attention to documentation.

[andrey mirtchovski]

On Fri, 2 Jul 2004 j...@plan9.bell-labs.com wrote:

>
> Fixing problems like that is not usually too difficult,
> by looking at the *BSD code as has been mentioned.

> Jean Mehat did it recently for one
> of the Alpha DECstations.
>

my alpha is up officially, though there's still some IRQ weirdness to be
ironed out. thanks to Jean Mehat for the sources.

it is an Alpha Personal Workstation 500au:

alpha% cat '#P/cputype'
21164A 500
alpha% pci
0.12.0: 03.00.00 1011/000d 248 0:90000008 4194304
0.3.0: 02.00.00 1011/0019 240 0:00009001 128 1:80159000 128
0.7.0: 06.01.00 1080/c693 240
0.7.1: 01.01.80 1080/c693 222 0:000001f1 16 1:000003f5 16 4:000090a1 16
0.7.2: 01.01.00 1080/c693 223 0:00000171 16 1:00000375 16 4:80140000 65536
0.7.3: 0c.03.10 1080/c693 218 0:80158000 4096
alpha%

andrey

[Ben Huntsman]

Did you use the out-of-the-box bootalphapc, or some other method to get it going? Also, is your filesystem running locally on the PWS, or from another machine via network? How much trouble was all this? Thanks!

-Ben

>>> andrey mirtchovski<mirt...@cpsc.ucalgary.ca> 7/6/2004 9:13:41 AM >>>

[andrey mirtchovski]

> Did you use the out-of-the-box bootalphapc, or some other method to
> get it going? Also, is your filesystem running locally on the PWS, or
> from another machine via network? How much trouble was all this?
>

i boot using bootalphapc from a Plan 9 cpu server on which i've
started ip/tftpd and ip/dhcpd. the ndb configuration for the alpha
(i.e. what the dhcp server will look at) is:

sys=alpha
ether=0000f875fafa
ip=192.168.1.5
bootf=bootalphapc
proto=tcp
fs=136.159.220.110
auth=136.159.220.110
authdom=plan9.ucalgary.ca
ipgw=192.168.1.1
dns=136.159.5.14
dns=136.159.5.15

not all of this is required (it should be in the ipnet= configuration).

bootalphapc looks for a configuration
file describing the machine in /alpha/conf/AA.BB.CC.DD (the ip address
of the machine booting). there's an example there (10.0.0.2), and here's
what i have:

plan9% cd /alpha/conf
plan9% ls
10.0.0.2
192.168.1.5
plan9% cat 192.168.1.5
bootfile=/alpha/9apccpu
bootargs=tcp
ether0=type=2114x
fs=136.159.220.110
auth=136.159.220.110
plan9%

bootalphapc downloads the kernel via tftp and jumps to it.

as for hard -- it wasn't hard at all. the kernel booted to 'root is
from:' immediately, the only thing i needed to do is fix interrupts
(the PCI interrupts seem to be offset by 8). there's still something
wrong with the clock interrupts, of which there are about 500 extra
ones generated every second.

the combined time wasn't more than 4-5 days, of which most was spent
trying different permutations of the IRQ settings and waiting for
others who know to reply to my silly questions.

andrey

ps: http://pages.cpsc.ucalgary.ca/~mirtchov/screenshots/alpha.png