Re: Everyone's SRM woes

[Alan Young <ayoung teleport com>]

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