Home | History | Annotate | only in /external/u-boot/doc/SPL
Up to higher level directory
NameDateSize
README.am335x-network22-Oct-20204.4K
README.omap322-Oct-20202.1K
README.spl-secure-boot22-Oct-2020721

README.am335x-network

      1 USING AM335x NETBOOT FEATURE
      2 
      3  Some boards (like TI AM335x based ones) have quite big on-chip RAM and
      4 have support for booting via network in ROM. The following describes
      5 how to setup network booting and then optionally use this support to flash
      6 NAND and bricked (empty) board with only a network cable.
      7 
      8  I. Building the required images
      9   1. You have to enable generic SPL configuration options (see
     10 doc/README.SPL) as well as CONFIG_SPL_NET_SUPPORT,
     11 CONFIG_ETH_SUPPORT, CONFIG_SPL_LIBGENERIC_SUPPORT and
     12 CONFIG_SPL_LIBCOMMON_SUPPORT in your board configuration file to build
     13 SPL with support for booting over the network. Also you have to enable
     14 the driver for the NIC used and CONFIG_SPL_BOARD_INIT option if your
     15 board needs some board-specific initialization (TI AM335x EVM does).
     16 If you want SPL to use some Vendor Class Identifier (VCI) you can set
     17 one with CONFIG_SPL_NET_VCI_STRING option. am335x_evm configuration
     18 comes with support for network booting preconfigured.
     19  2. Define CONFIG_BOOTCOMMAND for your board to load and run debrick
     20 script after boot:
     21 #define CONFIG_BOOTCOMMAND					\
     22 	"setenv autoload no; "					\
     23 	"bootp; "						\
     24 	"if tftp 80000000 debrick.scr; then "			\
     25 		"source 80000000; "				\
     26 	"fi"
     27 (Or create additional board configuration with such option).
     28  3. Build U-Boot as usual
     29   $ make <your_board_name>
     30     You will need u-boot.img and spl/u-boot.bin images to perform
     31 network boot. Copy them to u-boot-restore.img and
     32 u-boot-spl-restore.bin respectively to distinguish this version
     33 (with automatic restore running) from the main one.
     34 
     35  II. Host configuration.
     36   1. Setup DHCP server (recommended server is ISC DHCPd).
     37    - Install DHCP server and setup it to listen on the interface you
     38 chose to connect to the board (usually configured in
     39 /etc/default/dhcpd or /etc/default/isc-dhcp-server). Make sure there
     40 are no other active DHCP servers in the same network segment.
     41    - Edit your dhcpd.conf and subnet declaration matching the address
     42 on the interface. Specify the range of assigned addresses and bootfile
     43 to use. IMPORTANT! Both RBL and SPL use the image filename provided
     44 in the BOOTP reply but obviously they need different images (RBL needs
     45 raw SPL image -- u-boot-spl-restore.bin while SPL needs main U-Boot
     46 image -- u-boot-restore.img). So you have to configure DHCP server to
     47 provide different image filenames to RBL and SPL (and possibly another
     48 one to main U-Boot). This can be done by checking Vendor Class
     49 Identifier (VCI) set by BOOTP client (RBL sets VCI to "DM814x ROM v1.0"
     50 and you can set VCI used by SPL with CONFIG_SPL_NET_VCI_STRING option,
     51 see above).
     52    - If you plan to use TFTP server on another machine you have to set
     53 server-name option to point to it.
     54    - Here is sample configuration for ISC DHCPd, assuming the interface
     55 used to connect to the board is eth0, and it has address 192.168.8.1:
     56 
     57 subnet 192.168.8.0 netmask 255.255.255.0 {
     58   range dynamic-bootp 192.168.8.100 192.168.8.199;
     59 
     60   if substring (option vendor-class-identifier, 0, 10) = "DM814x ROM" {
     61     filename "u-boot-spl-restore.bin";
     62   } elsif substring (option vendor-class-identifier, 0, 17) = "AM335x U-Boot SPL" {
     63     filename "u-boot-restore.img";
     64   } else {
     65     filename "uImage";
     66   }
     67 }
     68 
     69   May the ROM bootloader sends another "vendor-class-identifier"
     70   on the shc board with an AM335X it is:
     71   "AM335x ROM"
     72 
     73   2. Setup TFTP server.
     74      Install TFTP server and put image files to it's root directory
     75 (likely /tftpboot or /var/lib/tftpboot or /srv/tftp). You will need
     76 u-boot.img and spl/u-boot-spl-bin files from U-Boot build directory.
     77 
     78  III. Reflashing (debricking) the board.
     79   1. Write debrick script. You will need to write a script that will
     80 be executed after network boot to perform actual rescue actions. You
     81 can use usual U-Boot commands from this script: tftp to load additional
     82 files, nand erase/nand write to erase/write the NAND flash.
     83 
     84   2. Create script image from your script. From U-Boot build directory:
     85 
     86 $ ./tools/mkimage -A arm -O U-Boot -C none -T script -d <your script> debrick.scr
     87 
     88 This will create debrick.scr file with your script inside.
     89 
     90   3. Copy debrick.scr to TFTP root directory. You also need to copy
     91 there all the files your script tries to load via TFTP. Example script
     92 loads u-boot.img and MLO. You have to create these files doing regular
     93 (not restore_flash) build and copy them to tftpboot directory.
     94 
     95   4. Boot the board from the network, U-Boot will load debrick script
     96 and run it after boot.
     97 

