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

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@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

Hello

Nice to see new entry to boot.
I would like to know if sdcard wired in spi mode can working with this spi boot support.
Why put sdcard in spi when i have an sdcard slot? :)
Just to solder it for bypass crappy sdcard socket pin contact then boot from usb.
microsd was cheap in 512mb size or less.

Is there limitation in chip memory selection?
Anyway thank for new support

Hello,

On Wed, 8 Jun 2016 02:56:41 -0700 (PDT)
boobwrt@gmail.com wrote:

> Hello
> 
> Nice to see new entry to boot.
> I would like to know if sdcard wired in spi mode can working with
> this spi boot support.

No, it can't. The SPI protocol used by the SD card is different
from the SPI protocol used by the SPI flash chips. The SPI is just
an underlying bus to send and receive data, but the higher level
protocols are incompatible.

> Why put sdcard in spi when i have an sdcard slot? :)
> Just to solder it for bypass crappy sdcard socket pin contact

You can still solder the SD card instead of plugging it into
the SD card slot.

In fact, that's how it is usually done with eMMC. And you can even
buy some development boards with eMMC instead of experimenting
with this stuff yourself.

> then boot from usb.
> microsd was cheap in 512mb size or less.

The price difference between the Orange Pi PC and the Orange Pi PC Plus
boards is not very big:

http://www.aliexpress.com/store/product/Orange-Pi-PC-linux-and-android-mini-PC-Beyond-Raspberry-Pi-2/1553371_32448079125.html
http://www.aliexpress.com/store/product/Orange-Pi-PC-Plus-ubuntu-linux-and-android-mini-PC-Beyond-Raspberry-Pi-2/1553371_32668618847.html

For extra 4.45 EUR you get a 8GB eMMC and also some sort of WiFi.
And the eMMC is also much faster than a regular SD card, so it's
not a very bad deal.

> Is there limitation in chip memory selection?

Any SPI flash chip should be supported if it uses the right voltage
(compatible with 3.3V) and supports the Read Data Bytes command (the
opcode 0x03, followed by a 24-bit address). You can always check the
datasheet.

A suitable SPI flash chip, which seems to cost only 4 cents, is
sold here:

http://www.aliexpress.com/item/W25Q16BVSSIG-W25Q16BVSIG-2MB-SOP8/32660083443.html

But I have no idea if this particular seller is trustworthy. One can
still easily find similar chips for around 10 cents in other places.

The SPI flash is cheaper than the eMMC if we look at the absolute
price. But the price per megabyte is an entirely different story.

For U-Boot you would need a 1 MiB (8 Mbit) chip, just check the
size of the u-boot-sunxi-with-spl.bin file and ensure a bit of
extra headroom.

> Anyway thank for new support 

Thanks.

Hi,

On 7 June 2016 at 05:28, Siarhei Siamashka <siarhei.siamashka@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@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.

Regards,
Simon

Hi Simon,

On Thu, 9 Jun 2016 17:36:10 -0700
Simon Glass <sjg@chromium.org> wrote:

> Hi,
> 
> On 7 June 2016 at 05:28, Siarhei Siamashka <siarhei.siamashka@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@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.

Hi,

On 9 June 2016 at 18:33, Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote:
> Hi Simon,
>
> On Thu, 9 Jun 2016 17:36:10 -0700
> Simon Glass <sjg@chromium.org> wrote:
>
>> Hi,
>>
>> On 7 June 2016 at 05:28, Siarhei Siamashka <siarhei.siamashka@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@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

On Thu, 9 Jun 2016 19:42:55 -0700
Simon Glass <sjg@chromium.org> wrote:

> Hi,
> 
> On 9 June 2016 at 18:33, Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote:
> > Hi Simon,
> >
> > On Thu, 9 Jun 2016 17:36:10 -0700
> > Simon Glass <sjg@chromium.org> wrote:
> >  
> >> Hi,
> >>
> >> On 7 June 2016 at 05:28, Siarhei Siamashka <siarhei.siamashka@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@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.

