On 15.09.2010 12:31, Peter Lemenkov wrote: > Hello! > > 2010/9/15 Carl-Daniel Hailfinger <c-d.hailfinger.devel.2...@gmx.net>: > > >>> --- a/chipset_enable.c >>> +++ b/chipset_enable.c >>> @@ -802,6 +802,23 @@ static int enable_flash_ck804(struct pci_dev *dev, >>> const char *name) >>> return 0; >>> } >>> >>> +static int enable_flash_osb4(struct pci_dev *dev, const char *name) >>> +{ >>> + uint8_t tmp; >>> + >>> + buses_supported = CHIP_BUSTYPE_PARALLEL; >>> + >>> + tmp = INB(0xc06); >>> + tmp |= 0x1; >>> + OUTB(tmp, 0xc06); >>> + >>> + tmp = INB(0xc6f); >>> + tmp |= 0x40; >>> + OUTB(tmp, 0xc6f); >>> + >>> + return 0; >>> +} >>> + >>> > > >> Funny. The 0xc6f access looks very similar to parts of the SB400 chipset >> enable. (Side note: we should ask AMD if the SB400 chipset enable is >> correct.) >> >> Peter, could you please attach /proc/ioports and check if dmesg mentions >> 0xc06 or 0xc6f or anything close to that? >> > > Attached /proc/ioports and dmesg contents. > > /proc/ioports: > [...] > 0c14-0c14 : pnp 00:02 > 0c49-0c49 : pnp 00:02 > 0c52-0c52 : pnp 00:02 > 0c6c-0c6c : pnp 00:02 > [...]
Thanks for the data. Yay for crappy BIOS. The chipset I/O ranges touched by the chipset enable are completely unreserved and other devices may live there. Joshua, if you send the chipset patch and flash chip patch in separate mails with a subject that allows easier identification, I will ack them and commit. Side note: If you have any download URLs for the flash chip datasheets you used, please mention them in the changelog. Regards, Carl-Daniel -- http://www.hailfinger.org/ _______________________________________________ flashrom mailing list flashrom@flashrom.org http://www.flashrom.org/mailman/listinfo/flashrom