[U-Boot] [PATCH v2] sunxi: Support booting from SPI flash

[Simon Glass]

Hi,

On 9 June 2016 at 18:33, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote:
> Hi Simon,
>
> On Thu, 9 Jun 2016 17:36:10 -0700
> Simon Glass <sjg at chromium.org> wrote:
>
>> Hi,
>>
>> On 7 June 2016 at 05:28, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote:
>> > Allwinner devices support SPI flash as one of the possible
>> > bootable media type. The SPI flash chip needs to be connected
>> > to SPI0 pins (port C) to make this work. More information is
>> > available at:
>> >
>> >     https://linux-sunxi.org/Bootable_SPI_flash
>> >
>> > This patch adds the initial support for booting from SPI flash.
>> > The existing SPI frameworks are not used in order to reduce the
>> > SPL code size. Right now the SPL size grows by ~370 bytes when
>> > CONFIG_SPL_SPI_SUNXI option is enabled.
>> >
>> > While there are no popular Allwinner devices with SPI flash at
>> > the moment, testing can be done using a SPI flash module (it
>> > can be bought for ~2$ on ebay) and jumper wires with the boards,
>> > which expose relevant pins on the expansion header. The SPI flash
>> > chips themselves are very cheap (some prices are even listed as
>> > low as 4 cents) and should not cost much if somebody decides to
>> > design a development board with an SPI flash chip soldered on
>> > the PCB.
>> >
>> > Another nice feature of the SPI flash is that it can be safely
>> > accessed in a device-independent way (since we know that the
>> > boot ROM is already probing these pins during the boot time).
>> > And if, for example, Olimex boards opted to use SPI flash instead
>> > of EEPROM, then they would have been able to have U-Boot installed
>> > in the SPI flash now and boot the rest of the system from the SATA
>> > hard drive. Hopefully we may see new interesting Allwinner based
>> > development boards in the future, now that the software support
>> > for the SPI flash is in a better shape :-)
>> >
>> > Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option
>> > in a board defconfig, then building U-Boot and finally flashing
>> > the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with
>> > a help of the sunxi-fel tool:
>> >
>> >    sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin
>> >
>> > The device needs to be switched into FEL (USB recovery) mode first.
>> > The most suitable boards for testing are Orange Pi PC and Pine64.
>> > Because these boards are cheap, have no built-in NAND/eMMC and
>> > expose SPI0 pins on the Raspberry Pi compatible expansion header.
>> > The A13-OLinuXino-Micro board also can be used.
>> >
>> > Signed-off-by: Siarhei Siamashka <siarhei.siamashka at gmail.com>
>> > ---
>> >
>> > Changes in v2:
>> >  - Add Kconfig option (CONFIG_SPL_SPI_SUNXI) and move the SPI flash
>> >    support code into a separate source file
>> >  - Use CONFIG_SYS_SPI_U_BOOT_OFFS instead of the hardcoded constant
>> >  - Deinitialize the SPI controller and undo pin muxing after the job
>> >    is done
>> >  - Size reduction of the SPI transfer function
>> >  - Add delay after each SPI transfer to ensure that the chip select
>> >    deassert timing requirements (tSHSL) are always satisfied
>> >  - More comments in the code
>> >
>> >
>> >  arch/arm/include/asm/arch-sunxi/gpio.h |   3 +
>> >  arch/arm/mach-sunxi/board.c            |   5 +
>> >  common/spl/spl.c                       |   4 +-
>> >  drivers/mtd/spi/Kconfig                |  12 ++
>> >  drivers/mtd/spi/Makefile               |   1 +
>> >  drivers/mtd/spi/sunxi_spi_spl.c        | 283 +++++++++++++++++++++++++++++++++
>> >  include/configs/sunxi-common.h         |   5 +
>> >  7 files changed, 311 insertions(+), 2 deletions(-)
>> >  create mode 100644 drivers/mtd/spi/sunxi_spi_spl.c
>>
>> Shouldn't this be a normal SPI driver? Then you could put this in
>> common/spl/spl_spi.c.
>
> This source file contains both a sunxi SPI controller support and a
> basic SPI flash read functionality glued together for size reduction
> purposes.
>
> We are interested in implementing the "spl_spi_load_image()" function,
> because this is what gets called when handling the BOOT_DEVICE_SPI
> case.
>
> The "drivers/mtd/spi" directory contains the "spi_spl_load.c" file,
> which implements this particular function with the help of the generic
> SPI flash support code from "spi_flash.c" and the generic SPI bus
> support provided by the code from the "drivers/spi" directory.
>
> What I'm doing in this patch is an implementation of a size reduced
> sunxi-specific replacement for "spi_spl_load.c". But in U-Boot proper
> (where the code size is not a problem anymore) we will need a real
> sunxi SPI driver.

OK I see, fair enough.

Do you know how much space this saves? I'm actually not sure how much
overhead the SPI flash layer adds.

Regards,
Simon