lkml.org 
[lkml]   [2001]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Encrypted Swap
    On 17 Aug 2001, Eric W. Biederman wrote:

    > "Richard B. Johnson" <root@chaos.analogic.com> writes:
    >
    > > On Fri, 17 Aug 2001, David Christensen wrote:
    > >
    > > > > > Ryan Mack proclaimed:
    > > > Most modern firmware does NOT clear memory during POST, it takes too long.
    >
    > Clearing memory on most machines takes a 1s or less. Think of memory
    > fill rates at the 800MB/s level. Most BIOS's seem to clear some of
    > the memory but I haven't read their code to see what they are doing.
    >
    > > > Certain compatibility areas are usually cleared (such as the 1st megabyte)
    > > > but the rest is
    > > > left as is, except for a few read/writes (usually on a megabyte boundary).
    > > > The
    > > > exception to this rule is ECC systems. They have to be written to make sure
    > > > the
    > > > ECC information is correct.
    > Correct.
    >
    > > > SDRAM memory sizing is usually done by reading an EEPROM on the SDRAM DIMM.
    > > > The BIOS doesn't need to guess the correct timing values, it simply reads
    > > > the EEPROM and programs the memory controller. In the case of a BIOS that
    > > > doesn't use EEPROM you might lose data as the BIOS iteratively tries
    > > > different memory timings and tests if they work.
    >
    > This would totally depend on your controller. But different timings
    > shouldn't affect your memory cells just the read/write paths to your
    > memory.
    >
    > > > I have done work implementing ACPI S3 (suspend-to-RAM) in DOS by simply
    > > > hitting
    > > > the RESET button and restoring the memory controller settings. The contents
    > > > of
    > > > RAM have always been valid.
    >
    > Hmm. That sounds a little risky. I have measured single bit errors
    > occuring as early as 1s after writing the data without somekind of
    > refresh running.
    >
    > > > David Christensen
    > > >
    > >
    > > I just posted working SDRAM controller initialization code. The SDRAM
    > > controller must be initialized in a specific step-by-step manner or
    > > else you don't even get to "restoring the memory controller settings".
    >
    > Comments frequently don't match the code. And how the SDRAM controller
    > must be initialized totally depends on the chipset and vendor. SDRAM
    > itself must be initialized in a specific matter.
    >

    That's what I said, and the comments match the code.

    > But for the case of a warm reset there is not need to reset the SDRAM
    > controller. Memory really only needs to be cleared in the case when
    > some form of error checking is being used.
    >

    Memory needs to be written (with anything). It must be written before
    it's used so that there are no "almost" logic levels within the cells.

    The parasitic currents from having some cells "just barely on" will
    totally screw up data retention in other cells. If anybody ever
    writes memory initialization software that doesn't perform this
    extremely important step, they just don't know what the hell they are
    doing and will contribute towards a poor reputation for software
    engineering.

    > Personally I think writing such code carries more credibility then
    > simply posting it anyway....
    >

    Well I wrote the code. And I have written SDRAM initialization code
    for many chip-sets.

    Cheers,
    Dick Johnson

    Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:57    [W:5.006 / U:0.432 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site