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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

Avoid calling directly into the MMC code - use the new API call instead.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This function is implemented by the legacy block functions now. Drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

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>

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>

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>

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>

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>

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>

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>

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>

"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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>