Quoting alfred hitch ([EMAIL PROTECTED]): > 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! _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel