On 01.08.2007 14:28, Stefan Reinauer wrote: > * Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [070801 13:45]: >> On 31.07.2007 23:44, Stefan Reinauer wrote: >>> * Jordan Crouse <[EMAIL PROTECTED]> [070731 23:33]: >>>>> In this scenario, who loads the correct kernel module(s)? >>>> The user. >>>> >>>>> Which southbridges does the MTD SPI code support? Last time I checked >>>>> only some ARM embedded systems were possibly supported. >>>> Sure - but what SPI southbridges does flashrom support? >>> Exactly as many as mtd for x86 based systems: 0 >> I don't know how difficult it will be for the existing chipset support >> drivers in the MTD framework to add SPI support, but maybe it is easier >> than we think. > > Sure it is not difficult, it just has to be done by someone with > datasheets. > >> * Nvidia CK804 >> * AMD 76X >> * Intel ICHx > > The code in mtd is completely useless. It just enables mapping the flash > to memory.
Not really. At least for ck804, it also enables flashing. Just look for pci_read_config_byte in ck804xrom.c and notice the similarities with chipset_enable.c from flashrom. > For SPI the actual flash logic (same as a flash chip driver for pre-spi > flash) goes into the southbridge code. Practically this means that > generic SPI support is completely useless unless you have your specific > southbridge supported. I see. >> MTD sort of has autodetection for SPI flash chips once the SPI >> southbridge has a driver loaded. > > With autodetection I was rather thinking about detection of the modules > to load. > > Auto detection of SPI flash is a de facto nop, since all the logic is in > the southbridge driver, which you just loaded manually. The pci device table ist there, so if somebody automatically loads all pci drivers matching his hardware, he is covered. >> BTW, that is something that bothers me about flashrom: You have to add >> probing support for every single flash chip to the code even if a new >> chip is detected by probe_jedec. > > Why would you add probing support for chips if probe_jedec does the job > already? I don't want to do that. > The reason you have to have a function pointer for probing is that some > flash chips answer to the wrong probing commands with non-ID data. So > some few flash chips need their own probing function. Sure. > SPI will also get its own probing function probe_spi which calls into > the southbridge specific code to do the job. > >> Some generic JEDEC detection run for >> different sizes followed by a lookup in a id table would be so much >> nicer. > > Why? Searching in positions where a chip can't possibly be anyways can > have pretty bad side effects. probe_jedec is called for every supported chip in the list with probe_jedec as probe function. Calling probe_jedec only once for every possible/reasonable chip size would be a lot more efficient. >> In case flashing needs special code we still have to read the >> data sheets now and this won't get worse in the future, but having a >> message "Your flash chip was detected as unknown (id $ID) from >> $MANUFACTURER, most probable size is $SIZE, please mail linuxbios@" >> would surely help a lot for adoption of flashrom. > > This can easily be done already by just adding a small snippet to probe_jedec. > just read the memory location before and after the ID command and test > if it changed. That would be nice. Regards, Carl-Daniel -- linuxbios mailing list [email protected] http://www.linuxbios.org/mailman/listinfo/linuxbios
