Jeremy Jackson <[EMAIL PROTECTED]> writes:
> "Eric W. Biederman" wrote:
>
> > "Carr, Bill" <[EMAIL PROTECTED]> writes:
> >
> > > (NOTE: I would like to put in code to detect which pal code is running so
> > > that the code could automatically update the PC in the case of the latest
> > > (defective) Digital SRM pal. Suggestions welcome!)
> >
> > alpha_uses_srm is the variable to test.
> >
> > Though I really think linux should always load the appropriate
> > palcode and then this wouldn't be an issue.
> >
>
> This may be necessary; does SROM set up any PAL code, or is this the job
> of the ARC/SRM console code in flash.
Yes, and no. There is palcode present from the SROM, but it isn't useable.
MILO is still the big reference as to what need to/can happen at that
level.
> If so, LinuxBIOS will need to include
> its own PAL. I wonder if PAL code for Digital UNIX is really optimal for
> Linux/Alpha? I know it's really rough stuff to work with (arch handbook
> refers to subtle side-effects), but I think
> all of this ultimately points to a kernel (or a linuxBIOS) with its own PAL
> code.
Definentily. What I'm going to hack temporarily is a loader with it's
own palcode, stolen from MILO. And I'll see where I can go from
there.
>
>
> (Remember I'm only talking about these UDB/Multias I have here)
>
> >
> > > I was thinking of changing the code to burn flash 0, but I was way out of my
>
> > > depth and in my past midnight delirium, I did not want to do irreparable
> > > damage. I do know that I can restore the flash to the 038 SRM as long as I
> > > have not fried (as opposed to burned) anything.
> >
> > Cool so you have a recover mechanism. Is this something implemented
> > in your SROM?
>
> yes is the recovery boot floppy code in SROM?
Not in the SROM I have but's it a 264 SROM.
All I have is a dip switch that causes the SROM to decide which
image first or second in the flash to update.
Question what do you have in flash?
> This would make it a lot safer to experiment.
Yes. Which is why I have my flash chips socketed.
> > > Regarding Jeremy's comment about what to write INTO the chip, we have a copy
>
> > > of the SRM image from which we could decode the "board specific header".
> >
> > It isn't board specific. The documentation is actually in
> > flash/romhead.h from milo-2.2-17
> >
> > The format matches the comments in the SROM source for the ds10
> > so we should be in good shape there.
>
> I don't think this proves it; at least it doesn't address the fact that the UDB
> flash chips can't be updated in blocks. (i27F020) All the others (or at least
> the ones MILO knows about) can be reprogrammed in blocks. So the
> question arises, does the UDB use the same 64k-block format as the others,
> and just loose the flexibliity if reprogramming, or does it use a different
> format
> adapted to the limitations of the UDB's flash storage.
Well the organization is perhaps different. I'm pretty certain the
header is the same.
Before you go any farther get a dump of your flash chips into a file,
and scrutenize it to see if it's there. That should resolve at least
one issue.
> What would really be useful is the UDB's SROM listing and a board schematic.
> Maybe I should call up my dentist and see it he's not using the X-ray this
> afternoon. :)
Eric
