Re: Fwd: memory probing

[Douglas Wade Needham]

Quoting alfred hitch (address@hidden):
> Hi Doug,
> 
> thanks a lot for your explanation, it explains quite well now to me
> the x86 arch.

It is not just the x86, but the same is true of other architectures
such as the PPC (PREP/CHRP or not), 68K, VAX or any other CPU
architecture.  You have a CPU core, and connected to it via some
processor specific bus you have a memory controller and some form of
logic to convert from that processor specific bus to a more open bus
architecture such as PCI (or ISA/EISA, MCA, VME, etc.).  And indeed,
this is true even in cases where the CPU chip/module incorporates the
memory controller and perhaps even presents just a bus such as PCI.  I
have dealt with so many different CPU architectures over the years,
and have seen such a case.  This is because space on a board and
routing the signals costs money.  So just like the NB and SB chips are
sometimes combined, sometimes the process goes to the extreme and
everything is on a single chip.

BTW...if you want to learn more about computer architecture at this
level, you can find all sorts of stuff in books and in data sheets on
the web.

> Ok coming back to the discussion, sau bios reads this info from north
> bridge, north bridge gets this across reboots from memory module using
> i2c.
> 
> so, basically the info is coming from the memory chip ?
> We are using micron chips /banks and I just checked their data sheet,
> I dont see any such register there ..
> I see only memory init sequences etc .. 

This is correct.  If you see terms like serial presence-detect, SPD or
other names, this is what is being referred to.  Indeed, even the old
100-pin DIMMs had this functionallity.  Just take a look at this page,
and go to the data sheets...

    http://www.micron.com/products/modules/sdram/partlist.aspx

And in case you are wondering, the old 72 and 36 pin DIMMs had
dedicated pins which were either at voltage or ground, and through
pull-up or pull-down circuits were connected to the memory controller
logic to tell what size/speed a module was.  They had learned from not
knowing on the 30-pin DIMMs that they needed something, but they also
learned that 4-8 pins of "presence detect" and the associated logic
was too expensive, and so they went to the I2C bus solution.

Oh, I forgot to mention one trick which was done way back when and is
still occasionally done.  Bus transactions generally have the remote
end ACK or NACK the R/W transaction, and some memory controllers and
bus bridges were smart enough to have a timeout which would kick in
after so many ns.  So in the process of your POST, where the firmware
(BIOS) was doing writes to initialize for ECC/parity, this code would
do a trick.  It knew where the ROM was located, and would set a
timeout timer for some value (say 500ns), which was longer than any
memory should take to respond.  Then it would proceed to scan for RAM,
perhaps by doing reads every 64k.  Then having done this, it would
know how much RAM there was, and could go back and do the writes to
initialize for ECC/Parity, then start treating those errors as error
conditions.

> In IXP data sheet memory controller section mentions only one register
> saying size and that is being overwritten by value from bootloader
> (hard coded compile time #define)
> 2 other registes are to talk to / initiate state machine of dram init
> seq, etc ..

You might want to dig through the data sheets and see if that register
is pre-initialized and instead should be read.  Or perhaps you are
dealing with a register where it has a base address and length, and
the memory controller maps the memory bus where you tell it, and the
PCI (or other bus) into another area, etc.  If you want to see how
some of this works, I would suggest looking at the docs for the
MCP-750.  You can find info about it at:

    
https://mcg.motorola.com/cfm/templates/product.cfm?PageID=895&ProductID=22&PageTypeID=1

The best doc here would be the MCP750A/PG6, where on page 1-4 (page 30
in the PDF), you will see how these bridges come together, and it will
talk about some of the register settings on the Falcon memory
controller and Raven PCI bridge later in that section.  BTW...on that
doc, the Falcon/Raven combo would essentially be the northbridge of a
x86 machine, and the peripheral bus controller and PCI-to-PCI bridge
would be the southbridge.

> Seem to me a dead wall ahead -;)

No.  Just some work getting the right person to talk to at the
vendors, getting management to get the NDA in place, and then lots of
reading.  I should know, as my group at my employer is doing the same
thing with some Intel HW for a network switch.

- Doug

-- 
Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own.  Since I don't want them, why
            should my employer, or anybody else for that matter!