gmane.comp.boot-loaders.u-boot

Re: [PATCH] MMC: DWMMC: Fix FIFO_DEPTH calculation

Jaehoon Chung — 2013-05-24T01:42:54

It should be set into board-specific file(dw-mmc_exynos.c) or others.

Best Regards,
Jaehoon Chung

Re: Building two different "SPL" for the same board?

Henrik Nordström — 2013-05-24T01:14:08

tor 2013-05-23 klockan 16:39 -0400 skrev Tom Rini:


Got it integrated into the tree now and after config changes it could be
reduced to only a dummy (empty) start.c + linker script. The binary grew
by a few KB compared to the separate version, but still well within the
margin.

https://github.com/linux-sunxi/u-boot-sunxi/commit/79272ff764ee392d616feb02fb91c2dcaad42f04

Will show up for review in next round of submitting the sunxi changes.

Regards
Henrik

Re: [Patch v2 2/4] NET: macb: support sama5d3x devices

Bo Shen — 2013-05-24T01:11:27

Hi Andreas,

On 5/23/2013 14:51, Andreas Bießmann wrote:

OK, I will wait Joe to take these patches.
Thanks.


Best Regards,
Bo Shen

[PATCH v2] sf: winbond: Add support for W25PXX SPI flash

Kuo-Jung Su — 2013-05-24T01:09:49

From: Kuo-Jung Su <dantesu< at >faraday-tech.com>

Add support for Winbond's W25PXX SPI flash.
These devices is used on Faraday A369 evaluation board.

Signed-off-by: Kuo-Jung Su <dantesu< at >faraday-tech.com>
CC: Jagan Teki <jagannadh.teki< at >gmail.com>
CC: Tom Rini <trini< at >ti.com>
---
Changes for v2:
   - Update commit message header
   - Add commit message body

 drivers/mtd/spi/winbond.c |   17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index 2716209..2a27837 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
