[LinuxBIOS] Use Linux MTD framework for SPI flash?

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Wed Aug 1 16:17:20 CEST 2007


On 01.08.2007 14:28, Stefan Reinauer wrote:
> * 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
> 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




More information about the coreboot mailing list