Date: Sat, 15 Apr 95 10:12 CDT From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: freebsd-current@FreeBSD.org Cc: uhclem@nemesis.lonestar.org Subject: Re: Memory init pattern Message-ID: <m0s09Wp-0004vsC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
[1]On Fri, 14 Apr 1995, Rodney W. Grimes wrote:
[1]Yes, setting it to 0xDeadBeef is a very good idea, that way you
[1]can find out some times when you pick up a wild pointer by the
[1]value in it :-).
Ugh. You do realize that selected Microsoft products used this
same pattern for a while in 1992 (I know Modular Windows did).
Then MS removed it because of protests from leaders of a somewhat large
group of people (millions?) out there whose religion doesn't eat beef and
didn't like this message being in something that they or their children
might see. I know Tandy demanded its removal as well so they wouldn't
have any trouble at the retail level over something so easily avoided.
It might be wise to avoid something that even managed to trip up The
Great Bill. :-)
FYI, I have worked with Phoenix BIOS source code (at least the
tree used by Tandy for Tandy, GRiD, DEC and Panasonic computers)
and it did write a value to every location in RAM partly to do the
sizing, but mainly to initialize parity bits. This included extended memory.
What has happened more recently is that TI has been suing computer
makers for performing power-on diagnostics and the memory test
(not the initialization) was considered to be one of them. That is
why some machines now do no tests at all, or others you have to press
some key to cause them to occur. (TI had a patent on a microwave
oven power-on self-check from '78/'79 and began using it against computer
makers. I came up with published prior art of a product with power-on
self tests but the corporate lawyers where I used to live apparently never
did anything with it. They eventually settled the various suits.)
Anyway, because of TI, a lot of systems only initialize RAM to
force parity and do a spot sizing, checking a word on 256K-byte
boundaries. Some BIOS versions don't even initialize the other locations
because the BIOS was assembled for a "no parity" platform. ("Makes it
boot faster", says the comment on the conditional.) But what you frequently
see is garage shops and other vendors forgetting which way they have the
BIOS set and shipping a non-initted BIOS on a system with parity memory or
one that doesn't take care of memory above 1Meg (a bug in one BIOS
version I know of).
Microsoft apparently ran into this type of stuff, and some of their
initialization in various systems (Windows %s) assumes the BIOS didn't do
the job correctly and repeats the write.
Even SCO didn't have the memory sizing test right at one point. The
test pattern wasn't complex enough and they would mis-size memory by
40 or 50K by reading bus ghosts of the pattern written to an adjacent
16 bits. Strangely, SCO allows a system to have 4.043Meg of RAM or
any other size you can think of. :-)
It is a good idea to at least initialize all of RAM that we plan to use
but I would pick a less annoying pattern. (Naturally there is some
low memory info like the CMOS size compute and other goodies that we should
utilize before we lay-waste to the below-640K areas, or perhaps we could
limit the re-write to above memory 1Meg, as that is where most of the
bad-inits usually occur.)
Also, any pattern written must be unique across adjacent two 32-bit
values. In other words, don't write 0x12345678 and in the next 32 bits
write 0x12345678. You are setting yourself up for ghosting in 64/32-bit
system. You wouldn't believe how long it took to prove to SCO this was
happening on a 32/16 bit system, and we had the logic analyzer!
(If you want details on how this happens, send mail. I've written a few
dozen memory diags over the years.) :-(
I think I'll go have a taco now. :-)
Frank Durda IV <uhclem@nemesis.lonestar.org>|"Modular Windows - Windows for
or uhclem%nemesis@trsvax.ast.com (Internet)| your TV, with "Network printer
...letni!rwsys!nemesis!uhclem | out of paper" messages still
...decvax!trsvax.fw.ast.com!nemesis!uhclem | buried inside. Huh?"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0s09Wp-0004vsC>