README.omap3

      1 Overview of SPL on OMAP3 devices
      2 ================================
      3 
      4 Introduction
      5 ------------
      6 
      7 This document provides an overview of how SPL functions on OMAP3 (and related
      8 such as am35x and am37x) processors.
      9 
     10 Methodology
     11 -----------
     12 
     13 On these platforms the ROM supports trying a sequence of boot devices.  Once
     14 one has been used successfully to load SPL this information is stored in memory
     15 and the location stored in a register.  We will read this to determine where to
     16 read U-Boot from in turn.
     17 
     18 Memory Map
     19 ----------
     20 
     21 This is an example of a typical setup.  See top-level README for documentation
     22 of which CONFIG variables control these values.  For a given board and the
     23 amount of DRAM available to it different values may need to be used.
     24 Note that the size of the SPL text rodata and data is enforced with a CONFIG
     25 option and growing over that size results in a link error.  The SPL stack
     26 starts at the top of SRAM (which is configurable) and grows downward.  The
     27 space between the top of SRAM and the enforced upper bound on the size of the
     28 SPL text, data and rodata is considered the safe stack area.  Details on
     29 confirming this behavior are shown below.
     30 
     31 A portion of the system memory map looks as follows:
     32 SRAM: 0x40200000 - 0x4020FFFF
     33 DDR1: 0x80000000 - 0xBFFFFFFF
     34 
     35 Option 1 (SPL only):
     36 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
     37 0x4020E000 - 0x4020FFFC: Area for the SPL stack.
     38 0x80000000 - 0x8007FFFF: Area for the SPL BSS.
     39 0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot
     40 0x80208000 - 0x80307FFF: malloc() pool available to SPL.
     41 
     42 Option 2 (SPL or X-Loader):
     43 0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
     44 0x4020E000 - 0x4020FFFC: Area for the SPL stack.
     45 0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot
     46 0x87000000 - 0x8707FFFF: Area for the SPL BSS.
     47 0x87080000 - 0x870FFFFF: malloc() pool available to SPL.
     48 
     49 For the areas that reside within DDR1 they must not be used prior to s_init()
     50 completing.  Note that CONFIG_SYS_TEXT_BASE must be clear of the areas that SPL
     51 uses while running.  This is why we have two versions of the memory map that
     52 only vary in where the BSS and malloc pool reside.
     53 

README.spl-secure-boot

      1 Overview of SPL verified boot on powerpc/mpc85xx & arm/layerscape platforms
      2 ===========================================================================
      3 
      4 Introduction
      5 ------------
      6 
      7 This document provides an overview of how SPL verified boot works on powerpc/
      8 mpc85xx & arm/layerscape platforms.
      9 
     10 Methodology
     11 -----------
     12 
     13 The SPL image is responsible for loading the next stage boot loader, which is
     14 the main u-boot image. For secure boot process on these platforms ROM verifies
     15 SPL image, so to continue chain of trust SPL image verifies U-boot image using
     16 spl_validate_uboot(). This function uses QorIQ Trust Architecture header
     17 (appended to U-boot image) to validate the U-boot binary just before passing
     18 control to it.
     19