diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.scrapyard | 89 | ||||
| -rw-r--r-- | doc/README.uniphier | 8 | ||||
| -rw-r--r-- | doc/README.vxworks | 82 | ||||
| -rw-r--r-- | doc/README.x86 | 10 | ||||
| -rw-r--r-- | doc/device-tree-bindings/remoteproc/remoteproc.txt | 14 | ||||
| -rw-r--r-- | doc/driver-model/remoteproc-framework.txt | 168 |
6 files changed, 345 insertions, 26 deletions
diff --git a/doc/README.scrapyard b/doc/README.scrapyard index c7b4fa3de2..2760f60f6d 100644 --- a/doc/README.scrapyard +++ b/doc/README.scrapyard @@ -12,15 +12,86 @@ The list should be sorted in reverse chronological order. Board Arch CPU Commit Removed Last known maintainer/contact ================================================================================================= -stxgp3 powerpc mpc85xx - - Dan Malek <dan@embeddedalley.com> -stxssa powerpc mpc85xx - - Dan Malek <dan@embeddedalley.com> -cmi_mpc5xx powerpc mpc5xx - - -zeus powerpc ppc4xx - - Stefan Roese <sr@denx.de> -sbc405 powerpc ppc4xx - - -pcs440ep powerpc ppc4xx - - Stefan Roese <sr@denx.de> -p3p440 powerpc ppc4xx - - Stefan Roese <sr@denx.de> -csb272/csb472 powerpc ppc4xx - - Tolunay Orkun <torkun@nextio.com> -alpr powerpc ppc4xx - - Stefan Roese <sr@denx.de> +lcd4_lwmon5 powerpc ppc4xx b6b5e394 2015-10-02 Stefan Roese <sr@denx.de> +da830evm arm arm926ejs d7e8b2b9 2015-09-12 Nick Thompson <nick.thompson@gefanuc.com> +wireless_space arm arm926ejs b352182a 2015-09-12 Albert ARIBAUD <albert.u.boot@aribaud.net> +stxgp3 powerpc mpc85xx 2ec69b88 2015-09-02 Dan Malek <dan@embeddedalley.com> +stxssa powerpc mpc85xx 2ec69b88 2015-09-02 Dan Malek <dan@embeddedalley.com> +cmi_mpc5xx powerpc mpc5xx 972f5320 2015-09-02 +zeus powerpc ppc4xx eb5d1dc7 2015-09-02 Stefan Roese <sr@denx.de> +sbc405 powerpc ppc4xx 0e030593 2015-09-02 +pcs440ep powerpc ppc4xx 242836a8 2015-09-02 Stefan Roese <sr@denx.de> +p3p440 powerpc ppc4xx c6999e5f 2015-09-02 Stefan Roese <sr@denx.de> +csb272/csb472 powerpc ppc4xx 54a3f260 2015-09-02 Tolunay Orkun <torkun@nextio.com> +alpr powerpc ppc4xx 0d2fc811 2015-09-02 Stefan Roese <sr@denx.de> +balloon3 arm pxa 679d4456 2015-08-30 Marek Vasut <marex@denx.de> +cpu9260_128M arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric@eukrea.com> +cpu9260 arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric@eukrea.com> +cpu9260_nand_128M arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric@eukrea.com> +cpu9260_nand arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric@eukrea.com> +cpu9G20_128M arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric@eukrea.com> +cpu9G20 arm arm926ejs af7f884b 2015-08-30 Eric Benard <eric@eukrea.com> +cpuat91 arm arm920t af7f884b 2015-08-30 Eric Benard <eric@eukrea.com> +cpuat91_ram arm arm920t af7f884b 2015-08-30 Eric Benard <eric@eukrea.com> +davinci_dm355evm arm arm926ejs 6761946f 2015-08-30 +davinci_dm355leopard arm arm926ejs 6761946f 2015-08-30 +davinci_dm365evm arm arm926ejs 6761946f 2015-08-30 +davinci_dm6467evm arm arm926ejs 6761946f 2015-08-30 +davinci_dm6467Tevm arm arm926ejs 6761946f 2015-08-30 +davinci_dvevm arm arm926ejs 6761946f 2015-08-30 +davinci_schmoogie arm arm926ejs 6761946f 2015-08-30 +davinci_sffsdr arm arm926ejs 6761946f 2015-08-30 +davinci_sonata arm arm926ejs 6761946f 2015-08-30 +dig297 arm armv7 5ff33d04 2015-08-30 Luca Ceresoli <luca.ceresoli@comelit.it> +ea20 arm arm926ejs 6761946f 2015-08-30 +eb_cpux9k2 arm arm920t 5522f12b 2015-08-30 Jens Scharsig <esw@bus-elektronik.de> +eb_cpux9k2_ram arm arm920t 5522f12b 2015-08-30 Jens Scharsig <esw@bus-elektronik.de> +enbw_cmc arm arm926ejs a6f7f787 2015-08-30 Heiko Schocher <hs@denx.de> +ima3-mx53 arm armv7 3eb8f58d 2015-08-30 +imx27lite arm arm926ejs bc0840bc 2015-08-30 Wolfgang Denk <wd@denx.de> +imx31_litekit arm arm1136 36d14178 2015-08-30 +jornada arm sa1100 df0b116d 2015-08-30 Kristoffer Ericson <kristoffer.ericson@gmail.com> +lp8x4x arm pxa 9f840b8d 2015-08-30 Sergey Yanovich <ynvich@gmail.com> +magnesium arm arm926ejs bc0840bc 2015-08-30 Heiko Schocher <hs@denx.de> +mv88f6281gtw_ge arm arm926ejs 7cd768cf 2015-08-30 Prafulla Wadaskar <prafulla@marvell.com> +mx51_efikamx arm armv7 b6073fd2 2015-08-30 +mx51_efikasb arm armv7 b6073fd2 2015-08-30 +nhk8815 arm arm926ejs 0abdd9d0 2015-08-30 Nomadik Linux Team <STN_WMM_nomadik_linux@list.st.com> +nhk8815_onenand arm arm926ejs 0abdd9d0 2015-08-30 Nomadik Linux Team <STN_WMM_nomadik_linux@list.st.com> +omap3_mvblx arm armv7 8dc372f9 2015-08-30 Michael Jones <michael.jones@matrix-vision.de> +omap3_sdp3430 arm armv7 93b25c08 2015-08-30 Nishanth Menon <nm@ti.com> +openrd_base arm arm926ejs 7a2c1b13 2015-08-30 Prafulla Wadaskar <prafulla@marvell.com> +openrd_client arm arm926ejs 7a2c1b13 2015-08-30 Prafulla Wadaskar <prafulla@marvell.com> +openrd_ultimate arm arm926ejs 7a2c1b13 2015-08-30 Prafulla Wadaskar <prafulla@marvell.com> +otc570 arm arm926ejs 819216dd 2015-08-30 Daniel Gorsulowski <daniel.gorsulowski@esd.eu> +otc570_dataflash arm arm926ejs 819216dd 2015-08-30 Daniel Gorsulowski <daniel.gorsulowski@esd.eu> +palmld arm pxa 35782e9c 2015-08-30 Marek Vasut <marex@denx.de> +palmtc arm pxa 8896325d 2015-08-30 Marek Vasut <marex@denx.de> +palmtreo680 arm pxa ad4f54ea 2015-08-30 Mike Dunn <mikedunn@newsguy.com> +polaris arm pxa f6eac00a 2015-08-30 Stefano Babic <sbabic@denx.de> +portuxg20 arm arm926ejs 79d19734 2015-08-30 Markus Hubig <mhubig@imko.de> +pxa255_idp arm pxa 49d8899b 2015-08-30 Marek Vasut <marex@denx.de> +qong arm arm1136 daf77086 2015-08-30 Wolfgang Denk <wd@denx.de> +rd6281a arm arm926ejs 47b87d2e 2015-08-30 Prafulla Wadaskar <prafulla@marvell.com> +scb9328 arm arm920t 7650beb7 2015-08-30 Torsten Koschorrek <koschorrek@synertronixx.de> +snowball arm armv7 7495e41b 2015-08-30 Mathieu Poirier <mathieu.poirier@linaro.org> +stamp9g20 arm arm926ejs 79d19734 2015-08-30 Markus Hubig <mhubig@imko.de> +tk71 arm arm926ejs f73db66d 2015-08-30 +trizepsiv arm pxa f6eac00a 2015-08-30 Stefano Babic <sbabic@denx.de> +tt01 arm arm1136 0c81f37d 2015-08-30 Helmut Raiger <helmut.raiger@hale.at> +tx25 arm arm926ejs b9599dd8 2015-08-30 John Rigby <jcrigby@gmail.com> +u8500_href arm armv7 7495e41b 2015-08-30 +versatileab arm arm926ejs b928e658 2015-08-30 +versatilepb arm arm926ejs b928e658 2015-08-30 +versatileqemu arm arm926ejs b928e658 2015-08-30 +vision2 arm armv7 bee2b99d 2015-08-30 Stefano Babic <sbabic@denx.de> +vl_ma2sc arm arm926ejs 6e830dfc 2015-08-30 Jens Scharsig <esw@bus-elektronik.de> +vl_ma2sc_ram arm arm926ejs 6e830dfc 2015-08-30 Jens Scharsig <esw@bus-elektronik.de> +vpac270_nor_128 arm pxa 452ef830 2015-08-30 Marek Vasut <marex@denx.de> +vpac270_nor_256 arm pxa 452ef830 2015-08-30 Marek Vasut <marex@denx.de> +vpac270_ond_256 arm pxa 452ef830 2015-08-30 Marek Vasut <marex@denx.de> +xaeniax arm pxa 1c87dd76 2015-08-30 +zipitz2 arm pxa 49d8899b 2015-08-30 Cliff Brake <cliff.brake@gmail.com> cam_enc_4xx arm arm926ejs 8d775763 2015-08-20 Heiko Schocher <hs@denx.de> atstk1003 avr32 - e5354b8a 2015-06-10 Haavard Skinnemoen <haavard.skinnemoen@atmel.com> atstk1004 avr32 - e5354b8a 2015-06-10 Haavard Skinnemoen <haavard.skinnemoen@atmel.com> diff --git a/doc/README.uniphier b/doc/README.uniphier index 6ba0320f4f..57b947b570 100644 --- a/doc/README.uniphier +++ b/doc/README.uniphier @@ -129,10 +129,10 @@ as follows: BKSZ Description RAM slot Peripherals -------------------------------------------------------------------- - 0b00 15MB RAM / 1MB Peri 00000000-0effffff 0f000000-0fffffff - 0b01 31MB RAM / 1MB Peri 00000000-1effffff 1f000000-1fffffff - 0b10 64MB RAM / 1MB Peri 00000000-3effffff 3f000000-3fffffff - 0b11 127MB RAM / 1MB Peri 00000000-7effffff 7f000000-7fffffff + 0b00 15MB RAM / 1MB Peri 00000000-00efffff 00f00000-00ffffff + 0b01 31MB RAM / 1MB Peri 00000000-01efffff 01f00000-01ffffff + 0b10 64MB RAM / 1MB Peri 00000000-03efffff 03f00000-03ffffff + 0b11 127MB RAM / 1MB Peri 00000000-07efffff 07f00000-07ffffff Set BSKZ[1:0] to 0b01 for U-Boot. This mode is the most handy because EA[24] is always supported by the save pin diff --git a/doc/README.vxworks b/doc/README.vxworks index 4cb302e7f4..3433e4f3ae 100644 --- a/doc/README.vxworks +++ b/doc/README.vxworks @@ -1,19 +1,85 @@ -From VxWorks 6.9+ (not include 6.9), VxWorks starts adopting device tree as its hardware -decription mechansim (for PowerPC and ARM), thus requiring boot interface changes. +# +# Copyright (C) 2013, Miao Yan <miao.yan@windriver.com> +# Copyright (C) 2015, Bin Meng <bmeng.cn@gmail.com> +# +# SPDX-License-Identifier: GPL-2.0+ +# + +VxWorks Support +=============== + +This document describes the information about U-Boot loading VxWorks kernel. + +Status +------ +U-Boot supports loading VxWorks kernels via 'bootvx' and 'bootm' commands. +For booting old kernels (6.9.x) on PowerPC and ARM, and all kernel versions +on other architectures, 'bootvx' shall be used. For booting VxWorks 7 kernels +on PowerPC and ARM, 'bootm' shall be used. + +64-bit x86 kernel cannot be loaded as of today. + +VxWork 7 on PowerPC and ARM +--------------------------- +From VxWorks 7, VxWorks starts adopting device tree as its hardware decription +mechansim (for PowerPC and ARM), thus requiring boot interface changes. This section will describe the new interface. -For PowerPC, the calling convention of the new VxWorks entry point conforms to the ePAPR standard, -which is shown below (see ePAPR for more details): +For PowerPC, the calling convention of the new VxWorks entry point conforms to +the ePAPR standard, which is shown below (see ePAPR for more details): - void (*kernel_entry)(fdt_addr, - 0, 0, EPAPR_MAGIC, boot_IMA, 0, 0) + void (*kernel_entry)(fdt_addr, 0, 0, EPAPR_MAGIC, boot_IMA, 0, 0) For ARM, the calling convention is show below: void (*kernel_entry)(void *fdt_addr) -When booting new VxWorks kernel (uImage format), the parameters passed to bootm is like below: +When booting new VxWorks kernel (uImage format), the parameters passed to bootm +is like below: bootm <kernel image address> - <device tree address> -The do_bootvx command still works as it was for older VxWorks kernels. +VxWorks bootline +---------------- +When using 'bootvx', the kernel bootline must be prepared by U-Boot at a +board-specific address before loading VxWorks. U-Boot supplies its address +via "bootaddr" environment variable. To check where the bootline should be +for a specific board, go to the VxWorks BSP for that board, and look for a +parameter called BOOT_LINE_ADRS. Assign its value to "bootaddr". A typical +value for "bootaddr" is 0x101200. + +If a "bootargs" variable is defined, its content will be copied to the memory +location pointed by "bootaddr" as the kernel bootline. If "bootargs" is not +there, command 'bootvx' can construct a valid bootline using the following +environments variables: bootdev, bootfile, ipaddr, netmask, serverip, +gatewayip, hostname, othbootargs. + +When using 'bootm', just define "bootargs" in the environment and U-Boot will +handle bootline fix up for the kernel dtb automatically. + +Serial console +-------------- +It's very common that VxWorks BSPs configure a different baud rate for the +serial console from what is being used by U-Boot. For example, VxWorks tends +to use 9600 as the default baud rate on all x86 BSPs while U-Boot uses 115200. +Please configure both U-Boot and VxWorks to use the same baud rate, or it may +look like VxWorks hangs somewhere as nothing outputs on the serial console. + +x86-specific information +------------------------ +Before loading an x86 kernel, two additional environment variables need to be +provided. They are "e820data" and "e820info", which represent the address of +E820 table and E820 information (defined by VxWorks) in system memory. + +Check VxWorks kernel configuration to look for BIOS_E820_DATA_START and +BIOS_E820_INFO_START, and assign their values to "e820data" and "e820info" +accordingly. If neither of these two are supplied, U-Boot assumes a default +location at 0x4000 for "e820data" and 0x4a00 for "e820info". Typical values +for "e820data" and "e820info" are 0x104000 and 0x104a00. But there is one +exception on Intel Galileo, where "e820data" and "e820info" should be left +unset, which assume the default location for VxWorks. + +Note since currently U-Boot does not support ACPI yet, VxWorks kernel must +be configured to use MP table and virtual wire interrupt mode. This requires +INCLUDE_MPTABLE_BOOT_OP and INCLUDE_VIRTUAL_WIRE_MODE to be included in a +VxWorks kernel configuration. diff --git a/doc/README.x86 b/doc/README.x86 index 6cf293b11e..1271e5edea 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -25,6 +25,8 @@ targets and all Intel boards support running U-Boot 'bare metal'. 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. +U-Boot supports loading an x86 VxWorks kernel. Please check README.vxworks +for more details. Build Instructions for U-Boot as coreboot payload ------------------------------------------------- @@ -188,6 +190,7 @@ Offset Description Controlling config 000000 descriptor.bin Hard-coded to 0 in ifdtool 001000 me.bin Set by the descriptor 500000 <spare> +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 @@ -330,9 +333,8 @@ In keeping with the U-Boot philosophy of providing functions to check and adjust internal settings, there are several x86-specific commands that may be useful: -hob - Display information about Firmware Support Package (FSP) Hand-off - Block. This is only available on platforms which use FSP, mostly - Atom. +fsp - Display information about Intel Firmware Support Package (FSP). + This is only available on platforms which use FSP, mostly Atom. iod - Display I/O memory iow - Write I/O memory mtrr - List and set the Memory Type Range Registers (MTRR). These are used to @@ -762,7 +764,6 @@ TODO List - Audio - Chrome OS verified boot - SMI and ACPI support, to provide platform info and facilities to Linux -- Desktop Management Interface (DMI) [15] support References ---------- @@ -780,4 +781,3 @@ References [12] http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf [13] http://events.linuxfoundation.org/sites/events/files/slides/elce-2014.pdf [14] doc/device-tree-bindings/misc/intel,irq-router.txt -[15] http://en.wikipedia.org/wiki/Desktop_Management_Interface diff --git a/doc/device-tree-bindings/remoteproc/remoteproc.txt b/doc/device-tree-bindings/remoteproc/remoteproc.txt new file mode 100644 index 0000000000..031764f515 --- /dev/null +++ b/doc/device-tree-bindings/remoteproc/remoteproc.txt @@ -0,0 +1,14 @@ +Remote Processor uclass + +Binding: + +Remoteproc devices shall have compatible corresponding to thier +drivers. However the following generic properties will be supported + +Optional Properties: +- remoteproc-name: a string, used if provided to describe the processor. + This must be unique in an operational system. +- remoteproc-internal-memory-mapped: a bool, indicates that the remote + processor has internal memory that it uses to execute code and store + data. Such a device is not expected to have a MMU. If no type property + is provided, the device is assumed to map to such a model. diff --git a/doc/driver-model/remoteproc-framework.txt b/doc/driver-model/remoteproc-framework.txt new file mode 100644 index 0000000000..094e98bba6 --- /dev/null +++ b/doc/driver-model/remoteproc-framework.txt @@ -0,0 +1,168 @@ +# +# (C) Copyright 2015 +# Texas Instruments Incorporated - http://www.ti.com/ +# SPDX-License-Identifier: GPL-2.0+ +# + +Remote Processor Framework +========================== +TOC: +1. Introduction +2. How does it work - The driver +3. Describing the device using platform data +4. Describing the device using device tree + +1. Introduction +=============== + +This is an introduction to driver-model for Remote Processors found +on various System on Chip(SoCs). The term remote processor is used to +indicate that this is not the processor on which U-Boot is operating +on, instead is yet another processing entity that may be controlled by +the processor on which we are functional. + +The simplified model depends on a single UCLASS - UCLASS_REMOTEPROC + +UCLASS_REMOTEPROC: +- drivers/remoteproc/rproc-uclass.c +- include/remoteproc.h + +Commands: +- common/cmd_remoteproc.c + +Configuration: +CONFIG_REMOTEPROC is selected by drivers as needed +CONFIG_CMD_REMOTEPROC for the commands if required. + +2. How does it work - The driver +================================= + +Overall, the driver statemachine transitions are typically as follows: + (entry) + +-------+ + +---+ init | + | | | <---------------------+ + | +-------+ | + | | + | | + | +--------+ | +Load| | reset | | + | | | <----------+ | + | +--------+ | | + | |Load | | + | | | | + | +----v----+ reset | | + +-> | | (opt) | | + | Loaded +-----------+ | + | | | + +----+----+ | + | Start | + +---v-----+ (opt) | + +->| Running | Stop | +Ping +- | +--------------------+ +(opt) +---------+ + +(is_running does not change state) +opt: Optional state transition implemented by driver. + +NOTE: It depends on the remote processor as to the exact behavior +of the statemachine, remoteproc core does not intent to implement +statemachine logic. Certain processors may allow start/stop without +reloading the image in the middle, certain other processors may only +allow us to start the processor(image from a EEPROM/OTP) etc. + +It is hence the responsibility of the driver to handle the requisite +state transitions of the device as necessary. + +Basic design assumptions: + +Remote processor can operate on a certain firmware that maybe loaded +and released from reset. + +The driver follows a standard UCLASS DM. + +in the bare minimum form: + +static const struct dm_rproc_ops sandbox_testproc_ops = { + .load = sandbox_testproc_load, + .start = sandbox_testproc_start, +}; + +static const struct udevice_id sandbox_ids[] = { + {.compatible = "sandbox,test-processor"}, + {} +}; + +U_BOOT_DRIVER(sandbox_testproc) = { + .name = "sandbox_test_proc", + .of_match = sandbox_ids, + .id = UCLASS_REMOTEPROC, + .ops = &sandbox_testproc_ops, + .probe = sandbox_testproc_probe, +}; + +This allows for the device to be probed as part of the "init" command +or invocation of 'rproc_init()' function as the system dependencies define. + +The driver is expected to maintain it's own statemachine which is +appropriate for the device it maintains. It must, at the very least +provide a load and start function. We assume here that the device +needs to be loaded and started, else, there is no real purpose of +using the remoteproc framework. + +3. Describing the device using platform data +============================================ + +*IMPORTANT* NOTE: THIS SUPPORT IS NOT MEANT FOR USE WITH NEWER PLATFORM +SUPPORT. THIS IS ONLY FOR LEGACY DEVICES. THIS MODE OF INITIALIZATION +*WILL* BE EVENTUALLY REMOVED ONCE ALL NECESSARY PLATFORMS HAVE MOVED +TO DM/FDT. + +Considering that many platforms are yet to move to device-tree model, +a simplified definition of a device is as follows: + +struct dm_rproc_uclass_pdata proc_3_test = { + .name = "proc_3_legacy", + .mem_type = RPROC_INTERNAL_MEMORY_MAPPED, + .driver_plat_data = &mydriver_data; +}; + +U_BOOT_DEVICE(proc_3_demo) = { + .name = "sandbox_test_proc", + .platdata = &proc_3_test, +}; + +There can be additional data that may be desired depending on the +remoteproc driver specific needs (for example: SoC integration +details such as clock handle or something similar). See appropriate +documentation for specific remoteproc driver for further details. +These are passed via driver_plat_data. + +3. Describing the device using device tree +========================================== +/ { + ... + aliases { + ... + remoteproc0 = &rproc_1; + remoteproc1 = &rproc_2; + + }; + ... + + rproc_1: rproc@1 { + compatible = "sandbox,test-processor"; + remoteproc-name = "remoteproc-test-dev1"; + }; + + rproc_2: rproc@2 { + compatible = "sandbox,test-processor"; + internal-memory-mapped; + remoteproc-name = "remoteproc-test-dev2"; + }; + ... +}; + +aliases usage is optional, but it is usually recommended to ensure the +users have a consistent usage model for a platform. +the compatible string used here is specific to the remoteproc driver involved. |