diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.arm-relocation | 14 | ||||
| -rw-r--r-- | doc/README.bootmenu | 115 | ||||
| -rw-r--r-- | doc/README.fdt-control | 8 | ||||
| -rw-r--r-- | doc/README.memory-test | 98 | ||||
| -rw-r--r-- | doc/README.menu | 9 | ||||
| -rw-r--r-- | doc/README.omap3 | 28 | ||||
| -rw-r--r-- | doc/README.scrapyard | 3 | ||||
| -rw-r--r-- | doc/README.silent | 4 | ||||
| -rw-r--r-- | doc/device-tree-bindings/exynos/tmu.txt | 44 | ||||
| -rw-r--r-- | doc/device-tree-bindings/video/exynos-dp.txt | 69 | ||||
| -rw-r--r-- | doc/device-tree-bindings/video/exynos-fb.txt | 92 | ||||
| -rw-r--r-- | doc/driver-model/UDM-pci.txt | 4 | ||||
| -rw-r--r-- | doc/driver-model/UDM-serial.txt | 42 | ||||
| -rw-r--r-- | doc/driver-model/UDM-watchdog.txt | 5 | ||||
| -rw-r--r-- | doc/feature-removal-schedule.txt | 49 |
15 files changed, 527 insertions, 57 deletions
diff --git a/doc/README.arm-relocation b/doc/README.arm-relocation index 5a9a2fb..645b374 100644 --- a/doc/README.arm-relocation +++ b/doc/README.arm-relocation @@ -40,15 +40,15 @@ Boards which are not fixed to support relocation will be REMOVED! ----------------------------------------------------------------------------- -For boards which boot from nand_spl, it is possible to save one copy +For boards which boot from spl, it is possible to save one copy if CONFIG_SYS_TEXT_BASE == relocation address! This prevents that uboot code is copied again in relocate_code(). -example for the tx25 board: +example for the tx25 board booting from NAND Flash: a) cpu starts b) it copies the first page in nand to internal ram - (nand_spl_code) + (spl code) c) end executes this code d) this initialize CPU, RAM, ... and copy itself to RAM (this bin must fit in one page, so board_init_f() @@ -79,20 +79,20 @@ TODO ----------------------------------------------------------------------------- -Relocation with NAND_SPL (example for the tx25): +Relocation with SPL (example for the tx25 booting from NAND Flash): - cpu copies the first page from NAND to 0xbb000000 (IMX_NFC_BASE) and start with code execution on this address. -- The First page contains u-boot code from u-boot:nand_spl/nand_boot_fsl_nfc.c - which inits the dram, cpu registers, reloacte itself to CONFIG_SYS_TEXT_BASE and loads +- The First page contains u-boot code from drivers/mtd/nand/mxc_nand_spl.c + which inits the dram, cpu registers, reloacte itself to CONFIG_SPL_TEXT_BASE and loads the "real" u-boot to CONFIG_SYS_NAND_U_BOOT_DST and starts execution @CONFIG_SYS_NAND_U_BOOT_START - This u-boot does no RAM init, nor CPU register setup. Just look where it has to copy and relocate itself to this address. If relocate address = CONFIG_SYS_TEXT_BASE (not the same, as the - CONFIG_SYS_TEXT_BASE from the nand_spl code), then there is no need + CONFIG_SPL_TEXT_BASE from the spl code), then there is no need to copy, just go on with bss clear and jump to board_init_r. ----------------------------------------------------------------------------- diff --git a/doc/README.bootmenu b/doc/README.bootmenu new file mode 100644 index 0000000..9e85b40 --- /dev/null +++ b/doc/README.bootmenu @@ -0,0 +1,115 @@ +/* + * (C) Copyright 2011-2012 Pali Rohár <pali.rohar@gmail.com> + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +ANSI terminal bootmenu command + +The "bootmenu" command uses U-Boot menu interfaces and provides +a simple mechanism for creating menus with different boot items. +The cursor keys "Up" and "Down" are used for navigation through +the items. Current active menu item is highlighted and can be +selected using the "Enter" key. The selection of the highlighted +menu entry invokes an U-Boot command (or a list of commands) +associated with this menu entry. + +The "bootmenu" command interprets ANSI escape sequencies, so +an ANSI terminal is required for proper menu rendering and item +selection. + +The assembling of the menu is done via a set of environment variables +"bootmenu_<num>" and "bootmenu_delay", i.e.: + + bootmenu_delay=<delay> + bootmenu_<num>="<title>=<commands>" + + <delay> is the autoboot delay in seconds, after which the first + menu entry will be selected automatically + + <num> is the boot menu entry number, starting from zero + + <title> is the text of the menu entry shown on the console + or on the boot screen + + <commands> are commands which will be executed when a menu + entry is selected + + (title and commands are separated by first appearance of '=' + character in the environment variable) + +First (optional) argument of the "bootmenu" command is a delay specifier +and it overrides the delay value defined by "bootmenu_delay" environment +variable. If the environment variable "bootmenu_delay" is not set or if +the argument of the "bootmenu" command is not specified, the default delay +will be CONFIG_BOOTDELAY. If delay is 0, no menu entries will be shown on +the console (or on the screen) and the command of the first menu entry will +be called immediately. If delay is less then 0, bootmenu will be shown and +autoboot will be disabled. + +Bootmenu always adds menu entry "U-Boot console" at the end of all menu +entries specified by environment variables. When selecting this entry +the bootmenu terminates and the usual U-Boot command prompt is presented +to the user. + +Example environment: + + setenv bootmenu_0 Boot 1. kernel=bootm 0x82000000 # Set first menu entry + setenv bootmenu_1 Boot 2. kernel=bootm 0x83000000 # Set second menu entry + setenv bootmenu_2 Reset board=reset # Set third menu entry + setenv bootmenu_3 U-Boot boot order=boot # Set fourth menu entry + bootmenu 20 # Run bootmenu with autoboot delay 20s + + +The above example will be rendered as below +(without decorating rectangle): + +┌──────────────────────────────────────────┐ +│ │ +│ *** U-Boot Boot Menu *** │ +│ │ +│ Boot 1. kernel │ +│ Boot 2. kernel │ +│ Reset board │ +│ U-Boot boot order │ +│ U-Boot console │ +│ │ +│ Hit any key to stop autoboot: 20 │ +│ Press UP/DOWN to move, ENTER to select │ +│ │ +└──────────────────────────────────────────┘ + +Selected menu entry will be highlighted - it will have inverted +background and text colors. + +To enable the "bootmenu" command add following definitions to the +board config file: + + #define CONFIG_CMD_BOOTMENU + #define CONFIG_MENU + +To run the bootmenu at startup add these additional definitions: + + #define CONFIG_AUTOBOOT_KEYED + #define CONFIG_BOOTDELAY 30 + #define CONFIG_MENU_SHOW + +When you intend to use the bootmenu on color frame buffer console, +make sure to additionally define CONFIG_CFB_CONSOLE_ANSI in the +board config file. diff --git a/doc/README.fdt-control b/doc/README.fdt-control index 85bda03..8352835 100644 --- a/doc/README.fdt-control +++ b/doc/README.fdt-control @@ -156,6 +156,14 @@ To use this, put something like this in your board header file: #define CONFIG_EXTRA_ENV_SETTINGS "fdtcontroladdr=10000\0" +Build: + +After board configuration is done, fdt supported u-boot can be build in two ways: +1) build the default dts which is defined from CONFIG_DEFAULT_DEVICE_TREE + $ make +2) build the user specified dts file + $ make DEVICE_TREE=<dts-file-name> + Limitations ----------- diff --git a/doc/README.memory-test b/doc/README.memory-test new file mode 100644 index 0000000..eb60e8d --- /dev/null +++ b/doc/README.memory-test @@ -0,0 +1,98 @@ +The most frequent cause of problems when porting U-Boot to new +hardware, or when using a sloppy port on some board, is memory errors. +In most cases these are not caused by failing hardware, but by +incorrect initialization of the memory controller. So it appears to +be a good idea to always test if the memory is working correctly, +before looking for any other potential causes of any problems. + +U-Boot implements 3 different approaches to perform memory tests: + +1. The get_ram_size() function (see "common/memsize.c"). + + This function is supposed to be used in each and every U-Boot port + determine the presence and actual size of each of the potential + memory banks on this piece of hardware. The code is supposed to be + very fast, so running it for each reboot does not hurt. It is a + little known and generally underrated fact that this code will also + catch 99% of hardware related (i. e. reliably reproducible) memory + errors. It is strongly recommended to always use this function, in + each and every port of U-Boot. + +2. The "mtest" command. + + This is probably the best known memory test utility in U-Boot. + Unfortunately, it is also the most problematic, and the most + useless one. + + There are a number of serious problems with this command: + + - It is terribly slow. Running "mtest" on the whole system RAM + takes a _long_ time before there is any significance in the fact + that no errors have been found so far. + + - It is difficult to configure, and to use. And any errors here + will reliably crash or hang your system. "mtest" is dumb and has + no knowledge about memory ranges that may be in use for other + purposes, like exception code, U-Boot code and data, stack, + malloc arena, video buffer, log buffer, etc. If you let it, it + will happily "test" all such areas, which of course will cause + some problems. + + - It is not easy to configure and use, and a large number of + systems are seriously misconfigured. The original idea was to + test basically the whole system RAM, with only exempting the + areas used by U-Boot itself - on most systems these are the areas + used for the exception vectors (usually at the very lower end of + system memory) and for U-Boot (code, data, etc. - see above; + these are usually at the very upper end of system memory). But + experience has shown that a very large number of ports use + pretty much bogus settings of CONFIG_SYS_MEMTEST_START and + CONFIG_SYS_MEMTEST_END; this results in useless tests (because + the ranges is too small and/or badly located) or in critical + failures (system crashes). + + Because of these issues, the "mtest" command is considered depre- + cated. It should not be enabled in most normal ports of U-Boot, + especially not in production. If you really need a memory test, + then see 1. and 3. above resp. below. + +3. The most thorough memory test facility is available as part of the + POST (Power-On Self Test) sub-system, see "post/drivers/memory.c". + + If you really need to perform memory tests (for example, because + it is mandatory part of your requirement specification), then + enable this test which is generic and should work on all archi- + tectures. + +WARNING: + +It should pointed out that _all_ these memory tests have one +fundamental, unfixable design flaw: they are based on the assumption +that memory errors can be found by writing to and reading from memory. +Unfortunately, this is only true for the relatively harmless, usually +static errors like shorts between data or address lines, unconnected +pins, etc. All the really nasty errors which will first turn your +hair gray, only to make you tear it out later, are dynamical errors, +which usually happen not with simple read or write cycles on the bus, +but when performing back-to-back data transfers in burst mode. Such +accesses usually happen only for certain DMA operations, or for heavy +cache use (instruction fetching, cache flushing). So far I am not +aware of any freely available code that implements a generic, and +efficient, memory test like that. The best known test case to stress +a system like that is to boot Linux with root file system mounted over +NFS, and then build some larger software package natively (say, +compile a Linux kernel on the system) - this will cause enough context +switches, network traffic (and thus DMA transfers from the network +controller), varying RAM use, etc. to trigger any weak spots in this +area. + +Note: An attempt was made once to implement such a test to catch +memory problems on a specific board. The code is pretty much board +specific (for example, it includes setting specific GPIO signals to +provide triggers for an attached logic analyzer), but you can get an +idea how it works: see "examples/standalone/test_burst*". + +Note 2: Ironically enough, the "test_burst" did not catch any RAM +errors, not a single one ever. The problems this code was supposed +to catch did not happen when accessing the RAM, but when reading from +NOR flash. diff --git a/doc/README.menu b/doc/README.menu index 6ce6bba..a8999ca 100644 --- a/doc/README.menu +++ b/doc/README.menu @@ -51,7 +51,9 @@ struct menu; * menu_create() - Creates a menu handle with default settings */ struct menu *menu_create(char *title, int timeout, int prompt, - void (*item_data_print)(void *)); + void (*item_data_print)(void *), + char *(*item_choice)(void *), + void *item_choice_data); /* * menu_item_add() - Adds or replaces a menu item @@ -64,6 +66,11 @@ int menu_item_add(struct menu *m, char *item_key, void *item_data); int menu_default_set(struct menu *m, char *item_key); /* + * menu_default_choice() - Set *choice to point to the default item's data + */ +int menu_default_choice(struct menu *m, void **choice); + +/* * menu_get_choice() - Returns the user's selected menu entry, or the * default if the menu is set to not prompt or the timeout expires. */ diff --git a/doc/README.omap3 b/doc/README.omap3 index 0a37de0..1fbe79d 100644 --- a/doc/README.omap3 +++ b/doc/README.omap3 @@ -145,6 +145,34 @@ int omap3_dma_wait_for_transfer(uint32_t chan) int omap3_dma_get_revision(uint32_t *minor, uint32_t *major) Read silicon Revision of the DMA module +NAND +==== + +There are some OMAP3 devices out there with NAND attached. Due to the fact that +OMAP3 ROM code can only handle 1-bit hamming ECC for accessing first page +(place where SPL lives) we require this setup for u-boot at least when reading +the second progam within SPL. A lot of newer NAND chips however require more +than 1-bit ECC for the pages, some can live with 1-bit for the first page. To +handle this we can switch to another ECC algorithm after reading the payload +within SPL. + +BCH8 +---- + +To enable hardware assisted BCH8 (8-bit BCH [Bose, Chaudhuri, Hocquenghem]) on +OMAP3 devices we can use the BCH library in lib/bch.c. To do so add CONFIG_BCH +to enable the library and CONFIG_NAND_OMAP_BCH8 to to enable hardware assisted +syndrom generation to your board config. +The NAND OOB layout is the same as in linux kernel, if the linux kernel BCH8 +implementation for OMAP3 works for you so the u-boot version should also. +When you require the SPL to read with BCH8 there are two more configs to +change: + + * CONFIG_SYS_NAND_ECCPOS (must be the same as .eccpos in + GPMC_NAND_HW_BCH8_ECC_LAYOUT defined in + arch/arm/include/asm/arch-omap3/omap_gpmc.h) + * CONFIG_SYS_NAND_ECCSIZE must be 512 + * CONFIG_SYS_NAND_ECCBYTES must be 13 for this BCH8 setup Acknowledgements ================ diff --git a/doc/README.scrapyard b/doc/README.scrapyard index e9ca96c..2cdb8a9 100644 --- a/doc/README.scrapyard +++ b/doc/README.scrapyard @@ -11,6 +11,7 @@ easily if here is something they might want to dig for... Board Arch CPU Commit Removed Last known maintainer/contact ================================================================================================= +smdk6400 arm arm1176 - - Zhong Hongbo <bocui107@gmail.com> ns9750dev arm arm926ejs - - Markus Pietrek <mpietrek@fsforth.de> AMX860 powerpc mpc860 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de> c2mon powerpc mpc855 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de> @@ -90,3 +91,5 @@ MVS1 powerpc MPC823 306620b 2008-08-26 Andre Schwar adsvix ARM PXA27x 7610db1 2008-07-30 Adrian Filipi <adrian.filipi@eurotech.com> R5200 ColdFire - 48ead7a 2008-03-31 Zachary P. Landau <zachary.landau@labxtechnologies.com> CPCI440 powerpc 440GP b568fd2 2007-12-27 Matthias Fuchs <matthias.fuchs@esd-electronics.com> +PCIPPC2 powerpc MPC740/MPC750 7c9e89b 2013-02-07 Wolfgang Denk <wd@denx.de> +PCIPPC6 powerpc MPC740/MPC750 - - Wolfgang Denk <wd@denx.de> diff --git a/doc/README.silent b/doc/README.silent index 70202ce..6d90a0e 100644 --- a/doc/README.silent +++ b/doc/README.silent @@ -23,4 +23,6 @@ The following actions are taken if "silent" is set at boot time: - When booting a linux kernel, the "bootargs" are fixed up so that the argument "console=" will be in the command line, no matter how - it was set in "bootargs" before. + it was set in "bootargs" before. If you don't want the linux command + line to be affected, define CONFIG_SILENT_U_BOOT_ONLY in your board + config file as well, and this part of the feature will be disabled. diff --git a/doc/device-tree-bindings/exynos/tmu.txt b/doc/device-tree-bindings/exynos/tmu.txt new file mode 100644 index 0000000..89d3bf0 --- /dev/null +++ b/doc/device-tree-bindings/exynos/tmu.txt @@ -0,0 +1,44 @@ +Exynos Thermal management Unit + +Required properties: + + - compatible : Should be "samsung,exynos-tmu" for TMU + - samsung,min-temp : Minimum temperature value (25 degree celsius) + - Current temperature of SoC should be more than this value. + - samsung,max-temp : Maximum temperature value (125 degree celsius) + - Current temperature of SoC should be less than this value. + - samsung,start-warning : Temperature at which TMU starts giving warning (degree celsius) + - samsung,start-tripping : Temperature at which TMU shuts down the system (degree celsius) + - samsung,hw-tripping : Temperature at which hardware tripping should happen + in case TMU fails to power off (degree celsius) + - samsung,efuse-min-value : SOC efuse min value (Constant 40) + - efuse-value should be more than this value. + - samsung,efuse-value : SOC actual efuse value (Literal value) + - This is the data trimming info. + - This value is used to calculate measuring error. + - samsung,efuse-max-value : SoC max efuse value (Constant 100) + - efuse-value should be less than this value. + - samsung,slope : Default value 274761730 (Constant 0x1060_8802). + - This is the default value for TMU_CONTROL register. + - It sets the gain of amplifier to the positive-tc generator block. + - It selects thermal tripping mode and enables thermal tripping. + - samsung,dc-value : Measured data calibration value (Constant 25) + - Used for tempearture calculation. + - This is 25 because temperature measured is always above 25 degrees. + + +Example: + +tmu@10060000 { + compatible = "samsung,exynos-tmu" + samsung,min-temp = <25>; + samsung,max-temp = <125>; + samsung,start-warning = <95>; + samsung,start-tripping = <105>; + samsung,hw-tripping = <110>; + samsung,efuse-min-value = <40>; + samsung,efuse-value = <55>; + samsung,efuse-max-value = <100>; + samsung,slope = <274761730>; + samsung,dc-value = <25>; +}; diff --git a/doc/device-tree-bindings/video/exynos-dp.txt b/doc/device-tree-bindings/video/exynos-dp.txt new file mode 100644 index 0000000..464a853 --- /dev/null +++ b/doc/device-tree-bindings/video/exynos-dp.txt @@ -0,0 +1,69 @@ +Exynos Display port controller +============================== + +Required properties: +SOC specific: + compatible: should be "samsung,exynos5-dp" + reg: Base address of DP IP + +Optional properties: + samsung,h-res: X resolution of the panel + samsung,h-sync-width: hsync value + samsung,h-back-porch: left margin + samsung,h-front-porch right margin + samsung,v-res: Y resolution of the panel + samsung,v-sync-width: vsync value + samsung,v-back-porch: upper margin + samsung,v-front-porch: lower margin + samsung,v-sync-rate: refresh rate + + samsung,lt-status: Link training status + 0(DP_LT_NONE), 1(DP_LT_START), 2(DP_LT_CR), 3(DP_LT_ET), + 4(DP_LT_FINISHED), 5(DP_LT_FAIL) + + samsung,master-mode: 1 if you want to run DP as master, else 0 + samsung,bist-mode: 1 to enable video bist mode, else 0 + samsung,bist-pattern: bist mode pattern type + 0(NO_PATTERN), 1(COLOR_RAMP), 2(BALCK_WHITE_V_LINES), + 3(COLOR_SQUARE), 4(INVALID_PATTERN), 5(COLORBAR_32), + 6(COLORBAR_64),7(WHITE_GRAY_BALCKBAR_32), + 8(WHITE_GRAY_BALCKBAR_64),9(MOBILE_WHITEBAR_32), + 10(MOBILE_WHITEBAR_64) + samsung,h-sync-polarity: Horizontal Sync polarity + CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH + samsung,v-sync-polarity: Vertical Sync polarity + CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH + samsung,interlaced: Progressive if 0, else Interlaced + samsung,color-space: input video data format + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2 + samsung,dynamic-range: dynamic range for input video data + VESA = 0, CEA = 1 + samsung,ycbcr-coeff: YCbCr co-efficients for input video + COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1 + samsung,color-depth: number of bits per colour component + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3 + +Example: +SOC specific part: + dp@145b0000 { + compatible = "samsung,exynos5-dp"; + reg = <0x145b0000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + }; + +Board(panel) specific part: + dp@145b0000 { + samsung,lt-status = <0>; + + samsung,master-mode = <0>; + samsung,bist-mode = <0>; + samsung,bist-pattern = <0>; + samsung,h-sync-polarity = <0>; + samsung,v-sync-polarity = <0>; + samsung,interlaced = <0>; + samsung,color-space = <0>; + samsung,dynamic-range = <0>; + samsung,ycbcr-coeff = <0>; + samsung,color-depth = <1>; + }; diff --git a/doc/device-tree-bindings/video/exynos-fb.txt b/doc/device-tree-bindings/video/exynos-fb.txt new file mode 100644 index 0000000..bb7441c --- /dev/null +++ b/doc/device-tree-bindings/video/exynos-fb.txt @@ -0,0 +1,92 @@ +Exynos Display Controller +========================= +Required properties: +SOC specific: + compatible: should be "samsung,exynos-fimd" + reg: Base address of FIMD IP. + +Board(panel specific): + samsung,vl-col: X resolution of the panel + samsung,vl-row: Y resolution of the panel + samsung,vl-freq: Refresh rate + samsung,vl-bpix: Bits per pixel + samsung,vl-hspw: Hsync value + samsung,vl-hfpd: Right margin + samsung,vl-hbpd: Left margin + samsung,vl-vspw: Vsync value + samsung,vl-vfpd: Lower margin + samsung,vl-vbpd: Upper margin + +Optional properties: +Board(panel specific): + samsung,vl-width: width of display area in mm + samsung,vl-height: Height of display area in mm + + samsung,vl-clkp: Clock polarity + CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH + samsung,vl-oep: Output Enable polarity + CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH + samsung,vl-hsp: Horizontal Sync polarity + CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH + samsung,vl-vsp: Vertical Sync polarity + CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH + samsung,vl-dp: Data polarity + CONFIG_SYS_LOW if defined, else CONFIG_SYS_HIGH + + samsung,vl-cmd-allow-len: Wait end of frame + samsung,winid: Window number on which data is to be displayed + samsung,init-delay: Delay before LCD initialization starts + samsung,power-on-delay: Delay after LCD is powered on + samsung,reset-delay: Delay after LCD is reset + samsung,interface-mode: 1(FIMD_RGB_INTERFACE), 2(FIMD_CPU_INTERFACE) + samsung,mipi-enabled: 1 if you want to use MIPI, else 0 + samsung,dp-enabled: 1is you want to use DP, else 0 + samsung,cs-setup: cs_setup value in FIMD_CPU_INTERFACE mode. + samsung,wr-setup: wr_setup value in FIMD_CPU_INTERFACE mode. + samsung,wr-act: wr_act value in FIMD_CPU_INTERFACE mode. + samsung,wr-hold: wr_hold value in FIMD_CPU_INTERFACE mode. + samsung,logo-on: 1 if you want to use custom logo. + 0 if you want LCD console. + samsung,logo-width: pixel width of logo image. Valid if logo_on = 1 + samsung,logo-height: pixel height of logo image. Valid if logo_on = 1 + samsung,logo-addr: Address of logo image. Valid if logo_on = 1 + samsung,rgb-mode: 0(MODE_RGB_P), 1(MODE_BGR_P), + 2(MODE_RGB_S), 3(MODE_BGR_S) + samsung,pclk-name: parent clock identifier: 1(MPLL), 2(EPLL), 3(VPLL) + samsung,sclk-div: parent_clock/source_clock ratio + samsung,dual-lcd-enabled: 1 if you support two LCD, else 0 + +Example: +SOC specific part: + fimd@14400000 { + compatible = "samsung,exynos-fimd"; + reg = <0x14400000 0x10000>; + #address-cells = <1>; + #size-cells = <1>; + }; + +Board specific part: + fimd@14400000 { + samsung,vl-freq = <60>; + samsung,vl-col = <2560>; + samsung,vl-row = <1600>; + samsung,vl-width = <2560>; + samsung,vl-height = <1600>; + + samsung,vl-clkp; + samsung,vl-dp; + samsung,vl-bpix = <4>; + + samsung,vl-hspw = <32>; + samsung,vl-hbpd = <80>; + samsung,vl-hfpd = <48>; + samsung,vl-vspw = <6>; + samsung,vl-vbpd = <37>; + samsung,vl-vfpd = <3>; + samsung,vl-cmd-allow-len = <0xf>; + + samsung,winid = <3>; + samsung,interface-mode = <1>; + samsung,dp-enabled = <1>; + samsung,dual-lcd-enabled = <0>; + }; diff --git a/doc/driver-model/UDM-pci.txt b/doc/driver-model/UDM-pci.txt index b65e9ea..c2cf2d5 100644 --- a/doc/driver-model/UDM-pci.txt +++ b/doc/driver-model/UDM-pci.txt @@ -240,10 +240,6 @@ III) Analysis of in-tree drivers ---------------- Standard driver, uses indirect functions. - 8) pcippc2/cpc710_pci.c - ----------------------- - Standard driver, uses indirect functions, has two busses. - 9) Marvell/db64360/pci.c ------------------------ Standard driver, uses dword for read/write ops, has two busses. diff --git a/doc/driver-model/UDM-serial.txt b/doc/driver-model/UDM-serial.txt index ef71fea..1011c32 100644 --- a/doc/driver-model/UDM-serial.txt +++ b/doc/driver-model/UDM-serial.txt @@ -96,88 +96,84 @@ III) Analysis of in-tree drivers ------------------ No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 10) s3c64xx.c + 10) sandbox.c ------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 11) sandbox.c - ------------- - No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - - 12) serial.c + 11) serial.c ------------ This is a complementary part of NS16550 UART driver, see above. - 13) serial_clps7111.c + 12) serial_clps7111.c --------------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 14) serial_imx.c + 13) serial_imx.c ---------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. This driver might be removed in favor of serial_mxc.c . - 15) serial_ixp.c + 14) serial_ixp.c ---------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 16) serial_ks8695.c + 15) serial_ks8695.c ------------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 17) serial_max3100.c + 16) serial_max3100.c -------------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 18) serial_mxc.c + 17) serial_mxc.c ---------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 19) serial_netarm.c + 18) serial_netarm.c ------------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 20) serial_pl01x.c + 19) serial_pl01x.c ------------------ No support for CONFIG_SERIAL_MULTI. Simple conversion possible, though this driver in fact contains two drivers in total. - 21) serial_pxa.c + 20) serial_pxa.c ---------------- This driver is a bit complicated, but due to clean support for CONFIG_SERIAL_MULTI, there are no expected obstructions throughout the conversion process. - 22) serial_s3c24x0.c + 21) serial_s3c24x0.c -------------------- This driver, being quite ad-hoc might need some work to bring back to shape. - 23) serial_s3c44b0.c + 22) serial_s3c44b0.c -------------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 24) serial_s5p.c + 23) serial_s5p.c ---------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 25) serial_sa1100.c + 24) serial_sa1100.c ------------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 26) serial_sh.c + 25) serial_sh.c --------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 27) serial_xuartlite.c + 26) serial_xuartlite.c ---------------------- No support for CONFIG_SERIAL_MULTI. Simple conversion possible. - 28) usbtty.c + 27) usbtty.c ------------ This driver seems very complicated and entangled with USB framework. The conversion might be complicated here. - 29) arch/powerpc/cpu/mpc512x/serial.c + 28) arch/powerpc/cpu/mpc512x/serial.c ------------------------------------- This driver supports CONFIG_SERIAL_MULTI. This driver will need to be moved to proper place. diff --git a/doc/driver-model/UDM-watchdog.txt b/doc/driver-model/UDM-watchdog.txt index 271bd26..7db3286 100644 --- a/doc/driver-model/UDM-watchdog.txt +++ b/doc/driver-model/UDM-watchdog.txt @@ -292,11 +292,6 @@ III) Analysis of in-tree drivers Only function proxy call. Code cleanup needed. - 45) board/pcippc2/pcippc2.c - --------------------------- - The driver is standard HW watchdog. Simple conversion is possible. - - 46) board/pcs440ep/pcs440ep.c ----------------------------- The driver is standard HW watchdog. Simple conversion is possible. diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt index e04ba2d..ce72861 100644 --- a/doc/feature-removal-schedule.txt +++ b/doc/feature-removal-schedule.txt @@ -7,30 +7,47 @@ file. --------------------------- -What: Users of the legacy miiphy_* code -When: undetermined +What: Remove CONFIG_CMD_MEMTEST from default list +When: Release v2013.07 -Why: We now have a PHY library, which allows everyone to share PHY - drivers. All new drivers should use this infrastructure, and - all old drivers should get converted to use it. +Why: The "mtest" command is of little practical use (if any), and + experience has shown that a large number of board configu- + rations define useless or even dangerous start and end + addresses. If not even the board maintainers are able to + figure out which memory range can be reliably tested, how can + we expect such from the end users? As this problem comes up + repeatedly, we rather do not enable this command by default, + so only people who know what they are doing will be confronted + with it. -Who: Andy Fleming <afleming@freescale.com> and driver maintainers +Who: Wolfgang Denk <wd@denx.de> --------------------------- -What: boards with xxx_config targets in top level Makefile -When: Release v2012.03 +What: Remove CONFIG_SYS_ENABLE_PADS_ALL and CONFIG_SYS_CLOCKS_ENABLE_ALL +When: Release v2013.07 + +Why: When set these options enable "all" of the pads and clocks found + on OMAP4/5 platforms, so that the Linux Kernel does not have to. + It has been agreed that this goes against the U-Boot design + philosophy and since f3f98bb0 we have not enabled more than is + used in U-Boot. The kernel has been updating drivers to enable + rather than assume pads/clocks have been enabled already. Our + expectation is that by v2013.07 a suitable kernel shall exist that + does not need these options set for a reasonable I/O set to function. + +Who: Tom Rini <trini@ti.com> and Sricharan R <r.sricharan@ti.com> -Why: We have a boards.cfg file which the vast majority of boards have - converted over to. Boards that still manually run mkconfig in the - top level Makefile are either dead, or the maintainer doesn't care, - or they are doing something weird/wrong that should be fixed in a - different way, or they need to extend boards.cfg syntax (unlikely). +--------------------------- + +What: Users of the legacy miiphy_* code +When: undetermined - In any case, if no one cares about these boards to figure out how - to make boards.cfg work, then we'll just punt them. +Why: We now have a PHY library, which allows everyone to share PHY + drivers. All new drivers should use this infrastructure, and + all old drivers should get converted to use it. -Who: Mike Frysinger <vapier@gentoo.org> +Who: Andy Fleming <afleming@freescale.com> and driver maintainers --------------------------- |