10 Jul, 2017
1 commit
-
* Add CONFIG_SYSTEM_RAMDISK_SUPPORT to support system's ramdisk
* Normal boot: cmdline to bypass ramdisk in boot.img,
but use Recovery boot: Use the ramdisk in boot.img
* commandline is larger than 512, system can't bootup sometime for commandline issue.
* support fastboot getvar.
* Support "fastboot erase" command for emmc device.
TODO: uboot community have api to operate flash, we can unify this part
* support "fastboot flash" even on damaged gptChange-Id: I080c25d6569d6cab56ff025601cd3b8df21cf3dd
11 Jan, 2017
1 commit
-
To maintain consistency, set_ios type of legacy mmc_ops changed to int.
Signed-off-by: Jaehoon Chung
01 Dec, 2016
2 commits
-
Add new configuration option CONFIG_MMC_TINY which strips away all
memory allocation within the MMC code and code for handling multiple
cards. This allows extremely space-constrained SPL code use the MMC
framework.Reviewed-by: Simon Glass
Signed-off-by: Marek Vasut
Cc: Tom Rini
Cc: Jaehoon Chung -
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: Tomas Melin
20 Sep, 2016
1 commit
-
Add function to read SD_STATUS information.
According to the information, get erase_timeout/erase_size/erase_offset.
Add a structure sd_ssr to include the erase related information.Signed-off-by: Peng Fan
Cc: Jaehoon Chung
Cc: Simon Glass
Cc: Bin Meng
Cc: Stefan Wahren
Cc: Clemens Gruber
Cc: Kever Yang
Cc: Eric Nelson
Cc: Stephen Warren
05 Aug, 2016
1 commit
-
Use the generic error number instead of specific error number.
If use the generic error number, it can debug more easier.Signed-off-by: Jaehoon Chung
Reviewed-by: Simon Glass
Reviewed-by: Minkyu Kang
31 Jul, 2016
1 commit
-
Not like the mmc-legacy which the devnum starts from 1, it starts from 0
in mmc-uclass, so the device number should be (devnum + 1) in get_mmc_num().Signed-off-by: Kever Yang
Acked-by: Simon Glass
Reviewed-by: Jaehoon Chung
12 Jul, 2016
1 commit
-
The driver model conversion for MMC has moved in small steps. The first step
was to have an MMC device (CONFIG_DM_MMC). The second was to use a child
block device (CONFIG_BLK). The final one is to use driver model for MMC
operations (CONFIG_DM_MMC_OP). Add support for this.The immediate priority is to make all boards that use DM_MMC also use those
other two options. This will allow them to be removed.Signed-off-by: Simon Glass
20 Jun, 2016
1 commit
-
Signed-off-by: Stefan Wahren
27 May, 2016
2 commits
-
All boards that use MMC define CONFIG_GENERIC_MMC now, so we can drop this
old code.Signed-off-by: Simon Glass
-
This function is no longer used.
Signed-off-by: Simon Glass
17 May, 2016
5 commits
-
Add support for enabling CONFIG_BLK with MMC. This involves changing a
few functions to use struct udevice and adding a MMC block device driver.Signed-off-by: Simon Glass
-
Binding an MMC device when CONFIG_BLK is enabled requires that a block
device be bound as a child of the MMC device. Add a function to do this.
The mmc_create() method will be used only when DM_BLK is disabled.Add an unbind method also.
Signed-off-by: Simon Glass
-
Update the existing drivers to set up this new pointer. This will be required
by the MMC uclass.Signed-off-by: Simon Glass
-
Avoid calling directly into the MMC code - use the new API call instead.
Signed-off-by: Simon Glass
-
The MMC block device is contained within struct mmc. But with driver model
this will not be the case. Add a function to obtain the block device. We
can later implement this for CONFIG_BLK.Signed-off-by: Simon Glass
15 Mar, 2016
1 commit
-
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: Simon Glass
Reviewed-by: Bin Meng
Tested-by: Stephen Warren
02 Feb, 2016
1 commit
-
This is a follow-up patch to e92029c0f4 and adds a prototype for
the weak mmc_get_env_dev function.Cc: Tom Rini
Cc: Stephen WarrenSigned-off-by: Clemens Gruber
Reviewed-by: Tom Rini
Reviewed-by: Peng Fan
14 Jan, 2016
1 commit
-
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: Stephen Warren
Reviewed-by: Tom Rini
13 Jan, 2016
1 commit
-
At present pci_mmc_init() does not correctly use the PCI function since the
list it passes is not terminated. The array size passed to pci_mmc_init() is
actually not used correctly. Fix this and adjust the pci_mmc_init() to scan
all available MMC devices.Adjust this code to use the new driver model PCI API.
This should move over to the new MMC uclass at some point.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
05 Jan, 2016
1 commit
-
Table 41 of the JEDEC standard for eMMC says that bit 31 of
the command argument is obsolete when issuing the ERASE
command (CMD38) on page 115 of this document:
http://www.jedec.org/sites/default/files/docs/jesd84-B45.pdfThe SD Card Association Physical Layer Simplified Specification also
makes no mention of the use of bit 31.
https://www.sdcard.org/downloads/pls/part1_410.pdfThe Linux kernel distinguishes between secure (bit 31 set) and
non-secure erase, and this patch copies the macro names from
include/linux/mmc/core.h.Tested-by: Fabio Estevam
Signed-off-by: Eric Nelson
Tested-by: Hector Palacios
22 Jul, 2015
1 commit
-
Add basic support for MMC, providing a uclass which can set up an MMC
device. This allows MMC drivers to move to using driver model.Signed-off-by: Simon Glass
05 May, 2015
4 commits
-
High capacity support is not a host capability, but a device capability
that is queried via the OCR. The flag in the operating conditions
request argument can just be set unconditionally. This matches the Linux
implementation.[panto] Hand merged and renumbering MMC_MODE_DDR_52MHz.
Signed-off-by: Rob Herring
Signed-off-by: Pantelis Antoniou
Cc: Pantelis Antoniou -
Starting part of device initialization sets the init_in_progress flag
only if the MMC card did not yet come to ready state and needs to continue
polling. If the card is SD or if the MMC card became ready quickly,
the flag is not set and (if using pre-initialization) the starting
phase will be re-executed from mmc_init function.Set the init_in_progress flag in all non-error cases. Also, move flags
setting statements around so that the flags are not set in error paths.
Also, IN_PROGRESS return status becomes unnecessary, so get rid of it.Signed-off-by: Andrew Gabbasov
-
The 'op_cond_response' field in mmc structure contains the response
from the last SEND_OP_COND MMC command while making iterational
polling of the card. Later it is copied to 'ocr' field, designed
to contain the OCR register value, which is actually the same
response from the same command. So, these fields have actually
the same data, just in different time periods. It's easier to use
the same 'ocr' field in both cases at once, without temporary using
of the 'op_cond_response' field.Signed-off-by: Andrew Gabbasov
-
The version flag constant name used in IS_MMC macro is incorrect/undefined.
Signed-off-by: Andrew Gabbasov
02 Mar, 2015
1 commit
24 Feb, 2015
1 commit
-
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: Pantelis Antoniou
Tested-by: Jaehoon Chung
Reported-by: Stephen Warren
Tested-by: Stephen Warren
23 Feb, 2015
1 commit
-
This adds support to switch to 1.8V in case CMD11 succeeds.
Signed-off-by: Otavio Salvador
Reviewed-by: Marek Vasut
07 Feb, 2015
1 commit
-
Since these board functions seem to be the same for all boards which use
FSP, move them into a common file. We can adjust this later if future FSPs
need more flexibility.This creates a generic PCI MMC device.
Signed-off-by: Simon Glass
Reviewed-by: Bin Meng
Tested-by: Bin Meng
19 Jan, 2015
7 commits
-
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 WRRELSigned-off-by: Diego Santa Cruz
-
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
-
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
-
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
-
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
-
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
-
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 ENHSigned-off-by: Diego Santa Cruz
13 Dec, 2014
3 commits
-
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: Andrew Gabbasov
-
Signed-off-by: Markus Niebel
Acked-by: Jaehoon Chung -
if the card claims to be high capacity and the card
is partitioned the capacity shall still be read from
ext_csd SEC_COUNT even if the resulting capacity is
smaller than 2 GiBSigned-off-by: Markus Niebel
Acked-by: Jaehoon Chung
