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? ----- Original Message ----- From: "Ronald G Minnich" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, February 17, 2002 6:09 PM Subject: Re: sanity > On 17 Feb 2002, Eric W. Biederman wrote: > > > Grumble, Grumble. This kind of thing really needs to be in an mtd map driver. > > Then you could have everything compiled into the kernel.... > > Grumble, Grumble. > > yeah but ... the mtd map driver has no idea what motherboard your on. > There's no "motherboard ID" register. In the general case there's no way a > kernel can figure out how to enable FLASH writes, since it can't figure > out the motherboard. It's truly awful. PCs suck. > > ron >
