Re: Everyone's SRM woes

[Alan Young <ayoung teleport com>]

Umm, I think you have that backward.  The LX has only enough room for
one. The PC64 does have room for both.  I have both images in the PC64
now.:)

Alan

Kurt Ludwig wrote:
> 
> well yes and no on the dual booters part. The PC* series only had 1MB of
> flash on them so you would have to preform voodoo to get AlphaBIOS out and
> put SRM in, or vice versa. If you had something like an AS1200 / AS800 /
> etc. then you had enough room in the prom (2MB) for both. Even though the
> capability was there to run either it was still a pain.
> 
> Kurt
> 
> -----Original Message-----
> From: Alan Young [mailto:ayoung@teleport.com]
> Sent: Wednesday, March 14, 2001 1:24 AM
> To: axp-list@redhat.com
> Subject: Re: Everyone's SRM woes
> 
> Peter Petrakis wrote:
> >
> > Alan Young wrote:
> >
> > Agreed. Though like you said, these machines run UNIX not windows.
> 
> Well, my machines up til last year or so ran NT fairly regularly.
> (I've kicked my Lightwave habit for the moment...)
> The LX164 and PC64 and other machines were sold as "dual booters".
> You could run NT, Tru64 and even OpenVMS on a bunch of them.
> 
> > It's not an excuse to cop out of having a nice BIOS setup your hardware
> > and bootstrap your box.
> 
> Agreed.  I think this is why AlphaBIOS came into being.
> It was step in the right direction.
> 
> > I don't fully understand why milo was needed to begin with.
> > If it was all just to switch palcode and mess with some registers then
> > why couldnt ARC/AB be extend to use that PAL and do the setup required and
> your
> > off. The only thing you would care about is passing cli arguments and you
> > already could do that with ARC/AB.
> 
> Good Question.  I've never dug into that one.
> One would guess that Linus' and/or DEC's original port may have attempted
> to use the PALcode in the ARC firmware.  I've been trying to recall if
> BLADE was developed on a SRM box or not.... Since SRM was being sold
> seperately back then, MILO may have been a stopgap measure so people
> did not have to pay extra to run a (semi-)free OS.  They may have had
> ARC issues so something more SRM-like was substituted???
> Could also be ARC was centered around a certain 32-bit OS and did
> not "fully" support 64-bitness?
> 
> > I love the help on "ed". Try it , you'll get a laugh.
> 
> "BASIC-like"...:)
> Try "edit test" and then list it.
> THAT'S SHELL SCRIPT!
> No wonder there's no room in the flash for hardware initialization!
> 
> > > 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.
> >
> > I'm not sure of the exact mechenism that starts the firmware update CD.
> > It uses fwupdate, I dont know how that works.
> 
> Hmmm...I suppose fwupdate could be a program similar to aboot.
> 
> > > > 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.(?)
> >
> > SRM understands FS like FAT and ISO9660 but not the concept of
> > parititons.
> 
> I have to try that file system command you gave in that other post.
> Seems odd that it knows one without the other.
> 
> > > 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.
> >
> > I thought there where patches for aboot out there that let it understand
> > PC partition style?
> 
> Yes, I coded one set of them.  They're in the axp-list archive.
> Before I did my patches, Rumors were that patches had been done by
> someone else too.  I couldn't find them.  The problem is that the SRM
> boot block and the PC partition table occupy the same space on the hard
> disk.  I've seen references to a work around, but to do that you lose
> half the partition table entries in that block.  With Extended partitions
> you could work around that.  My patches just handle the entries in the
> primary partition block.  They would need a bit of code to traverse the
> linked list of extended partitions.  I'm not sure how NT would react to
> "code" for the boot block being there.  I've not tried to play with my
> partition table.  I boot aboot from floppy.  yeah, a tad slow, but it works.
>:)
> 
> > > 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.
> >
> > Here I disagree since those tools can aid the OEM, VAR, or Manufacturer
> > to troubleshoot and stress test the hardware. It would also be cost
> prohibitive
> > from a manufacturing POV to assmeble a product with the "full featured"
> firmware
> > and later reflash it to the econosize. The software could possibly diverge
> from
> > it's trunk so much that it becomes it's own thing and has it's own bugs
> ontop
> > of those of the "original" firmware.
> 
> Please reread the last half of my suggestion again.  I suggested that they
> be
> removed from the firmware image, I did not suggest to delete them entirely.
> If the functionality could be retained in a standalone executable, then
> nothing is lost and we can actually _gain_.
> 
> And I was using memexer and isacfg as examples as that was all could think
> off of the top of my head.  There could be better ones to migrate to a
> stand alone executable.  Edit for instance...  Even PCs have this as a
> seperate command once DOS has booted.
> 
> > > 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.
> >
> > It probably could be made a seperate image though now you run into
> > problems with starting the initial firmware. On most Alphas the SROM
> > that executes at poweron is told to load the second rom image and execute.
> >
> > Now if rom image number 2 was the bios emulator number 3 would be SRM.
> > There are two points of attack here now. Modify the SROM, which is a read
> > only chip to load image 2 then load and start image 3. Or fix independant
> > bios emulator rom so that when it's down initialize that it should locate
> > the next adjacent rom image (depending on jumper configuartion) and load
> > it.
> >
> > You could make your own SROM using the EBSDK, thats one. It has source
> > code for sx,lx, and dp. I'm talking about version 4.0 . To accomplish
> > option number two you would need the source to the bios emulator, which I
> > suspect won't be readily offered by Compqa so you're forced to seek
> alternatives
> > like the one used by the xfree group.
> 
> Would you really need the source to the emulator?  I mean, if the community
> could conveince Compaq to provide an occasional binary snapshot with a
> README that said how to execute it, that would be similar to the binary only
> that we have today in MILO.  You compile your custom code and link with the
> emulator binary.  To me it seems like it would be a win for us and Compaq.
> 
> > I have accomplished the later but in a roundabout way. In my first
> attempts
> > to use DBM for the LX I tried to load it from the FSB and wondered why I
> heard
> > a few beeps but then nothing on my display (VGA). I then got clever and
> > renamed the file lx164nt.rom, put it on a floppy, and in srm entered "NT".
> > which read the DBM ,loaded it, and executed it right over the SRM console.
> > Since the DBM image didnt have a bios emulator attached and the setup
> > routines that go with it. It didnt reset the console, it just loaded :-)
> 
> Heehee... I thought of something similar to this a while ago.  Before
> the concept of a generic Alpha kernel came to be, I worked a bit on
> a boot/install loader that one could execute from ARC.  It would sit
> on the CD as \ALPHA\ARCINST.EXE.  Then all you would need to do was hit
> the "Install Windows NT" option from the ARC menu.  ARC would load and
> run it.  The program would use then the ARC ID to identify which machine
> specific Linux kernel to load and boot.
>  
> > Speaking of the EBSDK. If one had it could one put it on an ftp
> > site and redistribute it? The license is a BSD'sh for Alpha only.
> 
> Well, I'm not a lawyer, but I'll take a stab...
> 
> > 1. GRANT
> >
> > Compaq Computer Corporation ("COMPAQ") grants you the right to use the
> > Software Programs  and Restricted Software Program (the "Software")
> > specified above on any number of computers  according to the following
> > terms.
> >
> > You may copy, modify, and distribute the Software Programs (in both
> > source and object form) and  its documentation.
> 
> This bit is interesting.  It sounds like you can distribute the
> source and object code and documentation.
> 
> > You may distribute but not modify the Restricted Software Program.
> 
> However, this bit may be bad.  What do they mean by "Restricted
> Software Program"?  The whole kit?  It also seems to imply that you
> can NOT modify whatever has been defined as "Restricted".
> 
> > All copies of the Software and object code derived from the sources
> > are to be used solely within  products incorporating an integrated
> > circuit implementing the Alpha architecture. The permission  is granted
> > regardless of the origin of such integrated circuit provided that the
> > COMPAQ copyright  notice and these license terms appear in all copies.
> 
> No problem there. :)   I think we can safely say that we all plan to use
> it on Alpha boxen whether they be DEC, Compaq, Samsung or other.
> 
> > You may not use the name, logos, or trademarks of COMPAQ and affiliated
> > companies unless  agreed in a separate agreement. You agree to indemnify
> > and hold COMPAQ harmless for all  claims and related expenses incurred
> > by COMPAQ as a result of your use or distribution of the  Software and
> > object code.
> 
> This also seems to imply that you can distribute code.
> 
> > 5. U.S. GOVERNMENT RESTRICTED RIGHTS
> >
> > Commercial Computer Software, and Computer Software Documentation, and
> > Technical Data for  Commercial Items are licensed to the U.S. Government
> > with COMPAQ's standard commercial  license and, when applicable, the
> > rights in DFAR 252.227-7015, "Technical Data - Commercial  Items."
> 
> This bit definatly needs a lawyer.  DFAR is sticky when it comes to rights.
> 
> > 6. GENERAL
> >
> > You are responsible for compliance with all applicable export or re-export
> > control laws and  regulations if you export the Software. This agreement
> > is governed by and is to be construed under  the laws of the Commonwealth
> > of Massachusetts.
> 
> As long as there's no restricted encryption used in the code this should
> be ok too.
> 
> > If you have any questions concerning this Agreement, please contact your
> > local COMPAQ sales  office or write to: Compaq Computer Corporation,
> > Software Business Practices, ZKO1-2/D22,  110 Spit Brook Road, Nashua,
> > NH 03062-2802.
> 
> Well, there you go.  Write 'em! :)
> 
> <snip>
> 
> > anybody know a lawyer?
> 
> The rest of those looks pretty reasonable to me, but I'm not a lawyer.
> And I don't know one.
> 
> Alan
> 
> _______________________________________________
> 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