Re: Everyone's SRM woes

[Alan Young <ayoung teleport com>]

Peter Petrakis wrote:
> 
> I agree. I "like" SRM. I'm confortable with it and have come to
> appreciate all the neat things it can do for you. Never is there
> a "BIOS" I have seen that gives you so much control
> and does it with as much grace as SRM console does.

Unfortunately, this is one of the main things that drives people
away from setting up Alphas.  As much as SRM seems to offer, it's
interface is not very intuitive.  It's aimed at the power user
*nix geek.  (It's a problem that Linux in general has too.)
However, as people get attracted to the OS and the hardware it
becomes more of an issue from a learning perspective.  ARC was
a bit better, AlphaBIOS tried to make it homely (maybe too homely
[although the opening Alpha logo was cool]).  IMHO, I think the
basic menu of a Award or Phoenix based PC BIOS is good.  You get
in, hit the menu items you need to, set the boot order (floppy,
hard drive or CDROM), get out and reboot. :)

My biggest beef with SRM is   DOCUMENTATION.   As far as I can
find there is none, at least not up to date.  There's an ancient
one in the Compaq/Digital documentation archive.  But I've never
seen a current one.  Not even on the firmware update CD.  And
help <command> is too vague for some of the commands.  (If it
matters I have a LX164 with SRM 5.8-1.)

> Yes but the kicker here is you have to load that secondary bootloader
> from an SRM supported device. So unless you always want to load
> firmware X off a floppy (which isnt the most reliable
> medium in the world) you're back to square one.

I believe you can load the firmware off of CDROM too.  If I recall
right, I think this is how the firmware update CD works.

> EXT2 support in SRM is nice but whats stopping SRM from loading linux
> off a FAT fs of which it already understands?

I thought SRM did not understand filesystems.  I thought it knew
enough about a device to pull physical blocks of media into memory
and execute the code from there... that's why aboot was written to
read the ext2 partition and load the kernel.(?)

What would really help for those that may still run NT or perfer
slightly more sane partition table format is if SRM could be told to
look for the boot block somewhere other than what is the DOS/PC
style partition table sector. 
 
> If I could drill it into people's head to use BOOTP as their primary
> boostrap method this discussion wouldnt have half the urgency it
> presents since the #1 killer here is not being able to boot off host
> adapter X. Again, I'm assuming here that majority of  people have 
> small private networks with a DHCP server. It's not like you can't
> get a SRM support ethernet device, Any intel nic will do. I wish 3Com
> worked as well but ho hum.

The other problem with BOOTP is the person just getting started with
Linux and/or Alpha.  Setting up another server just to boot a Alpha
will scare even more people away for time and money reasons.

> I agree that the host adapter list is way too short and wish it could be
> extended.  Problem is from a engineering POV. If you just added X new
> features to SRM console you now have X regression tests to set guidelines
> for and implement.
> Else you document what you did, make an errata, and call the software an
> unsupported BETA. Both require some amount of engineering resources but
> before that there would need to be a concensus from managment to implement
> one of the projects to begin with.

Well, how about _removing_ some of the more esoteric features of SRM to
stand-alone executables.  I'm talking about things like memexer, isacfg,
etc. that are nice but take up space and you don't need them to boot
the machine all the time.  ARC/AlphaBIOS was good for this as it had a
SDK that you can program with your own add-ons  (ARCDOS being one example).
The executables could be loaded from disk or floppy.  If those features
could be moved out of SRM and still being accessable (say on a bootable
CD) for those that need it, then you could put more enhancments into
the base SRM.

> Video support would be a "nice thing".  It's not a need per say but
> those of us with 3 year old LX's who don't have the ching to spend
> on a UP1K "just" to get a AGP graphics card is unreasonable. Especially
> so since there hasnt been an "affordable" Alpha in the price/value
> market since the SX and that was... almost 3 years ago. A new bios
> emulator would let folks able to go out and get the PCI Radeon cards,
> Oxygen GVX1 cards (which X has yet to support AFAIK), and IBM's fireGL
> 1 (has that been released yet?). Short list yes  but the list is too
> short as it stands already.

I disagree.  Video support is number 2 after storage controllers.
How many times do we watch and see the new PCI/AGP card-of-the-month 
come out and go ooooh that would just make my Alpha fly, only to get
one and be greeted with a blank screen (if you're lucky it boots at
all).  I mean I'd love to slap a Geforce2 MX into a PC64, but it
doesn't work.  On the flip side when the Multia's got blown out and
everyone seemed to be buying one, there were all sorts of inquiries
to the lists about which card can use etc.  Some people were able
to find the S3 cards.  I don't know what the people that could not
find one did, hopefully not junk the board.

I know you can't please everyone all the time.  And I know it
does boil down to money at some point.  It's too bad that at least
for video that the emulator couldn't be seperated from the console
in some way so people with old machines could at least update the
emulator.
 
> > I have probably rambled too much.
> 
> You think you where rambling?
> it's a good thing sometimes :-)

It's a good thing.  It goes along with venting. :)

Alan

P.S. Peter, none of the above is meant to respond to you only.
     I _was_ venting...