diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.fdt-control | 6 | ||||
| -rw-r--r-- | doc/README.generic-board | 69 | ||||
| -rw-r--r-- | doc/README.nand | 15 | ||||
| -rw-r--r-- | doc/README.ti-secure | 91 | ||||
| -rw-r--r-- | doc/README.x86 | 124 | ||||
| -rw-r--r-- | doc/SPL/README.am335x-network | 4 | ||||
| -rw-r--r-- | doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt | 161 | ||||
| -rw-r--r-- | doc/device-tree-bindings/mailbox/mailbox.txt | 32 | ||||
| -rw-r--r-- | doc/device-tree-bindings/misc/intel,irq-router.txt | 5 | ||||
| -rw-r--r-- | doc/device-tree-bindings/net/ti,dp83867.txt | 25 | ||||
| -rw-r--r-- | doc/driver-model/README.txt | 23 | ||||
| -rw-r--r-- | doc/uImage.FIT/multi-with-fpga.its | 67 | ||||
| -rw-r--r-- | doc/uImage.FIT/source_file_format.txt | 3 |
13 files changed, 514 insertions, 111 deletions
diff --git a/doc/README.fdt-control b/doc/README.fdt-control index 29fd56a815..2913fcb360 100644 --- a/doc/README.fdt-control +++ b/doc/README.fdt-control @@ -33,12 +33,6 @@ the features of each board in the device tree file, and have a single generic source base. To enable this feature, add CONFIG_OF_CONTROL to your board config file. -It is currently supported on ARM, x86 and Microblaze - other architectures -will need to add code to their arch/xxx/lib/board.c file to locate the -FDT. Alternatively you can enable generic board support on your board -(with CONFIG_SYS_GENERIC_BOARD) if this is available (as it is for -PowerPC). For ARM, Tegra and Exynos5 have device trees available for -common devices. What is a Flat Device Tree? diff --git a/doc/README.generic-board b/doc/README.generic-board index 734f1aa924..6858c4daaf 100644 --- a/doc/README.generic-board +++ b/doc/README.generic-board @@ -5,29 +5,22 @@ # SPDX-License-Identifier: GPL-2.0+ # -DEPRECATION NOTICE FOR arch/<arch>/lib/board.c - -For board maintainers: Please submit patches for boards you maintain before -July 2014, to make them use generic board. - -For architecture maintainers: Please submit patches to remove your -architecture-specific board.c file before October 2014. - - Background ---------- -U-Boot has traditionally had a board.c file for each architecture. This has -introduced quite a lot of duplication, with each architecture tending to do +U-Boot traditionally had a board.c file for each architecture. This introduced +quite a lot of duplication, with each architecture tending to do initialisation slightly differently. To address this, a new 'generic board -init' feature was introduced a year ago in March 2013 (further motivation is +init' feature was introduced in March 2013 (further motivation is provided in the cover letter below). +All boards and architectures have moved to this as of mid 2016. + What has changed? ----------------- -The main change is that the arch/<arch>/lib/board.c file is being removed in +The main change is that the arch/<arch>/lib/board.c file is removed in favour of common/board_f.c (for pre-relocation init) and common/board_r.c (for post-relocation init). @@ -36,55 +29,6 @@ fields which are common to all architectures. Architecture-specific fields have been moved to separate structures. -Supported Architectures ------------------------- - -If you are unlucky then your architecture may not support generic board. -The following architectures are supported now: - - arc - arm - avr32 - blackfin - m68k - microblaze - mips - nios2 - powerpc - sandbox - x86 - -If your architecture is not supported, you need to select -HAVE_GENERIC_BOARD in arch/Kconfig -and test it with a suitable board, as follows. - - -Adding Support for your Board ------------------------------ - -To enable generic board for your board, define CONFIG_SYS_GENERIC_BOARD in -your board config header file. - -Test that U-Boot still functions correctly on your board, and fix any -problems you find. Don't be surprised if there are no problems - generic -board has had a reasonable amount of testing with common boards. - - -DeadLine --------- - -Please don't take this the wrong way - there is no intent to make your life -miserable, and we have the greatest respect and admiration for U-Boot users. -However, with any migration there has to be a period where the old way is -deprecated and removed. Every patch to the deprecated code introduces a -potential breakage in the new unused code. Therefore: - -Boards or architectures not converted over to general board by the -end of 2014 may be forcibly changed over (potentially causing run-time -breakage) or removed. - - - Further Background ------------------ @@ -190,3 +134,4 @@ convenience. Simon Glass, sjg@chromium.org March 2014 +Updated after final removal, May 2016 diff --git a/doc/README.nand b/doc/README.nand index 545d88ca68..96ffc48940 100644 --- a/doc/README.nand +++ b/doc/README.nand @@ -136,15 +136,8 @@ Configuration Options: Example of new init to be added to the end of an existing driver init: - /* - * devnum is the device number to be used in nand commands - * and in mtd->name. Must be less than - * CONFIG_SYS_NAND_MAX_DEVICE. - */ - mtd = &nand_info[devnum]; - /* chip is struct nand_chip, and is now provided by the driver. */ - mtd->priv = &chip; + mtd = &chip.mtd; /* * Fill in appropriate values if this driver uses these fields, @@ -165,7 +158,11 @@ Configuration Options: if (nand_scan_tail(mtd)) error out - if (nand_register(devnum)) + /* + * devnum is the device number to be used in nand commands + * and in mtd->name. Must be less than CONFIG_SYS_NAND_MAX_DEVICE. + */ + if (nand_register(devnum, mtd)) error out In addition to providing more flexibility to the driver, it reduces diff --git a/doc/README.ti-secure b/doc/README.ti-secure new file mode 100644 index 0000000000..7fc9b9bc30 --- /dev/null +++ b/doc/README.ti-secure @@ -0,0 +1,91 @@ +README on how boot images are created for secure TI devices + +CONFIG_TI_SECURE_DEVICE: +Secure TI devices require a boot image that is authenticated by ROM +code to function. Without this, even JTAG remains locked and the +device is essentially useless. In order to create a valid boot image for +a secure device from TI, the initial public software image must be signed +and combined with various headers, certificates, and other binary images. + +Information on the details on the complete boot image format can be obtained +from Texas Instruments. The tools used to generate boot images for secure +devices are part of a secure development package (SECDEV) that can be +downloaded from: + + http://www.ti.com/mysecuresoftware (login required) + +The secure development package is access controlled due to NDA and export +control restrictions. Access must be requested and granted by TI before the +package is viewable and downloadable. Contact TI, either online or by way +of a local TI representative, to request access. + +When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process requires +the presence and use of these tools in order to create a viable boot image. +The build process will look for the environment variable TI_SECURE_DEV_PKG, +which should be the path of the installed SECDEV package. If the +TI_SECURE_DEV_PKG variable is not defined or if it is defined but doesn't +point to a valid SECDEV package, a warning is issued during the build to +indicate that a final secure bootable image was not created. + +Within the SECDEV package exists an image creation script: + +${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh + +This is called as part of the SPL/u-boot build process. As the secure boot +image formats and requirements differ between secure SOC from TI, the +purpose of this script is to abstract these details as much as possible. + +The script is basically the only required interface to the TI SECDEV package +for secure TI devices. + +Invoking the script for AM43xx Secure Devices +============================================= + +create-boot-image.sh <IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR> + +<IMAGE_FLAG> is a value that specifies the type of the image to generate OR +the action the image generation tool will take. Valid values are: + SPI_X-LOADER - Generates an image for SPI flash (byte swapped) + XIP_X-LOADER - Generates a single stage u-boot for NOR/QSPI XiP + ISSW - Generates an image for all other boot modes + +<INPUT_FILE> is the full path and filename of the public world boot loader +binary file (depending on the boot media, this is usually either +u-boot-spl.bin or u-boot.bin). + +<OUTPUT_FILE> is the full path and filename of the final secure image. The +output binary images should be used in place of the standard non-secure +binary images (see the platform-specific user's guides and releases notes +for how the non-secure images are typically used) + u-boot-spl_HS_SPI_X-LOADER - byte swapped boot image for SPI flash + u-boot_HS_XIP_X-LOADER - boot image for NOR or QSPI flash + u-boot-spl_HS_ISSW - boot image for all other boot media + +<SPL_LOAD_ADDR> is the address at which SOC ROM should load the <INPUT_FILE> + +Invoking the script for DRA7xx/AM57xx Secure Devices +==================================================== + +create-boot-image.sh <IMAGE_TYPE> <INPUT_FILE> <OUTPUT_FILE> + +<IMAGE_TYPE> is a value that specifies the type of the image to generate OR +the action the image generation tool will take. Valid values are: + X-LOADER - Generates an image for NOR or QSPI boot modes + MLO - Generates an image for SD/MMC/eMMC boot modes + ULO - Generates an image for USB/UART peripheral boot modes + Note: ULO is not yet used by the u-boot build process + +<INPUT_FILE> is the full path and filename of the public world boot loader +binary file (for this platform, this is always u-boot-spl.bin). + +<OUTPUT_FILE> is the full path and filename of the final secure image. The +output binary images should be used in place of the standard non-secure +binary images (see the platform-specific user's guides and releases notes +for how the non-secure images are typically used) + u-boot-spl_HS_MLO - boot image for SD/MMC/eMMC. This image is + copied to a file named MLO, which is the name that + the device ROM bootloader requires for loading from + the FAT partition of an SD card (same as on + non-secure devices) + u-boot-spl_HS_X-LOADER - boot image for all other flash memories + including QSPI and NOR flash diff --git a/doc/README.x86 b/doc/README.x86 index c5c3010ee2..a548b54b5b 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -23,7 +23,8 @@ In this case, known as bare mode, from the fact that it runs on the 'bare metal', U-Boot acts like a BIOS replacement. The following platforms are supported: - - Bayley Bay + - Bayley Bay CRB + - Congatec QEVAL 2.0 & conga-QA3/E3845 - Cougar Canyon 2 CRB - Crown Bay CRB - Galileo @@ -303,12 +304,12 @@ Offset Description Controlling config 000000 descriptor.bin Hard-coded to 0 in ifdtool 001000 me.bin Set by the descriptor 500000 <spare> +6ef000 Environment CONFIG_ENV_OFFSET 6f0000 MRC cache CONFIG_ENABLE_MRC_CACHE 700000 u-boot-dtb.bin CONFIG_SYS_TEXT_BASE 790000 vga.bin CONFIG_VGA_BIOS_ADDR 7c0000 fsp.bin CONFIG_FSP_ADDR 7f8000 <spare> (depends on size of fsp.bin) -7fe000 Environment CONFIG_ENV_OFFSET 7ff800 U-Boot 16-bit boot CONFIG_SYS_X86_START16 Overall ROM image size is controlled by CONFIG_ROM_SIZE. @@ -412,18 +413,19 @@ If you want to check both consoles, use '-serial stdio'. Multicore is also supported by QEMU via '-smp n' where n is the number of cores to instantiate. Note, the maximum supported CPU number in QEMU is 255. -The fw_cfg interface in QEMU also provides information about kernel data, initrd, -command-line arguments and more. U-Boot supports directly accessing these informtion -from fw_cfg interface, this saves the time of loading them from hard disk or -network again, through emulated devices. To use it , simply providing them in -QEMU command line: +The fw_cfg interface in QEMU also provides information about kernel data, +initrd, command-line arguments and more. U-Boot supports directly accessing +these informtion from fw_cfg interface, which saves the time of loading them +from hard disk or network again, through emulated devices. To use it , simply +providing them in QEMU command line: $ qemu-system-i386 -nographic -bios path/to/u-boot.rom -m 1024 -kernel /path/to/bzImage -append 'root=/dev/ram console=ttyS0' -initrd /path/to/initrd -smp 8 Note: -initrd and -smp are both optional -Then start QEMU, in U-Boot command line use the following U-Boot command to setup kernel: +Then start QEMU, in U-Boot command line use the following U-Boot command to +setup kernel: => qfw qfw - QEMU firmware interface @@ -437,8 +439,8 @@ qfw <command> => qfw load loading kernel to address 01000000 size 5d9d30 initrd 04000000 size 1b1ab50 -Here the kernel (bzImage) is loaded to 01000000 and initrd is to 04000000. Then, 'zboot' -can be used to boot the kernel: +Here the kernel (bzImage) is loaded to 01000000 and initrd is to 04000000. Then, +'zboot' can be used to boot the kernel: => zboot 02000000 - 04000000 1b1ab50 @@ -490,8 +492,8 @@ Booting Ubuntu -------------- As an example of how to set up your boot flow with U-Boot, here are instructions for starting Ubuntu from U-Boot. These instructions have been -tested on Minnowboard MAX with a SATA driver but are equally applicable on -other platforms and other media. There are really only four steps and its a +tested on Minnowboard MAX with a SATA drive but are equally applicable on +other platforms and other media. There are really only four steps and it's a very simple script, but a more detailed explanation is provided here for completeness. @@ -499,7 +501,7 @@ Note: It is possible to set up U-Boot to boot automatically using syslinux. It could also use the grub.cfg file (/efi/ubuntu/grub.cfg) to obtain the GUID. If you figure these out, please post patches to this README. -Firstly, you will need Ubunutu installed on an available disk. It should be +Firstly, you will need Ubuntu installed on an available disk. It should be possible to make U-Boot start a USB start-up disk but for now let's assume that you used another boot loader to install Ubuntu. @@ -659,7 +661,7 @@ U-Boot: Loading bzImage at address 100000 (5805728 bytes) Magic signature found Initial RAM disk at linear address 0x04000000, size 19215259 bytes - Kernel command line: "console=ttyS0,115200 root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro" + Kernel command line: "root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro" Starting kernel ... @@ -679,13 +681,14 @@ above commands into a script since then it will be faster. 240,329 ahci 1,422,704 vesa display -Now the kernel actually starts: +Now the kernel actually starts: (if you want to examine kernel boot up message +on the serial console, append "console=ttyS0,115200" to the kernel command line) [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.13.0-58-generic (buildd@allspice) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #97-Ubuntu SMP Wed Jul 8 02:56:15 UTC 2015 (Ubuntu 3.13.0-58.97-generic 3.13.11-ckt22) - [ 0.000000] Command line: console=ttyS0,115200 root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro + [ 0.000000] Command line: root=/dev/disk/by-partuuid/965c59ee-1822-4326-90d2-b02446050059 ro console=ttyS0,115200 It continues for a long time. Along the way you will see it pick up your ramdisk: @@ -736,14 +739,6 @@ If you want to put this in a script you can use something like this: The \ is to tell the shell not to evaluate ${filesize} as part of the setenv command. -You will also need to add this to your board configuration file, e.g. -include/configs/minnowmax.h: - - #define CONFIG_BOOTDELAY 2 - -Now when you reset your board it wait a few seconds (in case you want to -interrupt) and then should boot straight into Ubuntu. - You can also bake this behaviour into your build by hard-coding the environment variables if you add this to minnowmax.h: @@ -812,6 +807,30 @@ to install/boot a Windows XP OS (below for example command to install Windows). This is also tested on Intel Crown Bay board with a PCIe graphics card, booting SeaBIOS then chain-loading a GRUB on a USB drive, then Linux kernel finally. +If you are using Intel Integrated Graphics Device (IGD) as the primary display +device on your board, SeaBIOS needs to be patched manually to get its VGA ROM +loaded and run by SeaBIOS. SeaBIOS locates VGA ROM via the PCI expansion ROM +register, but IGD device does not have its VGA ROM mapped by this register. +Its VGA ROM is packaged as part of u-boot.rom at a configurable flash address +which is unknown to SeaBIOS. An example patch is needed for SeaBIOS below: + +diff --git a/src/optionroms.c b/src/optionroms.c +index 65f7fe0..c7b6f5e 100644 +--- a/src/optionroms.c ++++ b/src/optionroms.c +@@ -324,6 +324,8 @@ init_pcirom(struct pci_device *pci, int isvga, u64 *sources) + rom = deploy_romfile(file); + else if (RunPCIroms > 1 || (RunPCIroms == 1 && isvga)) + rom = map_pcirom(pci); ++ if (pci->bdf == pci_to_bdf(0, 2, 0)) ++ rom = (struct rom_header *)0xfff90000; + if (! rom) + // No ROM present. + return; + +Note: the patch above expects IGD device is at PCI b.d.f 0.2.0 and its VGA ROM +is at 0xfff90000 which corresponds to CONFIG_VGA_BIOS_ADDR on Minnowboard MAX. +Change these two accordingly if this is not the case on your board. Development Flow ---------------- @@ -963,12 +982,65 @@ transformations. Remember to add attribution to coreboot for new files added to U-Boot. This should go at the top of each file and list the coreboot filename where the code originated. +Debugging ACPI issues with Windows: + +Windows might cache system information and only detect ACPI changes if you +modify the ACPI table versions. So tweak them liberally when debugging ACPI +issues with Windows. + +ACPI Support Status +------------------- +Advanced Configuration and Power Interface (ACPI) [16] aims to establish +industry-standard interfaces enabling OS-directed configuration, power +management, and thermal management of mobile, desktop, and server platforms. + +Linux can boot without ACPI with "acpi=off" command line parameter, but +with ACPI the kernel gains the capabilities to handle power management. +For Windows, ACPI is a must-have firmware feature since Windows Vista. +CONFIG_GENERATE_ACPI_TABLE is the config option to turn on ACPI support in +U-Boot. This requires Intel ACPI compiler to be installed on your host to +compile ACPI DSDT table written in ASL format to AML format. You can get +the compiler via "apt-get install iasl" if you are on Ubuntu or download +the source from [17] to compile one by yourself. + +Current ACPI support in U-Boot is not complete. More features will be added +in the future. The status as of today is: + + * Support generating RSDT, XSDT, FACS, FADT, MADT, MCFG tables. + * Support one static DSDT table only, compiled by Intel ACPI compiler. + * Support S0/S5, reboot and shutdown from OS. + * Support booting a pre-installed Ubuntu distribution via 'zboot' command. + * Support installing and booting Ubuntu 14.04 (or above) from U-Boot with + the help of SeaBIOS using legacy interface (non-UEFI mode). + * Support installing and booting Windows 8.1/10 from U-Boot with the help + of SeaBIOS using legacy interface (non-UEFI mode). + * Support ACPI interrupts with SCI only. + +Features not supported so far (to make it a complete ACPI solution): + * S3 (Suspend to RAM), S4 (Suspend to Disk). + +Features that are optional: + * ACPI global NVS support. We may need it to simplify ASL code logic if + utilizing NVS variables. Most likely we will need this sooner or later. + * Dynamic AML bytecodes insertion at run-time. We may need this to support + SSDT table generation and DSDT fix up. + * SMI support. Since U-Boot is a modern bootloader, we don't want to bring + those legacy stuff into U-Boot. ACPI spec allows a system that does not + support SMI (a legacy-free system). + +ACPI was initially enabled on BayTrail based boards. Testing was done by booting +a pre-installed Ubuntu 14.04 from a SATA drive. Installing Ubuntu 14.04 and +Windows 8.1/10 to a SATA drive and booting from there is also tested. Most +devices seem to work correctly and the board can respond a reboot/shutdown +command from the OS. + +For other platform boards, ACPI support status can be checked by examining their +board defconfig files to see if CONFIG_GENERATE_ACPI_TABLE is set to y. TODO List --------- - Audio - Chrome OS verified boot -- SMI and ACPI support, to provide platform info and facilities to Linux References ---------- @@ -987,3 +1059,5 @@ References [13] http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf [14] http://www.seabios.org/SeaBIOS [15] doc/device-tree-bindings/misc/intel,irq-router.txt +[16] http://www.acpi.info +[17] https://www.acpica.org/downloads diff --git a/doc/SPL/README.am335x-network b/doc/SPL/README.am335x-network index 9b63791ad1..e3cf93f8dc 100644 --- a/doc/SPL/README.am335x-network +++ b/doc/SPL/README.am335x-network @@ -66,6 +66,10 @@ subnet 192.168.8.0 netmask 255.255.255.0 { } } + May the ROM bootloader sends another "vendor-class-identifier" + on the shc board with an AM335X it is: + "AM335x ROM" + 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 diff --git a/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt b/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt new file mode 100644 index 0000000000..c82a2e221b --- /dev/null +++ b/doc/device-tree-bindings/gpio/nvidia,tegra186-gpio.txt @@ -0,0 +1,161 @@ +NVIDIA Tegra186 GPIO controllers + +Tegra186 contains two GPIO controllers; a main controller and an "AON" +controller. This binding document applies to both controllers. The register +layouts for the controllers share many similarities, but also some significant +differences. Hence, this document describes closely related but different +bindings and compatible values. + +The Tegra186 GPIO controller allows software to set the IO direction of, and +read/write the value of, numerous GPIO signals. Routing of GPIO signals to +package balls is under the control of a separate pin controller HW block. Two +major sets of registers exist: + +a) Security registers, which allow configuration of allowed access to the GPIO +register set. These registers exist in a single contiguous block of physical +address space. The size of this block, and the security features available, +varies between the different GPIO controllers. + +Access to this set of registers is not necessary in all circumstances. Code +that wishes to configure access to the GPIO registers needs access to these +registers to do so. Code which simply wishes to read or write GPIO data does not +need access to these registers. + +b) GPIO registers, which allow manipulation of the GPIO signals. In some GPIO +controllers, these registers are exposed via multiple "physical aliases" in +address space, each of which access the same underlying state. See the hardware +documentation for rationale. Any particular GPIO client is expected to access +just one of these physical aliases. + +Tegra HW documentation describes a unified naming convention for all GPIOs +implemented by the SoC. Each GPIO is assigned to a port, and a port may control +a number of GPIOs. Thus, each GPIO is named according to an alphabetical port +name and an integer GPIO name within the port. For example, GPIO_PA0, GPIO_PN6, +or GPIO_PCC3. + +The number of ports implemented by each GPIO controller varies. The number of +implemented GPIOs within each port varies. GPIO registers within a controller +are grouped and laid out according to the port they affect. + +The mapping from port name to the GPIO controller that implements that port, and +the mapping from port name to register offset within a controller, are both +extremely non-linear. The header file <dt-bindings/gpio/tegra186-gpio.h> +describes the port-level mapping. In that file, the naming convention for ports +matches the HW documentation. The values chosen for the names are alphabetically +sorted within a particular controller. Drivers need to map between the DT GPIO +IDs and HW register offsets using a lookup table. + +Each GPIO controller can generate a number of interrupt signals. Each signal +represents the aggregate status for all GPIOs within a set of ports. Thus, the +number of interrupt signals generated by a controller varies as a rough function +of the number of ports it implements. Note that the HW documentation refers to +both the overall controller HW module and the sets-of-ports as "controllers". + +Each GPIO controller in fact generates multiple interrupts signals for each set +of ports. Each GPIO may be configured to feed into a specific one of the +interrupt signals generated by a set-of-ports. The intent is for each generated +signal to be routed to a different CPU, thus allowing different CPUs to each +handle subsets of the interrupts within a port. The status of each of these +per-port-set signals is reported via a separate register. Thus, a driver needs +to know which status register to observe. This binding currently defines no +configuration mechanism for this. By default, drivers should use register +GPIO_${port}_INTERRUPT_STATUS_G1_0. Future revisions to the binding could +define a property to configure this. + +Required properties: +- compatible + Array of strings. + One of: + - "nvidia,tegra186-gpio". + - "nvidia,tegra186-gpio-aon". +- reg-names + Array of strings. + Contains a list of names for the register spaces described by the reg + property. May contain the following entries, in any order: + - "gpio": Mandatory. GPIO control registers. This may cover either: + a) The single physical alias that this OS should use. + b) All physical aliases that exist in the controller. This is + appropriate when the OS is responsible for managing assignment of + the physical aliases. + - "security": Optional. Security configuration registers. + Users of this binding MUST look up entries in the reg property by name, + using this reg-names property to do so. +- reg + Array of (physical base address, length) tuples. + Must contain one entry per entry in the reg-names property, in a matching + order. +- interrupts + Array of interrupt specifiers. + The interrupt outputs from the HW block, one per set of ports, in the + order the HW manual describes them. The number of entries required varies + depending on compatible value: + - "nvidia,tegra186-gpio": 6 entries. + - "nvidia,tegra186-gpio-aon": 1 entry. +- gpio-controller + Boolean. + Marks the device node as a GPIO controller/provider. +- #gpio-cells + Single-cell integer. + Must be <2>. + Indicates how many cells are used in a consumer's GPIO specifier. + In the specifier: + - The first cell is the pin number. + See <dt-bindings/gpio/tegra186-gpio.h>. + - The second cell contains flags: + - Bit 0 specifies polarity + - 0: Active-high (normal). + - 1: Active-low (inverted). +- interrupt-controller + Boolean. + Marks the device node as an interrupt controller/provider. +- #interrupt-cells + Single-cell integer. + Must be <2>. + Indicates how many cells are used in a consumer's interrupt specifier. + In the specifier: + - The first cell is the GPIO number. + See <dt-bindings/gpio/tegra186-gpio.h>. + - The second cell is contains flags: + - Bits [3:0] indicate trigger type and level: + - 1: Low-to-high edge triggered. + - 2: High-to-low edge triggered. + - 4: Active high level-sensitive. + - 8: Active low level-sensitive. + Valid combinations are 1, 2, 3, 4, 8. + +Example: + +#include <dt-bindings/interrupt-controller/irq.h> + +gpio@2200000 { + compatible = "nvidia,tegra186-gpio"; + reg-names = "security", "gpio"; + reg = + <0x0 0x2200000 0x0 0x10000>, + <0x0 0x2210000 0x0 0x10000>; + interrupts = + <0 47 IRQ_TYPE_LEVEL_HIGH>, + <0 50 IRQ_TYPE_LEVEL_HIGH>, + <0 53 IRQ_TYPE_LEVEL_HIGH>, + <0 56 IRQ_TYPE_LEVEL_HIGH>, + <0 59 IRQ_TYPE_LEVEL_HIGH>, + <0 180 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; +}; + +gpio@c2f0000 { + compatible = "nvidia,tegra186-gpio-aon"; + reg-names = "security", "gpio"; + reg = + <0x0 0xc2f0000 0x0 0x1000>, + <0x0 0xc2f1000 0x0 0x1000>; + interrupts = + <0 60 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; +}; diff --git a/doc/device-tree-bindings/mailbox/mailbox.txt b/doc/device-tree-bindings/mailbox/mailbox.txt new file mode 100644 index 0000000000..be05b9746c --- /dev/null +++ b/doc/device-tree-bindings/mailbox/mailbox.txt @@ -0,0 +1,32 @@ +* Generic Mailbox Controller and client driver bindings + +Generic binding to provide a way for Mailbox controller drivers to +assign appropriate mailbox channel to client drivers. + +* Mailbox Controller + +Required property: +- #mbox-cells: Must be at least 1. Number of cells in a mailbox + specifier. + +Example: + mailbox: mailbox { + ... + #mbox-cells = <1>; + }; + + +* Mailbox Client + +Required property: +- mboxes: List of phandle and mailbox channel specifiers. + +Optional property: +- mbox-names: List of identifier strings for each mailbox channel. + +Example: + pwr_cntrl: power { + ... + mbox-names = "pwr-ctrl", "rpc"; + mboxes = <&mailbox 0 &mailbox 1>; + }; diff --git a/doc/device-tree-bindings/misc/intel,irq-router.txt b/doc/device-tree-bindings/misc/intel,irq-router.txt index e4d8ead2ee..04ad34654c 100644 --- a/doc/device-tree-bindings/misc/intel,irq-router.txt +++ b/doc/device-tree-bindings/misc/intel,irq-router.txt @@ -14,6 +14,11 @@ Required properties : "ibase": IRQ routing is in the memory-mapped IBASE register block - intel,ibase-offset : IBASE register offset in the interrupt router's PCI configuration space, required only if intel,pirq-config = "ibase". +- intel,actl-8bit : If ACTL (ACPI control) register width is 8-bit, this must + be specified. The 8-bit ACTL register is seen on ICH series chipset, like + ICH9/Panther Point/etc. On Atom chipset it is a 32-bit register. +- intel,actl-addr : ACTL (ACPI control) register offset. ACTL can be either + in the interrupt router's PCI configuration space, or IBASE. - intel,pirq-link : Specifies the PIRQ link information with two cells. The first cell is the register offset that controls the first PIRQ link routing. The second cell is the total number of PIRQ links the router supports. diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt b/doc/device-tree-bindings/net/ti,dp83867.txt new file mode 100644 index 0000000000..cb77fdf082 --- /dev/null +++ b/doc/device-tree-bindings/net/ti,dp83867.txt @@ -0,0 +1,25 @@ +* Texas Instruments - dp83867 Giga bit ethernet phy + +Required properties: + - reg - The ID number for the phy, usually a small integer + - ti,rx-internal-delay - RGMII Recieve Clock Delay - see dt-bindings/net/ti-dp83867.h + for applicable values + - ti,tx-internal-delay - RGMII Transmit Clock Delay - see dt-bindings/net/ti-dp83867.h + for applicable values + - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h + for applicable values + +Default child nodes are standard Ethernet PHY device +nodes as described in doc/devicetree/bindings/net/ethernet.txt + +Example: + + ethernet-phy@0 { + reg = <0>; + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>; + ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>; + ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>; + }; + +Datasheet can be found: +http://www.ti.com/product/DP83867IR/datasheet diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt index 7a24552560..1b5ccec4b2 100644 --- a/doc/driver-model/README.txt +++ b/doc/driver-model/README.txt @@ -606,19 +606,24 @@ methods actually defined. 1. Bind stage -A device and its driver are bound using one of these two methods: +U-Boot discovers devices using one of these two methods: - - Scan the U_BOOT_DEVICE() definitions. U-Boot It looks up the -name specified by each, to find the appropriate driver. It then calls -device_bind() to create a new device and bind' it to its driver. This will -call the device's bind() method. + - Scan the U_BOOT_DEVICE() definitions. U-Boot looks up the name specified +by each, to find the appropriate U_BOOT_DRIVER() definition. In this case, +there is no path by which driver_data may be provided, but the U_BOOT_DEVICE() +may provide platdata. - Scan through the device tree definitions. U-Boot looks at top-level nodes in the the device tree. It looks at the compatible string in each node -and uses the of_match part of the U_BOOT_DRIVER() structure to find the -right driver for each node. It then calls device_bind() to bind the -newly-created device to its driver (thereby creating a device structure). -This will also call the device's bind() method. +and uses the of_match table of the U_BOOT_DRIVER() structure to find the +right driver for each node. In this case, the of_match table may provide a +driver_data value, but platdata cannot be provided until later. + +For each device that is discovered, U-Boot then calls device_bind() to create a +new device, initializes various core fields of the device object such as name, +uclass & driver, initializes any optional fields of the device object that are +applicable such as of_offset, driver_data & platdata, and finally calls the +driver's bind() method if one is defined. At this point all the devices are known, and bound to their drivers. There is a 'struct udevice' allocated for all devices. However, nothing has been diff --git a/doc/uImage.FIT/multi-with-fpga.its b/doc/uImage.FIT/multi-with-fpga.its new file mode 100644 index 0000000000..0cdb31fe91 --- /dev/null +++ b/doc/uImage.FIT/multi-with-fpga.its @@ -0,0 +1,67 @@ +/* + * U-Boot uImage source file with multiple kernels, ramdisks and FDT blobs + * This example makes use of the 'loadables' field + */ + +/dts-v1/; + +/ { + description = "Configuration to load fpga before Kernel"; + #address-cells = <1>; + + images { + fdt@1 { + description = "zc706"; + data = /incbin/("/tftpboot/devicetree.dtb"); + type = "flat_dt"; + arch = "arm"; + compression = "none"; + load = <0x10000000>; + hash@1 { + algo = "md5"; + }; + }; + + fpga@1 { + description = "FPGA"; + data = /incbin/("/tftpboot/download.bit"); + type = "fpga"; + arch = "arm"; + compression = "none"; + load = <0x30000000>; + hash@1 { + algo = "md5"; + }; + }; + + linux_kernel@1 { + description = "Linux"; + data = /incbin/("/tftpboot/zImage"); + type = "kernel"; + arch = "arm"; + os = "linux"; + compression = "none"; + load = <0x8000>; + entry = <0x8000>; + hash@1 { + algo = "md5"; + }; + }; + }; + + configurations { + default = "config@2"; + config@1 { + description = "Linux"; + kernel = "linux_kernel@1"; + fdt = "fdt@1"; + }; + + config@2 { + description = "Linux with fpga"; + kernel = "linux_kernel@1"; + fdt = "fdt@1"; + fpga = "fpga@1"; + }; + }; +}; diff --git a/doc/uImage.FIT/source_file_format.txt b/doc/uImage.FIT/source_file_format.txt index 9c527c3e01..3f5418045e 100644 --- a/doc/uImage.FIT/source_file_format.txt +++ b/doc/uImage.FIT/source_file_format.txt @@ -236,6 +236,7 @@ o config@1 |- kernel = "kernel sub-node unit name" |- ramdisk = "ramdisk sub-node unit name" |- fdt = "fdt sub-node unit-name" + |- fpga = "fpga sub-node unit-name" |- loadables = "loadables sub-node unit-name" @@ -251,6 +252,8 @@ o config@1 "fdt type"). - setup : Unit name of the corresponding setup binary (used for booting an x86 kernel). This contains the setup.bin file built by the kernel. + - fpga : Unit name of the corresponding fpga bitstream blob + (component image node of a "fpga type"). - loadables : Unit name containing a list of additional binaries to be loaded at their given locations. "loadables" is a comma-separated list of strings. U-Boot will load each binary at its given start-address. |
