Ronald G Minnich <[EMAIL PROTECTED]> writes:
> On 28 Aug 2001, Eric W. Biederman wrote:
>
> > Ronald G Minnich <[EMAIL PROTECTED]> writes:
> >
> > > Ollie, do you think that DoC will not fit then?
> >
> > Ron if it is anything like the recomendation for the AMD760 chipset.
> > The code will depend a lot more heavily on the SPD data then older
> > chipsets did. You can see how big my complete job for that got...
>
>
> OK here's a question for the list.
>
> If you think about the set of bits that you read from an SPD to get
> configuration data it is something on the order of 16 bits. If you look at
> the number of bits you have to set it is something like 32 or 64 bits.
>
> What this says is you can form a bit string from the SPD data, then turn
> that into an offset into an area of memory and from that get the
> programming for the registers.
>
> This would work if you had the ability to waste a lot of space. We have
> that with DoC.
>
> Of course it can get more complex, you can make the "address" bit string
> bigger and use it as an index into a gzip'ed bit stream. But given the
> presence of DoC I'm wondering if we can't get a little fancy.
Could we do paging on the doc? And just make certain to page in the subroutine
we are about to call before we call it?
I just got out my SPD chipset form the AMD760 and I am currently reading 17 bytes
of SPD information. And one or two of those bytes are timings in ns. So I don't
see how to condense them into an index.
For reference what I am looking at are:
SPD bytes:
3 number of row address on the assembly
4 number of column address on the assembly
5 number of Rows on the assembly
6,7 Data width of the assembly
13 SDRAM width
17 device attributes, number of banks
12 Refresh rate & type
11 DIMM configuration (Non-parity, Parity, ECC)
21 module attribtes (can detect registered dimms)
18 CAS latencies supported
9 cycle time at longest supported CAS latency
10 access time at at longest supported CAS latency
23 cycle time at next faster supported CAS latency
24 access time at next faster supported CAS latency
25 cylce time at next faster supported CAS latency
26 access time at next faster supported CAS latency
Maybe you can fit all of that in 512 bytes or an index but when you
get into timings I don't see how.
> comments?
Well if you can tell me how you would build your index from those
numbers I'd look at it. I would rather invent a calling convention
that could do paging on the doc. Call function A on page B.
Eric