From e44e3482bdb4d0ebde2d8b41830ac2cdb07948fb Mon Sep 17 00:00:00 2001 From: Yang Zhang Date: Fri, 28 Aug 2015 09:58:54 +0800 Subject: Add qemu 2.4.0 Change-Id: Ic99cbad4b61f8b127b7dc74d04576c0bcbaaf4f5 Signed-off-by: Yang Zhang --- qemu/roms/u-boot/doc/SPL/README.am335x-network | 92 ++++++++++++++++++++++++++ qemu/roms/u-boot/doc/SPL/README.omap3 | 52 +++++++++++++++ 2 files changed, 144 insertions(+) create mode 100644 qemu/roms/u-boot/doc/SPL/README.am335x-network create mode 100644 qemu/roms/u-boot/doc/SPL/README.omap3 (limited to 'qemu/roms/u-boot/doc/SPL') diff --git a/qemu/roms/u-boot/doc/SPL/README.am335x-network b/qemu/roms/u-boot/doc/SPL/README.am335x-network new file mode 100644 index 000000000..9b63791ad --- /dev/null +++ b/qemu/roms/u-boot/doc/SPL/README.am335x-network @@ -0,0 +1,92 @@ +USING AM335x NETBOOT FEATURE + + Some boards (like TI AM335x based ones) have quite big on-chip RAM and +have support for booting via network in ROM. The following describes +how to setup network booting and then optionally use this support to flash +NAND and bricked (empty) board with only a network cable. + + I. Building the required images + 1. You have to enable generic SPL configuration options (see +doc/README.SPL) as well as CONFIG_SPL_NET_SUPPORT, +CONFIG_ETH_SUPPORT, CONFIG_SPL_LIBGENERIC_SUPPORT and +CONFIG_SPL_LIBCOMMON_SUPPORT in your board configuration file to build +SPL with support for booting over the network. Also you have to enable +the driver for the NIC used and CONFIG_SPL_BOARD_INIT option if your +board needs some board-specific initialization (TI AM335x EVM does). +If you want SPL to use some Vendor Class Identifier (VCI) you can set +one with CONFIG_SPL_NET_VCI_STRING option. am335x_evm configuration +comes with support for network booting preconfigured. + 2. Define CONFIG_BOOTCOMMAND for your board to load and run debrick +script after boot: +#define CONFIG_BOOTCOMMAND \ + "setenv autoload no; " \ + "bootp; " \ + "if tftp 80000000 debrick.scr; then " \ + "source 80000000; " \ + "fi" +(Or create additional board configuration with such option). + 3. Build U-Boot as usual + $ make + You will need u-boot.img and spl/u-boot.bin images to perform +network boot. Copy them to u-boot-restore.img and +u-boot-spl-restore.bin respectively to distinguish this version +(with automatic restore running) from the main one. + + II. Host configuration. + 1. Setup DHCP server (recommended server is ISC DHCPd). + - Install DHCP server and setup it to listen on the interface you +chose to connect to the board (usually configured in +/etc/default/dhcpd or /etc/default/isc-dhcp-server). Make sure there +are no other active DHCP servers in the same network segment. + - Edit your dhcpd.conf and subnet declaration matching the address +on the interface. Specify the range of assigned addresses and bootfile +to use. IMPORTANT! Both RBL and SPL use the image filename provided +in the BOOTP reply but obviously they need different images (RBL needs +raw SPL image -- u-boot-spl-restore.bin while SPL needs main U-Boot +image -- u-boot-restore.img). So you have to configure DHCP server to +provide different image filenames to RBL and SPL (and possibly another +one to main U-Boot). This can be done by checking Vendor Class +Identifier (VCI) set by BOOTP client (RBL sets VCI to "DM814x ROM v1.0" +and you can set VCI used by SPL with CONFIG_SPL_NET_VCI_STRING option, +see above). + - If you plan to use TFTP server on another machine you have to set +server-name option to point to it. + - Here is sample configuration for ISC DHCPd, assuming the interface +used to connect to the board is eth0, and it has address 192.168.8.1: + +subnet 192.168.8.0 netmask 255.255.255.0 { + range dynamic-bootp 192.168.8.100 192.168.8.199; + + if substring (option vendor-class-identifier, 0, 10) = "DM814x ROM" { + filename "u-boot-spl-restore.bin"; + } elsif substring (option vendor-class-identifier, 0, 17) = "AM335x U-Boot SPL" { + filename "u-boot-restore.img"; + } else { + filename "uImage"; + } +} + + 2. Setup TFTP server. + Install TFTP server and put image files to it's root directory +(likely /tftpboot or /var/lib/tftpboot or /srv/tftp). You will need +u-boot.img and spl/u-boot-spl-bin files from U-Boot build directory. + + III. Reflashing (debricking) the board. + 1. Write debrick script. You will need to write a script that will +be executed after network boot to perform actual rescue actions. You +can use usual U-Boot commands from this script: tftp to load additional +files, nand erase/nand write to erase/write the NAND flash. + + 2. Create script image from your script. From U-Boot build directory: + +$ ./tools/mkimage -A arm -O U-Boot -C none -T script -d debrick.scr + +This will create debrick.scr file with your script inside. + + 3. Copy debrick.scr to TFTP root directory. You also need to copy +there all the files your script tries to load via TFTP. Example script +loads u-boot.img and MLO. You have to create these files doing regular +(not restore_flash) build and copy them to tftpboot directory. + + 4. Boot the board from the network, U-Boot will load debrick script +and run it after boot. diff --git a/qemu/roms/u-boot/doc/SPL/README.omap3 b/qemu/roms/u-boot/doc/SPL/README.omap3 new file mode 100644 index 000000000..c77ca4300 --- /dev/null +++ b/qemu/roms/u-boot/doc/SPL/README.omap3 @@ -0,0 +1,52 @@ +Overview of SPL on OMAP3 devices +================================ + +Introduction +------------ + +This document provides an overview of how SPL functions on OMAP3 (and related +such as am35x and am37x) processors. + +Methodology +----------- + +On these platforms the ROM supports trying a sequence of boot devices. Once +one has been used successfully to load SPL this information is stored in memory +and the location stored in a register. We will read this to determine where to +read U-Boot from in turn. + +Memory Map +---------- + +This is an example of a typical setup. See top-level README for documentation +of which CONFIG variables control these values. For a given board and the +amount of DRAM available to it different values may need to be used. +Note that the size of the SPL text rodata and data is enforced with a CONFIG +option and growing over that size results in a link error. The SPL stack +starts at the top of SRAM (which is configurable) and grows downward. The +space between the top of SRAM and the enforced upper bound on the size of the +SPL text, data and rodata is considered the safe stack area. Details on +confirming this behavior are shown below. + +A portion of the system memory map looks as follows: +SRAM: 0x40200000 - 0x4020FFFF +DDR1: 0x80000000 - 0xBFFFFFFF + +Option 1 (SPL only): +0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata +0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x80000000 - 0x8007FFFF: Area for the SPL BSS. +0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot +0x80208000 - 0x80307FFF: malloc() pool available to SPL. + +Option 2 (SPL or X-Loader): +0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata +0x4020E000 - 0x4020FFFC: Area for the SPL stack. +0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot +0x87000000 - 0x8707FFFF: Area for the SPL BSS. +0x87080000 - 0x870FFFFF: malloc() pool available to SPL. + +For the areas that reside within DDR1 they must not be used prior to s_init() +completing. Note that CONFIG_SYS_TEXT_BASE must be clear of the areas that SPL +uses while running. This is why we have two versions of the memory map that +only vary in where the BSS and malloc pool reside. -- cgit