Handling serial flashes on Broadcom SOCs

Handling serial flashes on Broadcom SOCs

[Rafał Miłecki]

[-- Attachment #1: Type: text/plain, Size: 2739 bytes --]

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ł

[-- Attachment #2: irc.bcm.serial.flash.log --]
[-- Type: application/octet-stream, Size: 5115 bytes --]

PaulFertser ─ Paul Fertser
KanjiMonster ─ Jonas Gorski
Zajec ─ Rafał Miłecki

[19:30] <PaulFertser> Zajec_: hey :) i saw your serial flash patch committed. Are those broadcom chips integrating some tricky non-spi controller specifically for serial flash?
[19:39] <PaulFertser> Zajec_: many devices based on Atheros ar71xx use SPI flash too. On boot the flash is memory-mapped but then while the kernel is loading it tooks over the SPI controller, turns off the memory mapping and works the usual way over the SPI bus.
[19:41] <PaulFertser> Zajec_: SPI is just a bidirectional 3-wire serial bus. SPI EEPROMs are fairly common but then the command set for communicating with memory via SPI was extended and now there're many ICs that talk the extended protocol supported by m25p80 Linux driver.
[19:42] <PaulFertser> Zajec_: (well, not just, one of the interesting features is that SPI can be chained as it's basically a shift register)
[19:43] <PaulFertser> Zajec_: and chances are that for the BCM chips you can write an SPI host controller driver too, disable emulation, and then use all the ready-made drivers over it.
[19:56] <PaulFertser> Zajec_: i think http://lxr.free-electrons.com/source/drivers/spi/spi-ath79.c#L95 is about the place where the flash memory mapping is getting disabled and a real spi controller driver takes over.
[20:06] <KanjiMonster> PaulFertser: you are assuming there is a real generic spi controller and (public) documententation for it, but there isn't any
[20:06] <PaulFertser> Zajec_: yes, here is the same code http://code.google.com/p/wr703n-uboot-with-web-failsafe/source/browse/trunk/u-boot/board/ar7100/common/ar7100_flash.c#131 to disable that integrated memory mapping and to do bitbanging.
[20:07] <PaulFertser> KanjiMonster: but on ar71xx a bitbanging spi host controller is still better than memory mapping (and is needed anyway to write to flash).
[20:09] <KanjiMonster> PaulFertser: this assumes that the spi lines are available as generic gpios, afaik they aren't
[20:09] <PaulFertser> KanjiMonster: do you think it's possible the BCM chips that Zajec_'s working on actually provide an abstraction on a level higher than an spi controller but lower than an actual flash memory driver?
[20:13] <PaulFertser> KanjiMonster: hm, i should have read https://dev.openwrt.org/browser/trunk/target/linux/brcm47xx/patches-3.6/060-ssb-add-serial-flash-driver.patch indeed
[20:18] <PaulFertser> KanjiMonster: but is it possible to share the database of known flash chips at least?
[20:21] <KanjiMonster> PaulFertser: in theory yes, in practise I'm not sure if it's worth, as the bcm47xx sflash controller supports only a subset of flashes
[20:26] <PaulFertser> KanjiMonster: the list of opcodes here http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/linux/ssb/ssb_driver_chipcommon.h#L477 is looking very much like the list of actual SPI flash opcodes.
[20:32] <KanjiMonster> PaulFertser: the problem is that this isn't a fully working spi controller, it can't do arbitrary reads or writes (from what I can tell you can read at most 4 byte at a time), so e.g. m25p80 will utterly fail
[20:34] <PaulFertser> KanjiMonster: i'm not sure i follow. How does m25p80 IC differ from m25p64 in this regard?
[20:34] <KanjiMonster> PaulFertser: "m25p80" is the driver name for spi connected flashes (connected to real spi controllers)
[20:35] <KanjiMonster> in retrospect quite a bad choice of name
[20:36] <PaulFertser> KanjiMonster: ah, i thought you're referring to the chip name that would possibly fail with ssb controller.
[20:39] <PaulFertser> Apparently that ssb controller covers devices that are usually used with mtd_dataflash.c too
[21:06] <PaulFertser> KanjiMonster: m25p80 needs long reads only to read data from flash, that an only function. I'm not sure everything else can't be emulated over the ssb controller. I'm looking at the code again and again and it seems possible.
[21:07] <KanjiMonster> PaulFertser: well, reading from flash is quite essential ;)
[21:09] <KanjiMonster> PaulFertser: and m25p80 will pass any read sizes from userspace, so if you do e.g. 4096 bytes read to a mtd device, then m25p80 expects to be able to read these 4K at once
[21:09] <PaulFertser> KanjiMonster: if the existing m25p80 driver can be made to work with reasonably little effort of adding a "handicapped"  spi controller and a single custom function, well, it'd probably be nice to do it that way.
[21:09] <KanjiMonster> PaulFertser: I seriously doubt it is worth it only to avoid a bit of data duplication
[21:12] <PaulFertser> KanjiMonster: i'm not sure that's only a bit. The sflash driver is not exactly small or trivial, and if it could be reduced to few functions pretending to be an spi controller, probably that would reduce complexity in the long run.
[21:13] <PaulFertser> Hm, probably it is small and it seemed big to me because i've read it for the first time.
[21:14] <PaulFertser> But it's still so close to existing code that i'd tempted to try to unify that.
[21:18] <PaulFertser> Meh, if only the datasheet for that controller was available.

Re: Handling serial flashes on Broadcom SOCs

[Hauke Mehrtens]

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

Re: Handling serial flashes on Broadcom SOCs

[Jonas Gorski]

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