[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