Or rather, wire up the address pins in any order, and the data pins in any order. A simple RAM chip's inputs were just symmetric. As long as you didn't care what transistor was storing which bit you could wire it how you liked.
For a ROM chip you actually had to be careful so that it actually generated the correct output for a given address, unless you were willing to burn an EPROM with the reverse transformation applied.
Even with DDR3 (and probably DDR4) you can still swap bits within a byte lane, and bytes within a word/channel depending on the setup of the memory controller. Some things change, and some stay the same!
Also, most current DDR3 controllers "scramble" which wire carries which bit based on the address. The idea is that when writing constant repeating data patterns, spreading energy among the wires reduces emitted EMI.
When you do a suspend-to-ram on a current x86 machine, it has to save the "scrambler seed" to CMOS so that it can decode the data it left stored in RAM.
I think this also helps mitigate the attack where the DRAM is chilled to make its contents less volatile, the machine is powered off, and the DRAM is then dumped in search of sensitive material.
That actually surprises me.. I would have guessed that there would be some amount of metadata you could query over the data lines, such as the specs for the DIMM. I guess that's all sent over I2C or something instead?
Yeah, that's all done through a seperate EEPROM chip accessed over SMBUS, which is essentially the same as I2C. Raw SDRAM chips don't provide any way to query their specification; on embedded systems that use them, the settings are generally all hardcoded in the bootloader.
SDRAM's interface doesn't leave room for extra commands, it's pretty much designed to read/store data and refresh content. It only has 3 lines to select the command (RAS#, CAS#, WE#).
Other RAMs/Flash with different interfaces (e.g. SPI) require a prefix command to be sent over the wire, so it's easier for them to implement things like chip id commands.
