X-Git-Url: https://git.kernelconcepts.de/?a=blobdiff_plain;f=README;h=e7cd1bcb436dff45feb2be387eaee30323cc15ae;hb=7267c925b3817478c9ccd0c4a1286ff81f7859f9;hp=f704eb3780082d76a93fe8a5d6a348f49ae7693f;hpb=48b3ed217f58487c583d59575d7dfe2aafbb738d;p=karo-tx-uboot.git diff --git a/README b/README index f704eb3780..e7cd1bcb43 100644 --- a/README +++ b/README @@ -252,15 +252,15 @@ Selection of Processor Architecture and Board Type: --------------------------------------------------- For all supported boards there are ready-to-use default -configurations available; just type "make _config". +configurations available; just type "make _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. @@ -272,7 +272,7 @@ board. This allows feature development which is not board- or architecture- 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: @@ -538,6 +538,18 @@ The following options need to be configured: 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 @@ -611,12 +623,119 @@ The following options need to be configured: exists, unlike the similar options in the Linux kernel. Do not set these options unless they apply! -- CPU timer options: - CONFIG_SYS_HZ +- Driver Model + Driver model is a new framework for devices in U-Boot + introduced in early 2014. U-Boot is being progressively + moved over to this. It offers a consistent device structure, + supports grouping devices into classes and has built-in + handling of platform data and device tree. + + To enable transition to driver model in a relatively + painful fashion, each subsystem can be independently + switched between the legacy/ad-hoc approach and the new + driver model using the options below. Also, many uclass + interfaces include compatibility features which may be + removed once the conversion of that subsystem is complete. + As a result, the API provided by the subsystem may in fact + not change with driver model. + + See doc/driver-model/README.txt for more information. + + CONFIG_DM + + Enable driver model. This brings in the core support, + including scanning of platform data on start-up. If + CONFIG_OF_CONTROL is enabled, the device tree will be + scanned also when available. + + CONFIG_CMD_DM + + Enable driver model test commands. These allow you to print + out the driver model tree and the uclasses. + + CONFIG_DM_DEMO + + Enable some demo devices and the 'demo' command. These are + really only useful for playing around while trying to + understand driver model in sandbox. + + CONFIG_SPL_DM + + Enable driver model in SPL. You will need to provide a + suitable malloc() implementation. If you are not using the + full malloc() enabled by CONFIG_SYS_SPL_MALLOC_START, + consider using CONFIG_SYS_MALLOC_SIMPLE. In that case you + must provide CONFIG_SYS_MALLOC_F_LEN to set the size. + In most cases driver model will only allocate a few uclasses + and devices in SPL, so 1KB should be enable. See + CONFIG_SYS_MALLOC_F_LEN for more details on how to enable + it. + + CONFIG_DM_SERIAL + + Enable driver model for serial. This replaces + drivers/serial/serial.c with the serial uclass, which + implements serial_putc() etc. The uclass interface is + defined in include/serial.h. + + CONFIG_DM_GPIO + + Enable driver model for GPIO access. The standard GPIO + interface (gpio_get_value(), etc.) is then implemented by + the GPIO uclass. Drivers provide methods to query the + particular GPIOs that they provide. The uclass interface + is defined in include/asm-generic/gpio.h. + + CONFIG_DM_SPI + + Enable driver model for SPI. The SPI slave interface + (spi_setup_slave(), spi_xfer(), etc.) is then implemented by + the SPI uclass. Drivers provide methods to access the SPI + buses that they control. The uclass interface is defined in + include/spi.h. The existing spi_slave structure is attached + as 'parent data' to every slave on each bus. Slaves + typically use driver-private data instead of extending the + spi_slave structure. + + CONFIG_DM_SPI_FLASH + + Enable driver model for SPI flash. This SPI flash interface + (spi_flash_probe(), spi_flash_write(), etc.) is then + implemented by the SPI flash uclass. There is one standard + SPI flash driver which knows how to probe most chips + supported by U-Boot. The uclass interface is defined in + include/spi_flash.h, but is currently fully compatible + with the old interface to avoid confusion and duplication + during the transition parent. SPI and SPI flash must be + enabled together (it is not possible to use driver model + for one and not the other). + + CONFIG_DM_CROS_EC + + Enable driver model for the Chrome OS EC interface. This + allows the cros_ec SPI driver to operate with CONFIG_DM_SPI + but otherwise makes few changes. Since cros_ec also supports + I2C and LPC (which don't support driver model yet), a full + conversion is not yet possible. + + + ** Code size options: The following options are enabled by + default except in SPL. Enable them explicitly to get these + features in SPL. + + CONFIG_DM_WARN + + Enable the dm_warn() function. This can use up quite a bit + of space for its strings. + + CONFIG_DM_STDIO + + Enable registering a serial device with the stdio library. + + CONFIG_DM_DEVICE_REMOVE + + Enable removing of devices. - 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 @@ -959,6 +1078,7 @@ The following options need to be configured: 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 @@ -983,6 +1103,7 @@ The following options need to be configured: CONFIG_CMD_EXT4 * ext4 command support CONFIG_CMD_FS_GENERIC * filesystem commands (e.g. load, ls) that work for multiple fs types + CONFIG_CMD_FS_UUID * Look up a filesystem UUID CONFIG_CMD_SAVEENV saveenv CONFIG_CMD_FDC * Floppy Disk Support CONFIG_CMD_FAT * FAT command support @@ -1152,6 +1273,7 @@ The following options need to be configured: 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 @@ -1377,6 +1499,10 @@ The following options need to be configured: CONFIG_SH_ETHER_CACHE_WRITEBACK If this option is set, the driver enables cache flush. +- PWM Support: + CONFIG_PWM_IMX + Support for PWM modul on the imx6. + - TPM Support: CONFIG_TPM Support TPM devices. @@ -1447,6 +1573,9 @@ The following options need to be configured: 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 @@ -1623,6 +1752,16 @@ The following options need to be configured: 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 @@ -2036,6 +2175,24 @@ CBFS (Coreboot Filesystem) support 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: @@ -2597,6 +2754,10 @@ CBFS (Coreboot Filesystem) support 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. @@ -2672,6 +2833,14 @@ CBFS (Coreboot Filesystem) support 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 @@ -2780,22 +2949,6 @@ CBFS (Coreboot Filesystem) support 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 - Busybox) as command line interpreter, thus enabling - powerful command line syntax like - if...then...else...fi conditionals or `&&' and '||' - constructs ("shell scripts"). - - If undefined, you get the old, much simpler behaviour - with a somewhat smaller memory footprint. - - CONFIG_SYS_PROMPT_HUSH_PS2 This defines the secondary prompt string, which is @@ -2926,6 +3079,17 @@ CBFS (Coreboot Filesystem) support 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 @@ -3315,6 +3479,9 @@ FIT uImage format: 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 @@ -3328,6 +3495,64 @@ FIT uImage format: 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 @@ -3425,7 +3650,7 @@ FIT uImage format: 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. @@ -3442,16 +3667,19 @@ FIT uImage format: 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 @@ -3480,6 +3708,10 @@ FIT uImage format: Support for the MTD subsystem within SPL. Useful for environment on NAND support within SPL. + CONFIG_SPL_NAND_RAW_ONLY + Support to boot only raw u-boot.bin images. Use this only + if you need to save space. + CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT Set for the SPL on PPC mpc8xxx targets, support for drivers/ddr/fsl/libddr.o in SPL binary. @@ -3749,9 +3981,14 @@ Configuration Settings: The memory will be freed (or in fact just forgotton) when U-Boot relocates itself. - Pre-relocation malloc() is only supported on sandbox + Pre-relocation malloc() is only supported on ARM and sandbox at present but is fairly easy to enable for other archs. +- CONFIG_SYS_MALLOC_SIMPLE + Provides a simple and small malloc() and calloc() for those + boards which do not use the full malloc in SPL (which is + enabled with CONFIG_SYS_SPL_MALLOC_START). + - CONFIG_SYS_BOOTM_LEN: Normally compressed uImages are limited to an uncompressed size of 8 MBytes. If this is not enough, @@ -3932,6 +4169,11 @@ Configuration Settings: 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: @@ -4363,6 +4605,11 @@ use the "saveenv" command to store a valid environment. 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: --------------------------------------------------- @@ -4840,9 +5087,9 @@ U-Boot is intended to be simple to build. After installing the 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 @@ -4851,10 +5098,10 @@ 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. @@ -4874,17 +5121,17 @@ this behavior and build U-Boot to some external directory: 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. @@ -4907,7 +5154,7 @@ steps: 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 _config" with your new name. +4. Run "make _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. @@ -5487,7 +5734,7 @@ which was introduced for our predecessor project PPCBoot and uses a Example: - make TQM850L_config + make TQM850L_defconfig make oldconfig make dep make uImage