< at >< at > -18,6 +18,21 < at >< at > struct winbond_spi_flash_params {
 
 static const struct winbond_spi_flash_params winbond_spi_flash_table[] = {
 {
+.id= 0x2014,
+.nr_blocks= 16,
+.name= "W25P80",
+},
+{
+.id= 0x2015,
+.nr_blocks= 32,
+.name= "W25P16",
+},
+{
+.id= 0x2016,
+.nr_blocks= 64,
+.name= "W25P32",
+},
+{
 .id= 0x3013,
 .nr_blocks= 8,
 .name= "W25X40",
< at >< at > -104,7 +119,7 < at >< at > struct spi_flash *spi_flash_probe_winbond(struct spi_slave *spi, u8 *idcode)
 }
 
 flash->page_size = 256;
-flash->sector_size = 4096;
+flash->sector_size = (idcode[1] == 0x20) ? 65536 : 4096;
 flash->size = 4096 * 16 * params->nr_blocks;
 
 return flash;

Re: [PATCH] mtd: spi: winbond: add W25PXX support

Kuo-Jung Su — 2013-05-24T00:57:19

2013/5/23 Jagan Teki <jagannadh.teki< at >gmail.com>:

Sure, I'll re-format the patch and re-post again.


Thanks.
It's pretty helpful to me, because my English is really terrible. :)




--
Best wishes,
Kuo-Jung Su

Re: Please pull u-boot-cfi-flash/master

Tom Rini — 2013-05-24T00:29:11


Applied to u-boot/master, thanks!

[PATCH] mx6slevk: Allow booting a device tree kernel

Fabio Estevam — 2013-05-23T23:57:18

From: Fabio Estevam <fabio.estevam< at >freescale.com>

When the mx6slevk board support was added in U-boot there was no device tree
support for mx6sl, so only a FSL 3.0.35 was tested at that time.

Now that mx6slevk support is available we can boot a device tree kernel, by
adjusting CONFIG_LOADADDR into a proper location, so that a non-dt and a dt
kernels can be booted.

Signed-off-by: Fabio Estevam <fabio.estevam< at >freescale.com>
---
 include/configs/mx6slevk.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/mx6slevk.h b/include/configs/mx6slevk.h
index 8a94efd..19dcdd6 100644
--- a/include/configs/mx6slevk.h
+++ b/include/configs/mx6slevk.h
< at >< at > -59,7 +59,7 < at >< at >
 
 #define CONFIG_BOOTDELAY3
 
-#define CONFIG_LOADADDR0x80800000
+#define CONFIG_LOADADDR0x82000000
 #define CONFIG_SYS_TEXT_BASE0x87800000
 
 #define CONFIG_EXTRA_ENV_SETTINGS \

Re: [PATCH 4/5][v5] board/bsc9131rdb:Add NAND boot support using new SPL format

Andy Fleming — 2013-05-23T22:32:16



Nevermind. It looks like subsequent patches also conflict. I will apply the
patches in the requested order. :)

Andy
_______________________________________________
U-Boot mailing list
U-Boot< at >lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [PATCH V3 1/4] README: document CONFIG_ENV_IS_IN_MMC

Peter Korsgaard — 2013-05-23T22:32:15

 Stephen> On 05/23/2013 03:59 PM, Peter Korsgaard wrote:
 >>>>>>> "S" == Stephen Warren <swarren< at >wwwdotorg.org> writes:
 >> 
 Stephen> ...
 S> +  These two values are in units of bytes, but must be aligned to an
 S> +  MMC sector boundary.
 >> 
 >> s/to an/to a/

 Stephen> http://owl.english.purdue.edu/owl/resource/540/1/ disagrees
 Stephen> since the M starts with a vowel sound. See the "An MSDS ..."
 Stephen> example.

Ok, I'm not a native speaker.

Re: [PATCH 4/5][v5] board/bsc9131rdb:Add NAND boot support using new SPL format

Andy Fleming — 2013-05-23T22:27:56

On Tue, Apr 16, 2013 at 2:58 AM, Prabhakar Kushwaha <prabhakar< at >freescale.com



I'm currently applying your SYSCLK change which depends on this patch. As
soon as I've pushed that upstream, could you rebase this patch on the top
of my tree? That patch added the BSC9131RDB_NAND_SYSCLK100 target, which
doesn't make sense without the initial NAND target, so this patch should
now add that target in addition to the BSC9131RDB_NAND target.

I should be pushing them up later today.

Thanks,
Andy
_______________________________________________
U-Boot mailing list
U-Boot< at >lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[PATCH] ARM: tegra: only enable SCU on Tegra20

Stephen Warren — 2013-05-23T22:26:18

From: Tom Warren <twarren< at >nvidia.com>

The non-SPL build of U-Boot on Tegra only runs on a single CPU, and
hence there is no need to enable the SCU when running U-Boot. If an
SMP OS is booted, and it needs the SCU enabled, it will enable the SCU
itself. U-Boot doing so is redundant.

The one exception is Tegra20, where an enabled SCU is required for some
aspects of PCIe to work correctly.

Some Tegra SoCs contain CPUs without a software-controlled SCU. In this
case, attempting to turn it on actively causes problems. This is the case
for Tegra114. For example, when running Linux, the first (or at least
some very early) user-space process will trigger the following kernel
message:

Unhandled fault: imprecise external abort (0x406) at 0x00000000

This is typically accompanied by that process receving a fatal signal,
and exiting. Since this process is usually pid 1, this causes total
system boot failure.

Signed-off-by: Tom Warren <twarren< at >nvidia.com>
[swarren, fleshed out description, ported to upstream chipid APIs]
Signed-off-by: Stephen Warren <swarren< at >nvidia.com>
---
 arch/arm/cpu/tegra-common/ap.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/cpu/tegra-common/ap.c b/arch/arm/cpu/tegra-common/ap.c
index e099683..9e6d51d 100644
--- a/arch/arm/cpu/tegra-common/ap.c
+++ b/arch/arm/cpu/tegra-common/ap.c
< at >< at > -109,6 +109,10 < at >< at > static void enable_scu(void)
 struct scu_ctlr *scu = (struct scu_ctlr *)NV_PA_ARM_PERIPHBASE;
 u32 reg;
 
+/* Only enable the SCU on T20/T25 */
+if (tegra_get_chip() != CHIPID_TEGRA20)
+return;
+
 /* If SCU already setup/enabled, return */
 if (readl(&scu->scu_ctrl) & SCU_CTRL_ENABLE)
 return;

Re: [PATCH V3 1/4] README: document CONFIG_ENV_IS_IN_MMC

Stephen Warren — 2013-05-23T22:15:43

...

http://owl.english.purdue.edu/owl/resource/540/1/ disagrees since the M
starts with a vowel sound. See the "An MSDS ..." example.

Either way though is fine by me though I guess.

I assume Tom can fix that up when applying, so I don't need to spam the
list with another resend.

[PATCH] input: simplify key_matrix_decode_fdt()

Stephen Warren — 2013-05-23T22:09:57

From: Stephen Warren <swarren< at >nvidia.com>

We know the exact property names that the code wants to process. Look
these up directly with fdt_get_property(), rather than iterating over
all properties within the node, and checking each property's name, in
a convoluted fashion, against the expected name.

Signed-off-by: Stephen Warren <swarren< at >nvidia.com>
---
Note: This depends on my previous patch "input: fix unaligned access
in key_matrix_decode_fdt()". While to two patches could be squashed
together, I'd prefer them to go in separately, since the former is a
bug-fix that makes the original code work again on ARMv7 at least, and
this patch is an unrelated refactoring.
---
 drivers/input/key_matrix.c |   66 +++++++++++++++++---------------------------
 1 file changed, 26 insertions(+), 40 deletions(-)

diff --git a/drivers/input/key_matrix.c b/drivers/input/key_matrix.c
index c8b048e..ea05c77 100644
--- a/drivers/input/key_matrix.c
+++ b/drivers/input/key_matrix.c
< at >< at > -154,54 +154,40 < at >< at > static uchar *create_keymap(struct key_matrix *config, u32 *data, int len,
 return map;
 }
 
-int key_matrix_decode_fdt(struct key_matrix *config, const void *blob,
-  int node)
+int key_matrix_decode_fdt(struct key_matrix *config, const void *blob, int node)
 {
 const struct fdt_property *prop;
-static const char prefix[] = "linux,";
-int plen = sizeof(prefix) - 1;
-int offset;
-
-/* Check each property name for ones that we understand */
-for (offset = fdt_first_property_offset(blob, node);
-      offset > 0;
-      offset = fdt_next_property_offset(blob, offset)) {
-const char *name;
-int len;
-
-prop = fdt_get_property_by_offset(blob, offset, NULL);
-name = fdt_string(blob, fdt32_to_cpu(prop->nameoff));
-len = strlen(name);
-
-/* Name needs to match "1,<type>keymap" */
-debug("%s: property '%s'\n", __func__, name);
-if (strncmp(name, prefix, plen) ||
-len < plen + 6 ||
-strcmp(name + len - 6, "keymap"))
-continue;
+int proplen;
+uchar *plain_keycode;
 
-len -= plen + 6;
-if (len == 0) {
-config->plain_keycode = create_keymap(config,
-(u32 *)prop->data, fdt32_to_cpu(prop->len),
-KEY_FN, &config->fn_pos);
-} else if (0 == strncmp(name + plen, "fn-", len)) {
-config->fn_keycode = create_keymap(config,
-(u32 *)prop->data, fdt32_to_cpu(prop->len),
--1, NULL);
-} else {
-debug("%s: unrecognised property '%s'\n", __func__,
-      name);
-}
-}
-debug("%s: Decoded key maps %p, %p from fdt\n", __func__,
-      config->plain_keycode, config->fn_keycode);
+prop = fdt_get_property(blob, node, "linux,keymap", &proplen);
+/* Basic keymap is required */
+if (!prop)
+return -1;
 
+plain_keycode = create_keymap(config, (u32 *)prop->data,
+proplen, KEY_FN, &config->fn_pos);
+config->plain_keycode = plain_keycode;
+/* Conversion error -> fail */
+if (!config->plain_keycode)
+return -1;
+
+prop = fdt_get_property(blob, node, "linux,fn-keymap", &proplen);
+/* fn keymap is optional */
+if (!prop)
+goto done;
+
+config->fn_keycode = create_keymap(config, (u32 *)prop->data,
+proplen, -1, NULL);
+/* Conversion error -> fail */
 if (!config->plain_keycode) {
-debug("%s: cannot find keycode-plain map\n", __func__);
+free(plain_keycode);
 return -1;
 }
 
+done:
+debug("%s: Decoded key maps %p, %p from fdt\n", __func__,
+      config->plain_keycode, config->fn_keycode);
 return 0;
 }

Re: [PATCH V3 1/4] README: document CONFIG_ENV_IS_IN_MMC

Peter Korsgaard — 2013-05-23T21:59:04

 S> From: Stephen Warren <swarren< at >nvidia.com>
 S> Describe the meaning of CONFIG_ENV_IS_IN_MMC, and all related defines that
 S> must or can be set when using that option.

 S> Signed-off-by: Stephen Warren <swarren< at >nvidia.com>
 S> ---
 S> v3:
 S> * Mention that env size/offset are in bytes.
 S> * Fix typo; s/CONFIG_ENV_OFFSET/CONFIG_ENV_SIZE/ in one place.
 S> v2: New patch.
 S> ---
 S>  README |   40 ++++++++++++++++++++++++++++++++++++++++
 S>  1 file changed, 40 insertions(+)

 S> diff --git a/README b/README
 S> index 3012dcd..e7fedb8 100644
 S> --- a/README
 S> +++ b/README
 S> < at >< at > -3606,6 +3606,46 < at >< at > but it can not erase, write this NOR flash by SRIO or PCIE interface.
 S>    You will probably want to define these to avoid a really noisy system
 S>    when storing the env in UBI.
 
 S> +- CONFIG_ENV_IS_IN_MMC:
 S> +
 S> +Define this if you have an MMC device which you want to use for the
 S> +environment.
 S> +
 S> +- CONFIG_SYS_MMC_ENV_DEV:
 S> +
 S> +  Specifies which MMC device the environment is stored in.
 S> +
 S> +- CONFIG_SYS_MMC_ENV_PART (optional):
 S> +
 S> +  Specifies which MMC partition the environment is stored in. If not
 S> +  set, defaults to partition 0, the user area. Common values might be
 S> +  1 (first MMC boot partition), 2 (second MMC boot partition).
 S> +
 S> +- CONFIG_ENV_OFFSET:
 S> +- CONFIG_ENV_SIZE:
 S> +
 S> +  These two #defines specify the offset and size of the environment
 S> +  area within the specified MMC device.
 S> +
 S> +  These two values are in units of bytes, but must be aligned to an
 S> +  MMC sector boundary.

s/to an/t a/

Other than that:

Reviewed-by: Peter Korsgaard <jacmet< at >sunsite.dk>

Re: [Patch v2 2/4] NET: macb: support sama5d3x devices

Joe Hershberger — 2013-05-23T21:58:35

Hi,

On Thu, May 23, 2013 at 1:51 AM, Andreas Bießmann
<andreas.devel< at >googlemail.com> wrote:


Yes, I hope to be getting to patches assigned to me in patchwork in
the next week or so.

-Joe

Re: [PATCH 2/2] wandboard: Disable data cache

Fabio Estevam — 2013-05-23T21:15:29

Hi Wolfgang,

On Thu, May 23, 2013 at 6:12 PM, Wolfgang Denk <wd< at >denx.de> wrote:


Right, I should have marked this patch as RFC.

Anatolij kindly pointed me to a patch that solves the problem, so this
one can be discarded.

Regards,

Fabio Estevam

Re: [PATCH 2/2] wandboard: Disable data cache

Wolfgang Denk — 2013-05-23T21:12:58

Dear Fabio Estevam,

In message <1369331424-25835-2-git-send-email-fabio.estevam< at >freescale.com> you wrote:

Even without a proper fix this should not be done unconditionally.
Please do this only when you actually have to, i. e. when really using
the HDMI framebuffer in a system.  It's not a good idea to let all
others suffer from that.

Also, I wonder if we should issue a warning then (at build time).

Best regards,

Wolfgang Denk

Re: disassembler ?

Wolfgang Denk — 2013-05-23T21:09:57

Dear Brad Walker,

In message <CAPKZHbU1wKxJZ82O9v54Lct482o7MfcN4Yq_WniwL-TB8_-cGg< at >mail.gmail.com> you wrote:

I have no information what the target for your new processor might be;
there is such systems that go to basically a single big customer / a
single, highly specific use case, and there are those that are
intended for general use - the more use cases the better.  If you want
to make your system easy to use for a big grouyp of people, then make
sure that standard debug tools work.  Include JTAG, and make sure it
works with standard tools like the Abatron BDI2000/3000, Lauterbach
Trace32 and OpenOCD etc.


Well, without a working binut=ils you cannot build U-Boot anyway, so
you probably have to wait for that.


BedBug is strill there, because it was useful for some (at some point
of time), and it does not hurt to have it.  I think the actual number
of users is epsilon.


I'd recommend to save the efforts, and rather help the guys who are
working on binutils.  This is probably better invested time, then.

Best regards,

Wolfgang Denk

Re: disassembler ?

Peter Barada — 2013-05-23T20:56:49

If one was lucky maybe.  But who builds schedules around luck?  And yes,
Murphy's a mother...

I was assuming that through some black magic they could get into Bedbug
on reset and use it to inspect memory.  Of course this assumes that
Bedbug and u-boot don't collide, u-boot doesn't try to relocate itself
(or scribble over memory), all of which is extra development that a
JTAG[1] attached debugger would preclude.

A JTAG debugger would allow you to load code directly into memory and
then step through the processor initialization(or supply instructions on
the fly!), low-level startup development that everyone does on a new
processor.  Also by stepping you can see where/when the processor is
about to go off into the weeds many, many, many instructions _before_ it
munches any hope of postmortem debugging.  From experience bringing up
boards w/o JTAG is not only tedious but unpredictable and takes a
loooong time - the extra cost/effort of integrating JTAG (especially
since this is a spanking new processor!) is more than justified by it
reducing both total development time and overall schedule risk...

[1] I use JTAG to mean any industry standard hardware debug/access
method that allows arbitrary execution and inspection/modification of
registers/memory...

[PATCH V3 2/4] mmc: report capacity for the selectedpartition

Stephen Warren — 2013-05-23T20:51:45

From: Stephen Warren <swarren< at >nvidia.com>

Enhance the MMC core to calculate the size of each MMC partition, and
update mmc->capacity whenever a partition is selected. This causes:

mmc dev 0 1 ; mmcinfo

... to report the size of the currently selected partition, rather than
always reporting the size of the user partition.

Signed-off-by: Stephen Warren <swarren< at >nvidia.com>
---
v3: No change.
v2: No change.
---
 drivers/mmc/mmc.c |   68 +++++++++++++++++++++++++++++++++++++++++++++++------
 include/mmc.h     |    7 ++++++
 2 files changed, 68 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 0a2f535..31036f7 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
< at >< at > -700,16 +700,49 < at >< at > static int mmc_change_freq(struct mmc *mmc)
 return 0;
 }
 