I don't have a DM based SPI driver for sunxi yet. But I tried to
disable SPI flash on some other boards and check the SPL size
reduction. I don't remember what kind of board it was before, but
the size was reduced by several kilobytes. Now tried it again with
the "spring_defconfig" build:

== normal build ==

   text	   data	    bss	    dec	    hex	filename
  11796	   1260	      0	  13056	   3300	spl/u-boot-spl

== spi flash disabled ==

   text	   data	    bss	    dec	    hex	filename
   6812	   1052	      0	   7864	   1eb8	spl/u-boot-spl

My changes in "include/configs/exynos5-dt-common.h" to disable SPI
flash:

-#define CONFIG_ENV_IS_IN_SPI_FLASH
+#define CONFIG_ENV_IS_IN_MMC
+/*
 #define CONFIG_ENV_SPI_BASE    0x12D30000
 #define FLASH_SIZE             (4 << 20)
 #define CONFIG_ENV_OFFSET      (FLASH_SIZE - CONFIG_ENV_SECT_SIZE)
 #define CONFIG_SPI_BOOTING
+*/

Yes, this was not a very clean experiment. But still ~5K looks
significantly larger than ~400 bytes.


For comparison, building "Cubieboard_defconfig" from the current
master branch (6b3943f1b04be60f147ee540fbd72c4c7ea89f80) results
in the following SPL sizes, depending on the GCC version:

=== GCC 4.7 ===
   text	   data	    bss	    dec	    hex	filename
  21743	    640	    256	  22639	   586f	spl/u-boot-spl

=== GCC 4.9 ===
   text	   data	    bss	    dec	    hex	filename
  21667	    640	    256	  22563	   5823	spl/u-boot-spl

=== GCC 5.3 ===
   text	   data	    bss	    dec	    hex	filename
  21571	    640	    256	  22467	   57c3	spl/u-boot-spl

=== GCC 6.1 ===
   text	   data	    bss	    dec	    hex	filename
  18406	    640	    256	  19302	   4b66	spl/u-boot-spl

Please note that NAND and FIT are still not enabled, though
CONFIG_USE_TINY_PRINTF is not enabled either. And 24 KiB is
the size limit for the SPL, enforced by the boot ROM.

On 9 June 2016 at 22:28, Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote:
> On Thu, 9 Jun 2016 19:42:55 -0700
> Simon Glass <sjg@chromium.org> wrote:
>
>> Hi,
>>
>> On 9 June 2016 at 18:33, Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote:
>> > Hi Simon,
>> >
>> > On Thu, 9 Jun 2016 17:36:10 -0700
>> > Simon Glass <sjg@chromium.org> wrote:
>> >
>> >> Hi,
>> >>
>> >> On 7 June 2016 at 05:28, Siarhei Siamashka <siarhei.siamashka@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@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.
>
> I don't have a DM based SPI driver for sunxi yet. But I tried to
> disable SPI flash on some other boards and check the SPL size
> reduction. I don't remember what kind of board it was before, but
> the size was reduced by several kilobytes. Now tried it again with
> the "spring_defconfig" build:
>
> == normal build ==
>
>    text    data     bss     dec     hex filename
>   11796    1260       0   13056    3300 spl/u-boot-spl
>
> == spi flash disabled ==
>
>    text    data     bss     dec     hex filename
>    6812    1052       0    7864    1eb8 spl/u-boot-spl
>
> My changes in "include/configs/exynos5-dt-common.h" to disable SPI
> flash:
>
> -#define CONFIG_ENV_IS_IN_SPI_FLASH
> +#define CONFIG_ENV_IS_IN_MMC
> +/*
>  #define CONFIG_ENV_SPI_BASE    0x12D30000
>  #define FLASH_SIZE             (4 << 20)
>  #define CONFIG_ENV_OFFSET      (FLASH_SIZE - CONFIG_ENV_SECT_SIZE)
>  #define CONFIG_SPI_BOOTING
> +*/
>
> Yes, this was not a very clean experiment. But still ~5K looks
> significantly larger than ~400 bytes.
>
>
> For comparison, building "Cubieboard_defconfig" from the current
> master branch (6b3943f1b04be60f147ee540fbd72c4c7ea89f80) results
> in the following SPL sizes, depending on the GCC version:
>
> === GCC 4.7 ===
>    text    data     bss     dec     hex filename
>   21743     640     256   22639    586f spl/u-boot-spl
>
> === GCC 4.9 ===
>    text    data     bss     dec     hex filename
>   21667     640     256   22563    5823 spl/u-boot-spl
>
> === GCC 5.3 ===
>    text    data     bss     dec     hex filename
>   21571     640     256   22467    57c3 spl/u-boot-spl
>
> === GCC 6.1 ===
>    text    data     bss     dec     hex filename
>   18406     640     256   19302    4b66 spl/u-boot-spl
>
> Please note that NAND and FIT are still not enabled, though
> CONFIG_USE_TINY_PRINTF is not enabled either. And 24 KiB is
> the size limit for the SPL, enforced by the boot ROM.

