X-Git-Url: https://git.kernelconcepts.de/?p=karo-tx-uboot.git;a=blobdiff_plain;f=README;h=de436ce786f020ece8904a74f0b2383b36f0e136;hp=352c9d22b509f74ff8c5c51afb763b10397c1792;hb=refs%2Fheads%2Ftx6qp-devel;hpb=433387bafd75e56424736fb45f210991910a1d63 diff --git a/README b/README index 352c9d22b5..de436ce786 100644 --- a/README +++ b/README @@ -701,7 +701,11 @@ The following options need to be configured: NOTE: The following can be machine specific errata. These do have ability to provide rudimentary version and machine specific checks, but expect no product checks. + CONFIG_ARM_ERRATA_430973 + CONFIG_ARM_ERRATA_454179 + CONFIG_ARM_ERRATA_621766 CONFIG_ARM_ERRATA_798870 + CONFIG_ARM_ERRATA_801819 - Tegra SoC options: CONFIG_TEGRA_SUPPORT_NON_SECURE @@ -710,119 +714,6 @@ The following options need to be configured: impossible actions will be skipped if the CPU is in NS mode, such as ARM architectural timer initialization. -- 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. - - Linux Kernel Interface: CONFIG_CLOCKS_IN_MHZ @@ -1491,9 +1382,6 @@ The following options need to be configured: Management command for E1000 devices. When used on devices with SPI support you can reprogram the EEPROM from U-Boot. - CONFIG_E1000_FALLBACK_MAC - default MAC for empty EEPROM after production. - CONFIG_EEPRO100 Support for Intel 82557/82559/82559ER chips. Optional CONFIG_EEPRO100_SROM_WRITE enables EEPROM @@ -1606,12 +1494,6 @@ The following options need to be configured: Support for i2c bus TPM devices. Only one device per system is supported at this time. - CONFIG_TPM_TIS_I2C_BUS_NUMBER - Define the the i2c bus number for the TPM device - - CONFIG_TPM_TIS_I2C_SLAVE_ADDRESS - Define the TPM's address on the i2c bus - CONFIG_TPM_TIS_I2C_BURST_LIMITATION Define the burst count bytes upper limit @@ -1781,7 +1663,7 @@ The following options need to be configured: key for the Replay Protection Memory Block partition in eMMC. - USB Device Firmware Update (DFU) class support: - CONFIG_DFU_FUNCTION + CONFIG_USB_FUNCTION_DFU This enables the USB portion of the DFU USB class CONFIG_CMD_DFU @@ -1826,6 +1708,9 @@ The following options need to be configured: sending again an USB request to the device. - USB Device Android Fastboot support: + CONFIG_USB_FUNCTION_FASTBOOT + This enables the USB part of the fastboot gadget + CONFIG_CMD_FASTBOOT This enables the command "fastboot" which enables the Android fastboot mode for the platform's USB device. Fastboot is a USB @@ -1837,12 +1722,12 @@ The following options need to be configured: This enables support for booting images which use the Android image format header. - CONFIG_USB_FASTBOOT_BUF_ADDR + CONFIG_FASTBOOT_BUF_ADDR The fastboot protocol requires a large memory buffer for downloads. Define this to the starting RAM address to use for downloaded images. - CONFIG_USB_FASTBOOT_BUF_SIZE + CONFIG_FASTBOOT_BUF_SIZE The fastboot protocol requires a large memory buffer for downloads. This buffer should be as large as possible for a platform. Define this to the size available RAM for fastboot. @@ -3206,11 +3091,6 @@ CBFS (Coreboot Filesystem) support memories can be connected with a given cs line. Currently Xilinx Zynq qspi supports these type of connections. - CONFIG_SPI_FLASH_DATAFLASH SPI based Dataflash - - Define this option to access AT45xxx Dataflash chips support - using spi flash interface. - - SystemACE Support: CONFIG_SYSTEMACE @@ -5189,6 +5069,33 @@ within that device. normal addressable memory via the LBC. CONFIG_SYS_LS_MC_FW_ADDR is the virtual address in NOR flash. +Freescale Layerscape Debug Server Support: +------------------------------------------- +The Freescale Layerscape Debug Server Support supports the loading of +"Debug Server firmware" and triggering SP boot-rom. +This firmware often needs to be loaded during U-Boot booting. + +- CONFIG_FSL_DEBUG_SERVER + Enable the Debug Server for Layerscape SoCs. + +- CONFIG_SYS_DEBUG_SERVER_DRAM_BLOCK_MIN_SIZE + Define minimum DDR size required for debug server image + +- CONFIG_SYS_MEM_TOP_HIDE_MIN + Define minimum DDR size to be hided from top of the DDR memory + +Reproducible builds +------------------- + +In order to achieve reproducible builds, timestamps used in the U-Boot build +process have to be set to a fixed value. + +This is done using the SOURCE_DATE_EPOCH environment variable. +SOURCE_DATE_EPOCH is to be set on the build host's shell, not as a configuration +option for U-Boot or an environment variable in U-Boot. + +SOURCE_DATE_EPOCH should be set to a number of seconds since the epoch, in UTC. + Building the Software: ======================