diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.fdt-control | 16 | ||||
| -rw-r--r-- | doc/README.mpc85xx | 2 | ||||
| -rw-r--r-- | doc/README.rockchip | 31 | ||||
| -rw-r--r-- | doc/README.ti-secure | 20 | ||||
| -rw-r--r-- | doc/device-tree-bindings/chosen.txt | 22 | ||||
| -rw-r--r-- | doc/device-tree-bindings/config.txt | 22 | ||||
| -rw-r--r-- | doc/device-tree-bindings/net/fixed-link.txt | 30 | ||||
| -rw-r--r-- | doc/device-tree-bindings/pci/armada8k-pcie.txt | 49 | ||||
| -rw-r--r-- | doc/device-tree-bindings/timer/arc_timer.txt | 24 | ||||
| -rw-r--r-- | doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 28 | ||||
| -rw-r--r-- | doc/driver-model/fdt-fixup.txt | 132 |
11 files changed, 357 insertions, 19 deletions
diff --git a/doc/README.fdt-control b/doc/README.fdt-control index 2913fcb360..c965629905 100644 --- a/doc/README.fdt-control +++ b/doc/README.fdt-control @@ -168,22 +168,6 @@ After board configuration is done, fdt supported u-boot can be build in two ways $ make DEVICE_TREE=<dts-file-name> -Configuration Options ---------------------- - -A number of run-time configuration options are provided in the /config node -of the control device tree. You can access these using fdtdec_get_config_int(), -fdtdec_get_config_bool() and fdtdec_get_config_string(). - -Available options are: - -silent-console - If present and non-zero, the console is silenced by default on boot. - -no-keyboard - Tells U-Boot not to expect an attached keyboard with a VGA console - - Limitations ----------- diff --git a/doc/README.mpc85xx b/doc/README.mpc85xx index f9b023f284..93ed641df3 100644 --- a/doc/README.mpc85xx +++ b/doc/README.mpc85xx @@ -156,7 +156,7 @@ B) !defined(CONFIG_SYS_RAMBOOT) i.e. NOR boot Disable : 15, 14 11) Create DDR's TLB entriy - Location : Board_init_f -> init_func_ram -> initdram + Location : Board_init_f -> dram_init TLB entry : Search free TLB entry 12) Update Flash's TLB entry diff --git a/doc/README.rockchip b/doc/README.rockchip index 186a1a007e..2d8cf9fae0 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -36,15 +36,16 @@ You will need: Building ======== -At present seven RK3288 boards are supported: +At present eight RK3288 boards are supported: - EVB RK3288 - use evb-rk3288 configuration - Fennec RK3288 - use fennec-rk3288 configuration - Firefly RK3288 - use firefly-rk3288 configuration - Hisense Chromebook - use chromebook_jerry configuration - - Tinker RK3288 - use tinker-rk3288 configuration + - MiQi RK3288 - use miqi-rk3288 configuration - PopMetal RK3288 - use popmetal-rk3288 configuration - Radxa Rock 2 - use rock2 configuration + - Tinker RK3288 - use tinker-rk3288 configuration Two RK3036 board are supported: @@ -147,6 +148,32 @@ For evb_rk3036 board: Note: rk3036 SDMMC and debug uart use the same iomux, so if you boot from SD, the debug uart must be disabled + +Booting from an SD card on RK3188 +================================= + +For rk3188 boards the general storage onto the card stays the same as +described above, but the image creation needs a bit more care. + +The bootrom of rk3188 expects to find a small 1kb loader which returns +control to the bootrom, after which it will load the real loader, which +can then be up to 29kb in size and does the regular ddr init. + +Additionally the rk3188 requires everything the bootrom loads to be +rc4-encrypted. Except for the very first stage the bootrom always reads +and decodes 2kb pages, so files should be sized accordingly. + +# copy tpl, pad to 1020 bytes and append spl +cat tpl/u-boot-tpl.bin > tplspl.bin +truncate -s 1020 tplspl.bin +cat spl/u-boot-spl.bin >> tplspl.bin +tools/mkimage -n rk3188 -T rksd -d tplspl.bin out + +# truncate, encode and append u-boot.bin +truncate -s %2048 u-boot.bin +cat u-boot.bin | split -b 512 --filter='openssl rc4 -K 7C4E0304550509072D2C7B38170D1711' >> out + + Using fastboot on rk3288 ======================== - Write GPT partition layout to mmc device which fastboot want to use it to diff --git a/doc/README.ti-secure b/doc/README.ti-secure index 9b0fbf9732..4b5380c0f3 100644 --- a/doc/README.ti-secure +++ b/doc/README.ti-secure @@ -133,6 +133,26 @@ Booting of U-Boot SPL u-boot-spl_HS_X-LOADER - boot image for all other flash memories including QSPI and NOR flash + Invoking the script for Keystone2 Secure Devices + ============================================= + + create-boot-image.sh \ + <UNUSED> <INPUT_FILE> <OUTPUT_FILE> <UNUSED> + + <UNUSED> is currently ignored and reserved for future use. + + <INPUT_FILE> is the full path and filename of the public world boot + loader binary file (only u-boot.bin is currently supported on + Keystone2 devices, u-boot-spl.bin is not currently supported). + + <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_HS_MLO - signed and encrypted boot image that can be used to + boot from all media. Secure boot from SPI NOR flash is not + currently supported. + Booting of Primary U-Boot (u-boot.img) ====================================== diff --git a/doc/device-tree-bindings/chosen.txt b/doc/device-tree-bindings/chosen.txt index bf9a30a8f9..5625d210e8 100644 --- a/doc/device-tree-bindings/chosen.txt +++ b/doc/device-tree-bindings/chosen.txt @@ -41,3 +41,25 @@ Example reg = <0xf00 0x10>; }; }; + +u-boot,spl-boot-order property +------------------------------ + +In a system using an SPL stage and having multiple boot sources +(e.g. SPI NOR flash, on-board eMMC and a removable SD-card), the boot +device may be probed by reading the image and verifying an image +signature. + +If the SPL is configured through the device-tree, the boot-order can +be configured with the spl-boot-order property under the /chosen node. +Each list element of the property should specify a device to be probed +in the order they are listed: references (i.e. implicit paths), a full +path or an alias is expected for each entry. + +Example +------- +/ { + chosen { + u-boot,spl-boot-order = &sdmmc, "/sdhci@fe330000"; + }; +}; diff --git a/doc/device-tree-bindings/config.txt b/doc/device-tree-bindings/config.txt new file mode 100644 index 0000000000..5640bae72f --- /dev/null +++ b/doc/device-tree-bindings/config.txt @@ -0,0 +1,22 @@ +The /config node (Configuration Options) +---------------------------------------- + +A number of run-time configuration options are provided in the /config node +of the control device tree. You can access these using fdtdec_get_config_int(), +fdtdec_get_config_bool() and fdtdec_get_config_string(). + +Available options are: + +silent-console + If present and non-zero, the console is silenced by default on boot. + +no-keyboard + Tells U-Boot not to expect an attached keyboard with a VGA console + +u-boot,efi-partition-entries-offset + If present, this provides an offset (in bytes, from the start of a + device) that should be skipped over before the partition entries. + This is used by the EFI/GPT partition implementation when a device + is formatted. + + This setting will override any values configured via Kconfig. diff --git a/doc/device-tree-bindings/net/fixed-link.txt b/doc/device-tree-bindings/net/fixed-link.txt new file mode 100644 index 0000000000..5829bd81a2 --- /dev/null +++ b/doc/device-tree-bindings/net/fixed-link.txt @@ -0,0 +1,30 @@ +Fixed link Device Tree binding +------------------------------ + +Some Ethernet MACs have a "fixed link", and are not connected to a +normal MDIO-managed PHY device. For those situations, a Device Tree +binding allows to describe a "fixed link". + +Such a fixed link situation is described by creating a 'fixed-link' +sub-node of the Ethernet MAC device node, with the following +properties: + +* 'speed' (integer, mandatory), to indicate the link speed. Accepted + values are 10, 100 and 1000 +* 'full-duplex' (boolean, optional), to indicate that full duplex is + used. When absent, half duplex is assumed. +* 'pause' (boolean, optional), to indicate that pause should be + enabled. +* 'asym-pause' (boolean, optional), to indicate that asym_pause should + be enabled. + +Examples: + +ethernet@0 { + ... + fixed-link { + speed = <1000>; + full-duplex; + }; + ... +}; diff --git a/doc/device-tree-bindings/pci/armada8k-pcie.txt b/doc/device-tree-bindings/pci/armada8k-pcie.txt new file mode 100644 index 0000000000..7230f10443 --- /dev/null +++ b/doc/device-tree-bindings/pci/armada8k-pcie.txt @@ -0,0 +1,49 @@ +Armada-8K PCIe DT details: +========================== + +Armada-8k uses synopsis designware PCIe controller. + +Required properties: +- compatible : should be "marvell,armada8k-pcie", "snps,dw-pcie". +- reg: base addresses and lengths of the pcie control and global control registers. + "ctrl" registers points to the global control registers, while the "config" space + points to the pcie configuration registers as mentioned in dw-pcie dt bindings in the link below. +- interrupt-map-mask and interrupt-map, standard PCI properties to + define the mapping of the PCIe interface to interrupt numbers. +- All other definitions as per generic PCI bindings +See Linux kernel documentation: +"Documentation/devicetree/bindings/pci/designware-pcie.txt" + +Optional properties: +PHY support is still not supported for armada-8k, once it will, the following parameters can be used: +- phys : phandle to phy node associated with pcie controller. +- phy-names : must be "pcie-phy" +- marvell,reset-gpio : specifies a gpio that needs to be activated for plug-in + card reset signal release. +Example: + +cpm_pcie0: pcie@f2600000 { + compatible = "marvell,armada8k-pcie", "snps,dw-pcie"; + reg = <0 0xf2600000 0 0x10000>, + <0 0xf6f00000 0 0x80000>; + reg-names = "ctrl", "config"; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + device_type = "pci"; + dma-coherent; + + bus-range = <0 0xff>; + ranges = + /* downstream I/O */ + <0x81000000 0 0xf9000000 0 0xf9000000 0 0x10000 + /* non-prefetchable memory */ + 0x82000000 0 0xf6000000 0 0xf6000000 0 0xf00000>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic 0 GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; + num-lanes = <1>; + clocks = <&cpm_syscon0 1 13>; + marvell,reset-gpio = <&cpm_gpio1 20 GPIO_ACTIVE_HIGH>; + status = "disabled"; +}; diff --git a/doc/device-tree-bindings/timer/arc_timer.txt b/doc/device-tree-bindings/timer/arc_timer.txt new file mode 100644 index 0000000000..5493b21d27 --- /dev/null +++ b/doc/device-tree-bindings/timer/arc_timer.txt @@ -0,0 +1,24 @@ +ARC Timer + +Required properties: + +- compatible : should be "snps,arc-timer". +- reg : Specifies timer ID, could be either 0 or 1. +- clocks : Specifies clocks that drives the counter. + +Examples: + +timer@0 { + compatible = "snps,arc-timer"; + clocks = <&core_clk>; + reg = <0>; +}; + +timer@1 { + compatible = "snps,arc-timer"; + clocks = <&core_clk>; + reg = <1>; +}; + +NOTE: if you specify both timers, clocks always should be the same +as each timer is driven by the same core clock. diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt new file mode 100644 index 0000000000..e042d1b966 --- /dev/null +++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt @@ -0,0 +1,28 @@ +Marvell SOC USB controllers + +This controller is integrated in Armada 3700/8K. +It uses the same properties as a generic XHCI host controller + +Required properties : + - compatible: should be one or more of: + - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx SoCs + - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs + - reg: should contain address and length of the standard XHCI + register set for the device. + - interrupts: one XHCI interrupt should be described here. + +Optional properties: + - clocks: phandle to system controller clock driving this unit + - vbus-supply : If present, specifies the fixed regulator to be turned on + for providing power to the USB VBUS rail. + +Example: + cpm_usb3_0: usb3@500000 { + compatible = "marvell,armada-8k-xhci", + "generic-xhci"; + reg = <0x500000 0x4000>; + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpm_syscon0 1 22>; + vbus-supply = <®_usb3h0_vbus>; + status = "disabled"; + }; diff --git a/doc/driver-model/fdt-fixup.txt b/doc/driver-model/fdt-fixup.txt new file mode 100644 index 0000000000..70344bd2c3 --- /dev/null +++ b/doc/driver-model/fdt-fixup.txt @@ -0,0 +1,132 @@ +Pre-relocation device tree manipulation +======================================= + +Contents: + +1. Purpose +2. Implementation +3. Example +4. Work to be done + +1. Purpose +---------- + +In certain markets, it is beneficial for manufacturers of embedded devices to +offer certain ranges of products, where the functionality of the devices within +one series either don't differ greatly from another, or can be thought of as +"extensions" of each other, where one device only differs from another in the +addition of a small number of features (e.g. an additional output connector). + +To realize this in hardware, one method is to have a motherboard, and several +possible daughter boards that can be attached to this mother board. Different +daughter boards then either offer the slightly different functionality, or the +addition of the daughter board to the device realizes the "extension" of +functionality to the device described previously. + +For the software, we obviously want to reuse components for all these +variations of the device. This means that the software somehow needs to cope +with the situation that certain ICs may or may not be present on any given +system, depending on which daughter boards are connected to the motherboard. + +In the Linux kernel, one possible solution to this problem is to employ the +device tree overlay mechanism: There exists one "base" device tree, which +features only the components guaranteed to exist in all varieties of the +device. At the start of the kernel, the presence and type of the daughter +boards is then detected, and the corresponding device tree overlays are applied +to support the components on the daughter boards. + +Note that the components present on every variety of the board must, of course, +provide a way to find out if and which daughter boards are installed for this +mechanism to work. + +In the U-Boot boot loader, support for device tree overlays has recently been +integrated, and is used on some boards to alter the device tree that is later +passed to Linux. But since U-Boot's driver model, which is device tree-based as +well, is being used in more and more drivers, the same problem of altering the +device tree starts cropping up in U-Boot itself as well. + +An additional problem with the device tree in U-Boot is that it is read-only, +and the current mechanisms don't allow easy manipulation of the device tree +after the driver model has been initialized. While migrating to a live device +tree (at least after the relocation) would greatly simplify the solution of +this problem, it is a non-negligible task to implement it, an a interim +solution is needed to address the problem at least in the medium-term. + +Hence, we propose a solution to this problem by offering a board-specific +call-back function, which is passed a writeable pointer to the device tree. +This function is called before the device tree is relocated, and specifically +before the main U-Boot's driver model is instantiated, hence the main U-Boot +"sees" all modifications to the device tree made in this function. Furthermore, +we have the pre-relocation driver model at our disposal at this stage, which +means that we can query the hardware for the existence and variety of the +components easily. + +2. Implementation +----------------- + +To take advantage of the pre-relocation device tree manipulation mechanism, +boards have to implement the function board_fix_fdt, which has the following +signature: + +int board_fix_fdt (void *rw_fdt_blob) + +The passed-in void pointer is a writeable pointer to the device tree, which can +be used to manipulate the device tree using e.g. functions from +include/fdt_support.h. The return value should either be 0 in case of +successful execution of the device tree manipulation or something else for a +failure. Note that returning a non-null value from the function will +unrecoverably halt the boot process, as with any function from init_sequence_f +(in common/board_f.c). + +Furthermore, the Kconfig option OF_BOARD_FIXUP has to be set for the function +to be called: + +Device Tree Control +-> [*] Board-specific manipulation of Device Tree + ++----------------------------------------------------------+ +| WARNING: The actual manipulation of the device tree has | +| to be the _last_ set of operations in board_fix_fdt! | +| Since the pre-relocation driver model does not adapt to | +| changes made to the device tree either, its references | +| into the device tree will be invalid after manipulating | +| it, and unpredictable behavior might occur when | +| functions that rely on them are executed! | ++----------------------------------------------------------+ + +Hence, the recommended layout of the board_fixup_fdt call-back function is the +following: + +int board_fix_fdt(void *rw_fdt_blob) +{ + /* Collect information about device's hardware and store them in e.g. + local variables */ + + /* Do device tree manipulation using the values previously collected */ + + /* Return 0 on successful manipulation and non-zero otherwise */ +} + +If this convention is kept, both an "additive" approach, meaning that nodes for +detected components are added to the device tree, as well as a "subtractive" +approach, meaning that nodes for absent components are removed from the tree, +as well as a combination of both approaches should work. + +3. Example +---------- + +The controlcenterdc board (board/gdsys/a38x/controlcenterdc.c) features a +board_fix_fdt function, in which six GPIO expanders (which might be present or +not, since they are on daughter boards) on a I2C bus are queried for, and +subsequently deactivated in the device tree if they are not present. + +Note that the dm_i2c_simple_probe function does not use the device tree, hence +it is safe to call it after the tree has already been manipulated. + +4. Work to be done +------------------ + +* The application of device tree overlay should be possible in board_fixup_fdt, + but has not been tested at this stage. + +2017-01-06, Mario Six <mario.six@gdsys.cc> |