Nice work.

Reviewed-by: Simon Glass <sjg@chromium.org>

(I'm not a fan of the *********** in comments but will leave that to
Hans to decide)

Hi,

On 07-06-16 13:28, Siarhei Siamashka 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@gmail.com>

Thanks, I've added this to u-boot-sunxi/next for merging into
v2016.09 as soon as the merge window for that opens.

Regards,

Hans



> ---
>
> 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
>
> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h b/arch/arm/include/asm/arch-sunxi/gpio.h
> index 1ace548..bff7d14 100644
> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> @@ -141,6 +141,7 @@ enum sunxi_gpio_number {
>  /* GPIO pin function config */
>  #define SUNXI_GPIO_INPUT	0
>  #define SUNXI_GPIO_OUTPUT	1
> +#define SUNXI_GPIO_DISABLE	7
>
>  #define SUNXI_GPA_EMAC		2
>  #define SUN6I_GPA_GMAC		2
> @@ -162,8 +163,10 @@ enum sunxi_gpio_number {
>  #define SUN50I_GPB_UART0	4
>
>  #define SUNXI_GPC_NAND		2
> +#define SUNXI_GPC_SPI0		3
>  #define SUNXI_GPC_SDC2		3
>  #define SUN6I_GPC_SDC3		4
> +#define SUN50I_GPC_SPI0		4
>
>  #define SUN8I_GPD_SDC1		3
>  #define SUNXI_GPD_LCD0		2
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index bd15b9b..025df4d 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -223,6 +223,11 @@ u32 spl_boot_device(void)
>  	if (!is_boot0_magic(SPL_ADDR + 4)) /* eGON.BT0 */
>  		return BOOT_DEVICE_BOARD;
>
> +#ifdef CONFIG_SPL_SPI_SUNXI
> +	if (readb(SPL_ADDR + 0x28) == SUNXI_BOOTED_FROM_SPI)
> +		return BOOT_DEVICE_SPI;
> +#endif
> +
>  	/* The BROM will try to boot from mmc0 first, so try that first. */
>  #ifdef CONFIG_MMC
>  	mmc_initialize(gd->bd);
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index c8dfc14..d49ce2b 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -265,7 +265,7 @@ struct boot_device_name boot_name_table[] = {
>  #ifdef CONFIG_SPL_YMODEM_SUPPORT
>  	{ BOOT_DEVICE_UART, "UART" },
>  #endif
> -#ifdef CONFIG_SPL_SPI_SUPPORT
> +#if defined(CONFIG_SPL_SPI_SUPPORT) || defined(CONFIG_SPL_SPI_FLASH_SUPPORT)
>  	{ BOOT_DEVICE_SPI, "SPI" },
>  #endif
>  #ifdef CONFIG_SPL_ETH_SUPPORT
> @@ -341,7 +341,7 @@ static int spl_load_image(u32 boot_device)
>  	case BOOT_DEVICE_UART:
>  		return spl_ymodem_load_image();
>  #endif
> -#ifdef CONFIG_SPL_SPI_SUPPORT
> +#if defined(CONFIG_SPL_SPI_SUPPORT) || defined(CONFIG_SPL_SPI_FLASH_SUPPORT)
>  	case BOOT_DEVICE_SPI:
>  		return spl_spi_load_image();
>  #endif
> diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> index 3f7433c..1f23c8e 100644
> --- a/drivers/mtd/spi/Kconfig
> +++ b/drivers/mtd/spi/Kconfig
> @@ -128,4 +128,16 @@ config SPI_FLASH_MTD
>
>  	  If unsure, say N
>
> +if SPL
> +
> +config SPL_SPI_SUNXI
> +	bool "Support for SPI Flash on Allwinner SoCs in SPL"
> +	depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I || MACH_SUN8I_H3 || MACH_SUN50I
> +	---help---
> +	Enable support for SPI Flash. This option allows SPL to read from
> +	sunxi SPI Flash. It uses the same method as the boot ROM, so does
> +	not need any extra configuration.
> +
> +endif
> +
>  endmenu # menu "SPI Flash Support"
> diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
> index c665836..6f47a66 100644
> --- a/drivers/mtd/spi/Makefile
> +++ b/drivers/mtd/spi/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_DM_SPI_FLASH) += sf-uclass.o
>  ifdef CONFIG_SPL_BUILD
>  obj-$(CONFIG_SPL_SPI_LOAD)	+= spi_spl_load.o
>  obj-$(CONFIG_SPL_SPI_BOOT)	+= fsl_espi_spl.o
> +obj-$(CONFIG_SPL_SPI_SUNXI)	+= sunxi_spi_spl.o
>  endif
>
>  obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi_flash.o sf_params.o sf.o
> diff --git a/drivers/mtd/spi/sunxi_spi_spl.c b/drivers/mtd/spi/sunxi_spi_spl.c
> new file mode 100644
> index 0000000..e3ded5b
> --- /dev/null
> +++ b/drivers/mtd/spi/sunxi_spi_spl.c
> @@ -0,0 +1,283 @@
> +/*
> + * Copyright (C) 2016 Siarhei Siamashka <siarhei.siamashka@gmail.com>
> + *
> + * SPDX-License-Identifier:	GPL-2.0+
> + */
> +
> +#include <common.h>
> +#include <spl.h>
> +#include <asm/gpio.h>
> +#include <asm/io.h>
> +
> +#ifdef CONFIG_SPL_OS_BOOT
> +#error CONFIG_SPL_OS_BOOT is not supported yet
> +#endif
> +
> +/*
> + * This is a very simple U-Boot image loading implementation, trying to
> + * replicate what the boot ROM is doing when loading the SPL. Because we
> + * know the exact pins where the SPI Flash is connected and also know
> + * that the Read Data Bytes (03h) command is supported, the hardware
> + * configuration is very simple and we don't need the extra flexibility
> + * of the SPI framework. Moreover, we rely on the default settings of
> + * the SPI controler hardware registers and only adjust what needs to
> + * be changed. This is good for the code size and this implementation
> + * adds less than 400 bytes to the SPL.
> + *
> + * There are two variants of the SPI controller in Allwinner SoCs:
> + * A10/A13/A20 (sun4i variant) and everything else (sun6i variant).
> + * Both of them are supported.
> + *
> + * The pin mixing part is SoC specific and only A10/A13/A20/H3/A64 are
> + * supported at the moment.
> + */
> +
> +/*****************************************************************************/
> +/* SUN4I variant of the SPI controller                                       */
> +/*****************************************************************************/
> +
> +#define SUN4I_SPI0_CCTL             (0x01C05000 + 0x1C)
> +#define SUN4I_SPI0_CTL              (0x01C05000 + 0x08)
> +#define SUN4I_SPI0_RX               (0x01C05000 + 0x00)
> +#define SUN4I_SPI0_TX               (0x01C05000 + 0x04)
> +#define SUN4I_SPI0_FIFO_STA         (0x01C05000 + 0x28)
> +#define SUN4I_SPI0_BC               (0x01C05000 + 0x20)
> +#define SUN4I_SPI0_TC               (0x01C05000 + 0x24)
> +
> +#define SUN4I_CTL_ENABLE            BIT(0)
> +#define SUN4I_CTL_MASTER            BIT(1)
> +#define SUN4I_CTL_TF_RST            BIT(8)
> +#define SUN4I_CTL_RF_RST            BIT(9)
> +#define SUN4I_CTL_XCH               BIT(10)
> +
> +/*****************************************************************************/
> +/* SUN6I variant of the SPI controller                                       */
> +/*****************************************************************************/
> +
> +#define SUN6I_SPI0_CCTL             (0x01C68000 + 0x24)
> +#define SUN6I_SPI0_GCR              (0x01C68000 + 0x04)
> +#define SUN6I_SPI0_TCR              (0x01C68000 + 0x08)
> +#define SUN6I_SPI0_FIFO_STA         (0x01C68000 + 0x1C)
> +#define SUN6I_SPI0_MBC              (0x01C68000 + 0x30)
> +#define SUN6I_SPI0_MTC              (0x01C68000 + 0x34)
> +#define SUN6I_SPI0_BCC              (0x01C68000 + 0x38)
> +#define SUN6I_SPI0_TXD              (0x01C68000 + 0x200)
> +#define SUN6I_SPI0_RXD              (0x01C68000 + 0x300)
> +
> +#define SUN6I_CTL_ENABLE            BIT(0)
> +#define SUN6I_CTL_MASTER            BIT(1)
> +#define SUN6I_CTL_SRST              BIT(31)
> +#define SUN6I_TCR_XCH               BIT(31)
> +
> +/*****************************************************************************/
> +
> +#define CCM_AHB_GATING0             (0x01C20000 + 0x60)
> +#define CCM_SPI0_CLK                (0x01C20000 + 0xA0)
> +#define SUN6I_BUS_SOFT_RST_REG0     (0x01C20000 + 0x2C0)
> +
> +#define AHB_RESET_SPI0_SHIFT        20
> +#define AHB_GATE_OFFSET_SPI0        20
> +
> +#define SPI0_CLK_DIV_BY_2           0x1000
> +#define SPI0_CLK_DIV_BY_4           0x1001
> +
> +/*****************************************************************************/
> +
> +/*
> + * Allwinner A10/A20 SoCs were using pins PC0,PC1,PC2,PC23 for booting
> + * from SPI Flash, everything else is using pins PC0,PC1,PC2,PC3.
> + */
> +static void spi0_pinmux_setup(unsigned int pin_function)
> +{
> +	unsigned int pin;
> +
> +	for (pin = SUNXI_GPC(0); pin <= SUNXI_GPC(2); pin++)
> +		sunxi_gpio_set_cfgpin(pin, pin_function);
> +
> +	if (IS_ENABLED(CONFIG_MACH_SUN4I) || IS_ENABLED(CONFIG_MACH_SUN7I))
> +		sunxi_gpio_set_cfgpin(SUNXI_GPC(23), pin_function);
> +	else
> +		sunxi_gpio_set_cfgpin(SUNXI_GPC(3), pin_function);
> +}
> +
> +/*
> + * Setup 6 MHz from OSC24M (because the BROM is doing the same).
> + */
> +static void spi0_enable_clock(void)
> +{
> +	/* Deassert SPI0 reset on SUN6I */
> +	if (IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I))
> +		setbits_le32(SUN6I_BUS_SOFT_RST_REG0,
> +			     (1 << AHB_RESET_SPI0_SHIFT));
> +
> +	/* Open the SPI0 gate */
> +	setbits_le32(CCM_AHB_GATING0, (1 << AHB_GATE_OFFSET_SPI0));
> +
> +	/* Divide by 4 */
> +	writel(SPI0_CLK_DIV_BY_4, IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I) ?
> +				  SUN6I_SPI0_CCTL : SUN4I_SPI0_CCTL);
> +	/* 24MHz from OSC24M */
> +	writel((1 << 31), CCM_SPI0_CLK);
> +
> +	if (IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I)) {
> +		/* Enable SPI in the master mode and do a soft reset */
> +		setbits_le32(SUN6I_SPI0_GCR, SUN6I_CTL_MASTER |
> +					     SUN6I_CTL_ENABLE |
> +					     SUN6I_CTL_SRST);
> +		/* Wait for completion */
> +		while (readl(SUN6I_SPI0_GCR) & SUN6I_CTL_SRST)
> +			;
> +	} else {
> +		/* Enable SPI in the master mode and reset FIFO */
> +		setbits_le32(SUN4I_SPI0_CTL, SUN4I_CTL_MASTER |
> +					     SUN4I_CTL_ENABLE |
> +					     SUN4I_CTL_TF_RST |
> +					     SUN4I_CTL_RF_RST);
> +	}
> +}
> +
> +static void spi0_disable_clock(void)
> +{
> +	/* Disable the SPI0 controller */
> +	if (IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I))
> +		clrbits_le32(SUN6I_SPI0_GCR, SUN6I_CTL_MASTER |
> +					     SUN6I_CTL_ENABLE);
> +	else
> +		clrbits_le32(SUN4I_SPI0_CTL, SUN4I_CTL_MASTER |
> +					     SUN4I_CTL_ENABLE);
> +
> +	/* Disable the SPI0 clock */
> +	writel(0, CCM_SPI0_CLK);
> +
> +	/* Close the SPI0 gate */
> +	clrbits_le32(CCM_AHB_GATING0, (1 << AHB_GATE_OFFSET_SPI0));
> +
> +	/* Assert SPI0 reset on SUN6I */
> +	if (IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I))
> +		clrbits_le32(SUN6I_BUS_SOFT_RST_REG0,
> +			     (1 << AHB_RESET_SPI0_SHIFT));
> +}
> +
> +static int spi0_init(void)
> +{
> +	unsigned int pin_function = SUNXI_GPC_SPI0;
> +	if (IS_ENABLED(CONFIG_MACH_SUN50I))
> +		pin_function = SUN50I_GPC_SPI0;
> +
> +	spi0_pinmux_setup(pin_function);
> +	spi0_enable_clock();
> +}
> +
> +static void spi0_deinit(void)
> +{
> +	/* New SoCs can disable pins, older could only set them as input */
> +	unsigned int pin_function = SUNXI_GPIO_INPUT;
> +	if (IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I))
> +		pin_function = SUNXI_GPIO_DISABLE;
> +
> +	spi0_disable_clock();
> +	spi0_pinmux_setup(pin_function);
> +}
> +
> +/*****************************************************************************/
> +
> +#define SPI_READ_MAX_SIZE 60 /* FIFO size, minus 4 bytes of the header */
> +
> +static void sunxi_spi0_read_data(u8 *buf, u32 addr, u32 bufsize,
> +				 u32 spi_ctl_reg,
> +				 u32 spi_ctl_xch_bitmask,
> +				 u32 spi_fifo_reg,
> +				 u32 spi_tx_reg,
> +				 u32 spi_rx_reg,
> +				 u32 spi_bc_reg,
> +				 u32 spi_tc_reg,
> +				 u32 spi_bcc_reg)
> +{
> +	writel(4 + bufsize, spi_bc_reg); /* Burst counter (total bytes) */
> +	writel(4, spi_tc_reg);           /* Transfer counter (bytes to send) */
> +	if (spi_bcc_reg)
> +		writel(4, spi_bcc_reg);  /* SUN6I also needs this */
> +
> +	/* Send the Read Data Bytes (03h) command header */
> +	writeb(0x03, spi_tx_reg);
> +	writeb((u8)(addr >> 16), spi_tx_reg);
> +	writeb((u8)(addr >> 8), spi_tx_reg);
> +	writeb((u8)(addr), spi_tx_reg);
> +
> +	/* Start the data transfer */
> +	setbits_le32(spi_ctl_reg, spi_ctl_xch_bitmask);
> +
> +	/* Wait until everything is received in the RX FIFO */
> +	while ((readl(spi_fifo_reg) & 0x7F) < 4 + bufsize)
> +		;
> +
> +	/* Skip 4 bytes */
> +	readl(spi_rx_reg);
> +
> +	/* Read the data */
> +	while (bufsize-- > 0)
> +		*buf++ = readb(spi_rx_reg);
> +
> +	/* tSHSL time is up to 100 ns in various SPI flash datasheets */
> +	udelay(1);
> +}
> +
> +static void spi0_read_data(void *buf, u32 addr, u32 len)
> +{
> +	u8 *buf8 = buf;
> +	u32 chunk_len;
> +
> +	while (len > 0) {
> +		chunk_len = len;
> +		if (chunk_len > SPI_READ_MAX_SIZE)
> +			chunk_len = SPI_READ_MAX_SIZE;
> +
> +		if (IS_ENABLED(CONFIG_SUNXI_GEN_SUN6I)) {
> +			sunxi_spi0_read_data(buf8, addr, chunk_len,
> +					     SUN6I_SPI0_TCR,
> +					     SUN6I_TCR_XCH,
> +					     SUN6I_SPI0_FIFO_STA,
> +					     SUN6I_SPI0_TXD,
> +					     SUN6I_SPI0_RXD,
> +					     SUN6I_SPI0_MBC,
> +					     SUN6I_SPI0_MTC,
> +					     SUN6I_SPI0_BCC);
> +		} else {
> +			sunxi_spi0_read_data(buf8, addr, chunk_len,
> +					     SUN4I_SPI0_CTL,
> +					     SUN4I_CTL_XCH,
> +					     SUN4I_SPI0_FIFO_STA,
> +					     SUN4I_SPI0_TX,
> +					     SUN4I_SPI0_RX,
> +					     SUN4I_SPI0_BC,
> +					     SUN4I_SPI0_TC,
> +					     0);
> +		}
> +
> +		len  -= chunk_len;
> +		buf8 += chunk_len;
> +		addr += chunk_len;
> +	}
> +}
> +
> +/*****************************************************************************/
> +
> +int spl_spi_load_image(void)
> +{
> +	int err;
> +	struct image_header *header;
> +	header = (struct image_header *)(CONFIG_SYS_TEXT_BASE);
> +
> +	spi0_init();
> +
> +	spi0_read_data((void *)header, CONFIG_SYS_SPI_U_BOOT_OFFS, 0x40);
> +	err = spl_parse_image_header(header);
> +	if (err)
> +		return err;
> +
> +	spi0_read_data((void *)spl_image.load_addr, CONFIG_SYS_SPI_U_BOOT_OFFS,
> +		       spl_image.size);
> +
> +	spi0_deinit();
> +	return 0;
> +}
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index b33cfb8..7d244d9 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -137,6 +137,11 @@
>  #define CONFIG_SPL_NAND_SUPPORT 1
>  #endif
>
> +#ifdef CONFIG_SPL_SPI_SUNXI
> +#define CONFIG_SPL_SPI_FLASH_SUPPORT	1
> +#define CONFIG_SYS_SPI_U_BOOT_OFFS	0x8000
> +#endif
> +
>  /* mmc config */
>  #ifdef CONFIG_MMC
>  #define CONFIG_GENERIC_MMC
>