summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
* mmc: extend mmcinfo output to show partition write reliability settingsDiego Santa Cruz2015-01-19-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This extends the mmcinfo hardware partition info output to show partitions with write reliability enabled with the "WRREL" string. If the partition does not have write reliability enabled the "WRREL" string is omitted; this is analogous to the ehhanced attribute. Example output: Device: OMAP SD/MMC Manufacturer ID: fe OEM: 14e Name: MMC16 Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.41 High Capacity: Yes Capacity: 13.8 GiB Bus Width: 4-bit Erase Group Size: 8 MiB HC WP Group Size: 16 MiB User Capacity: 13.8 GiB ENH WRREL User Enhanced Start: 0 Bytes User Enhanced Size: 512 MiB Boot Capacity: 16 MiB ENH RPMB Capacity: 128 KiB ENH GP1 Capacity: 64 MiB ENH WRREL GP2 Capacity: 64 MiB ENH WRREL Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: extend the mmc hwpartition sub-command to change write reliabilityDiego Santa Cruz2015-01-19-24/+92
| | | | | | | | | This change extends the mmc hwpartition sub-command to change the per-partition write reliability settings. It also changes the syntax used for the enhanced user data area slightly to better accomodate the write reliability option. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: extend the mmc hardware partitioning API with write reliabilityDiego Santa Cruz2015-01-19-1/+51
| | | | | | | | | The eMMC partition write reliability settings are to be set while partitioning a device, as per the eMMC spec, so changes to these attributes needs to be done in the hardware partitioning API. This commit adds such support. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: add mmc hwpartition sub-command to do eMMC hardware partitioningDiego Santa Cruz2015-01-19-1/+92
| | | | | | | | | Adds the mmc hwpartition sub-command to perform eMMC hardware partitioning on an mmc device. The number of arguments can be large for a complex partitioning, but as the partitioning has to be done in one go it is difficult to make it simpler. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: add API to do eMMC hardware partitioningDiego Santa Cruz2015-01-19-0/+175
| | | | | | | | | | | | | | | | | | This adds an API to do hardware partitioning on eMMC devices. The new mmc_hwpart_config() function does the partitioning in one go. As the different attributes and partitioning options on eMMC may be interdependent validation has to be done based on the complete partitioning configuration. The function accepts three modes: - MMC_HWPART_CONF_CHECK: just validates that the configuration is valid. - MMC_HWPART_CONF_SET: validates and sets all the fields in EXT_CSD but without setting the "partitioning completed" bit, and thus is reversible. - MMC_HWPART_CONF_COMPLETE: does everything and is thus not reversible. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: the ext_csd data may be used during init even if reading failedDiego Santa Cruz2015-01-19-1/+3
| | | | | | | | | | The mmc_startup() function uses the ext_csd data even if reading it from the mmc device failed. This bug was introduced in commit bc897b1d4d86597311430dbe7b3e6c807c8c53e5. We now bail out if reading it fails, this should not be a problem as ext_csd was introduced in MMC 4.0 and this code is conditional on MMC >= 4.0. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: eMMC partitioning data is not effective till partitioning completedDiego Santa Cruz2015-01-19-23/+35
| | | | | | | | | | | | | | | | | The eMMC spec says that partitioning is only effective after the PARTITION_SETTING_COMPLETED is set in EXT_CSD (and a power cycle was done, but that we cannot know). Thus the partition sizes and attributes should be ignored when that bit is not set, otherwise the various capacities are not coherent (e.g., the user data capacity will be that of the unpartitioned device while partition sizes would be non-zero). Prescence of non-zero partitioning data is nevertheless still used to activate the high-capacity size definitions (EXT_CSD_ERASE_GROUP_DEF) as it is necessary to set that to write any of the partitioning fields in EXT_CSD, so having partitioning data means someone previously activated that and we should keep it activated. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: show the erase group size and HC WP group size in mmcinfo outputDiego Santa Cruz2015-01-19-0/+8
| | | | | | | | | This adds the erase group size and high-capacity WP group size to mmcinfo's output. The erase group size is necessary to properly align erase requests on eMMC. The high-capacity WP group size is necessary to properly align partitions on eMMC. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: read the high capacity WP group size for eMMCDiego Santa Cruz2015-01-19-0/+7
| | | | | | | | Read the eMMC high capacity write protect group size at mmc device initialization. This is useful to correctly partition an eMMC device, as partitions need to be aligned to this size. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: fix erase_grp_size computation with high-capacity size definitionDiego Santa Cruz2015-01-19-3/+2
| | | | | | | | | The erase_grp_size in struct mmc is to be a size in 512-byte sectors but the code used to compute it for eMMC when EXT_CSD_ERASE_GROUP_DEF is enabled computed it as bytes, leading to erase sizes and alignment much larger than what is actually required by the mmc device. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: display size and start of eMMC enhanced user data area in mmcinfoDiego Santa Cruz2015-01-19-3/+8
| | | | | | | This adds output to show the eMMC enhanced user data area size and offset along with the partition sizes in mmcinfo's output. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: read the size of eMMC enhanced user data areaDiego Santa Cruz2015-01-19-0/+19
| | | | | | | | This modification reads the size of the eMMC enhanced user data area upon initialization of an mmc device, it will be used later by mmcinfo. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: computation of eMMC GP partition size was missing 512 KiB factorDiego Santa Cruz2015-01-19-0/+1
| | | | Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: incomplete test to switch to high-capacity group size definitionsDiego Santa Cruz2015-01-19-22/+30
| | | | | | | | | | | | | | | | | The eMMC spec mandates that the high-capacity group size definitions should be enabled when the device is partitioned (by setting ERASE_GROUP_DEF in EXT_CSD). The current test to determine when this is required misses a few cases. In particular a device may have been partitioned without setting the enhanced attribute on any partition or partitioning may be completed without creating any extra partitions. This change moves the code to set ERASE_GROUP_DEF to after reading all partition information. It is also enabled when PARTITIONING_SETTING_COMPLETED is set as it is necessary to enable ERASE_GROUP_DEF before setting that bit, so it means that the user previously switched to the high capacity definitions. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: skip mmcinfo partition info processing for eMMC < 4.41Diego Santa Cruz2015-01-19-1/+1
| | | | | | | eMMC partitions are defined as of eMMC 4.41, but mmcinfo process partition info for eMMC >= 4.0, change it to do it for >= 4.41 Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: make eMMC general purpose partition numbering match specDiego Santa Cruz2015-01-19-1/+1
| | | | | | | | | The eMMC spec numbers general purpose partitions starting at 1, but the mmcinfo output follows the internal numbering which starts at 0. Make the mmcinfo command output number partitions as in the eMMC spec to avoid confusion. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: extend mmcinfo to show enhanced partition attributeDiego Santa Cruz2015-01-19-4/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | This extends the mmcinfo command's output to show which eMMC partitions have the enhanced attribute set. Note that the eMMC spec says that if the enhanced attribute is supported then the boot and RPMB partitions are of the enhanced type. The output of mmcinfo becomes: Device: OMAP SD/MMC Manufacturer ID: fe OEM: 14e Name: MMC16 Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.41 High Capacity: Yes Capacity: 13.8 GiB Bus Width: 4-bit User Capacity: 13.8 GiB ENH Boot Capacity: 16 MiB ENH RPMB Capacity: 128 KiB ENH GP1 Capacity: 64 MiB ENH GP2 Capacity: 64 MiB ENH Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com>
* mmc: show hardware partition sizes in mmcinfo outputDiego Santa Cruz2015-01-19-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is currently no command that will provide an overview of the hardware partitions present on an eMMC device, one has to switch to every partition via "mmc dev" and run mmcinfo for each to get the partition's capacity. This commit adds a few lines of output to mmcinfo with the sizes of the present partitions, like this: Device: OMAP SD/MMC Manufacturer ID: fe OEM: 14e Name: MMC16 Tran Speed: 52000000 Rd Block Len: 512 MMC version 4.41 High Capacity: Yes Capacity: 13.8 GiB Bus Width: 4-bit User Capacity: 13.8 GiB Boot Capacity: 16 MiB RPMB Capacity: 128 KiB GP1 Capacity: 64 MiB GP2 Capacity: 64 MiB panto: Minor edit removing superfluous parentheses. Signed-off-by: Diego Santa Cruz <Diego.SantaCruz@spinetix.com> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
* mmc: rmobile: Add SDHC support for Renesas rmobile ARM SoCNobuhiro Iwamatsu2015-01-19-0/+897
| | | | | | | | This adds Renesas rmobile ARM SoC's SD/MMC host support. This drivers tested with Gose board and Koelsch board. Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
* Merge branch 'master' of git://git.denx.de/u-boot-tiTom Rini2015-01-16-399/+579
|\
| * omap5: Add netargs and netboot optionCooper Jr., Franklin2015-01-13-1/+14
| | | | | | | | | | | | | | | | * Add netargs and netboot option. * This enables tftp and nfs booting * This puts omap5 devices inline with other devices such as am335x and am437x Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
| * arm: omap3: devkit8000: inherit from ti_omap3_common.hAnthoine Bourgeois2015-01-13-42/+16
| | | | | | | | Signed-off-by: Anthoine Bourgeois <anthoine.bourgeois@gmail.com>
| * arm: omap3: devkit8000: inherit from ti_armv7_common.hAnthoine Bourgeois2015-01-13-98/+36
| |
| * pcm051: Add boot script support to pcm051matwey.kornilov@gmail.com2015-01-13-11/+18
| | | | | | | | | | | | This patch adds boot script support to pcm051 Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
| * board: ti: am43xx: add support for AM43xx Industrial Development KitFelipe Balbi2015-01-13-19/+118
| | | | | | | | | | | | | | | | | | | | | | | | AM43xx Industrial Development Kit is a new board based on AM437x line of SoCs. Targetted at Industrial Automation applications, it comes with EtherCAT, motor control and other goodies. Thanks to James Doublesin for all the help. Cc: James Doublesin <doublesin@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * pmic: add tps62362 simple wrapper codeFelipe Balbi2015-01-13-0/+77
| | | | | | | | | | | | | | | | This regulator is used with AM437x IDK to feed VDD_MPU, without means to scale VDD_MPU we can't support higher frequencies. Signed-off-by: Felipe Balbi <balbi@ti.com>
| * board: ti: am43xx: take care of all OPPsFelipe Balbi2015-01-13-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure that all OPPs are checked on scale_vcores(). While at that also fix 600MHz VDD_MPU voltage according to AM437x Data Manual available at [1]. Table 5-3 on that document, lists all valid voltages per frequency. [1] http://www.ti.com/lit/ds/symlink/am4379.pdf Signed-off-by: Felipe Balbi <balbi@ti.com>
| * power: tps65218: define all valid VDD_MPU voltagesFelipe Balbi2015-01-13-0/+3
| | | | | | | | | | | | | | | | DCDC1 is used as VDD_MPU in all known boards, let's define all other valid voltages for that rail so it can be used by our boards. Signed-off-by: Felipe Balbi <balbi@ti.com>
| * board: ti: am43xx: replace if else if else with a switchFelipe Balbi2015-01-13-3/+6
| | | | | | | | | | | | | | | | A switch statement fits better in this case, specially considering we have a few extra frequencies to use. Signed-off-by: Felipe Balbi <balbi@ti.com>
| * arm: am437x: Correct PLL frequency for 25MHzJames Doublesin2015-01-13-1/+1
| | | | | | | | | | | | | | | | The frequencies for 25MHz in dpll_per were out of spec for 25MHz, correct. Signed-off-by: James Doublesin <doublesin@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * arm: am437x: Enable hardware leveling for EMIFJames Doublesin2015-01-13-207/+138
| | | | | | | | | | | | | | | | | | | | | | | | Switch to using hardware leveling for certain parameters on the EMIF rather than using precalculated values. Doing this also means we have a common place now between am437x and am335x for setting emif_sdram_ref_ctrl with a value for the correct delay length. Tested-by: Felipe Balbi <balbi@ti.com> Tested-by: Tom Rini <trini@ti.com> Signed-off-by: James Doublesin <doublesin@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
| * arm: am437x: PLL values for all input frequenciesJames Doublesin2015-01-13-26/+33
| | | | | | | | | | | | | | | | | | | | Need to provide PLL values for all possible input frequencies (19.2, 24, 25, 26MHz). Values provide are also optimized for jitter (needed especially for PER PLL and DDR PLL). Signed-off-by: James Doublesin <doublesin@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
| * mtd: OMAP: Enable GPMC prefetch modeDaniel Mack2015-01-13-3/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable GPMC's prefetch feature for NAND access. This speeds up NAND read access a lot by pre-fetching contents in the background and reading them through the FIFO address. The current implementation has two limitations: a) it only works in 8-bit mode b) it only supports read access Both is easily fixable by someone who has hardware to implement it. Note that U-Boot code uses non word-aligned buffers to read data into, and request read lengths that are not multiples of 4, so both partial buffers (head and tail) have to be addressed. Tested on AM335x hardware. Tested-by: Guido Martínez <guido@vanguardiasur.com.ar> Reviewed-by: Guido Martínez <guido@vanguardiasur.com.ar> Signed-off-by: Daniel Mack <zonque@gmail.com> [trini: Make apply again, use 'cs' fix pointed out by Guido] Signed-off-by: Tom Rini <trini@ti.com>
* | powerpc: 74xx_7xx: remove 74xx_7xx cpu supportMasahiro Yamada2015-01-16-18881/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | All the 74xx_7xx boards are still non-generic boards: P3G4, ZUMA, ppmc7xx, ELPPC, mpc7448hpc2 Acked-by: Marek Vasut <marex@denx.de> Acked-by: Stefan Roese <sr@denx.de> Acked-by: York Sun <yorksun@freescale.com> Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Nye Liu <nyet@zumanetworks.com> Cc: Roy Zang <tie-fei.zang@freescale.com>
* | mpc8xx: remove unused linker scriptMasahiro Yamada2015-01-16-82/+0
| | | | | | | | | | | | | | | | | | | | Now TQM8xx is the only remaining board family of mpc8xx. It uses its own linker script, board/tqc/tqm8xx/u-boot.lds. arch/powerpc/cpu/mpc8xx/u-boot.lds is not used by any boards. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Wolfgang Denk <wd@denx.de>
* | ppc4xx: remove dead codeMasahiro Yamada2015-01-16-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | Since commit 843125daebd7 (ppc4xx: remove HH405 board), CONFIG_HH405 is not defined. Since commit d52633047913 (ppc4xx: remove PMC405), CONFIG_PMC405 is not defined. Acked-by: Stefan Roese <sr@denx.de> Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Matthias Fuchs <matthias.fuchs@esd.eu>
* | Merge branch 'buildman' of git://git.denx.de/u-boot-x86Tom Rini2015-01-15-78/+606
|\ \
| * | buildman: Add an option to write the full build outputSimon Glass2015-01-14-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | Normally buildman runs with 'make -s' meaning that only errors and warnings appear in the log file. Add a -V option to run make in verbose mode, and with V=1, causing a full build log to be created. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | buildman: Add the option to download toolchains from kernel.orgSimon Glass2015-01-14-13/+303
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The site at https://www.kernel.org/pub/tools/crosstool/ is a convenient repository of toolchains which can be used for U-Boot. Add a feature to download and install a toolchain for a selected architecture automatically. It isn't clear how long this site will stay in the current place and format, but we should be able to rely on bug reports if it changes. Suggested-by: Marek Vašut <marex@denx.de> Suggested-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Simon Glass <sjg@chromium.org>
| * | buildman: Allow architecture to alias to multiple toolchainsSimon Glass2015-01-14-5/+23
| | | | | | | | | | | | | | | | | | | | | Some archs have need than one alias, so support a list of alises in the ..buildman file. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | buildman: Don't use the local settings when running testsSimon Glass2015-01-14-1/+14
| | | | | | | | | | | | | | | | | | | | | We should create a test setting file when running testes, not use whatever happens to be on the local machine. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | buildman: Don't complain about missing sections in ~/.buildmanSimon Glass2015-01-14-1/+0
| | | | | | | | | | | | | | | | | | Silently ignore this since it is valid to have missing sections. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | buildman: Add documentation about the .buildman fileSimon Glass2015-01-14-20/+53
| | | | | | | | | | | | | | | | | | | | | This file is only partially documented. Add some more details. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Wolfgang Denk <wd@denx.de>
| * | buildman: Add a note about Python pre-requisitesSimon Glass2015-01-14-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | Since we need a few modules which might not be available in a bare-bones distribution, add a note about that to the README. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Wolfgang Denk <wd@denx.de>
| * | buildman: Add an option to use the full tool chain pathSimon Glass2015-01-14-10/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some cases there may be multiple toolchains with the same name in the path. Provide an option to use the full path in the CROSS_COMPILE environment variable. Note: Wolfgang mentioned that this is dangerous since in some cases there may be other tools on the path that are needed. So this is set up as an option, not the default. I will need test confirmation (i.e. that this commit fixes a real problem) before merging it. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Steve Rae <srae@broadcom.com>
| * | buildman: Put the toolchain path first instead of last in PATHSimon Glass2015-01-14-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If: 1. Toolchains A and B have the same filename 2. Toolchain A is in the PATH 3. Toolchain B is given in ~/.buildman and buildman uses it to build then buildman will add toolchain B to the end of its path but will not necessarily use it since U-Boot will find toolchain A first in the PATH. Try to fix this by putting the toolchain first in the path instead of last. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | buildman: Try to avoid hard-coded string parsingSimon Glass2015-01-14-1/+8
| | | | | | | | | | | | | | | | | | | | | The assumption that the compiler name will always end in gcc is incorrect for clang and apparently on BSD. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | buildman: Allow specifying a range of commits to buildSimon Glass2015-01-14-9/+45
| | | | | | | | | | | | | | | | | | | | | | | | Adjust the -b flag to permit a range expression as well as a branch. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Tested-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
| * | buildman: Don't remove entire output directory when testingSimon Glass2015-01-14-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | When running tests the output directory is often wiped. This is only safe if a branch is being built. The output directory may contain other things besides the buildman test output. Signed-off-by: Simon Glass <sjg@chromium.org>
| * | buildman: Add an option to flatten output directory treesSimon Glass2015-01-14-6/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building current source for a single board, buildman puts the output in <output_dir>/current/current/<board>. Add an option to make it use <output_dir>/<board> instead. This removes the unnecessary directories in that case, controlled by the --no-subdirs/-N option. Suggested-by: Tom Rini <trini@ti.com> Signed-off-by: Simon Glass <sjg@chromium.org>
generated by cgit v1.1 at 2024-10-18 02:34:02 +0000