On Thu, 9 Jun 2016 19:42:55 -0700 Simon Glass <s...@chromium.org> wrote:
> 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. 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. -- Regards, Sierž _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
