Allocateing resouces for PCI expansion roms... (was 440bx VGA probs)

Stefan Reinauer stepan at
Thu Sep 9 02:28:00 CEST 2004

* Eric W. Biederman <ebiederman at> [040909 02:58]:
> > I don't understand.  Shadowing is chipset specific and would have to be done for
> > all chipsets in v1 or v2.  Putting it in the chipsets northbridge.c is way
> > better than having to modify and keep a special version of ADLO's loader.s thats
> > only works for one specfic chipset.
> Enabling everything as memory except the legacy vga bios hole should
> be done.  On an Intel chipset it should just be properly setting
> the PAM register.
> Unless there is a good reason not to every chipsets northbridge should
> do this.  And there is no reason to make it conditional.
> > All this does is provide an nice easy method of getting the vbios into C000.
> > Rather than the multi-step method of boot card in machine with COTS bios, copy
> > bios to file, add file to the ADLO build, rebuild linuxbios, boot card under
> > linuxbios+adlo.
> As for the copy that is something different.
> ADLO should really look at the pci options roms and do the appropriate
> thing, so if LinuxBIOS can reserve a hole in the memory address space
> to map the ROM into, ADLO should do the rest.

This would require to actively change the PAM registers during ADLO
still, would it not? 

With our current abstraction, this is something that should clearly go
to LinuxBIOS though since it is chipset specific. 

Ok, we don't want callbacks, but could we not store the information on
how to cope with PAM registers in the LinuxBIOS table, probably as some
array of PCI addresses to read+[&|]+write to? This would allow to keep
ADLO completely generic. 

Thinking forward, we should store much more information in the LinuxBIOS
table. For example on machines where LinuxBIOS initializes video itself 
(ATI XL, Trident Cyberblade) the LinuxBIOS table should contain an entry
with the framebuffer address, the resolution and the color depth. Then
any payload can spare reinitializing video without having to make
ventured assumptions on the status of the hardware. 


More information about the coreboot mailing list