Hi, On 9 June 2016 at 18:33, Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: > Hi Simon, > > On Thu, 9 Jun 2016 17:36:10 -0700 > Simon Glass <s...@chromium.org> wrote: > >> Hi, >> >> On 7 June 2016 at 05:28, Siarhei Siamashka <siarhei.siamas...@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.siamas...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
