[LinuxBIOS] Use Linux MTD framework for SPI flash?
stepan at coresystems.de
Wed Aug 1 14:28:39 CEST 2007
* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [070801 13:45]:
> On 31.07.2007 23:44, Stefan Reinauer wrote:
> > * Jordan Crouse <jordan.crouse at 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
> * Nvidia CK804
> * AMD 76X
> * Intel ICHx
The code in mtd is completely useless. It just enables mapping the flash
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
> 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
Auto detection of SPI flash is a de facto nop, since all the logic is in
the southbridge driver, which you just loaded manually.
> 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
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.
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
Why? Searching in positions where a chip can't possibly be anyways can
have pretty bad side effects.
> 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.
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
More information about the coreboot