Broadcom SOCs have flash memories, some of them are serial flashes.
They are detected by ssb/bcma and need to be handled by some extra
drivers.
Access to that flash memories is specific to the Broadcom devices.
Reading is simple, as they are memory mapped. Writing is done with the
ChipCommon (bus device/core) registers.
The initial idea was to register platform device in ssb/bcma and then
access it in a separated driver placed in the mtd tree. However at
some point it was noticed (by Paul?) that (some of?) the chipsets
available at ssb/bcma buses are known from other devices. They are
usually available over SPI bus, and there are available drivers for
them. An example can be m25p80.c.
I can't say yet how much m25p80.c is compatible with chipsets on
Broadcom devices. Not all of them are available in m25p80.c, I'm
especially worried about Atmel flashes. There is only one Atmel entry
in m25p80.c and according to the SSB/BCMA code that devices require
different programming way.
I don't think extending m25p80.c to support SSB/BCMA is acceptable, so
we've two options now:
1) Just implement serial flashes support in separated driver operating
on ssb/bcma buses.
Easy to do, but requires some code duplication with m25p80.c
2) Fake SPI master in ssb & bcma and use m25p80.c
I think it's much more complicated, as there probably isn't any real
SPI on Broadcom devices. We have to fake/emulate it's operations. From
early overview, some words-tips are: struct spi_master,
spi_alloc_master, spi_register_master.
I also don't know well m25p80.c is going to support chipsets on
Broadcom devices. With some luck, we will have to extend it's database
only. But it may happen we will have to add some/many modifications in
m25p80.c as well.
Another problem is early flash access. To boot properly we need to
access serial flash very early to read NVRAM from it (plain text
partition with board settings). This may be required even before we
get "alloc" available, which may require additional extra hacks in
m25p80.c.
Personally I'm for the first option. It's much simpler, doesn't
require a lot of research (how to correctly emulate SPI calls?). I'm
also afraid that emulating SPI bus and adding extra hacks into
m25p80.c will require more code than simple duplication in a ssb/bcma
focused driver. I also can't predict how well serial flash will behave
in case of accessing it over emulated SPI. Is this going to be working
correct? Is this going to be slower/faster?
I wish we discuss this situation and take a one solid decision. I'm
afraid of second solution, but maybe someone of you sees additional
advantages and/or has some experience in that matter.
--
Rafał
On 01/28/2013 12:37 PM, Rafał Miłecki wrote:
> Broadcom SOCs have flash memories, some of them are serial flashes.
> They are detected by ssb/bcma and need to be handled by some extra
> drivers.
>
> Access to that flash memories is specific to the Broadcom devices.
> Reading is simple, as they are memory mapped. Writing is done with the
> ChipCommon (bus device/core) registers.
>
> The initial idea was to register platform device in ssb/bcma and then
> access it in a separated driver placed in the mtd tree. However at
> some point it was noticed (by Paul?) that (some of?) the chipsets
> available at ssb/bcma buses are known from other devices. They are
> usually available over SPI bus, and there are available drivers for
> them. An example can be m25p80.c.
>
> I can't say yet how much m25p80.c is compatible with chipsets on
> Broadcom devices. Not all of them are available in m25p80.c, I'm
> especially worried about Atmel flashes. There is only one Atmel entry
> in m25p80.c and according to the SSB/BCMA code that devices require
> different programming way.
>
> I don't think extending m25p80.c to support SSB/BCMA is acceptable, so
> we've two options now:
>
> 1) Just implement serial flashes support in separated driver operating
> on ssb/bcma buses.
> Easy to do, but requires some code duplication with m25p80.c
>
> 2) Fake SPI master in ssb & bcma and use m25p80.c
> I think it's much more complicated, as there probably isn't any real
> SPI on Broadcom devices. We have to fake/emulate it's operations. From
> early overview, some words-tips are: struct spi_master,
> spi_alloc_master, spi_register_master.
> I also don't know well m25p80.c is going to support chipsets on
> Broadcom devices. With some luck, we will have to extend it's database
> only. But it may happen we will have to add some/many modifications in
> m25p80.c as well.
> Another problem is early flash access. To boot properly we need to
> access serial flash very early to read NVRAM from it (plain text
> partition with board settings). This may be required even before we
> get "alloc" available, which may require additional extra hacks in
> m25p80.c.
>
> Personally I'm for the first option. It's much simpler, doesn't
> require a lot of research (how to correctly emulate SPI calls?). I'm
> also afraid that emulating SPI bus and adding extra hacks into
> m25p80.c will require more code than simple duplication in a ssb/bcma
> focused driver. I also can't predict how well serial flash will behave
> in case of accessing it over emulated SPI. Is this going to be working
> correct? Is this going to be slower/faster?
>
> I wish we discuss this situation and take a one solid decision. I'm
> afraid of second solution, but maybe someone of you sees additional
> advantages and/or has some experience in that matter.
>
I just had a quick look into the m25p80 driver, but emulating a spi
controller does not sounds easy to me and m25p80 still has to be
extended. The current code used in OpenWrt with kernel 2.6 supports all
serial flash chip connected to these SoC I have see I would also go with
duplicating some code and writing an own driver.
This driver should be written to support the serial flash chips found on
SoCs using ssb and bcma and it should share more code than the current
implementation used in OpenWrt with kernel 3.6.
Hauke
On 28 January 2013 12:37, Rafał Miłecki <[email protected]> wrote:
> (snip)
> I don't think extending m25p80.c to support SSB/BCMA is acceptable, so
> we've two options now:
>
> 1) Just implement serial flashes support in separated driver operating
> on ssb/bcma buses.
> Easy to do, but requires some code duplication with m25p80.c
>
> 2) Fake SPI master in ssb & bcma and use m25p80.c
> I think it's much more complicated, as there probably isn't any real
> SPI on Broadcom devices. We have to fake/emulate it's operations. From
> early overview, some words-tips are: struct spi_master,
> spi_alloc_master, spi_register_master.
> I also don't know well m25p80.c is going to support chipsets on
> Broadcom devices. With some luck, we will have to extend it's database
> only. But it may happen we will have to add some/many modifications in
> m25p80.c as well.
> Another problem is early flash access. To boot properly we need to
> access serial flash very early to read NVRAM from it (plain text
> partition with board settings). This may be required even before we
> get "alloc" available, which may require additional extra hacks in
> m25p80.c.
Going from my experience in implementing/rewriting an SPI controller
driver, and having played around with the Broadcom sflash driver, I'd
definitely vote for 1). The expectations to an SPI controller are
quite broad, and the possibilities of the serial flash controller are
quite limited, so making it work with m25p80 will be likely add more
code than could be saved by emulating an SPI controller.
What I think might be doable is to export the SPI flashes list of
m25p80 list and letting both drivers use it. Not sure how much there
is to gain, though.
Jonas