diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.fdt-control | 16 | ||||
| -rw-r--r-- | doc/README.pxe | 7 | ||||
| -rw-r--r-- | doc/README.x86 | 36 | ||||
| -rw-r--r-- | doc/device-tree-bindings/net/ti,dp83867.txt | 8 | ||||
| -rw-r--r-- | doc/driver-model/README.txt | 7 | ||||
| -rw-r--r-- | doc/driver-model/pci-info.txt | 14 |
6 files changed, 61 insertions, 27 deletions
diff --git a/doc/README.fdt-control b/doc/README.fdt-control index 634a10616f..d6ab7bf570 100644 --- a/doc/README.fdt-control +++ b/doc/README.fdt-control @@ -56,7 +56,11 @@ In case you are wondering, OF stands for Open Firmware. Tools ----- -To use this feature you will need to get the device tree compiler here: +To use this feature you will need to get the device tree compiler. This is +provided by U-Boot automatically. If you have a system version of dtc +(typically in the 'device-tree-compiler' package), it is currently not used. + +If you want to build your own dtc, it is kept here: git://git.kernel.org/pub/scm/utils/dtc/dtc.git @@ -170,6 +174,16 @@ After board configuration is done, fdt supported u-boot can be build in two ways $ make DEVICE_TREE=<dts-file-name> +Relocation, SPL and TPL +----------------------- + +U-Boot can be divided into three phases: TPL, SPL and U-Boot proper. + +The full device tree is available to U-Boot proper, but normally only a subset +(or none at all) is available to TPL and SPL. See 'Pre-Relocation Support' and +'SPL Support' in doc/driver-model/README.txt for more details. + + Limitations ----------- diff --git a/doc/README.pxe b/doc/README.pxe index 98862cdfde..42f913c61f 100644 --- a/doc/README.pxe +++ b/doc/README.pxe @@ -140,6 +140,13 @@ kernel <path> - if this label is chosen, use tftp to retrieve the kernel (or FIT image) at <path>. it will be stored at the address indicated in the kernel_addr_r environment variable, and that address will be passed to bootm to boot this kernel. + For FIT image, The configuration specification can be + appended to the file name, with the format: + <path>#<conf>[#<extra-conf[#...]] + It will passed to bootm with that address. + (see: doc/uImage.FIT/command_syntax_extensions.txt) + It useful for overlay selection in pxe file + (see: doc/uImage.FIT/overlay-fdt-boot.txt) append <string> - use <string> as the kernel command line when booting this label. diff --git a/doc/README.x86 b/doc/README.x86 index 8cc46725f2..fa49cb8b8a 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -32,7 +32,7 @@ are supported: - Link (Chromebook Pixel) - Minnowboard MAX - Samus (Chromebook Pixel 2015) - - QEMU x86 + - QEMU x86 (32-bit & 64-bit) As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit Linux kernel as part of a FIT image. It also supports a compressed zImage. @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode: To build u-boot.rom for QEMU x86 targets, just simply run -$ make qemu-x86_defconfig +$ make qemu-x86_defconfig (for 32-bit) +or +$ make qemu-x86_64_defconfig (for 64-bit) $ make all Note this default configuration will build a U-Boot for the QEMU x86 i440FX @@ -479,6 +481,19 @@ Here the kernel (bzImage) is loaded to 01000000 and initrd is to 04000000. Then, => zboot 01000000 - 04000000 1b1ab50 +To run 64-bit U-Boot, qemu-system-x86_64 should be used instead, e.g.: +$ qemu-system-x86_64 -nographic -bios path/to/u-boot.rom + +A specific CPU can be specified via the '-cpu' parameter but please make +sure the specified CPU supports 64-bit like '-cpu core2duo'. Conversely +'-cpu pentium' won't work for obvious reasons that the processor only +supports 32-bit. + +Note 64-bit support is very preliminary at this point. Lots of features +are missing in the 64-bit world. One notable feature is the VGA console +support which is currently missing, so that you must specify '-nographic' +to get 64-bit U-Boot up and running. + Updating U-Boot on Edison ------------------------- By default Intel Edison boards are shipped with preinstalled heavily @@ -1145,27 +1160,10 @@ to load a 'u-boot-payload.efi', see below test logs on QEMU. See README.u-boot_on_efi and README.uefi for details of EFI support in U-Boot. -64-bit Support --------------- -U-Boot supports booting a 64-bit kernel directly and is able to change to -64-bit mode to do so. However, U-Boot itself is currently always built -in 32-bit mode. Some access to the full memory range is provided with -arch_phys_memset(). - -The development work to make U-Boot itself run in 64-bit mode has not yet -been attempted. The best approach would likely be to build a 32-bit SPL -image for U-Boot, with CONFIG_SPL_BUILD. This could then handle the early CPU -init in 16-bit and 32-bit mode, running the FSP and any other binaries that -are needed. Then it could change to 64-bit model and jump to U-Boot proper. - -Given U-Boot's extensive 64-bit support this has not been a high priority, -but it would be a nice addition. - TODO List --------- - Audio - Chrome OS verified boot -- Building U-Boot to run in 64-bit mode References ---------- diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt b/doc/device-tree-bindings/net/ti,dp83867.txt index cb77fdf082..034146f5f8 100644 --- a/doc/device-tree-bindings/net/ti,dp83867.txt +++ b/doc/device-tree-bindings/net/ti,dp83867.txt @@ -8,6 +8,12 @@ Required properties: for applicable values - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h for applicable values + - enet-phy-lane-swap - Indicates that PHY will swap the TX/RX lanes to + compensate for the board being designed with the lanes swapped. + - enet-phy-no-lane-swap - Indicates that PHY will disable swap of the + TX/RX lanes. + - ti,clk-output-sel - Clock output select - 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 @@ -19,6 +25,8 @@ Example: 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>; + enet-phy-lane-no-swap; + ti,clk-output-sel = <DP83867_CLK_O_SEL_CHN_A_TCLK>; }; Datasheet can be found: diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt index e949ff63ba..36541630a2 100644 --- a/doc/driver-model/README.txt +++ b/doc/driver-model/README.txt @@ -832,11 +832,14 @@ Pre-Relocation Support For pre-relocation we simply call the driver model init function. Only drivers marked with DM_FLAG_PRE_RELOC or the device tree 'u-boot,dm-pre-reloc' flag are initialised prior to relocation. This helps -to reduce the driver model overhead. +to reduce the driver model overhead. This flag applies to SPL and TPL as +well, if device tree is enabled there. It is possible to limit this to specific relocation steps, by using the more specialized 'u-boot,dm-spl' and 'u-boot,dm-tpl' flags -in the devicetree. +in the device tree node. For U-Boot proper you can use 'u-boot,dm-pre-proper' +which means that it will be processed (and a driver bound) in U-Boot proper +prior to relocation, but will not be available in SPL or TPL. Then post relocation we throw that away and re-init driver model again. For drivers which require some sort of continuity between pre- and diff --git a/doc/driver-model/pci-info.txt b/doc/driver-model/pci-info.txt index e1701d1fbc..14364c5c75 100644 --- a/doc/driver-model/pci-info.txt +++ b/doc/driver-model/pci-info.txt @@ -34,11 +34,15 @@ under that bus. Note that this is all done on a lazy basis, as needed, so until something is touched on PCI (eg: a call to pci_find_devices()) it will not be probed. -PCI devices can appear in the flattened device tree. If they do this serves to -specify the driver to use for the device. In this case they will be bound at -first. Each PCI device node must have a compatible string list as well as a -<reg> property, as defined by the IEEE Std 1275-1994 PCI bus binding document -v2.1. Note we must describe PCI devices with the same bus hierarchy as the +PCI devices can appear in the flattened device tree. If they do, their node +often contains extra information which cannot be derived from the PCI IDs or +PCI class of the device. Each PCI device node must have a <reg> property, as +defined by the IEEE Std 1275-1994 PCI bus binding document v2.1. Compatible +string list is optional and generally not needed, since PCI is discoverable +bus, albeit there are justified exceptions. If the compatible string is +present, matching on it takes precedence over PCI IDs and PCI classes. + +Note we must describe PCI devices with the same bus hierarchy as the hardware, otherwise driver model cannot detect the correct parent/children relationship during PCI bus enumeration thus PCI devices won't be bound to their drivers accordingly. A working example like below: |