* Dave Ashley linuxbios@xdr.com [031102 17:43]:
These discussions on romcc running out of registers, optimizations, inline and all are surprising. Isn't the point of romcc to just get the system ram up right at the beginning? Then once that is done any compiler (gcc) can be used to write code. Because dram configuration is so complicated and interpreting the SPD data from the dram, people would rather code that in 'C' than in x86 asm, so that's the purpose of romcc?
Yes. The problem that makes romcc run out of registers in my case can be circumvented by some small restructures in the code.
Given that not all spd roms of all modules are visible at the same time, but switched via an smbus hub, I have to make sure that before trying to access spd rom data with smbus_read_byte() the smbus hub is switched to the correct rom.
The current approach is to do this in spd_read_byte, which is used as a wrapper function around smbus_read_byte. It always sends a "switch" command to the smbus hub before actually reading from the rom. Since the function for switching parses the information from the ram controller struct and does an smbus_write_byte, it eats quite some registers all the time, in addition to the already used ones.
Since the dram controllers are initialized one after the other, we don't need to switch the smbus hub every time we do an access, but only before starting dram initialization on a given controller. This lowers register usage noticably and especially only uses registers at a point when we have plenty of them.
Therefore I suggest adding a function activate_spd_rom(const struct mem_controller *ctrl) that is called as the first command in sdram_set_spd_registers() that can be implemented by the motherboard specific code if needed, similar to memreset() now.
As far as I can see, all spd accesses done by sdram_set_spd_registers() end up on the same spd rom, making it safe to switch only one time per call to this function.
I'll change the code to reflect this and see if it works out.
Stefan