I did a lot of experimentation with DoC Millennium because we have a tricky
(large) SDRAM sizing algorithm which does not entirely fit into the 512
bytes available. I was also in contact with the guys at M-Systems and the
bottom line is that it is not possible to page the DoC. It is not possible
to page data into the SDRAM on the Millennium. Our thoughts were to have a
uniform exit/entry from to contiguous pages of the device and to do some
form of paging, but it is just not possible.
The only option with larger code is to use the Millenium+ or the new
DOC2000, but of course these devices are only available in a 48-pin TSOP-I
package so it is a problem using them as an aftermarket device, unless of
course someone made an adapter to fit the new devices onto a 32-pin DIP
socket.
Just for your info, the 2 new devices are:
MD2811-D32-V3 - 32MByte Doc Millennium Plus with 1k SDRAM (8 or 16-bit data
bus)
MD2211-D16-V3 - 16MByte DoC2000 with 1k SDRAM (8 bit data bus)
In our environment though, we generally have an embedded system with the
SDRAM soldered directly on the board so we *SHOULD* know what we are dealing
with! At this point in time we are just hard coding the SDRAM type into the
LinuxBIOS.
Hamish
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Eric W. Biederman
Sent: Wednesday, August 29, 2001 5:12 AM
To: Ronald G Minnich
Cc: Ollie Lho; [EMAIL PROTECTED]
Subject: Re: SIS 730/SIS 735
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
