Handling serial flashes on Broadcom SOCs

Jonas Gorski jonas.gorski at gmail.com
Tue Jan 29 08:26:19 EST 2013


On 28 January 2013 12:37, Rafał Miłecki <zajec5 at gmail.com> 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



More information about the linux-mtd mailing list