Re: [U-Boot] [PATCH] env_sf: Fix recovery default
2015-03-24 8:59 GMT+01:00 Mario Schuknecht mario.schukne...@dresearch-fe.de:
The u-boot environment is redundantly stored in a NOR flash on our boards.
Redundant means that there are two places to store the environment. But only
one of the two is active. I discovered that on one board the u-boot (env_sf)
uses the environment from the second place and the Kernel (fw_printenv) uses
the environment from the first place.
To decide which is the active environment there is a byte inside the
environment. 1 means active and 0 means obsolete. But on that board both
environments had have a 1. This can happen if a power loss or reset occurs
during writing the environment. In this situation the u-boot (env_sf)
implementation uses the second environment as default. But the Kernel
(fw_printenv) implementation uses the first environment as default.
This commit corrects the default in the u-boot env_sf implementation when a
problem was detected. Now the recovery default is the same like in all other
environment implementations. E.g. fw_printenv and env_flash. This ensures that
u-boot and Kernel use the same environment.
Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de
---
common/env_sf.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/env_sf.c b/common/env_sf.c
index 5e3729c..e928f57 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -188,15 +188,17 @@ void env_relocate_spec(void)
tmp_env2-flags == ACTIVE_FLAG) {
gd-env_valid = 2;
} else if (tmp_env1-flags == tmp_env2-flags) {
- gd-env_valid = 2;
+ gd-env_valid = 1;
} else if (tmp_env1-flags == 0xFF) {
+ gd-env_valid = 1;
+ } else if (tmp_env2-flags == 0xFF) {
gd-env_valid = 2;
} else {
/*
* this differs from code in env_flash.c, but I think a sane
* default path is desirable.
*/
- gd-env_valid = 2;
+ gd-env_valid = 1;
}
if (gd-env_valid == 1)
--
2.1.4
Any comment, ACK or NAK?
The problem can be easily enforced by calling fw_setenv test abc and
immediatly pressing ctrl-c.
Regards
Mario
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_sf: Fix recovery default
The u-boot environment is redundantly stored in a NOR flash on our boards.
Redundant means that there are two places to store the environment. But only
one of the two is active. I discovered that on one board the u-boot (env_sf)
uses the environment from the second place and the Kernel (fw_printenv) uses
the environment from the first place.
To decide which is the active environment there is a byte inside the
environment. 1 means active and 0 means obsolete. But on that board both
environments had have a 1. This can happen if a power loss or reset occurs
during writing the environment. In this situation the u-boot (env_sf)
implementation uses the second environment as default. But the Kernel
(fw_printenv) implementation uses the first environment as default.
This commit corrects the default in the u-boot env_sf implementation when a
problem was detected. Now the recovery default is the same like in all other
environment implementations. E.g. fw_printenv and env_flash. This ensures that
u-boot and Kernel use the same environment.
Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de
---
common/env_sf.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/env_sf.c b/common/env_sf.c
index 5e3729c..e928f57 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -188,15 +188,17 @@ void env_relocate_spec(void)
tmp_env2-flags == ACTIVE_FLAG) {
gd-env_valid = 2;
} else if (tmp_env1-flags == tmp_env2-flags) {
- gd-env_valid = 2;
+ gd-env_valid = 1;
} else if (tmp_env1-flags == 0xFF) {
+ gd-env_valid = 1;
+ } else if (tmp_env2-flags == 0xFF) {
gd-env_valid = 2;
} else {
/*
* this differs from code in env_flash.c, but I think a sane
* default path is desirable.
*/
- gd-env_valid = 2;
+ gd-env_valid = 1;
}
if (gd-env_valid == 1)
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/6] ARM: kirkwood: mvebu_mmc: Speed up access time
2014-12-13 21:35 GMT+01:00 Gérald Kerma drea...@doukki.net: This serie of patches speed up access time of MVEBUMMC driver This is allowed by a fix in MVEBUMMC init status check inspired from linux MVSDIO driver. * Hardware weirdness. The FIFO_EMPTY bit of the HW_STATE * register is sometimes not set before a while when some * unusual data block sizes are used (such as with the SWITCH * command), even despite the fact that the XFER_DONE interrupt * was raised. And if another data transfer starts before * this bit comes to good sense (which eventually happens by * itself) then the new transfer simply fails with a timeout. It allows about 10x to 40x faster access time transfer on SHEEVAPLUG MMC It may also fixes some SD types incompatibilities ### before patch Marvell ext2load mmc 0:1 0x80 uImage 1613392 bytes read in 977 ms (1.6 MiB/s) ### with fix Marvell ext2load mmc 0:1 0x80 uImage 1613392 bytes read in 83 ms (18.5 MiB/s) Looks good to me. ACK to this series of patches: Gérald Kerma (6): MVEBUMMC : Change copyright date MVEBUMMC : Speed up access time MVEBUMMC : FIX debug strings MVEBUMMC : REMOVE unnecessary delays MVEBUMMC : CLEAN code MVEBUMMC : REMOVE unnecessary delay from init drivers/mmc/mvebu_mmc.c | 103 include/mvebu_mmc.h | 1 + 2 files changed, 61 insertions(+), 43 deletions(-) -- 2.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mvebu_mmc: Speed up access time
Remove udelay, because card status is polled in a loop. Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de --- drivers/mmc/mvebu_mmc.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/mmc/mvebu_mmc.c b/drivers/mmc/mvebu_mmc.c index 9f98c3f..2bf9444 100644 --- a/drivers/mmc/mvebu_mmc.c +++ b/drivers/mmc/mvebu_mmc.c @@ -72,8 +72,6 @@ static int mvebu_mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, debug(cmdidx [0x%x] resp_type[0x%x] cmdarg[0x%x]\n, cmd-cmdidx, cmd-resp_type, cmd-cmdarg); - udelay(10*1000); - debug(%s: cmd %d (hw state 0x%04x)\n, DRIVER_NAME, cmd-cmdidx, mvebu_mmc_read(SDIO_HW_STATE)); -- 1.8.4.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mmc: Fix mmc bus width
After setting the bus width, the extended CSD register is read. Some selected fields are compared with previously read extended CSD register fields. In this comparison the EXT_CSD_ERASE_GROUP_DEF field is compared. But this field is previously written under certain circumstances. And then the comparison fails. Only compare read-only fields. Therefore compare field EXT_CSD_HC_WP_GRP_SIZE instead of field EXT_CSD_ERASE_GROUP_DEF. Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de --- drivers/mmc/mmc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index a26f3ce..d1faa9f 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1127,10 +1127,11 @@ static int mmc_startup(struct mmc *mmc) mmc_set_bus_width(mmc, widths[idx]); err = mmc_send_ext_csd(mmc, test_csd); + /* Only compare read only fields */ if (!err ext_csd[EXT_CSD_PARTITIONING_SUPPORT] \ == test_csd[EXT_CSD_PARTITIONING_SUPPORT] - ext_csd[EXT_CSD_ERASE_GROUP_DEF] \ - == test_csd[EXT_CSD_ERASE_GROUP_DEF] \ + ext_csd[EXT_CSD_HC_WP_GRP_SIZE] \ + == test_csd[EXT_CSD_HC_WP_GRP_SIZE] \ ext_csd[EXT_CSD_REV] \ == test_csd[EXT_CSD_REV] ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] \ -- 1.8.4.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mvebu_mmc: Driver addition
Is there a chance that this patch [1] will be applied? Mario [1] http://lists.denx.de/pipermail/u-boot/2014-August/187109.html 2014-08-25 15:28 GMT+02:00 Stefan Roese s...@denx.de: On 25.08.2014 14:12, Mario Schuknecht wrote: In function mvebu_mmc_write notice command timeout. It is possible that a command is done, but a timeout occurred. Enable timeout in set bus function. Set window registers. Without that I could not use the driver on a Kirkwood 88F6282 SoC. Set high capacity and 52MHz driver feature. Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de Reviewed-by: Stefan Roese s...@denx.de Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mvebu_mmc: Driver addition
2014-08-25 11:55 GMT+02:00 Stefan Roese s...@denx.de:
On 24.08.2014 21:31, Mario Schuknecht wrote:
In function mvebu_mmc_write notice command timeout. It is possible that a
command is done, but a timeout occurred.
Enable timeout in set bus function.
Set window registers. Without that I could not use the driver on a
Kirkwood
88F6282 SoC.
Set high capacity and 52MHz driver feature.
Thanks. A few review comments below.
Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de
---
drivers/mmc/mvebu_mmc.c | 59 ++
++-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/mvebu_mmc.c b/drivers/mmc/mvebu_mmc.c
index 9759198..53754aa 100644
--- a/drivers/mmc/mvebu_mmc.c
+++ b/drivers/mmc/mvebu_mmc.c
@@ -17,8 +17,12 @@
#include asm/arch/kirkwood.h
#include mvebu_mmc.h
+DECLARE_GLOBAL_DATA_PTR;
+
#define DRIVER_NAME MVEBU_MMC
+#define MVEBU_TARGET_DRAM 0
+
static void mvebu_mmc_write(u32 offs, u32 val)
{
writel(val, CONFIG_SYS_MMC_BASE + (offs));
@@ -164,6 +168,9 @@ static int mvebu_mmc_send_cmd(struct mmc *mmc, struct
mmc_cmd *cmd,
return TIMEOUT;
}
}
+ if (mvebu_mmc_read(SDIO_ERR_INTR_STATUS)
+ (SDIO_ERR_CMD_TIMEOUT | SDIO_ERR_DATA_TIMEOUT))
+ return TIMEOUT;
/* Handling response */
if (cmd-resp_type MMC_RSP_136) {
@@ -271,6 +278,7 @@ static void mvebu_mmc_set_bus(unsigned int bus)
/* default to maximum timeout */
ctrl_reg |= SDIO_HOST_CTRL_TMOUT(SDIO_HOST_CTRL_TMOUT_MAX);
+ ctrl_reg |= SDIO_HOST_CTRL_TMOUT_EN;
ctrl_reg |= SDIO_HOST_CTRL_PUSH_PULL_EN;
@@ -296,6 +304,53 @@ static void mvebu_mmc_set_ios(struct mmc *mmc)
mvebu_mmc_set_clk(mmc-clock);
}
+/*
+ * Set window register.
+ */
+static void mvebu_window_setup(void)
+{
+ int i;
+
+for (i = 0; i 4; i++) {
+ mvebu_mmc_write(WINDOW_CTRL(i), 0);
+ mvebu_mmc_write(WINDOW_BASE(i), 0);
+}
Spaces instead of tabs for indentation. Please fix globally (checkpatch
clean)
A question. What is meant by Spaces instead of tabs for indentation?
In the whole file (and other files) tabs are used for indentation.
Should I create two patches. The first corrects all indentations (spaces
instead of tabs)
and the second contains the actual patch?
+ for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
+ u32 size, base, attrib;
+
+ /* Enable DRAM bank */
+ switch (i) {
+ case 0:
+ attrib = KWCPU_ATTR_DRAM_CS0;
+ break;
+ case 1:
+ attrib = KWCPU_ATTR_DRAM_CS1;
+ break;
+ case 2:
+ attrib = KWCPU_ATTR_DRAM_CS2;
+ break;
+ case 3:
+ attrib = KWCPU_ATTR_DRAM_CS3;
+ break;
+ default:
+ /* invalide bank, disable access */
+ attrib = 0;
+ break;
+ }
+
+ size = gd-bd-bi_dram[i].size;
+ base = gd-bd-bi_dram[i].start;
+ if ((size) (attrib))
size and attrib don't need parentheses here.
You're right.
+ mvebu_mmc_write(WINDOW_CTRL(i),
+ MVCPU_WIN_CTRL_DATA(size,
MVEBU_TARGET_DRAM,
+ attrib, MVCPU_WIN_ENABLE));
+ else
+ mvebu_mmc_write(WINDOW_CTRL(i),
MVCPU_WIN_DISABLE);
Please use correct coding style for multi-line statements. So this
should look like this:
if (size attrib) {
mvebu_mmc_write(WINDOW_CTRL(i),
MVCPU_WIN_CTRL_DATA(size, MVEBU_TARGET_DRAM,
attrib, MVCPU_WIN_ENABLE));
} else {
mvebu_mmc_write(WINDOW_CTRL(i), MVCPU_WIN_DISABLE);
}
Ok, I'll change that.
Regards,
Mario
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] mvebu_mmc: Driver addition
In function mvebu_mmc_write notice command timeout. It is possible that a
command is done, but a timeout occurred.
Enable timeout in set bus function.
Set window registers. Without that I could not use the driver on a Kirkwood
88F6282 SoC.
Set high capacity and 52MHz driver feature.
Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de
---
Changes in v2:
- Correct indentation
- Remove unneeded parentheses
- Use correct coding style for multi-line statements
drivers/mmc/mvebu_mmc.c | 62 -
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/mvebu_mmc.c b/drivers/mmc/mvebu_mmc.c
index 9759198..d34e743 100644
--- a/drivers/mmc/mvebu_mmc.c
+++ b/drivers/mmc/mvebu_mmc.c
@@ -17,8 +17,12 @@
#include asm/arch/kirkwood.h
#include mvebu_mmc.h
+DECLARE_GLOBAL_DATA_PTR;
+
#define DRIVER_NAME MVEBU_MMC
+#define MVEBU_TARGET_DRAM 0
+
static void mvebu_mmc_write(u32 offs, u32 val)
{
writel(val, CONFIG_SYS_MMC_BASE + (offs));
@@ -164,6 +168,9 @@ static int mvebu_mmc_send_cmd(struct mmc *mmc, struct
mmc_cmd *cmd,
return TIMEOUT;
}
}
+ if (mvebu_mmc_read(SDIO_ERR_INTR_STATUS)
+ (SDIO_ERR_CMD_TIMEOUT | SDIO_ERR_DATA_TIMEOUT))
+ return TIMEOUT;
/* Handling response */
if (cmd-resp_type MMC_RSP_136) {
@@ -271,6 +278,7 @@ static void mvebu_mmc_set_bus(unsigned int bus)
/* default to maximum timeout */
ctrl_reg |= SDIO_HOST_CTRL_TMOUT(SDIO_HOST_CTRL_TMOUT_MAX);
+ ctrl_reg |= SDIO_HOST_CTRL_TMOUT_EN;
ctrl_reg |= SDIO_HOST_CTRL_PUSH_PULL_EN;
@@ -296,6 +304,55 @@ static void mvebu_mmc_set_ios(struct mmc *mmc)
mvebu_mmc_set_clk(mmc-clock);
}
+/*
+ * Set window register.
+ */
+static void mvebu_window_setup(void)
+{
+ int i;
+
+ for (i = 0; i 4; i++) {
+ mvebu_mmc_write(WINDOW_CTRL(i), 0);
+ mvebu_mmc_write(WINDOW_BASE(i), 0);
+ }
+ for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
+ u32 size, base, attrib;
+
+ /* Enable DRAM bank */
+ switch (i) {
+ case 0:
+ attrib = KWCPU_ATTR_DRAM_CS0;
+ break;
+ case 1:
+ attrib = KWCPU_ATTR_DRAM_CS1;
+ break;
+ case 2:
+ attrib = KWCPU_ATTR_DRAM_CS2;
+ break;
+ case 3:
+ attrib = KWCPU_ATTR_DRAM_CS3;
+ break;
+ default:
+ /* invalide bank, disable access */
+ attrib = 0;
+ break;
+ }
+
+ size = gd-bd-bi_dram[i].size;
+ base = gd-bd-bi_dram[i].start;
+ if (size attrib) {
+ mvebu_mmc_write(WINDOW_CTRL(i),
+ MVCPU_WIN_CTRL_DATA(size,
+ MVEBU_TARGET_DRAM,
+ attrib,
+ MVCPU_WIN_ENABLE));
+ } else {
+ mvebu_mmc_write(WINDOW_CTRL(i), MVCPU_WIN_DISABLE);
+ }
+ mvebu_mmc_write(WINDOW_BASE(i), base);
+ }
+}
+
static int mvebu_mmc_initialize(struct mmc *mmc)
{
debug(%s: mvebu_mmc_initialize, DRIVER_NAME);
@@ -322,6 +379,8 @@ static int mvebu_mmc_initialize(struct mmc *mmc)
mvebu_mmc_write(SDIO_NOR_INTR_EN, 0);
mvebu_mmc_write(SDIO_ERR_INTR_EN, 0);
+ mvebu_window_setup();
+
/* SW reset */
mvebu_mmc_write(SDIO_SW_RESET, SDIO_SW_RESET_NOW);
@@ -342,7 +401,8 @@ static struct mmc_config mvebu_mmc_cfg = {
.f_min = MVEBU_MMC_BASE_FAST_CLOCK / MVEBU_MMC_BASE_DIV_MAX,
.f_max = MVEBU_MMC_CLOCKRATE_MAX,
.voltages = MMC_VDD_32_33 | MMC_VDD_33_34,
- .host_caps = MMC_MODE_4BIT | MMC_MODE_HS,
+ .host_caps = MMC_MODE_4BIT | MMC_MODE_HS | MMC_MODE_HC |
+ MMC_MODE_HS_52MHz,
.part_type = PART_TYPE_DOS,
.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
};
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mvebu_mmc: Driver addition
In function mvebu_mmc_write notice command timeout. It is possible that a
command is done, but a timeout occurred.
Enable timeout in set bus function.
Set window registers. Without that I could not use the driver on a Kirkwood
88F6282 SoC.
Set high capacity and 52MHz driver feature.
Signed-off-by: Mario Schuknecht mario.schukne...@dresearch-fe.de
---
drivers/mmc/mvebu_mmc.c | 59 -
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/mvebu_mmc.c b/drivers/mmc/mvebu_mmc.c
index 9759198..53754aa 100644
--- a/drivers/mmc/mvebu_mmc.c
+++ b/drivers/mmc/mvebu_mmc.c
@@ -17,8 +17,12 @@
#include asm/arch/kirkwood.h
#include mvebu_mmc.h
+DECLARE_GLOBAL_DATA_PTR;
+
#define DRIVER_NAME MVEBU_MMC
+#define MVEBU_TARGET_DRAM 0
+
static void mvebu_mmc_write(u32 offs, u32 val)
{
writel(val, CONFIG_SYS_MMC_BASE + (offs));
@@ -164,6 +168,9 @@ static int mvebu_mmc_send_cmd(struct mmc *mmc, struct
mmc_cmd *cmd,
return TIMEOUT;
}
}
+ if (mvebu_mmc_read(SDIO_ERR_INTR_STATUS)
+ (SDIO_ERR_CMD_TIMEOUT | SDIO_ERR_DATA_TIMEOUT))
+ return TIMEOUT;
/* Handling response */
if (cmd-resp_type MMC_RSP_136) {
@@ -271,6 +278,7 @@ static void mvebu_mmc_set_bus(unsigned int bus)
/* default to maximum timeout */
ctrl_reg |= SDIO_HOST_CTRL_TMOUT(SDIO_HOST_CTRL_TMOUT_MAX);
+ ctrl_reg |= SDIO_HOST_CTRL_TMOUT_EN;
ctrl_reg |= SDIO_HOST_CTRL_PUSH_PULL_EN;
@@ -296,6 +304,53 @@ static void mvebu_mmc_set_ios(struct mmc *mmc)
mvebu_mmc_set_clk(mmc-clock);
}
+/*
+ * Set window register.
+ */
+static void mvebu_window_setup(void)
+{
+ int i;
+
+for (i = 0; i 4; i++) {
+ mvebu_mmc_write(WINDOW_CTRL(i), 0);
+ mvebu_mmc_write(WINDOW_BASE(i), 0);
+}
+ for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
+ u32 size, base, attrib;
+
+ /* Enable DRAM bank */
+ switch (i) {
+ case 0:
+ attrib = KWCPU_ATTR_DRAM_CS0;
+ break;
+ case 1:
+ attrib = KWCPU_ATTR_DRAM_CS1;
+ break;
+ case 2:
+ attrib = KWCPU_ATTR_DRAM_CS2;
+ break;
+ case 3:
+ attrib = KWCPU_ATTR_DRAM_CS3;
+ break;
+ default:
+ /* invalide bank, disable access */
+ attrib = 0;
+ break;
+ }
+
+ size = gd-bd-bi_dram[i].size;
+ base = gd-bd-bi_dram[i].start;
+ if ((size) (attrib))
+ mvebu_mmc_write(WINDOW_CTRL(i),
+ MVCPU_WIN_CTRL_DATA(size, MVEBU_TARGET_DRAM,
+ attrib, MVCPU_WIN_ENABLE));
+ else
+ mvebu_mmc_write(WINDOW_CTRL(i), MVCPU_WIN_DISABLE);
+
+ mvebu_mmc_write(WINDOW_BASE(i), base);
+ }
+}
+
static int mvebu_mmc_initialize(struct mmc *mmc)
{
debug(%s: mvebu_mmc_initialize, DRIVER_NAME);
@@ -322,6 +377,8 @@ static int mvebu_mmc_initialize(struct mmc *mmc)
mvebu_mmc_write(SDIO_NOR_INTR_EN, 0);
mvebu_mmc_write(SDIO_ERR_INTR_EN, 0);
+ mvebu_window_setup();
+
/* SW reset */
mvebu_mmc_write(SDIO_SW_RESET, SDIO_SW_RESET_NOW);
@@ -342,7 +399,7 @@ static struct mmc_config mvebu_mmc_cfg = {
.f_min = MVEBU_MMC_BASE_FAST_CLOCK / MVEBU_MMC_BASE_DIV_MAX,
.f_max = MVEBU_MMC_CLOCKRATE_MAX,
.voltages = MMC_VDD_32_33 | MMC_VDD_33_34,
- .host_caps = MMC_MODE_4BIT | MMC_MODE_HS,
+ .host_caps = MMC_MODE_4BIT | MMC_MODE_HS | MMC_MODE_HC |
MMC_MODE_HS_52MHz,
.part_type = PART_TYPE_DOS,
.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT,
};
--
1.8.4.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] csb1724 88f6282
Hello, we want to use the marvell 88f6282 SoC in our products. For evaluation we use the cogent1724 board [1]. Does anyone have experience with the cogent csb1724 board [1] and the marvell 88f6282? I've searched the mainline u-boot sources, but found no config for the 88f6282. Is it possible to build a mainline u-boot for that SoC? If so, which config works? If not, is it planned to support the board and the marvell 88f6282 SoC? Kind regards, Mario Schuknecht [1] http://www.cogcomp.com/csb_csb1724.htm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] cfi_flash: use AMD fixups for AMIC (e.g. A29L160A series) too
Signed-off-by: Mario Schuknecht m.schukne...@dresearch.de
Signed-off-by: Steffen Sledz sl...@dresearch.de
---
drivers/mtd/cfi_flash.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index dd394a8..527a3a5 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1924,7 +1924,8 @@ ulong flash_get_size (phys_addr_t base, int banknum)
/* Do manufacturer-specific fixups */
switch (info-manufacturer_id) {
- case 0x0001:
+ case 0x0001: /* AMD */
+ case 0x0037: /* AMIC */
flash_fixup_amd(info, qry);
break;
case 0x001f:
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