+static int mmc_set_capacity(struct mmc *mmc, int part_num)
+{
+switch (part_num) {
+case 0:
+mmc->capacity = mmc->capacity_user;
+break;
+case 1:
+case 2:
+mmc->capacity = mmc->capacity_boot;
+break;
+case 3:
+mmc->capacity = mmc->capacity_rpmb;
+break;
+case 4:
+case 5:
+case 6:
+case 7:
+mmc->capacity = mmc->capacity_gp[part_num - 4];
+break;
+default:
+return -1;
+}
+
+mmc->block_dev.lba = lldiv(mmc->capacity, mmc->read_bl_len);
+
+return 0;
+}
+
 int mmc_switch_part(int dev_num, unsigned int part_num)
 {
 struct mmc *mmc = find_mmc_device(dev_num);
+int ret;
 
 if (!mmc)
 return -1;
 
-return mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
-  (mmc->part_config & ~PART_ACCESS_MASK)
-  | (part_num & PART_ACCESS_MASK));
+ret = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_PART_CONF,
+ (mmc->part_config & ~PART_ACCESS_MASK)
+ | (part_num & PART_ACCESS_MASK));
+if (ret)
+return ret;
+
+return mmc_set_capacity(mmc, part_num);
 }
 
 int mmc_getcd(struct mmc *mmc)
