X-Git-Url: https://git.kernelconcepts.de/?p=karo-tx-uboot.git;a=blobdiff_plain;f=README;h=0a0f528af117e94f86918078b23b7ec8c5561f96;hp=a248ab5d39fc85438ba4adc6ffd0141a5dffd99c;hb=1f359e3611c55d9cfae88dafce04db1833033bd0;hpb=21d29f7f9f4888a4858b58b368ae7cf8783a6ebf diff --git a/README b/README index a248ab5d39..0a0f528af1 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. @@ -959,6 +959,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 @@ -1000,6 +1001,7 @@ The following options need to be configured: CONFIG_CMD_IMLS List all images found in NOR flash CONFIG_CMD_IMLS_NAND * List all images found in NAND flash CONFIG_CMD_IMMAP * IMMR dump support + CONFIG_CMD_IOTRACE * I/O tracing for debugging CONFIG_CMD_IMPORTENV * import an environment CONFIG_CMD_INI * import data from an ini file into the env CONFIG_CMD_IRQ * irqinfo @@ -1151,6 +1153,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 @@ -1171,6 +1174,28 @@ The following options need to be configured: Note that if the GPIO device uses I2C, then the I2C interface must also be configured. See I2C Support, below. +- I/O tracing: + When CONFIG_IO_TRACE is selected, U-Boot intercepts all I/O + accesses and can checksum them or write a list of them out + to memory. See the 'iotrace' command for details. This is + useful for testing device drivers since it can confirm that + the driver behaves the same way before and after a code + change. Currently this is supported on sandbox and arm. To + add support for your architecture, add '#include ' + to the bottom of arch//include/asm/io.h and test. + + Example output from the 'iotrace stats' command is below. + Note that if the trace buffer is exhausted, the checksum will + still continue to operate. + + iotrace is enabled + Start: 10000000 (buffer start address) + Size: 00010000 (buffer size) + Offset: 00000120 (current buffer offset) + Output: 10000120 (start + offset) + Count: 00000018 (number of trace records) + CRC32: 9526fb66 (CRC32 of all trace records) + - Timestamp Support: When CONFIG_TIMESTAMP is selected, the timestamp @@ -1354,6 +1379,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. @@ -1424,9 +1453,6 @@ 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_HUB_MIN_POWER_ON_DELAY defines the minimum - interval for usb hub power-on delay.(minimum 100msec) - - USB Device: Define the below if you wish to use the USB console. Once firmware is rebuilt from a serial console issue the @@ -2016,6 +2042,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: @@ -2268,6 +2312,21 @@ CBFS (Coreboot Filesystem) support 9 i2c buses for Exynos4 and 1 for S3C24X0 SoCs from Samsung) with a fix speed from 100000 and the slave addr 0! + - drivers/i2c/ihs_i2c.c + - activate this driver with CONFIG_SYS_I2C_IHS + - CONFIG_SYS_I2C_IHS_CH0 activate hardware channel 0 + - CONFIG_SYS_I2C_IHS_SPEED_0 speed channel 0 + - CONFIG_SYS_I2C_IHS_SLAVE_0 slave addr channel 0 + - CONFIG_SYS_I2C_IHS_CH1 activate hardware channel 1 + - CONFIG_SYS_I2C_IHS_SPEED_1 speed channel 1 + - CONFIG_SYS_I2C_IHS_SLAVE_1 slave addr channel 1 + - CONFIG_SYS_I2C_IHS_CH2 activate hardware channel 2 + - CONFIG_SYS_I2C_IHS_SPEED_2 speed channel 2 + - CONFIG_SYS_I2C_IHS_SLAVE_2 slave addr channel 2 + - CONFIG_SYS_I2C_IHS_CH3 activate hardware channel 3 + - CONFIG_SYS_I2C_IHS_SPEED_3 speed channel 3 + - CONFIG_SYS_I2C_IHS_SLAVE_3 slave addr channel 3 + additional defines: CONFIG_SYS_NUM_I2C_BUSES @@ -2562,6 +2621,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. @@ -2891,6 +2954,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 @@ -3234,6 +3308,11 @@ FIT uImage format: disabled. If a board need legacy image format support enable this through CONFIG_IMAGE_FORMAT_LEGACY + CONFIG_FIT_DISABLE_SHA256 + Supporting SHA256 hashes has quite an impact on binary size. + For constrained systems sha256 hash support can be disabled + with this option. + - Standalone program support: CONFIG_STANDALONE_LOAD_ADDR @@ -3275,6 +3354,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 @@ -3288,6 +3370,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 @@ -3696,6 +3836,25 @@ Configuration Settings: - 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 sandbox + at present but is fairly easy to enable for other archs. + + Pre-relocation malloc() is only supported on ARM 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, @@ -4049,6 +4208,43 @@ to save the current settings. environment area within the total memory of your DataFlash placed at the specified address. +- CONFIG_ENV_IS_IN_SPI_FLASH: + + Define this if you have a SPI Flash memory device which you + want to use for the environment. + + - CONFIG_ENV_OFFSET: + - CONFIG_ENV_SIZE: + + These two #defines specify the offset and size of the + environment area within the SPI Flash. CONFIG_ENV_OFFSET must be + aligned to an erase sector boundary. + + - CONFIG_ENV_SECT_SIZE: + + Define the SPI flash's sector size. + + - CONFIG_ENV_OFFSET_REDUND (optional): + + This setting describes a second storage area of CONFIG_ENV_SIZE + size used to hold a redundant copy of the environment data, so + that there is a valid backup copy in case there is a power failure + during a "saveenv" operation. CONFIG_ENV_OFFSET_RENDUND must be + aligned to an erase sector boundary. + + - CONFIG_ENV_SPI_BUS (optional): + - CONFIG_ENV_SPI_CS (optional): + + Define the SPI bus and chip select. If not defined they will be 0. + + - CONFIG_ENV_SPI_MAX_HZ (optional): + + Define the SPI max work clock. If not defined then use 1MHz. + + - CONFIG_ENV_SPI_MODE (optional): + + Define the SPI work mode. If not defined then use SPI_MODE_3. + - CONFIG_ENV_IS_IN_REMOTE: Define this if you have a remote memory space which you @@ -4136,6 +4332,37 @@ but it can not erase, write this NOR flash by SRIO or PCIE interface. You will probably want to define these to avoid a really noisy system when storing the env in UBI. +- CONFIG_ENV_IS_IN_FAT: + Define this if you want to use the FAT file system for the environment. + + - FAT_ENV_INTERFACE: + + Define this to a string that is the name of the block device. + + - FAT_ENV_DEV_AND_PART: + + Define this to a string to specify the partition of the device. It can + be as following: + + "D:P", "D:0", "D", "D:" or "D:auto" (D, P are integers. And P >= 1) + - "D:P": device D partition P. Error occurs if device D has no + partition table. + - "D:0": device D. + - "D" or "D:": device D partition 1 if device D has partition + table, or the whole device D if has no partition + table. + - "D:auto": first partition in device D with bootable flag set. + If none, first valid paratition in device D. If no + partition table then means device D. + + - FAT_ENV_FILE: + + It's a string of the FAT file name. This file use to store the + envrionment. + + - CONFIG_FAT_WRITE: + This should be defined. Otherwise it cannot save the envrionment file. + - CONFIG_ENV_IS_IN_MMC: Define this if you have an MMC device which you want to use for the @@ -4239,6 +4466,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: --------------------------------------------------- @@ -4656,6 +4888,33 @@ within that device. window->master inbound window->master LAW->the ucode address in master's memory space. +Freescale Layerscape Management Complex Firmware Support: +--------------------------------------------------------- +The Freescale Layerscape Management Complex (MC) supports the loading of +"firmware". +This firmware often needs to be loaded during U-Boot booting, so macros +are used to identify the storage device (NOR flash, SPI, etc) and the address +within that device. + +- CONFIG_FSL_MC_ENET + Enable the MC driver for Layerscape SoCs. + +- CONFIG_SYS_LS_MC_FW_ADDR + The address in the storage device where the firmware is located. The + meaning of this address depends on which CONFIG_SYS_LS_MC_FW_IN_xxx macro + is also specified. + +- CONFIG_SYS_LS_MC_FW_LENGTH + The maximum possible size of the firmware. The firmware binary format + has a field that specifies the actual size of the firmware, but it + might not be possible to read any part of the firmware unless some + local storage is allocated to hold the entire firmware first. + +- CONFIG_SYS_LS_MC_FW_IN_NOR + Specifies that MC firmware is located in NOR flash, mapped as + normal addressable memory via the LBC. CONFIG_SYS_LS_MC_FW_ADDR is the + virtual address in NOR flash. + Building the Software: ====================== @@ -4689,9 +4948,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 @@ -4700,10 +4959,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. @@ -4723,14 +4982,14 @@ 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: export BUILD_DIR=/tmp/build make distclean - make NAME_config + make NAME_defconfig make all Note that the command line "O=" setting overrides the BUILD_DIR environment @@ -4756,7 +5015,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. @@ -5311,6 +5570,11 @@ Information structure as we define in include/asm-/u-boot.h, and make sure that your definition of IMAP_ADDR uses the same value as your U-Boot configuration in CONFIG_SYS_IMMR. +Note that U-Boot now has a driver model, a unified model for drivers. +If you are adding a new driver, plumb it into driver model. If there +is no uclass available, you are encouraged to create one. See +doc/driver-model. + Configuring the Linux kernel: ----------------------------- @@ -5331,7 +5595,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