Hello all,
I have done some further investigation and I thought I'd bring you all up to
date.
First in answer to a comment that Jeremy made:
>>> > Note that aboot/SRM console gives me problems with
>>> > fpu instructions - i suspect pal code problems.
Yes, there is a pal code problem. According to the Alpha architecture
manual, an opDEC instruction fault should return the PC of the instruction
AFTER the fault (since MILO works just fine, I have to conclude that it is
doing the right thing). However, the latest available Digital SRM (version
038) returns the PC AT the opDEC fault. So the following patch seems to
overcome the problem:
(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!)
==============
diff -Nau arch/alpha/kernel/traps.c
../linux-2.2.17-multia-kgdb/arch/alpha/kernel
--- arch/alpha/kernel/traps.c Fri Jan 12 04:31:34 2001
+++ ../linux-2.2.17-multia-kgdb/arch/alpha/kernel/traps.c Tue Dec 19
18:19:02 2000
@@ -449,6 +449,9 @@
case 4: /* opDEC */
if (implver() == IMPLVER_EV4) {
+#if 1 /* alpha SRM */
+ regs.pc += 4;
+#endif /* alpha SRM */
/* EV4 does not implement anything except normal
rounding. Everything else will come here as
an illegal instruction. Emulate them. */
=============================
OK, on to the Multia flash burning topic. I have downloaded the MILO-2.2-17
kit. I had to make some minor tweeks to get it to build, but I have
successfully gotten MILO to boot from the failsafe floppy as documented in
the MILO-HOWTO. Further, I have gotten the FMU to identify that there are
indeed 3 x Intel 27F020 flash devices, so the NoName code can correctly
address the flash chips for identification. However, it appears that the
NoName code wants to update flash roms 2 and 3, when on the Multia they are
roms 0,1, and 2.
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.
I thought I would avail myself of your collective wisdom before proceeding.
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".
However, if the rom should be laid out in a specific ROM-fs format as
Jeremy's suspects, decoding the entire 500k SRM image is a challenge I'm
not prepared to tackle.
As to Eric's comment:
>>I actually have the source to a SROM. And the license on it looks like I
can redistribute it, but I'll have to double check. I can >>definentily get
you the the format that is used by the firmware.
What is the status of the source to the SROM, and are SROM codes
sufficiently similar that they would apply to the Multia?
Thanks for all your help!
Bill