< at >< at > -917,7 +950,7 < at >< at > static void mmc_set_bus_width(struct mmc *mmc, uint width)
 
 static int mmc_startup(struct mmc *mmc)
 {
-int err;
+int err, i;
 uint mult, freq;
 u64 cmult, csize, capacity;
 struct mmc_cmd cmd;
< at >< at > -1035,8 +1068,12 < at >< at > static int mmc_startup(struct mmc *mmc)
 cmult = (mmc->csd[2] & 0x00038000) >> 15;
 }
 
-mmc->capacity = (csize + 1) << (cmult + 2);
-mmc->capacity *= mmc->read_bl_len;
+mmc->capacity_user = (csize + 1) << (cmult + 2);
+mmc->capacity_user *= mmc->read_bl_len;
+mmc->capacity_boot = 0;
+mmc->capacity_rpmb = 0;
+for (i = 0; i < 4; i++)
+mmc->capacity_gp[i] = 0;
 
 if (mmc->read_bl_len > MMC_MAX_BLOCK_LEN)
 mmc->read_bl_len = MMC_MAX_BLOCK_LEN;
< at >< at > -1075,7 +1112,7 < at >< at > static int mmc_startup(struct mmc *mmc)
 | ext_csd[EXT_CSD_SEC_CNT + 3] << 24;
 capacity *= MMC_MAX_BLOCK_LEN;
 if ((capacity >> 20) > 2 * 1024)
