---------------------------------------------------
For all supported boards there are ready-to-use default
-configurations available; just type "make <board_name>_config".
+configurations available; just type "make <board_name>_defconfig".
Example: For a TQM823L module type:
cd u-boot
- make TQM823L_config
+ make TQM823L_defconfig
For the Cogent platform, you need to specify the CPU type as well;
-e.g. "make cogent_mpc8xx_config". And also configure the cogent
+e.g. "make cogent_mpc8xx_defconfig". And also configure the cogent
directory according to the instructions in cogent/README.
specific to be undertaken on a native platform. The sandbox is also used to
run some of U-Boot's tests.
-See board/sandbox/sandbox/README.sandbox for more details.
+See board/sandbox/README.sandbox for more details.
Configuration Options:
interleaving mode, handled by Dickens for Freescale layerscape
SoCs with ARM core.
+ CONFIG_SYS_FSL_DDR_MAIN_NUM_CTRLS
+ Number of controllers used as main memory.
+
+ CONFIG_SYS_FSL_OTHER_DDR_NUM_CTRLS
+ Number of controllers used for other than main memory.
+
+ CONFIG_SYS_FSL_SEC_BE
+ Defines the SEC controller register space as Big Endian
+
+ CONFIG_SYS_FSL_SEC_LE
+ Defines the SEC controller register space as Little Endian
+
- Intel Monahans options:
CONFIG_SYS_MONAHANS_RUN_MODE_OSC_RATIO
exists, unlike the similar options in the Linux kernel. Do not
set these options unless they apply!
-- CPU timer options:
- CONFIG_SYS_HZ
-
- The frequency of the timer returned by get_timer().
- get_timer() must operate in milliseconds and this CONFIG
- option must be set to 1000.
-
- Linux Kernel Interface:
CONFIG_CLOCKS_IN_MHZ
CONFIG_CMD_BMP * BMP support
CONFIG_CMD_BSP * Board specific commands
CONFIG_CMD_BOOTD bootd
+ CONFIG_CMD_BOOTI * ARM64 Linux kernel Image support
CONFIG_CMD_CACHE * icache, dcache
CONFIG_CMD_CLK * clock command support
CONFIG_CMD_CONSOLE coninfo
CONFIG_RTC_DS1307 - use Maxim, Inc. DS1307 RTC
CONFIG_RTC_DS1337 - use Maxim, Inc. DS1337 RTC
CONFIG_RTC_DS1338 - use Maxim, Inc. DS1338 RTC
+ CONFIG_RTC_DS1339 - use Maxim, Inc. DS1339 RTC
CONFIG_RTC_DS164x - use Dallas DS164x RTC
CONFIG_RTC_ISL1208 - use Intersil ISL1208 RTC
CONFIG_RTC_MAX6900 - use Maxim, Inc. MAX6900 RTC
CONFIG_USB_EHCI_TXFIFO_THRESH enables setting of the
txfilltuning field in the EHCI controller on reset.
+ CONFIG_USB_DWC2_REG_ADDR the physical CPU address of the DWC2
+ HW module registers.
+
- USB Device:
Define the below if you wish to use the USB console.
Once firmware is rebuilt from a serial console issue the
downloads. This buffer should be as large as possible for a
platform. Define this to the size available RAM for fastboot.
+ CONFIG_FASTBOOT_FLASH
+ The fastboot protocol includes a "flash" command for writing
+ the downloaded image to a non-volatile storage device. Define
+ this to enable the "fastboot flash" command.
+
+ CONFIG_FASTBOOT_FLASH_MMC_DEV
+ The fastboot "flash" command requires additional information
+ regarding the non-volatile storage device. Define this to
+ the eMMC device that fastboot should use to store the image.
+
- Journaling Flash filesystem support:
CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF, CONFIG_JFFS2_NAND_SIZE,
CONFIG_JFFS2_NAND_DEV
4th and following
BOOTP requests: delay 0 ... 8 sec
+ CONFIG_BOOTP_ID_CACHE_SIZE
+
+ BOOTP packets are uniquely identified using a 32-bit ID. The
+ server will copy the ID from client requests to responses and
+ U-Boot will use this to determine if it is the destination of
+ an incoming response. Some servers will check that addresses
+ aren't in use before handing them out (usually using an ARP
+ ping) and therefore take up to a few hundred milliseconds to
+ respond. Network congestion may also influence the time it
+ takes for a response to make it back to the client. If that
+ time is too long, U-Boot will retransmit requests. In order
+ to allow earlier responses to still be accepted after these
+ retransmissions, U-Boot's BOOTP client keeps a small cache of
+ IDs. The CONFIG_BOOTP_ID_CACHE_SIZE controls the size of this
+ cache. The default is to keep IDs for up to four outstanding
+ requests. Increasing this will allow U-Boot to accept offers
+ from a BOOTP client in networks with unusually high latency.
+
- DHCP Advanced Options:
You can fine tune the DHCP functionality by defining
CONFIG_BOOTP_* symbols:
Enables the driver for the SPI controllers on i.MX and MXC
SoCs. Currently i.MX31/35/51 are supported.
+ CONFIG_SYS_SPI_MXC_WAIT
+ Timeout for waiting until spi transfer completed.
+ default: (CONFIG_SYS_HZ/100) /* 10 ms */
+
- FPGA Support: CONFIG_FPGA
Enables FPGA subsystem.
200 ms.
- Configuration Management:
+ CONFIG_BUILD_TARGET
+
+ Some SoCs need special image types (e.g. U-Boot binary
+ with a special header) as build targets. By defining
+ CONFIG_BUILD_TARGET in the SoC / board header, this
+ special image will be automatically built upon calling
+ make / MAKEALL.
+
CONFIG_IDENT_STRING
If defined, this string will be added to the U-Boot
Enable auto completion of commands using TAB.
- Note that this feature has NOT been implemented yet
- for the "hush" shell.
-
-
CONFIG_SYS_HUSH_PARSER
Define this variable to enable the "hush" shell (from
memories can be connected with a given cs line.
currently Xilinx Zynq qspi support these type of connections.
+ CONFIG_SYS_SPI_ST_ENABLE_WP_PIN
+ enable the W#/Vpp signal to disable writing to the status
+ register on ST MICRON flashes like the N25Q128.
+ The status register write enable/disable bit, combined with
+ the W#/VPP signal provides hardware data protection for the
+ device as follows: When the enable/disable bit is set to 1,
+ and the W#/VPP signal is driven LOW, the status register
+ nonvolatile bits become read-only and the WRITE STATUS REGISTER
+ operation will not execute. The only way to exit this
+ hardware-protected mode is to drive W#/VPP HIGH.
+
- SystemACE Support:
CONFIG_SYSTEMACE
Adds the MTD partitioning infrastructure from the Linux
kernel. Needed for UBI support.
+ CONFIG_MTD_NAND_VERIFY_WRITE
+ verify if the written data is correct reread.
+
- UBI support
CONFIG_CMD_UBI
Make the verbose messages from UBI stop printing. This leaves
warnings and errors enabled.
+
+ CONFIG_MTD_UBI_WL_THRESHOLD
+ This parameter defines the maximum difference between the highest
+ erase counter value and the lowest erase counter value of eraseblocks
+ of UBI devices. When this threshold is exceeded, UBI starts performing
+ wear leveling by means of moving data from eraseblock with low erase
+ counter to eraseblocks with high erase counter.
+
+ The default value should be OK for SLC NAND flashes, NOR flashes and
+ other flashes which have eraseblock life-cycle 100000 or more.
+ However, in case of MLC NAND flashes which typically have eraseblock
+ life-cycle less than 10000, the threshold should be lessened (e.g.,
+ to 128 or 256, although it does not have to be power of 2).
+
+ default: 4096
+
+ CONFIG_MTD_UBI_BEB_LIMIT
+ This option specifies the maximum bad physical eraseblocks UBI
+ expects on the MTD device (per 1024 eraseblocks). If the
+ underlying flash does not admit of bad eraseblocks (e.g. NOR
+ flash), this value is ignored.
+
+ NAND datasheets often specify the minimum and maximum NVM
+ (Number of Valid Blocks) for the flashes' endurance lifetime.
+ The maximum expected bad eraseblocks per 1024 eraseblocks
+ then can be calculated as "1024 * (1 - MinNVB / MaxNVB)",
+ which gives 20 for most NANDs (MaxNVB is basically the total
+ count of eraseblocks on the chip).
+
+ To put it differently, if this value is 20, UBI will try to
+ reserve about 1.9% of physical eraseblocks for bad blocks
+ handling. And that will be 1.9% of eraseblocks on the entire
+ NAND chip, not just the MTD partition UBI attaches. This means
+ that if you have, say, a NAND flash chip admits maximum 40 bad
+ eraseblocks, and it is split on two MTD partitions of the same
+ size, UBI will reserve 40 eraseblocks when attaching a
+ partition.
+
+ default: 20
+
+ CONFIG_MTD_UBI_FASTMAP
+ Fastmap is a mechanism which allows attaching an UBI device
+ in nearly constant time. Instead of scanning the whole MTD device it
+ only has to locate a checkpoint (called fastmap) on the device.
+ The on-flash fastmap contains all information needed to attach
+ the device. Using fastmap makes only sense on large devices where
+ attaching by scanning takes long. UBI will not automatically install
+ a fastmap on old images, but you can set the UBI parameter
+ CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT to 1 if you want so. Please note
+ that fastmap-enabled images are still usable with UBI implementations
+ without fastmap support. On typical flash devices the whole fastmap
+ fits into one PEB. UBI will reserve PEBs to hold two fastmaps.
+
+ CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT
+ Set this parameter to enable fastmap automatically on images
+ without a fastmap.
+ default: 0
+
- UBIFS support
CONFIG_CMD_UBIFS
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR,
CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS,
- CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION
+ CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION
Address, size and partition on the MMC to load U-Boot from
when the MMC is being used in raw mode.
CONFIG_SPL_FAT_SUPPORT
Support for fs/fat/libfat.o in SPL binary
- CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME
- Filename to read to load U-Boot when reading from FAT
+ CONFIG_SPL_EXT_SUPPORT
+ Support for EXT filesystem in SPL binary
+
+ CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
+ Filename to read to load U-Boot when reading from filesystem
- CONFIG_SPL_FAT_LOAD_KERNEL_NAME
+ CONFIG_SPL_FS_LOAD_KERNEL_NAME
Filename to read to load kernel uImage when reading
- from FAT (for Falcon mode)
+ from filesystem (for Falcon mode)
- CONFIG_SPL_FAT_LOAD_ARGS_NAME
+ CONFIG_SPL_FS_LOAD_ARGS_NAME
Filename to read to load kernel argument parameters
- when reading from FAT (for Falcon mode)
+ when reading from filesystem (for Falcon mode)
CONFIG_SPL_MPC83XX_WAIT_FOR_NAND
Set this for NAND SPL on PPC mpc83xx targets, so that
- CONFIG_SYS_MALLOC_LEN:
Size of DRAM reserved for malloc() use.
+- CONFIG_SYS_MALLOC_F_LEN
+ Size of the malloc() pool for use before relocation. If
+ this is defined, then a very simple malloc() implementation
+ will become available before relocation. The address is just
+ below the global data, and the stack is moved down to make
+ space.
+
+ This feature allocates regions with increasing addresses
+ within the region. calloc() is supported, but realloc()
+ is not available. free() is supported but does nothing.
+ The memory will be freed (or in fact just forgotton) when
+ U-Boot relocates itself.
+
+ Pre-relocation malloc() is only supported on ARM and sandbox
+ at present but is fairly easy to enable for other archs.
+
- CONFIG_SYS_BOOTM_LEN:
Normally compressed uImages are limited to an
uncompressed size of 8 MBytes. If this is not enough,
be asserted. See doc/README.omap-reset-time for details on how
the value can be calulated on a given board.
+- CONFIG_USE_STDINT
+ If stdint.h is available with your toolchain you can define this
+ option to enable it. You can provide option 'USE_STDINT=1' when
+ building U-Boot to enable this.
+
The following definitions that deal with the placement and management
of environment data (variable area); in general, we support the
following configurations:
later, once stdio is running and output goes to the LCD, if
present.
+- CONFIG_BOARD_SIZE_LIMIT:
+ Maximum size of the U-Boot image. When defined, the
+ build system checks that the actual size does not
+ exceed it.
+
Low Level (hardware related) configuration options:
---------------------------------------------------
sources you must configure U-Boot for one specific board type. This
is done by typing:
- make NAME_config
+ make NAME_defconfig
-where "NAME_config" is the name of one of the existing configu-
+where "NAME_defconfig" is the name of one of the existing configu-
rations; see boards.cfg for supported names.
Note: for some board special configuration names may exist; check if
or with LCD support. You can select such additional "features"
when choosing the configuration, i. e.
- make TQM823L_config
+ make TQM823L_defconfig
- will configure for a plain TQM823L, i. e. no LCD support
- make TQM823L_LCD_config
+ make TQM823L_LCD_defconfig
- will configure for a TQM823L with U-Boot console on LCD
etc.
1. Add O= to the make command line invocations:
make O=/tmp/build distclean
- make O=/tmp/build NAME_config
+ make O=/tmp/build NAME_defconfig
make O=/tmp/build all
-2. Set environment variable BUILD_DIR to point to the desired location:
+2. Set environment variable KBUILD_OUTPUT to point to the desired location:
- export BUILD_DIR=/tmp/build
+ export KBUILD_OUTPUT=/tmp/build
make distclean
- make NAME_config
+ make NAME_defconfig
make all
-Note that the command line "O=" setting overrides the BUILD_DIR environment
+Note that the command line "O=" setting overrides the KBUILD_OUTPUT environment
variable.
your board
3. If you're porting U-Boot to a new CPU, then also create a new
directory to hold your CPU specific code. Add any files you need.
-4. Run "make <board>_config" with your new name.
+4. Run "make <board>_defconfig" with your new name.
5. Type "make", and you should get a working "u-boot.srec" file
to be installed on your target system.
6. Debug and solve any problems that might arise.
Example:
- make TQM850L_config
+ make TQM850L_defconfig
make oldconfig
make dep
make uImage