Re: Everyone's SRM woes

[Alan Young <ayoung teleport com>]

If Compaq doesn't believe the cost of creating CDs, packaging, etc. is
worth it for those few that are interested in such a package, could the
SRM development kit (or pieces there of) be offered as a "downloadable"?
The ARC ADK was offered this way until NT died.

Alan

"Jemiolo, John" wrote:
> 
> Until the Compaq purchase, Digital offered a SRM developers kit, that
> included documentation, code samples, and OEM pal code (the pal code Milo
> uses). for about $125. However when Compaq sold off the OEM group they
> stopped offering this kit.
> 
> Maybe some pressure could be brought to offer the kit again.
> 
> JJ
> 
> -----Original Message-----
> From: Alan Young [mailto:ayoung@teleport.com]
> Sent: Tuesday, March 13, 2001 12:09 AM
> To: axp-list@redhat.com
> Subject: Re: Everyone's SRM woes
> 
> 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...
> 
> _______________________________________________
> Axp-list mailing list
> Axp-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/axp-list
> 
> _______________________________________________
> Axp-list mailing list
> Axp-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/axp-list