On 01.08.2007 14:28, Stefan Reinauer wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070801 13:45]:
On 31.07.2007 23:44, Stefan Reinauer wrote:
- Jordan Crouse jordan.crouse@amd.com [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