Hi!
While thinking about adding SPI support to flashrom, I came across the directory linux/drivers/mtd/maps/ in a recent kernel tree and found drivers for flash on * Nvidia CK804 * AMD 76X * Intel ICHx
Should we try to use the Linux MTD framework before hacking flashrom? If so, can somebody test? My machines either run too old kernels (production router) or the chipset doesn't appear in the list.
Regards, Carl-Daniel
On Fri, Jul 27, 2007 at 12:49:10AM +0200, Carl-Daniel Hailfinger wrote:
While thinking about adding SPI support to flashrom, I came across the directory linux/drivers/mtd/maps/ in a recent kernel tree and found drivers for flash on
- Nvidia CK804
- AMD 76X
- Intel ICHx
These are at best generic, ie. there's no specific support for SPI in them. Now, MTD does have a driver for some SST SPI chips, in mtd/devices/m25p80.c
Should we try to use the Linux MTD framework before hacking flashrom?
Worth a shot, but..
If so, can somebody test? My machines either run too old kernels (production router) or the chipset doesn't appear in the list.
..there is only support for a few SPI masters in Linux.
An SPI driver for each chipset needs to be written before MTD can talk to the flash. The same code has to be written for flashrom anyway so it could just as well go to both places.
But, trouble comes if some of the chipsets aren't really generic SPI masters but rather specialized for SPI flash. I seem to remember reading some PDF (ICH7/8?) where the southbridge SPI interface wasn't completely generic. :\
//Peter
On 27/07/07 01:43 +0200, Peter Stuge wrote:
If so, can somebody test? My machines either run too old kernels (production router) or the chipset doesn't appear in the list.
..there is only support for a few SPI masters in Linux.
An SPI driver for each chipset needs to be written before MTD can talk to the flash. The same code has to be written for flashrom anyway so it could just as well go to both places.
I think that the MTD is the right horse to bet on here - if anything, it will enrich a larger community. And, if flashrom understands how to talk to the MTD interfaces, and somebody adds a SPI chip to the kernel that we don't yet know about, we win for free.
But, trouble comes if some of the chipsets aren't really generic SPI masters but rather specialized for SPI flash. I seem to remember reading some PDF (ICH7/8?) where the southbridge SPI interface wasn't completely generic. :\
Even if we only put the really generic SPI code into the MTD subsystem, I think its a good thing. The way I see it, flashrom should _want_ to use the generic interfaces, and if it can't, it will go its own way like it does now. Even in the worst cases, that will mean less work and less duplication.
Jordan
* Jordan Crouse jordan.crouse@amd.com [070731 17:28]:
I think that the MTD is the right horse to bet on here - if anything, it will enrich a larger community. And, if flashrom understands how to talk to the MTD interfaces, and somebody adds a SPI chip to the kernel that we don't yet know about, we win for free.
In this scenario, who loads the correct kernel module(s)?
Which southbridges does the MTD SPI code support? Last time I checked only some ARM embedded systems were possibly supported.
Even if we only put the really generic SPI code into the MTD subsystem, I think its a good thing. The way I see it, flashrom should _want_ to use the generic interfaces, and if it can't, it will go its own way like it does now. Even in the worst cases, that will mean less work and less duplication.
Flashrom _is_ the generic interface for many systems.
I think mtd is overly generic and overly complex for what it helps for bios flash chips. But if we can easily support it (patches anyone) we should of course do it. For the task of bios flashing mtd only supports a fraction of systems flashrom supports, and it requires kernel updates for every new chip and system -- this was the reason I abandoned /dev/bios in favour of supporting flashrom.
Stefan
On 31/07/07 23:19 +0200, Stefan Reinauer wrote:
- Jordan Crouse jordan.crouse@amd.com [070731 17:28]:
I think that the MTD is the right horse to bet on here - if anything, it will enrich a larger community. And, if flashrom understands how to talk to the MTD interfaces, and somebody adds a SPI chip to the kernel that we don't yet know about, we win for free.
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? The work has to happen - its just a matter of where the work goes. Personally, I would rather put the work into the kernel, because as I said, that hits the widest possible audience.
Even if we only put the really generic SPI code into the MTD subsystem, I think its a good thing. The way I see it, flashrom should _want_ to use the generic interfaces, and if it can't, it will go its own way like it does now. Even in the worst cases, that will mean less work and less duplication.
Flashrom _is_ the generic interface for many systems.
I think mtd is overly generic and overly complex for what it helps for bios flash chips. But if we can easily support it (patches anyone) we should of course do it. For the task of bios flashing mtd only supports a fraction of systems flashrom supports, and it requires kernel updates for every new chip and system -- this was the reason I abandoned /dev/bios in favour of supporting flashrom.
Again - don't exclude MTD because it doesn't support devices today - if we put as much work into the MTD drivers as we do into flashrom, then MTD would be the well supported one, and flashrom would be struggling.
But this is just my opinion. For my part, any new SPIish gadgets that we happen to support will have a MTD driver, and I'll even patch flashrom to support it (because I'm that nice of a guy). If somebody is interested in porting that support natively to flashrom, then good on ya.
Jordan
* 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
Again - don't exclude MTD because it doesn't support devices today - if we put as much work into the MTD drivers as we do into flashrom, then MTD would be the well supported one, and flashrom would be struggling.
Sure we don't want to lock out opportunities to support more hardware!
But this is just my opinion. For my part, any new SPIish gadgets that we happen to support will have a MTD driver, and I'll even patch flashrom to support it (because I'm that nice of a guy).
That would indeed be cool.
Are there any plans for mtd to do hardware detection like /dev/bios or flashrom do?
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. * Nvidia CK804 * AMD 76X * Intel ICHx
Are there any plans for mtd to do hardware detection like /dev/bios or flashrom do?
MTD sort of has autodetection for SPI flash chips once the SPI southbridge has a driver loaded.
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. Some generic JEDEC detection run for different sizes followed by a lookup in a id table would be so much nicer. 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.
Regards, Carl-Daniel
* 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. 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.
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.
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?
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 nicer.
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.
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
On Wed, Aug 01, 2007 at 04:17:20PM +0200, Carl-Daniel Hailfinger wrote:
- Nvidia CK804
- AMD 76X
- Intel ICHx
The code in mtd is completely useless.
Not really.
Yes, 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.
..because they both only do parallel flash.
There's nothing in the MTD code that supports SPI flash on the above hardware.
It's completely different from parallel flash.
//Peter
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070801 16:17]:
- 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.
Correct. Unfortunately SPI is a completely different kettle of fish.
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.
Ok. But how do you go for the other probing functions then?
We could build an array of probe addresses/probe functions and do a "sort unique" ;-)
Stefan
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Peter Stuge -
Stefan Reinauer