[LinuxBIOS] E7501 SDRAM command bug?

Steven J. Magnani steve at digidescorp.com
Tue Jun 14 16:54:58 CEST 2005

I'm still working on getting the DRAM running on our E7501-based board.
I've run across something in the E7501 raminit code that doesn't look

The E7501 datasheet isn't clear about how RAM commands get sent to the
DIMMs. All it says is (for example): "NOP Command Enable - All processor
cycles to DRAM result in a NOP command on the DRAM interface". It isn't
clear whether a single access to DRAM causes the command to go to all
DIMMs, or only to the one addressed by the access. I ran some
experiments and it appears that only the addressed DIMM gets the

So, the raminit.c code that sends commands to RAM (below) needs to loop
over all the possible DIMMs, accessing a memory address that lies within

    static inline void do_ram_command (const struct mem_controller
*ctrl, uint32_t value) {
            uint32_t dword;
            uint8_t byte;
            int i;
            uint32_t result;

            /* Compute the offset */
            dword = value >> 16;
            for(i=0;i<8;i++) {
                    /* Set the ram command */
                    byte = pci_read_config8(ctrl->d0, 0x7c);
                    byte &= 0x8f;
                    byte |= (uint8_t)(value & 0xff);
                    pci_write_config8(ctrl->d0, 0x7c, byte);

                    /* Assert the command to the memory */

                    result = read32(dword);

                    /* Go to the next base address */
                    dword += 0x04000000;


            /* The command has been sent to all dimms so get out */

The problem is that the code assumes that the address "distance" from
one DIMM to the next is always 0x04000000. Depending on the DIMM
geometry, that may not be the case. Instead, shouldn't the code be using
the previously-initialized DRAM boundary registers to construct
addresses for each DIMM? And for systems with more than 4 GB, shouldn't
it have the ability to access 36-bit addresses?

Steve Magnani

More information about the coreboot mailing list