- 12 1月, 2018 5 次提交
-
-
由 Jean-Jacques Hiblot 提交于
hc_wp_grp_size is needed only if hardware partitionning is used. On ARM removing it saves about 30 bytes of code space. Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
-
由 Jean-Jacques Hiblot 提交于
Also remove erase_grp_size and write_bl_len from struct mmc as they are not used anymore. On ARM, removing them saves about 100 bytes of code space in SPL. Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
-
由 Jean-Jacques Hiblot 提交于
Not all boards have an eMMC and not all users have a need for this. Allow to compile it out. By default it is still included. Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
-
由 Jean-Jacques Hiblot 提交于
This is a useful information while debugging the initialization process or performance issues. Also dump this information with the other mmc info if the verbose option is selected Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com>
-
由 Jean-Jacques Hiblot 提交于
Display the mode name when the user execute 'mmc info'. Also instead of displaying tran_speed, display the actual bus speed. Signed-off-by: NJean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
- 15 9月, 2017 1 次提交
-
-
由 Bin Meng 提交于
All these places seem to inherit the codes from the MMC driver where a FIXME was put in the comment. However the correct operation after read should be cache invalidate, not flush. The underlying drivers should be responsible for the cache operation. Remove these codes completely. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NStefan Roese <sr@denx.de> Reviewed-by: NYork Sun <york.sun@nxp.com> Reviewed-by: NJoe Hershberger <joe.hershberger@ni.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Tested-by: NYork Sun <york.sun@nxp.com>
-
- 17 8月, 2017 1 次提交
-
-
由 Angelo Dureghello 提交于
This patch allows to show the EXT_CSD[179] partition_config register info, just by specifying the dev param: U-Boot> mmc partconf 0 EXT_CSD[179], PARTITION_CONFIG: BOOT_ACK: 0x0 BOOT_PARTITION_ENABLE: 0x0 PARTITION_ACCESS: 0x0 Signed-off-by: NAngelo Dureghello <angelo@sysam.it> Signed-off-by: NAnatolij Gustschin <agust@denx.de>
-
- 19 7月, 2017 1 次提交
-
-
由 Kever Yang 提交于
When CONFIG_BLK is enabled, the hwpart id is different with legacy interface, update it to kame driver work with CONFIG_BLK. Signed-off-by: NKever Yang <kever.yang@rock-chips.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
-
- 13 4月, 2017 1 次提交
-
-
由 Markus Niebel 提交于
The handler do_setdsr receives only the dsr parameter, the action is parsed before. Error was introduced when restructuring the mmc command implementation in commit 1fd93c6e. Reported-by: NMichael Krummsdorf <Michael.Krummsdorf@tq-group.com> Signed-off-by: NMarkus Niebel <Markus.Niebel@tq-group.com>
-
- 01 12月, 2016 1 次提交
-
-
由 Tomas Melin 提交于
Add new command that provides possibility to enable the background operations handshake functionality (BKOPS_EN, EXT_CSD byte [163]) on eMMC devices. This is an optional feature of eMMCs, the setting is write-once. The command must be explicitly taken into use with CONFIG_CMD_BKOPS_ENABLE. Signed-off-by: NTomas Melin <tomas.melin@vaisala.com>
-
- 27 5月, 2016 1 次提交
-
-
由 Simon Glass 提交于
All boards that use MMC define CONFIG_GENERIC_MMC now, so we can drop this old code. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 17 5月, 2016 3 次提交
-
-
由 Simon Glass 提交于
At present the MMC subsystem maintains its own list of MMC devices. This cannot work with driver model, which needs to maintain this itself. Move the list code into a separate 'legacy' file. The core MMC code remains, and will be shared with the driver-model implementation. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Avoid calling directly into the MMC code - use the new API call instead. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
This function is implemented by the legacy block functions now. Drop it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 06 5月, 2016 1 次提交
-
-
由 Marek Vasut 提交于
Since we do not build any board with CONFIG_SUPPORT_EMMC_RPMB , this piece of code evaded conversion. Fix the following compiler error: cmd/mmc.c: In function 'do_mmcrpmb': cmd/mmc.c:316:32: error: 'struct blk_desc' has no member named 'part_num' original_part = mmc->block_dev.part_num; ^ Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: Tom Rini <trini@konsulko.com>
-
- 02 4月, 2016 1 次提交
-
-
由 Eric Nelson 提交于
Call blk_dread, blk_dwrite, blk_derase to ensure that the block cache is used if enabled and to remove build breakage when CONFIG_BLK is enabled. Signed-off-by: NEric Nelson <eric@nelint.com> Reviewed-by: NTom Rini <trini@konsulko.com>
-
- 15 3月, 2016 2 次提交
-
-
由 Simon Glass 提交于
Rename three partition functions so that they start with part_. This makes it clear what they relate to. Signed-off-by: NSimon Glass <sjg@chromium.org> Tested-by: NStephen Warren <swarren@nvidia.com>
-
由 Simon Glass 提交于
Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long and causes 80-column violations, rename it to struct blk_desc. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Tested-by: NStephen Warren <swarren@nvidia.com>
-
- 25 1月, 2016 2 次提交
-
-
由 Simon Glass 提交于
Now that they are in their own directory, we can remove this prefix. This makes it easier to find a file since the prefix does not get in the way. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NHeiko Schocher <hs@denx.de> Acked-by: NStefan Roese <sr@denx.de> Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
-
由 Simon Glass 提交于
There are a lot of unrelated files in common, including all of the commands. Moving them into their own directory makes them easier to find and is more logical. Some commands include non-command code, such as cmd_scsi.c. This should be sorted out at some point so that the function can be enabled with or without the associated command. Unfortunately, with m68k I get this error: m68k: + M5329AFEE +arch/m68k/cpu/mcf532x/start.o: In function `_start': +arch/m68k/cpu/mcf532x/start.S:159:(.text+0x452): relocation truncated to fit: R_68K_PC16 against symbol `board_init_f' defined in .text.board_init_f section in common/built-in.o I hope someone can shed some light on what this means. I hope it isn't depending on the position of code in the image. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NHeiko Schocher <hs@denx.de> Acked-by: NStefan Roese <sr@denx.de> Acked-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
-
- 14 1月, 2016 2 次提交
-
-
由 Stephen Warren 提交于
This will allow us to have multiple block device structs each referring to the same eMMC device, yet different HW partitions. For now, there is still a single block device per eMMC device. As before, this block device always accesses whichever HW partition was most recently selected. Clients wishing to make use of multiple block devices referring to different HW partitions can simply take a copy of this block device once it points at the correct HW partition, and use each one as they wish. This feature will be used by the next patch. In the future, perhaps get_device() could be enhanced to return a dynamically allocated block device struct, to avoid the client needing to copy it in order to maintain multiple block devices. However, this would require all users to be updated to free those block device structs at some point, which is rather a large change. Most callers of mmc_switch_part() wish to permanently switch the default MMC block device's HW partition. Enhance mmc_switch_part() so that it does this. This removes the need for callers to do this. However, common/env_mmc.c needs to save and restore the current HW partition. Make it do this more explicitly. Replace use of mmc_switch_part() with mmc_select_hwpart() in order to remove duplicate code that skips the call if that HW partition is already selected. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NTom Rini <trini@konsulko.com>
-
由 Stephen Warren 提交于
This will allow the implementation to make use of data in the block_dev structure beyond the base device number. This will be useful so that eMMC block devices can encompass the HW partition ID rather than treating this out-of-band. Equally, the existence of the priv field is crying out for this patch to exist. Signed-off-by: NStephen Warren <swarren@nvidia.com> Reviewed-by: NTom Rini <trini@konsulko.com>
-
- 06 12月, 2015 1 次提交
-
-
由 Peng Fan 提交于
"enable" is unsigned char type and its value will not be negative, so discard "enable < 0". Signed-off-by: NPeng Fan <Peng.Fan@freescale.com> Cc: Diego Santa Cruz <Diego.SantaCruz@spinetix.com> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Cc: Andrew Gabbasov <andrew_gabbasov@mentor.com> Cc: Simon Glass <sjg@chromium.org> Cc: Stefano Babic <sbabic@denx.de> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
- 20 11月, 2015 1 次提交
-
-
由 Simon Glass 提交于
The console includes a global variable and several functions that are only used by a small subset of U-Boot files. Before adding more functions, move the definitions into their own header file. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 24 2月, 2015 1 次提交
-
-
由 Pantelis Antoniou 提交于
The SD/MMC version scheme was buggy when dealing with standard major.minor.change cases. Fix it by using something similar to the linux's kernel versioning method. Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com> Tested-by: NJaehoon Chung <jh80.chung@samsung.com> Reported-by: NStephen Warren <swarren@nvidia.com> Tested-by: NStephen Warren <swarren@nvidia.com>
-
- 19 1月, 2015 9 次提交
-
-
由 Diego Santa Cruz 提交于
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: NDiego Santa Cruz <Diego.SantaCruz@spinetix.com>
-
由 Diego Santa Cruz 提交于
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: NDiego Santa Cruz <Diego.SantaCruz@spinetix.com>
-
由 Diego Santa Cruz 提交于
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: NDiego Santa Cruz <Diego.SantaCruz@spinetix.com>
-
由 Diego Santa Cruz 提交于
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: NDiego Santa Cruz <Diego.SantaCruz@spinetix.com>
-
由 Diego Santa Cruz 提交于
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: NDiego Santa Cruz <Diego.SantaCruz@spinetix.com>
-
由 Diego Santa Cruz 提交于
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: NDiego Santa Cruz <Diego.SantaCruz@spinetix.com>
-
由 Diego Santa Cruz 提交于
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: NDiego Santa Cruz <Diego.SantaCruz@spinetix.com>
-
由 Diego Santa Cruz 提交于
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: NDiego Santa Cruz <Diego.SantaCruz@spinetix.com>
-
由 Diego Santa Cruz 提交于
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: NDiego Santa Cruz <Diego.SantaCruz@spinetix.com> Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com>
-
- 13 12月, 2014 1 次提交
-
-
由 Andrew Gabbasov 提交于
If the MMC_MODE_DDR_52MHz flag is set in card capabilities bitmask, it is never cleared, even if switching to DDR mode fails, and if the controller driver uses this flag to check the DDR mode, it can take incorrect actions. Also, DDR related checks in mmc_startup() incorrectly handle the case when the host controller does not support some bus widths (e.g. can't support 8 bits), since the host_caps is checked for DDR bit, but not bus width bits. This fix clearly separates using of card_caps bitmask, having there the flags for the capabilities, that the card can support, and actual operation mode, described outside of card_caps (i.e. bus_width and ddr_mode fields in mmc structure). Separate host controller drivers may need to be updated to use the actual flags. Respectively, the capabilities checks in mmc_startup are made more correct and clear. Also, some clean up is made with errors handling and code syntax layout. Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
-
- 03 10月, 2014 1 次提交
-
-
由 Wally Yeh 提交于
sub-command 'bootpart-resize' check for argc == 4, it will retrun CMD_RET_FAILURE when argc value not matched. but bootpart-resize's maxarg is 3, which means you never execute this sub-command successfully. fix it by change bootpart-resize maxarg to 4. Signed-off-by: Nwally.yeh <wally.yeh@atrustcorp.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Pierre Aubert <p.aubert@staubli.com> Acked-by: NPantelis Antoniou <panto@antoniou-consulting.com>
-
- 12 6月, 2014 4 次提交
-
-
由 Stephen Warren 提交于
Currently, U-Boot behaves as follows: - Begin with no SD card inserted in "mmc 1" - Execute: mmc dev 1 - This fails, since there is no card - User plugs in an SD card - Execute: mmc dev 1 - This still fails, since the HW isn't reprobed. With this change, U-Boot behaves as follows: - Begin with no SD card inserted in "mmc 1" - Execute: mmc dev 1 - This fails, since there is no card - User plugs in an SD card - Execute: mmc dev 1 - The newly present SD card is detected I know that "mmc rescan" will force the HW to be reprobed, but I feel it makes more sense if "mmc dev" always reprobes the HW after selecting the current MMC device. This allows scripts to just execute "mmc dev", and not have to also execute "mmc rescan" to check for media presense. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NPantelis Antoniou <panto@antoniou-consulting.com>
-
由 Stephen Warren 提交于
The body of init_mmc_device() is now identical to that of do_mmc_rescan() except for the error codes returned. Modify do_mmc_rescan() to simply call init_mmc_device() and convert the error codes, to avoid code duplication. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NPantelis Antoniou <panto@antoniou-consulting.com>
-
由 Stephen Warren 提交于
This allows callers to inject mmc->has_init = 0 between finding the MMC device, and calling mmc_init(), which forces mmc_init() to rescan the HW. Future changes will use this feature. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NJaehoon Chung <jh80.chung@samsung.com> Acked-by: NPantelis Antoniou <panto@antoniou-consulting.com>
-
由 Stephen Warren 提交于
Currently, "mmc dev 0" does not change the selected HW partition. I think it makes more sense if "mmc dev 0" is an alias for "mmc dev 0 0", i.e. that HW partition 0 (main data area) is always selected by default if the user didn't request a specific partition. Otherwise, the following happens, which feels wrong: Select HW partition 1 (boot0): mmc dev 0 1 Doesn't change the HW partition, so it's still 1 (boot0): mmc dev 0 With this patch, the second command above re-selects the main data area. Note that some MMC devices (i.e. SD cards) don't support HW partitions. However, this patch still works, since mmc_start_init() sets the current partition number to 0, and mmc_select_hwpart() succeeds if the requested partition is already selected. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NPantelis Antoniou <panto@antoniou-consulting.com>
-