Hi Vignesh,
On 02.03.19 11:50, Vignesh Raghavendra wrote:
Hi Stefan,
On 02-Mar-19 3:56 PM, Stefan Roese wrote:
Hi Chris, Hi Vignesh,
On 02.03.19 09:36, Vignesh Raghavendra wrote:
On 02-Mar-19 1:15 PM, Chris Packham wrote:
This board uses Micron N25Q256A SPI flash. Enable SPI_FLASH_BAR to allow us to access the whole chip.
Signed-off-by: Chris Packham judge.packham@gmail.com Cc: Vignesh R vigneshr@ti.com
Could add imply SPI_FLASH_BAR to KIRKWOOD_SPI instead? So that we don't have to fix every defconfig that using kirkwood_spi.c.
Did you use BAR before the newly introduced SPI NOR restructuring? If not, then I would rather oppose to using it now, since option should only be used by those platforms that used it earlier as well.
configs/db-88f6820-amc_defconfig did use SPI_FLASH_BAR before SPI NOR re-work
I see. Thanks for checking.
BAR mode is not supported by Linux and an U-Boot special.
Looks like kernel driver does support 3/4 byte addressing, but U-Boot version of the driver doesn't.
Could you please double check, if and how addressing of the whole 32MiB was done before? And perhaps its possible to enhance the SPI driver to support 3 and 4 byte addressing instead.
It would be great if driver could be modified to support 3 and 4 byte addressing modes.
I fail to see, what really is needed to make the SPI driver support 3 and 4 byte addressing modes. I recently added the MT7688 SPI driver (mt7621_spi.c) which supports 3 and 4 byte mode and I remember no driver specials that I needed to implement for this feature. Its address mode agnostic AFAICT and just xfers a buffer of data to and from the SPI device.
Could you please let me know, what exactly is missing for this 4 byte mode?
Thanks, Stefan