Re: eb164 SROM

Maurice Hilarius (
Fri, 8 Nov 1996 18:53:38 -0700

At 07:11 hrs. 11-08-96 -0600, you wrote:
>> Nope, don't think so. Ponder this:
>> Machine I am sitting next to:
>> 300MHz EB164
>> 256 MB RAM
>> 2 MB cache
>> ncr 53c810 scsi
>> 1 x quantum XP 34300 fast scsi 3 (wide)
>> trio64+ s3 video
>> 512MB swap on sda1 1, root on sda2
>> Things to check:
>> SROM's on some machines don't recognise RAM properly. Does SRM or MILO see
>> right amount of RAM?
>> Bad cache can show up in mysterious ways, as well. Only way to check this is
>> to change it (not so easy, as it is a very special part).
>> I do know that after fighting with an EB164 very much like yours, it is now
>> running kernel 2.0.24, and is quite happy so far.
>> I am fighting with a Buslogic on it, and after that it is pretty well where
>> I want it to be.
>> >first, (this is during 3.0.3 and 4.0 installs) mkswap fails.
>> Yup, this happened to me too, until new SROM was installed. System at that
>> time only saw 64MB< not the 256 that is in it.
>Okay, Okay... :P I think that I am seeing the light. After paying attention
>to what you were saying, I looked through my (sparse) manual, and located the
>SROM. In the diagrams, it is number 16, component number U12, described as:
>"Xilinx serial ROM (initialization code) chip (mbB164.30)"
>and it is located right next to the bottom SIMM socket. It IS socketed, and
>has a yellow paper label that reads "U12 DAF2"
>I suppose that this is the little creature that needs to be replaced. :)
>I was fooled, because the SRM console ALWAYS saw 128 MB. MILO, however,
>had to be told that I had 128 MB, or would default to 32 MB.
Ah-ha !
And when I first saw this problem, I always got 64MB.
The reason: DEC decided to use the pd jumpers to provide a "quick" memory
size to SRM. The fact , though, is to use these for what the JEDEC standard
said they are for, and that is to inform a system of memory _speed_.
Because this bogus code on the SROM is looking for this in the non-standard
way, it always reads a particular size due to whatever the pd jumpers are
set to on the RAM. My solution to this came in the form of new SROM's from
DEC. There _is_ a program that can reprogram these, but the problem is, to
run the program you need a healthy machine, which is using RAM properly.
Call your Digital source and ask for the "fixed" SROM's. They should be
aware of the problem.

>> >> Do the milo and kernel versions have to match?
>> No, I have booted this machine with it's older 2.0.12 and worked OK as well.
>I find this interesting:
>With the 2.0.12 MILO and the 2.0.18 kernel, fsck would always validate my
>/usr partition, whereas with the 2.0.22 MILO and the 2.0.18 kernel, it would
>always FAIL. Ack. Happily, it took that catalyst to get me to see the
>light. If I had been following the (ahem.. unspoken) rules (bug!) and
>had / and /usr on one partition, I'd have never had that kick in the pants
>to get a solution.
>thanks much for your insight.

| Maurice Hilarius | The Past is History |
| President / Computer Entomologist | The Future is Mystery |
| Hard Data Ltd. | Today is a Gift |
| 403-456-1510 / FAX 403-457-1338 | That is why they call it |
| | The Present |

To unsubscribe: send e-mail to with
'unsubscribe' as the subject.  Do not send it to

Feedback | Store | News | Support | Product Errata | About Us | Linux Info | Search | JumpWords
No Frames | Show Frames

Copyright © 1995-1997 Red Hat Software. Legal notices