-mmc->capacity = capacity;
+mmc->capacity_user = capacity;
 }
 
 switch (ext_csd[EXT_CSD_REV]) {
< at >< at > -1117,8 +1154,25 < at >< at > static int mmc_startup(struct mmc *mmc)
 if ((ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & PART_SUPPORT) ||
     ext_csd[EXT_CSD_BOOT_MULT])
 mmc->part_config = ext_csd[EXT_CSD_PART_CONF];
+
+mmc->capacity_boot = ext_csd[EXT_CSD_BOOT_MULT] << 17;
+
+mmc->capacity_rpmb = ext_csd[EXT_CSD_RPMB_MULT] << 17;
+
+for (i = 0; i < 4; i++) {
+int idx = EXT_CSD_GP_SIZE_MULT + i * 3;
+mmc->capacity_gp[i] = (ext_csd[idx + 2] << 16) +
+(ext_csd[idx + 1] << 8) + ext_csd[idx];
+mmc->capacity_gp[i] *=
+ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE];
+mmc->capacity_gp[i] *= ext_csd[EXT_CSD_HC_WP_GRP_SIZE];
+}
 }
 
+err = mmc_set_capacity(mmc, mmc->part_num);
+if (err)
+return err;
+
 if (IS_SD(mmc))
 err = sd_change_freq(mmc);
 else
