"Jeremy Jackson" <[EMAIL PROTECTED]> writes: > I've had some thoughts on this. If the motherboard has PCI (usually a > given), usually, (as is the case > with at least the PIIXn) the southbridge, a PCI peripheral, interfaces the > EEPROM socket to the CPU host bridge. It is a "special case" for booting, > in that it's address decoders are configured at power-on-reset to map the > rom. So... > > I can see the MTD map driver using the kernel pci_ config functions to > determine the southbridge or northsouthbridge, and act (intelligently) > accordingly. If that particular part requires a write enable be turned on > by a PCI config or other register, the off it goes and does it. The PIIX > has config registers to select 64/128/512/1024k ROM size, also. The map > driver could even just be an enumerator, and kmod the right driver that > implements flash_on and other hooks when the device is opened. It could set > any cache, MTRRs etc that need special treatment for the ROM's address > space. > > Also, some flash devices require whole blocks/pages be written with certain > timing specs. A robust MTD implementation would ensure that interrupts are > disabled, but masters (IDE and/or NICs) quiesced, perhaps even preload > caches to avoid delays? The chipset-specific map driver should implement > hooks (and in comparison, the map framework should provide hooks) for these > functions. > > Thoughs?
Take a look at what already exists. The infrastructure is fairly close to what you are thinking about. A little more work may need to be done for map drivers but otherwise all of the infrastructure is in place. Eric
