RomCC

Stefan Reinauer stepan at suse.de
Mon Nov 3 06:15:01 CET 2003


* Dave Ashley <linuxbios at 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

 
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development



More information about the coreboot mailing list