diff --git a/include/mmc.h b/include/mmc.h
index 566db59..ea198d8 100644
--- a/include/mmc.h
+++ b/include/mmc.h
< at >< at > -158,7 +158,9 < at >< at >
 /*
  * EXT_CSD fields
  */
+#define EXT_CSD_GP_SIZE_MULT143/* R/W */
 #define EXT_CSD_PARTITIONING_SUPPORT160/* RO */
+#define EXT_CSD_RPMB_MULT168/* RO */
 #define EXT_CSD_ERASE_GROUP_DEF175/* R/W */
 #define EXT_CSD_PART_CONF179/* R/W */
 #define EXT_CSD_BUS_WIDTH183/* R/W */
< at >< at > -166,6 +168,7 < at >< at >
 #define EXT_CSD_REV192/* RO */
 #define EXT_CSD_CARD_TYPE196/* RO */
 #define EXT_CSD_SEC_CNT212/* RO, 4 bytes */
+#define EXT_CSD_HC_WP_GRP_SIZE221/* RO */
 #define EXT_CSD_HC_ERASE_GRP_SIZE224/* RO */
 #define EXT_CSD_BOOT_MULT226/* RO */
 
< at >< at > -263,6 +266,10 < at >< at > struct mmc {
 uint write_bl_len;
 uint erase_grp_size;
 u64 capacity;
+u64 capacity_user;
+u64 capacity_boot;
+u64 capacity_rpmb;
+u64 capacity_gp[4];
 block_dev_desc_t block_dev;
 int (*send_cmd)(struct mmc *mmc,
 struct mmc_cmd *cmd, struct mmc_data *data);

[PATCH V3 1/4] README: document CONFIG_ENV_IS_IN_MMC

Stephen Warren — 2013-05-23T20:51:44

From: Stephen Warren <swarren< at >nvidia.com>

Describe the meaning of CONFIG_ENV_IS_IN_MMC, and all related defines that
must or can be set when using that option.

Signed-off-by: Stephen Warren <swarren< at >nvidia.com>
---
v3:
* Mention that env size/offset are in bytes.
* Fix typo; s/CONFIG_ENV_OFFSET/CONFIG_ENV_SIZE/ in one place.
v2: New patch.
---
 README |   40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/README b/README
index 3012dcd..e7fedb8 100644
--- a/README
+++ b/README
< at >< at > -3606,6 +3606,46 < at >< at > but it can not erase, write this NOR flash by SRIO or PCIE interface.
   You will probably want to define these to avoid a really noisy system
   when storing the env in UBI.
 
+- CONFIG_ENV_IS_IN_MMC:
+
+Define this if you have an MMC device which you want to use for the
+environment.
+
+- CONFIG_SYS_MMC_ENV_DEV:
+
+  Specifies which MMC device the environment is stored in.
+
+- CONFIG_SYS_MMC_ENV_PART (optional):
+
+  Specifies which MMC partition the environment is stored in. If not
+  set, defaults to partition 0, the user area. Common values might be
+  1 (first MMC boot partition), 2 (second MMC boot partition).
+
+- CONFIG_ENV_OFFSET:
+- CONFIG_ENV_SIZE:
+
+  These two #defines specify the offset and size of the environment
+  area within the specified MMC device.
+
+  These two values are in units of bytes, but must be aligned to an
+  MMC sector boundary.
+
+- CONFIG_ENV_OFFSET_REDUND (optional):
+
+  Specifies a second storage area, of CONFIG_ENV_SIZE size, used to
+  hold a redundant copy of the environment data. This provides a
+  valid backup copy in case the other copy is corrupted, e.g. due
+  to a power failure during a "saveenv" operation.
+
+  This value is also in units of bytes, but must also be aligned to
+  an MMC sector boundary.
+
+- CONFIG_ENV_SIZE_REDUND (optional):
+
+  This value need not be set, even when CONFIG_ENV_OFFSET_REDUND is
+  set. If this value is set, it must be set to the same value as
+  CONFIG_ENV_SIZE.
+
 - CONFIG_SYS_SPI_INIT_OFFSET
 
 Defines offset to the initial SPI buffer area in DPRAM. The