On 9 June 2016 at 22:28, Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: > 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.
Nice work. Reviewed-by: Simon Glass <s...@chromium.org> (I'm not a fan of the *********** in comments but will leave that to Hans to decide) _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot