Re: [U-Boot] [PATCH V2 0/2] add sdhci generic framework
Hi Vadim, The quirk is standing for some workaround for those host that has some limitation that it cannot directly be applied with standard sdhci.c code, so that we add one quirk for it, which let it could use the sdhci.c. Like the quirk as SDHCI_QUIRK_32BIT_DMA_ADDR, it indicate that some host has dma engine limitation that it must start from address with alignement. So if sdhci find caller set this quirk, it would follow corresponding workaround for it. There is no formal description for it as I could see. Thanks, Lei > -Original Message- > From: vben...@gmail.com [mailto:vben...@gmail.com] On Behalf Of Vadim > Bendebury > Sent: Tuesday, October 15, 2013 10:09 AM > To: Lei Wen > Cc: Prafulla Wadaskar; aflem...@gmail.com; Rob Herring; u- > b...@lists.denx.de; Yu Tang; Prabhanjan Sarnaik; Ashish Karkare; Andy > Fleming > Subject: Re: [U-Boot] [PATCH V2 0/2] add sdhci generic framework > > Hello Lei, > > I am looking into adding eMMC support for some intel SDHCI controllers > based on this common SDHCI driver submission. > > One thing which is not quite clear is the quirks - can you (or somebody > else on this list) please shed some light on what the quirks are. Is > there some kind of formal description/definition of various defined > quirks and their processing. > > Thank you in advance, > > --vb > > > On Wed, Jun 29, 2011 at 12:50 AM, Lei Wen wrote: > > V1: > > add sdhci generic framework and with marvell sdhci implementation > > > > V2: > > rename the previous file name from sdhci-mv to mv_sdhci > > > > Lei Wen (2): > > MMC: add sdhci generic framework > > MMC: add marvell sdhci driver > > > > drivers/mmc/Makefile |2 + > > drivers/mmc/mv_sdhci.c | 21 +++ > > drivers/mmc/sdhci.c| 433 > > > include/sdhci.h| 325 > > 4 files changed, 781 insertions(+), 0 deletions(-) create mode > > 100644 drivers/mmc/mv_sdhci.c create mode 100644 drivers/mmc/sdhci.c > > create mode 100644 include/sdhci.h > > > > ___ > > 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 V2 5/6] lib: add gzip lib function callback
Signed-off-by: Lei Wen
---
Changelog:
No change
include/common.h |7 +++
lib/Makefile |1 +
lib/gzip.c | 142 ++
3 files changed, 150 insertions(+), 0 deletions(-)
create mode 100644 lib/gzip.c
diff --git a/include/common.h b/include/common.h
index 55025c0..a7fb05e 100644
--- a/include/common.h
+++ b/include/common.h
@@ -829,6 +829,13 @@ void fputc(int file, const char c);
intftstc(int file);
intfgetc(int file);
+/* lib/gzip.c */
+int gzip(void *dst, unsigned long *lenp,
+ unsigned char *src, unsigned long srclen);
+int zzip(void *dst, unsigned long *lenp, unsigned char *src,
+ unsigned long srclen, int stoponerr,
+ int (*func)(unsigned long, unsigned long));
+
/* lib/net_utils.c */
#include
static inline IPaddr_t getenv_IPaddr(char *var)
diff --git a/lib/Makefile b/lib/Makefile
index c60c380..45798de 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -42,6 +42,7 @@ COBJS-y += errno.o
COBJS-$(CONFIG_OF_CONTROL) += fdtdec.o
COBJS-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o
COBJS-$(CONFIG_GZIP) += gunzip.o
+COBJS-$(CONFIG_GZIP_COMPRESSED) += gzip.o
COBJS-y += hashtable.o
COBJS-$(CONFIG_LMB) += lmb.o
COBJS-y += ldiv.o
diff --git a/lib/gzip.c b/lib/gzip.c
new file mode 100644
index 000..a83f4af
--- /dev/null
+++ b/lib/gzip.c
@@ -0,0 +1,142 @@
+/*
+ * (C) Copyright 2012
+ * Lei Wen , Marvell Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "zlib/zutil.h"
+
+#ifndef CONFIG_GZIP_COMPRESS_DEF_SZ
+#define CONFIG_GZIP_COMPRESS_DEF_SZ0x200
+#endif
+#define ZALLOC_ALIGNMENT 16
+
+static void *zalloc(void *x, unsigned items, unsigned size)
+{
+ void *p;
+
+ size *= items;
+ size = (size + ZALLOC_ALIGNMENT - 1) & ~(ZALLOC_ALIGNMENT - 1);
+
+ p = malloc (size);
+
+ return (p);
+}
+
+static void zfree(void *x, void *addr, unsigned nb)
+{
+ free (addr);
+}
+
+int gzip(void *dst, unsigned long *lenp,
+ unsigned char *src, unsigned long srclen)
+{
+ return zzip(dst, lenp, src, srclen, 1, NULL);
+}
+
+/*
+ * Compress blocks with zlib
+ */
+int zzip(void *dst, unsigned long *lenp, unsigned char *src,
+ unsigned long srclen, int stoponerr,
+ int (*func)(unsigned long, unsigned long))
+{
+ z_stream s;
+ int r, flush, orig, window;
+ unsigned long comp_len, left_len;
+
+ if (!srclen)
+ return 0;
+
+#ifndef CONFIG_GZIP
+ window = MAX_WBITS;
+#else
+ window = 2 * MAX_WBITS;
+#endif
+ orig = *lenp;
+ s.zalloc = zalloc;
+ s.zfree = zfree;
+ s.opaque = Z_NULL;
+
+ r = deflateInit2_(&s, Z_BEST_SPEED, Z_DEFLATED, window,
+ DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY,
+ ZLIB_VERSION, sizeof(z_stream));
+ if (r != Z_OK) {
+ printf ("Error: deflateInit2_() returned %d\n", r);
+ return -1;
+ }
+
+ while (srclen > 0) {
+ comp_len = (srclen > CONFIG_GZIP_COMPRESS_DEF_SZ) ?
+ CONFIG_GZIP_COMPRESS_DEF_SZ : srclen;
+
+ s.next_in = src;
+ s.avail_in = comp_len;
+ flush = (srclen > CONFIG_GZIP_COMPRESS_DEF_SZ)?
+ Z_NO_FLUSH : Z_FINISH;
+
+ do {
+ left_len = (*lenp > CONFIG_GZIP_COMPRESS_DEF_SZ) ?
+ CONFIG_GZIP_COMPRESS_DEF_SZ : *lenp;
+ s.next_out = dst;
+ s.avail_out = left_len;
+ r = deflate(&s, flush);
+ if (r == Z_STREAM_ERROR && stoponerr == 1) {
+ printf("Error: deflate() returned %d\n", r);
+ r = -1;
+ goto bail;
+ }
+ if (!func) {
+ dst += (left_len - s.avail_out);
+ *lenp -= (left_l
[U-Boot] [PATCH V2 3/6] lib: zlib: include deflate into zlib build
Add a new config CONFIG_GZIP_ENABLED, if enabled, the uboot bin would
include zlib's deflate method which could be used for compressing.
Signed-off-by: Lei Wen
---
Changelog:
No change
include/u-boot/zlib.h | 40 +++-
lib/zlib/trees.c |8
lib/zlib/zlib.c |8
lib/zlib/zutil.h |4
4 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/include/u-boot/zlib.h b/include/u-boot/zlib.h
index fbb08a3..b611fe7 100644
--- a/include/u-boot/zlib.h
+++ b/include/u-boot/zlib.h
@@ -513,11 +513,41 @@ typedef gz_header FAR *gz_headerp;
If the first character differs, the library code actually used is
not compatible with the zlib.h header file used by the application.
This check is automatically made by deflateInit and inflateInit.
- */
-
-ZEXTERN int ZEXPORT inflateInit_ OF((z_streamp strm, const char *version,
- int stream_size));
-
+ */
+
+ZEXTERN int ZEXPORT deflate OF((z_streamp strm, int flush));
+ZEXTERN int ZEXPORT deflateInit_ OF((z_streamp strm, int level,
+ const char *version, int stream_size));
+ZEXTERN int ZEXPORT deflateEnd OF((z_streamp strm));
+ZEXTERN int ZEXPORT deflateInit2_ OF((z_streamp strm, int level, int method,
+ int windowBits, int memLevel,
+ int strategy, const char *version,
+ int stream_size));
+ZEXTERN int ZEXPORT deflateReset OF((z_streamp strm));
+ZEXTERN int ZEXPORT deflateSetDictionary OF((z_streamp strm,
+ const Bytef *dictionary,
+ uInt dictLength));
+ZEXTERN int ZEXPORT deflateSetHeader OF((z_streamp strm,
+ gz_headerp head));
+ZEXTERN int ZEXPORT deflatePrime OF((z_streamp strm,
+ int bits,
+ int value));
+ZEXTERN int ZEXPORT deflateParams OF((z_streamp strm,
+ int level,
+ int strategy));
+ZEXTERN int ZEXPORT deflateTune OF((z_streamp strm,
+ int good_length,
+ int max_lazy,
+ int nice_length,
+ int max_chain));
+ZEXTERN uLong ZEXPORT deflateBound OF((z_streamp strm,
+ uLong sourceLen));
+ZEXTERN int ZEXPORT deflateCopy OF((z_streamp dest,
+ z_streamp source));
+
+
+ZEXTERN int ZEXPORT inflateInit_ OF((z_streamp strm,
+ const char *version, int stream_size));
ZEXTERN int ZEXPORT inflate OF((z_streamp strm, int flush));
/*
inflate decompresses as much data as possible, and stops when the input
diff --git a/lib/zlib/trees.c b/lib/zlib/trees.c
index 56e9bb1..a0078d0 100644
--- a/lib/zlib/trees.c
+++ b/lib/zlib/trees.c
@@ -1168,14 +1168,14 @@ local int detect_data_type(s)
* method would use a table)
* IN assertion: 1 <= len <= 15
*/
-local unsigned bi_reverse(code, len)
-unsigned code; /* the value to invert */
+local unsigned bi_reverse(value, len)
+unsigned value; /* the value to invert */
int len; /* its bit length */
{
register unsigned res = 0;
do {
-res |= code & 1;
-code >>= 1, res <<= 1;
+res |= value & 1;
+value >>= 1, res <<= 1;
} while (--len > 0);
return res >> 1;
}
diff --git a/lib/zlib/zlib.c b/lib/zlib/zlib.c
index 230d0df..7e15702 100644
--- a/lib/zlib/zlib.c
+++ b/lib/zlib/zlib.c
@@ -12,6 +12,14 @@
* - added inflateIncomp
*/
+#include
+
+#ifdef CONFIG_GZIP_COMPRESSED
+#define NO_DUMMY_DECL
+#include "deflate.c"
+#include "trees.c"
+#endif
+
#include "zutil.h"
#include "inftrees.h"
#include "inflate.h"
diff --git a/lib/zlib/zutil.h b/lib/zlib/zutil.h
index 114cb74..7e05c3b 100644
--- a/lib/zlib/zutil.h
+++ b/lib/zlib/zutil.h
@@ -83,6 +83,10 @@ extern const char * const z_errmsg[10]; /* indexed by
2-zlib_error */
/* The minimum and maximum match lengths */
/* functions */
+#ifdef CONFIG_GZIP_COMPRESSED
+#define PRESET_DICT 0x20 /* preset dictionary flag in zlib header */
+# define OS_CODE 0x03 /* assume Unix */
+#endif
#include
#define zmemcpy memcpy
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
Hi Tom, > > If the patch is generally accepted, I would update with another > > version with the README update included. > > Yes, please v2 things with an updated README. Thanks. > > I have updated the patch set, please help re-check it. Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 6/6] common: add zip command support
Signed-off-by: Lei Wen
---
Changelog:
Add README description for new added zip command
README |6 +
common/Makefile |1 +
common/cmd_zip.c | 60 ++
3 files changed, 67 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_zip.c
diff --git a/README b/README
index a745d0b..af76b0c 100644
--- a/README
+++ b/README
@@ -1483,6 +1483,12 @@ The following options need to be configured:
can be displayed via the splashscreen support or the
bmp command.
+- Do compresssing for memory range:
+ CONFIG_CMD_ZIP
+
+ If this option is set, it would use zlib deflate method
+ to compress the specified memory at its best effort.
+
- Compression support:
CONFIG_BZIP2
diff --git a/common/Makefile b/common/Makefile
index b56df1d..125b2be 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -170,6 +170,7 @@ endif
COBJS-$(CONFIG_CMD_XIMG) += cmd_ximg.o
COBJS-$(CONFIG_YAFFS2) += cmd_yaffs2.o
COBJS-$(CONFIG_CMD_SPL) += cmd_spl.o
+COBJS-$(CONFIG_CMD_ZIP) += cmd_zip.o
COBJS-$(CONFIG_CMD_ZFS) += cmd_zfs.o
# others
diff --git a/common/cmd_zip.c b/common/cmd_zip.c
new file mode 100644
index 000..a73c86d
--- /dev/null
+++ b/common/cmd_zip.c
@@ -0,0 +1,60 @@
+/*
+ * (C) Copyright 2012
+ * Lei Wen , Marvell Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+
+static int do_zip(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ unsigned long src, dst;
+ unsigned long src_len, dst_len = ~0UL;
+ char buf[32];
+
+ switch (argc) {
+ case 5:
+ dst_len = simple_strtoul(argv[4], NULL, 16);
+ /* fall through */
+ case 4:
+ src = simple_strtoul(argv[1], NULL, 16);
+ src_len = simple_strtoul(argv[2], NULL, 16);
+ dst = simple_strtoul(argv[3], NULL, 16);
+ break;
+ default:
+ return cmd_usage(cmdtp);
+ }
+
+ if (gzip((void *) dst, &dst_len, (void *) src, src_len) != 0)
+ return 1;
+
+ printf("Compressed size: %ld = 0x%lX\n", dst_len, dst_len);
+ sprintf(buf, "%lX", dst_len);
+ setenv("filesize", buf);
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ zip,5, 1, do_zip,
+ "zip a memory region",
+ "srcaddr srcsize dstaddr [dstsize]"
+);
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 4/6] lib: zlib: remove the limitation for cannot using 0 as start
We often need the requirement that compressing those memory range start
from 0, but the default deflate code in zlib prevent us to do this.
Considering the special case of uboot, that it could access all memory
range, it is reasonable to be able to also take the address space from 0
into compression.
Signed-off-by: Lei Wen
---
Changelog:
No change
lib/zlib/deflate.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/lib/zlib/deflate.c b/lib/zlib/deflate.c
index 5c4022f..9a20b70 100644
--- a/lib/zlib/deflate.c
+++ b/lib/zlib/deflate.c
@@ -592,9 +592,7 @@ int ZEXPORT deflate (strm, flush)
}
s = strm->state;
-if (strm->next_out == Z_NULL ||
-(strm->next_in == Z_NULL && strm->avail_in != 0) ||
-(s->status == FINISH_STATE && flush != Z_FINISH)) {
+if (s->status == FINISH_STATE && flush != Z_FINISH) {
ERR_RETURN(strm, Z_STREAM_ERROR);
}
if (strm->avail_out == 0) ERR_RETURN(strm, Z_BUF_ERROR);
--
1.7.5.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/6] lib: zlib: import trees file from 1.2.5
Signed-off-by: Lei Wen
---
Changelog:
No change
lib/zlib/trees.c | 1244 ++
lib/zlib/trees.h | 128 ++
2 files changed, 1372 insertions(+), 0 deletions(-)
create mode 100644 lib/zlib/trees.c
create mode 100644 lib/zlib/trees.h
diff --git a/lib/zlib/trees.c b/lib/zlib/trees.c
new file mode 100644
index 000..56e9bb1
--- /dev/null
+++ b/lib/zlib/trees.c
@@ -0,0 +1,1244 @@
+/* trees.c -- output deflated data using Huffman coding
+ * Copyright (C) 1995-2010 Jean-loup Gailly
+ * detect_data_type() function provided freely by Cosmin Truta, 2006
+ * For conditions of distribution and use, see copyright notice in zlib.h
+ */
+
+/*
+ * ALGORITHM
+ *
+ * The "deflation" process uses several Huffman trees. The more
+ * common source values are represented by shorter bit sequences.
+ *
+ * Each code tree is stored in a compressed form which is itself
+ * a Huffman encoding of the lengths of all the code strings (in
+ * ascending order by source values). The actual code strings are
+ * reconstructed from the lengths in the inflate process, as described
+ * in the deflate specification.
+ *
+ * REFERENCES
+ *
+ * Deutsch, L.P.,"'Deflate' Compressed Data Format Specification".
+ * Available in ftp.uu.net:/pub/archiving/zip/doc/deflate-1.1.doc
+ *
+ * Storer, James A.
+ * Data Compression: Methods and Theory, pp. 49-50.
+ * Computer Science Press, 1988. ISBN 0-7167-8156-5.
+ *
+ * Sedgewick, R.
+ * Algorithms, p290.
+ * Addison-Wesley, 1983. ISBN 0-201-06672-6.
+ */
+
+/* @(#) $Id$ */
+
+/* #define GEN_TREES_H */
+
+#include "deflate.h"
+
+#ifdef DEBUG
+# include
+#endif
+
+/* ===
+ * Constants
+ */
+
+#define MAX_BL_BITS 7
+/* Bit length codes must not exceed MAX_BL_BITS bits */
+
+#define END_BLOCK 256
+/* end of block literal code */
+
+#define REP_3_6 16
+/* repeat previous bit length 3-6 times (2 bits of repeat count) */
+
+#define REPZ_3_1017
+/* repeat a zero length 3-10 times (3 bits of repeat count) */
+
+#define REPZ_11_138 18
+/* repeat a zero length 11-138 times (7 bits of repeat count) */
+
+local const int extra_lbits[LENGTH_CODES] /* extra bits for each length code */
+ = {0,0,0,0,0,0,0,0,1,1,1,1,2,2,2,2,3,3,3,3,4,4,4,4,5,5,5,5,0};
+
+local const int extra_dbits[D_CODES] /* extra bits for each distance code */
+ = {0,0,0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7,8,8,9,9,10,10,11,11,12,12,13,13};
+
+local const int extra_blbits[BL_CODES]/* extra bits for each bit length code */
+ = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,2,3,7};
+
+local const uch bl_order[BL_CODES]
+ = {16,17,18,0,8,7,9,6,10,5,11,4,12,3,13,2,14,1,15};
+/* The lengths of the bit length codes are sent in order of decreasing
+ * probability, to avoid transmitting the lengths for unused bit length codes.
+ */
+
+#define Buf_size (8 * 2*sizeof(char))
+/* Number of bits used within bi_buf. (bi_buf might be implemented on
+ * more than 16 bits on some systems.)
+ */
+
+/* ===
+ * Local data. These are initialized only once.
+ */
+
+#define DIST_CODE_LEN 512 /* see definition of array dist_code below */
+
+#if defined(GEN_TREES_H) || !defined(STDC)
+/* non ANSI compilers may not accept trees.h */
+
+local ct_data static_ltree[L_CODES+2];
+/* The static literal tree. Since the bit lengths are imposed, there is no
+ * need for the L_CODES extra codes used during heap construction. However
+ * The codes 286 and 287 are needed to build a canonical tree (see _tr_init
+ * below).
+ */
+
+local ct_data static_dtree[D_CODES];
+/* The static distance tree. (Actually a trivial tree since all codes use
+ * 5 bits.)
+ */
+
+uch _dist_code[DIST_CODE_LEN];
+/* Distance codes. The first 256 values correspond to the distances
+ * 3 .. 258, the last 256 values correspond to the top 8 bits of
+ * the 15 bit distances.
+ */
+
+uch _length_code[MAX_MATCH-MIN_MATCH+1];
+/* length code for each normalized match length (0 == MIN_MATCH) */
+
+local int base_length[LENGTH_CODES];
+/* First normalized length for each code (0 = MIN_MATCH) */
+
+local int base_dist[D_CODES];
+/* First normalized distance for each code (0 = distance of 1) */
+
+#else
+# include "trees.h"
+#endif /* GEN_TREES_H */
+
+struct static_tree_desc_s {
+const ct_data *static_tree; /* static tree or NULL */
+const intf *extra_bits; /* extra bits for each code or NULL */
+int extra_base; /* base index for extra_bits */
+int elems; /* max number of elements in the tree */
+int max_length; /* max bit length for the codes */
+};
+
+local static_tree_desc static_l_desc =
+{static_ltree, extra_lbits, LITERALS+1, L_CODES, MAX_BITS};
+
+local static_tree_desc static_d_desc =
+{static_dtree, ext
[U-Boot] [PATCH V2 0/6] add zip command support for uboot
Change since V1: add CONFIG_CMD_ZIP into README description This patch set add zip command support for uboot. The first two patches import deflate and trees functions from zlib 1.2.5 without any change. While the third patch did the necessary change to make the import file could be built passed in uboot environment. The fourth patch make us could zip the memory from 0 in the address space. The latter fifth and sixth patch does the adding gzip lib function exporting and zip command support. Patch set test with zip&unzip and compared with original memory content. Lei Wen (6): lib: zlib: import deflate source file from 1.2.5 lib: zlib: import trees file from 1.2.5 lib: zlib: include deflate into zlib build lib: zlib: remove the limitation for cannot using 0 as start lib: add gzip lib function callback common: add zip command support README|6 + common/Makefile |1 + common/cmd_zip.c | 60 ++ include/common.h |7 + include/u-boot/zlib.h | 40 +- lib/Makefile |1 + lib/gzip.c| 142 lib/zlib/deflate.c| 1832 + lib/zlib/deflate.h| 342 + lib/zlib/trees.c | 1244 + lib/zlib/trees.h | 128 lib/zlib/zlib.c |8 + lib/zlib/zutil.h |4 + 13 files changed, 3810 insertions(+), 5 deletions(-) create mode 100644 common/cmd_zip.c create mode 100644 lib/gzip.c create mode 100644 lib/zlib/deflate.c create mode 100644 lib/zlib/deflate.h create mode 100644 lib/zlib/trees.c create mode 100644 lib/zlib/trees.h -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
Hi Marek, On Wed, Sep 26, 2012 at 11:34 PM, Marek Vasut wrote: > Dear Lei Wen, > > > On Thu, Sep 6, 2012 at 6:49 PM, Marek Vasut wrote: > > > Dear Lukasz Majewski, > > > > > > [...] > > > > > > > > Ok, that means we can make use of this command ? > > > > > > > > I cannot promise, that I will provide the "zip" support straightaway > in > > > > the DFU. > > > > > > > > On the one hand if DFU is the only user of this command we are adding > > > > in fact a "dead" code. > > > > On the other hand we can use proper #define CONFIG_CMD_ZIP to not > > > > compile it until we "really" use this. > > > > > > I'd rather see a user and code added, not the other way. > > > > common/cmd_zip.c is another user. :) > > I'm OK with this one. > Nice to hear that. > > > And file systems could use the zip callback to directly create the zipped > > file. > > Definitelly not ... zip callback for FS is wrong. > If there is another work around that facilitate write compressed memory into fs, I also like to take it. Certainly callback is not the only choice. > > Since current ext4 and fat in uboot support write function, I think it > > could be > > a potential feature to add. > > cmd_zip + fs write call is OK. But why do we need to zip anything in uboot, > what's the usecase? > The use case may come from we need to dump a range of board memory. While this range tend to be large, and this dump operation behavior may occur frequently. Then do compression would be a good choice. It would allow us to do more dump than the non-compression one. > > > > > > Are there any other potential "users" of this functionality (ZIP > > > > compression/decompression) in u-boot? > > > > > > None that I know of. Is it really zip or is it gzip ? > > > > It is porting from zlib, and is there any different for the compression > > side for > > zip and gzip? > > I ain't no expert, so I'm asking > I quote below saying from zlib.net, maybe this could make us understand the difference. :) "Mark is also the author of gzip's andUnZip<http://www.info-zip.org/pub/infozip/UnZip.html>'s main decompression routines and was the original author of Zip. Not surprisingly, the compression algorithm used in zlib is essentially the same as that in gzip and Zip, namely, the `deflate' method that originated in PKWARE <http://www.pkware.com/>'s PKZIP 2.x." Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
Hi Tom, On Thu, Sep 27, 2012 at 12:20 AM, Tom Rini wrote: > On Wed, Sep 26, 2012 at 05:34:25PM +0200, Marek Vasut wrote: > > Dear Lei Wen, > > > > > On Thu, Sep 6, 2012 at 6:49 PM, Marek Vasut wrote: > > > > Dear Lukasz Majewski, > > > > > > > > [...] > > > > > > > > > > Ok, that means we can make use of this command ? > > > > > > > > > > I cannot promise, that I will provide the "zip" support > straightaway in > > > > > the DFU. > > > > > > > > > > On the one hand if DFU is the only user of this command we are > adding > > > > > in fact a "dead" code. > > > > > On the other hand we can use proper #define CONFIG_CMD_ZIP to not > > > > > compile it until we "really" use this. > > > > > > > > I'd rather see a user and code added, not the other way. > > > > > > common/cmd_zip.c is another user. :) > > > > I'm OK with this one. > > > > > And file systems could use the zip callback to directly create the > zipped > > > file. > > > > Definitelly not ... zip callback for FS is wrong. > > > > > Since current ext4 and fat in uboot support write function, I think it > > > could be > > > a potential feature to add. > > > > cmd_zip + fs write call is OK. But why do we need to zip anything in > uboot, > > what's the usecase? > > > > > > > > > Are there any other potential "users" of this functionality (ZIP > > > > > compression/decompression) in u-boot? > > > > > > > > None that I know of. Is it really zip or is it gzip ? > > > > > > It is porting from zlib, and is there any different for the compression > > > side for > > > zip and gzip? > > > > I ain't no expert, so I'm asking > > > > > This patch is pending for too long time, do we have a answer now > whether > > > it could be merged? > > > > Ccing Tom > > I am fine, conceptually. I see a few needed changes / clarifications: > - Is this zip or gzip compression in the exposed command? > Sure, the zip command is exposed. U_BOOT_CMD( zip,5, 1, do_zip, "zip a memory region", "srcaddr srcsize dstaddr [dstsize]" ); > - You don't update README with CONFIG_CMD_ZIP > If the patch is generally accepted, I would update with another version with the README update included. Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
On Thu, Sep 6, 2012 at 6:49 PM, Marek Vasut wrote: > Dear Lukasz Majewski, > > [...] > > > > Ok, that means we can make use of this command ? > > > > I cannot promise, that I will provide the "zip" support straightaway in > > the DFU. > > > > On the one hand if DFU is the only user of this command we are adding in > > fact a "dead" code. > > On the other hand we can use proper #define CONFIG_CMD_ZIP to not > > compile it until we "really" use this. > > I'd rather see a user and code added, not the other way. > common/cmd_zip.c is another user. :) And file systems could use the zip callback to directly create the zipped file. Since current ext4 and fat in uboot support write function, I think it could be a potential feature to add. > > > Are there any other potential "users" of this functionality (ZIP > > compression/decompression) in u-boot? > > None that I know of. Is it really zip or is it gzip ? > It is porting from zlib, and is there any different for the compression side for zip and gzip? This patch is pending for too long time, do we have a answer now whether it could be merged? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
Hi Marek, On Thu, Sep 6, 2012 at 12:18 PM, Marek Vasut wrote: > Dear adrian.w...@gmail.com, > >> From: Lei Wen > > Lei? Long time no see :) Long time no see. :) > >> This patch set add zip command support for uboot. >> The first two patches import deflate and trees functions from zlib 1.2.5 >> without any change. While the third patch did the necessary change to >> make the import file could be built passed in uboot environment. >> >> The fourth patch make us could zip the memory from 0 in the address space. >> >> The latter fifth and sixth patch does the adding gzip lib function >> exporting and zip command support. >> >> Patch set test with zip&unzip and compared with original memory content. >> >> >> Lei Wen (6): >> lib: zlib: import deflate source file from 1.2.5 >> lib: zlib: import trees file from 1.2.5 >> lib: zlib: include deflate into zlib build >> lib: zlib: remove the limitation for cannot using 0 as start >> lib: add gzip lib function callback >> common: add zip command support >> >> common/Makefile |1 + >> common/cmd_zip.c | 60 ++ >> include/common.h |7 + >> include/u-boot/zlib.h | 40 +- >> lib/Makefile |1 + >> lib/gzip.c| 143 >> lib/zlib/deflate.c| 1831 >> + lib/zlib/deflate.h| >> 342 + >> lib/zlib/trees.c | 1244 + >> lib/zlib/trees.h | 128 >> lib/zlib/zlib.c |8 + >> lib/zlib/zutil.h |4 + >> 12 files changed, 3804 insertions(+), 5 deletions(-) >> create mode 100644 common/cmd_zip.c >> create mode 100644 lib/gzip.c >> create mode 100644 lib/zlib/deflate.c >> create mode 100644 lib/zlib/deflate.h >> create mode 100644 lib/zlib/trees.c >> create mode 100644 lib/zlib/trees.h > > Are there any users for this code? What is it for ? This patch was intended to compress the memory when uploading through USB. So that uploaded image could be smaller. Maybe there are some other usage, like memory testing? > > Best regards, > Marek Vasut Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
On Wed, Apr 11, 2012 at 9:24 AM, Lei Wen wrote: > Hi Mike, > > On Wed, Apr 11, 2012 at 6:11 AM, Mike Frysinger wrote: >> On Tuesday 10 April 2012 01:05:13 Lei Wen wrote: >>> Hi Mike, >>> >>> On Tue, Apr 10, 2012 at 12:37 PM, Mike Frysinger wrote: >>> > On Tuesday 03 April 2012 05:31:09 Lei Wen wrote: >>> >> Hi Mike, >>> >> >>> >> On Tue, Apr 3, 2012 at 3:17 AM, Mike Frysinger wrote: >>> >> > On Tue, Mar 27, 2012 at 04:04, Lei Wen wrote: >>> >> >> On Sun, Mar 25, 2012 at 11:53 PM, wrote: >>> >> >>> From: Lei Wen >>> >> >>> >>> >> >>> This patch set add zip command support for uboot. >>> >> >>> The first two patches import deflate and trees functions from zlib >>> >> >>> 1.2.5 without any change. While the third patch did the necessary >>> >> >>> change to make the import file could be built passed in uboot >>> >> >>> environment. >>> >> >> >>> >> >> Any comments to this series? >>> >> > >>> >> > did you forward port the misc fixes/optimization that were done ? or >>> >> > did you just drop in the new code ? >>> >> >>> >> The fixes/optimization is already separated in different patch, as the >>> >> 0004 in current series. >>> >> Other file is just import as intact from zlib1.2.5, the 0001 and 0002 >>> >> patch. >>> > >>> > i don't understand what you mean. 0004 is "lib: zlib: remove the >>> > limitation for cannot using 0 as start" and doesn't look like a fix that >>> > was merged before. >>> > >>> >> > for example, cd514aeb996e2f7aefbe1f78481965d9d074aed4 is pretty >>> >> > important >>> >> >>> >> I see. I try my best to keep the current modification history adding >>> >> to the original zlib code. >>> > >>> > so you have maintained the bug fixes / optimizations ? it isn't clear in >>> > your response (at least to me). >>> >>> I see what your concerns... >>> Yes, this change is not included in the zlib's own code, but just >>> added by myself. >>> Without this change, in uboot, we cannot zip from the start of ddr >>> memory, since many >>> platforms, at least from what I saw, their start ddr memory address is from >>> 0. >> >> i think you've missed the point of my questions. we aren't concerned with >> changes you've written (such as patch 4/6 in this series), but bug fixes that >> were added to the zlib code before you updated things. updating to a newer >> version and dropping previous fixes/optimizations isn't acceptable. > > I didn't overwrite the previous bug fix that existed in the uboot... > The commit you point out is still there in lib/zlib/inffast.c > > What I am doing is just adding, not subtracting, nor overwriting... > This patch set change is not to updating the zlib version... > The previous inflate related stuff in uboot code is kept untouched. ping... Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND 2/2] mmc:fix Call mmc_init() when executing mmc_get_dev()
Hi Lukasz, On Fri, Apr 20, 2012 at 3:09 PM, Lukasz Majewski wrote: > Hi, Lei > >> I'm concerning with this adding init here. >> Since not every platform mount with emmc as boot device, and what they >> need is booting fast. > > If I remember correctly, u-boot policy is to not initialize the mmc > until it is needed (i.e. command is executed). > So the extra init won't be executed until fatls or mmc is executed. > >> If you order them to initialize all mmc/sd at >> mmc register stage, this adding booting time may not be the one they >> want to see. > > I think that booting time will not increase, because in the mmc_init() > there is a check: > > if (mmc->has_init) > return 0; > > To prevent multiple register level initialization. > > The execution time increase is boiled down to executing a > few instructions (when mmc->has_init is set). > > I misunderstood your original patch... I was thinking you want to init the mmc device directly in the mmc register process which is a bad idea. But since you add the init only in the get_dev, I think this approach is ok to me. Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND 1/2] mmc:fix: Set mmc width according to MMC host capabilities
On Thu, Apr 19, 2012 at 8:39 PM, Lukasz Majewski wrote:
> This patch sets the MMC width according to the MMC host capabilities.
> It turned out, that there are some targets (e.g. GONI), which are able
> to read data from SPI only at 4 bit mode.
> This patch restricts the width number according to the MMC host.
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Kyungmin Park
> Cc: Andy Fleming
> ---
> drivers/mmc/mmc.c | 4 +++-
> include/mmc.h | 3 +++
> 2 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index e70fa9f..618960e 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1199,7 +1199,9 @@ int mmc_startup(struct mmc *mmc)
> else
> mmc_set_clock(mmc, 2500);
> } else {
> - for (width = EXT_CSD_BUS_WIDTH_8; width >= 0; width--) {
> + width = ((mmc->host_caps & MMC_MODE_MASK_WIDTH_BITS) >>
> + MMC_MODE_WIDTH_BITS_SHIFT);
> + for (; width >= 0; width--) {
> /* Set the card to use 4 bit*/
> err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
> EXT_CSD_BUS_WIDTH, width);
> diff --git a/include/mmc.h b/include/mmc.h
> index f52df70..ee16349 100644
> --- a/include/mmc.h
> +++ b/include/mmc.h
> @@ -47,6 +47,9 @@
> #define MMC_MODE_SPI 0x400
> #define MMC_MODE_HC 0x800
>
> +#define MMC_MODE_MASK_WIDTH_BITS (MMC_MODE_4BIT | MMC_MODE_8BIT)
> +#define MMC_MODE_WIDTH_BITS_SHIFT 8
> +
> #define SD_DATA_4BIT 0x0004
>
> #define IS_SD(x) (x->version & SD_VERSION_SD)
> --
> 1.7.2.3
>
Acked-by: Lei Wen
Thanks,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND 2/2] mmc:fix Call mmc_init() when executing mmc_get_dev()
Hi Lukasz,
On Thu, Apr 19, 2012 at 8:39 PM, Lukasz Majewski wrote:
> This code adds call to mmc_init(), for partition related commands (e.g.
> fatls, fatinfo etc.).
>
> It is safe to call mmc_init() multiple times since mmc->has_init flag
> prevents from multiple initialization.
>
> The FAT related code calls get_dev high level method and then uses
> elements from mmc->block_dev, which is uninitialized until the mmc_init
> (and thereof mmc_startup) is called.
>
> This problem appears on boards, which don't use mmc as the default
> place for envs
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Kyungmin Park
> Cc: Andy Fleming
> ---
> drivers/mmc/mmc.c | 5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 618960e..84eb4e0 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1305,8 +1305,11 @@ int mmc_register(struct mmc *mmc)
> block_dev_desc_t *mmc_get_dev(int dev)
> {
> struct mmc *mmc = find_mmc_device(dev);
> + if (!mmc)
> + return NULL;
>
> - return mmc ? &mmc->block_dev : NULL;
> + mmc_init(mmc);
I'm concerning with this adding init here.
Since not every platform mount with emmc as boot device, and what they
need is booting fast. If you order them to initialize all mmc/sd at mmc register
stage, this adding booting time may not be the one they want to see.
For FAT command, I think you could abstract a init method, in which mmc
could call its mmc_init(). I previously make a patch for this, don't whether it
could fit your need:
diff --git a/disk/part.c b/disk/part.c
index e4e7997..3d00670 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -77,7 +77,7 @@ DECLARE_GLOBAL_DATA_PTR;
block_dev_desc_t *get_dev(char* ifname, int dev)
{
const struct block_drvr *drvr = block_drvr;
- block_dev_desc_t* (*reloc_get_dev)(int dev);
+ block_dev_desc_t* (*reloc_get_dev)(int dev), *dev_desc;
char *name;
name = drvr->name;
@@ -91,8 +91,13 @@ block_dev_desc_t *get_dev(char* ifname, int dev)
name += gd->reloc_off;
reloc_get_dev += gd->reloc_off;
#endif
- if (strncmp(ifname, name, strlen(name)) == 0)
- return reloc_get_dev(dev);
+ if (strncmp(ifname, name, strlen(name)) == 0) {
+ dev_desc = reloc_get_dev(dev);
+ if (dev_desc && dev_desc->dev_init(dev_desc->dev))
+ dev_desc = NULL;
+
+ return dev_desc;
+ }
drvr++;
}
return NULL;
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 1622417..c4c48e7 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1150,6 +1150,7 @@ int mmc_send_if_cond(struct mmc *mmc)
return 0;
}
+static int mmc_dev_init(int dev_num);
int mmc_register(struct mmc *mmc)
{
/* Setup the universal parts of the block interface just once */
@@ -1159,6 +1160,7 @@ int mmc_register(struct mmc *mmc)
mmc->block_dev.block_read = mmc_bread;
mmc->block_dev.block_write = mmc_bwrite;
mmc->block_dev.block_erase = mmc_berase;
+ mmc->block_dev.dev_init = mmc_dev_init;
if (!mmc->b_max)
mmc->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
@@ -1226,6 +1228,15 @@ int mmc_init(struct mmc *mmc)
return err;
}
+static int mmc_dev_init(int dev_num)
+{
+ struct mmc *mmc = find_mmc_device(dev_num);
+ if (!mmc)
+ return -1;
+
+ return mmc_init(mmc);
+}
+
/*
* CPU and board-specific MMC initializations. Aliased function
* signals caller to move on
diff --git a/include/part.h b/include/part.h
index 2864adb..dac2bdd 100644
--- a/include/part.h
+++ b/include/part.h
@@ -41,6 +41,7 @@ typedef struct block_dev_desc {
charvendor [40+1]; /* IDE model, SCSI Vendor */
charproduct[20+1]; /* IDE Serial no, SCSI product */
charrevision[8+1]; /* firmware revision */
+ int (*dev_init)(int dev);
unsigned long (*block_read)(int dev,
unsigned long start,
lbaint_t blkcnt,
Thanks,
Lei
Thanks,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] mmc: support sdhci instead of s5p_mmc
Hi Jaehoon, On Tue, Apr 10, 2012 at 10:04 AM, Jaehoon Chung wrote: > This patchset is supported the sdhci controller for Samsung-SoC. > In mmc driver, already implemented the generic sdhci. > There is no reason that didn't use sdhci.c. > So, use the sdhci instead of s5p_mmc. > > Changelog-v4: > - seperate the device driver and SoC patch. > > Changelog-v3: > - Add the quirks for broken R1b response. > - Add the timeout to prevent infinite loop. > > Changelog-v2: > - removed the s5p_mmc.c > - based-on u-boot-samsung repository. > > Jaehoon Chung (4): > mmc: sdhci: add the quirk for broken r1b response > mmc: add the quirk to use the sdhci for samsung-soc > mmc: support the sdhci instead of s5p_mmc for samsung-soc > ARM: SAMSUNG: support sdhci controller > > arch/arm/include/asm/arch-exynos/mmc.h | 93 +++--- > arch/arm/include/asm/arch-s5pc1xx/mmc.h | 93 +++--- > drivers/mmc/Makefile | 2 +- > drivers/mmc/s5p_mmc.c | 490 > --- > drivers/mmc/s5p_sdhci.c | 98 ++ > drivers/mmc/sdhci.c | 24 ++ > include/configs/origen.h | 3 +- > include/configs/s5p_goni.h | 3 +- > include/configs/s5pc210_universal.h | 3 +- > include/configs/smdk5250.h | 3 +- > include/configs/smdkv310.h | 3 +- > include/configs/trats.h | 3 +- > include/sdhci.h | 7 + > 13 files changed, 236 insertions(+), 589 deletions(-) > delete mode 100644 drivers/mmc/s5p_mmc.c > create mode 100644 drivers/mmc/s5p_sdhci.c > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Ack to this series. Acked-by: Lei Wen Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
Hi Mike, On Wed, Apr 11, 2012 at 6:11 AM, Mike Frysinger wrote: > On Tuesday 10 April 2012 01:05:13 Lei Wen wrote: >> Hi Mike, >> >> On Tue, Apr 10, 2012 at 12:37 PM, Mike Frysinger wrote: >> > On Tuesday 03 April 2012 05:31:09 Lei Wen wrote: >> >> Hi Mike, >> >> >> >> On Tue, Apr 3, 2012 at 3:17 AM, Mike Frysinger wrote: >> >> > On Tue, Mar 27, 2012 at 04:04, Lei Wen wrote: >> >> >> On Sun, Mar 25, 2012 at 11:53 PM, wrote: >> >> >>> From: Lei Wen >> >> >>> >> >> >>> This patch set add zip command support for uboot. >> >> >>> The first two patches import deflate and trees functions from zlib >> >> >>> 1.2.5 without any change. While the third patch did the necessary >> >> >>> change to make the import file could be built passed in uboot >> >> >>> environment. >> >> >> >> >> >> Any comments to this series? >> >> > >> >> > did you forward port the misc fixes/optimization that were done ? or >> >> > did you just drop in the new code ? >> >> >> >> The fixes/optimization is already separated in different patch, as the >> >> 0004 in current series. >> >> Other file is just import as intact from zlib1.2.5, the 0001 and 0002 >> >> patch. >> > >> > i don't understand what you mean. 0004 is "lib: zlib: remove the >> > limitation for cannot using 0 as start" and doesn't look like a fix that >> > was merged before. >> > >> >> > for example, cd514aeb996e2f7aefbe1f78481965d9d074aed4 is pretty >> >> > important >> >> >> >> I see. I try my best to keep the current modification history adding >> >> to the original zlib code. >> > >> > so you have maintained the bug fixes / optimizations ? it isn't clear in >> > your response (at least to me). >> >> I see what your concerns... >> Yes, this change is not included in the zlib's own code, but just >> added by myself. >> Without this change, in uboot, we cannot zip from the start of ddr >> memory, since many >> platforms, at least from what I saw, their start ddr memory address is from >> 0. > > i think you've missed the point of my questions. we aren't concerned with > changes you've written (such as patch 4/6 in this series), but bug fixes that > were added to the zlib code before you updated things. updating to a newer > version and dropping previous fixes/optimizations isn't acceptable. I didn't overwrite the previous bug fix that existed in the uboot... The commit you point out is still there in lib/zlib/inffast.c What I am doing is just adding, not subtracting, nor overwriting... This patch set change is not to updating the zlib version... The previous inflate related stuff in uboot code is kept untouched. > -mike Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
Hi Mike, On Tue, Apr 10, 2012 at 12:37 PM, Mike Frysinger wrote: > On Tuesday 03 April 2012 05:31:09 Lei Wen wrote: >> Hi Mike, >> >> On Tue, Apr 3, 2012 at 3:17 AM, Mike Frysinger wrote: >> > On Tue, Mar 27, 2012 at 04:04, Lei Wen wrote: >> >> On Sun, Mar 25, 2012 at 11:53 PM, wrote: >> >>> From: Lei Wen >> >>> >> >>> This patch set add zip command support for uboot. >> >>> The first two patches import deflate and trees functions from zlib >> >>> 1.2.5 without any change. While the third patch did the necessary >> >>> change to make the import file could be built passed in uboot >> >>> environment. >> >> >> >> Any comments to this series? >> > >> > did you forward port the misc fixes/optimization that were done ? or >> > did you just drop in the new code ? >> >> The fixes/optimization is already separated in different patch, as the >> 0004 in current series. >> Other file is just import as intact from zlib1.2.5, the 0001 and 0002 >> patch. > > i don't understand what you mean. 0004 is "lib: zlib: remove the limitation > for cannot using 0 as start" and doesn't look like a fix that was merged > before. > >> > for example, cd514aeb996e2f7aefbe1f78481965d9d074aed4 is pretty important >> >> I see. I try my best to keep the current modification history adding >> to the original zlib code. > > so you have maintained the bug fixes / optimizations ? it isn't clear in your > response (at least to me). I see what your concerns... Yes, this change is not included in the zlib's own code, but just added by myself. Without this change, in uboot, we cannot zip from the start of ddr memory, since many platforms, at least from what I saw, their start ddr memory address is from 0. If you are still not comfortable with this patch, I could remove the 004 from patch set. What do you think of this suggestion? > -mike Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
Hi Mike, On Tue, Apr 3, 2012 at 3:17 AM, Mike Frysinger wrote: > On Tue, Mar 27, 2012 at 04:04, Lei Wen wrote: >> On Sun, Mar 25, 2012 at 11:53 PM, wrote: >>> From: Lei Wen >>> >>> This patch set add zip command support for uboot. >>> The first two patches import deflate and trees functions from zlib 1.2.5 >>> without any change. While the third patch did the necessary change to >>> make the import file could be built passed in uboot environment. >> >> Any comments to this series? > > did you forward port the misc fixes/optimization that were done ? or > did you just drop in the new code ? The fixes/optimization is already separated in different patch, as the 0004 in current series. Other file is just import as intact from zlib1.2.5, the 0001 and 0002 patch. > > for example, cd514aeb996e2f7aefbe1f78481965d9d074aed4 is pretty important I see. I try my best to keep the current modification history adding to the original zlib code. > > you can view other fixes by: > git log -p -- lib_generic/zlib.c > git log -p -- lib/zlib.c > git log -p -- lib/zlib/ > -mike Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
Dear Wolfgang, On Wed, Mar 28, 2012 at 10:23 AM, Lei Wen wrote: > Hi Tom, > > On Wed, Mar 28, 2012 at 2:12 AM, Tom Rini wrote: >> On Tue, Mar 27, 2012 at 04:04:29PM +0800, Lei Wen wrote: >>> Hi, >>> >>> On Sun, Mar 25, 2012 at 11:53 PM, wrote: >>> > From: Lei Wen >>> > >>> > This patch set add zip command support for uboot. >>> > The first two patches import deflate and trees functions from zlib 1.2.5 >>> > without any change. While the third patch did the necessary change to >>> > make the import file could be built passed in uboot environment. >>> > >>> > The fourth patch make us could zip the memory from 0 in the address space. >>> > >>> > The latter fifth and sixth patch does the adding gzip lib function >>> > exporting >>> > and zip command support. >>> > >>> > Patch set test with zip&unzip and compared with original memory content. >>> > >>> > >>> > Lei Wen (6): >>> > ?lib: zlib: import deflate source file from 1.2.5 >>> > ?lib: zlib: import trees file from 1.2.5 >>> > ?lib: zlib: include deflate into zlib build >>> > ?lib: zlib: remove the limitation for cannot using 0 as start >>> > ?lib: add gzip lib function callback >>> > ?common: add zip command support >>> > >>> > ?common/Makefile ? ? ? | ? ?1 + >>> > ?common/cmd_zip.c ? ? ?| ? 60 ++ >>> > ?include/common.h ? ? ?| ? ?7 + >>> > ?include/u-boot/zlib.h | ? 40 +- >>> > ?lib/Makefile ? ? ? ? ?| ? ?1 + >>> > ?lib/gzip.c ? ? ? ? ? ?| ?143 >>> > ?lib/zlib/deflate.c ? ?| 1831 >>> > + >>> > ?lib/zlib/deflate.h ? ?| ?342 + >>> > ?lib/zlib/trees.c ? ? ?| 1244 + >>> > ?lib/zlib/trees.h ? ? ?| ?128 >>> > ?lib/zlib/zlib.c ? ? ? | ? ?8 + >>> > ?lib/zlib/zutil.h ? ? ?| ? ?4 + >>> > ?12 files changed, 3804 insertions(+), 5 deletions(-) >>> > ?create mode 100644 common/cmd_zip.c >>> > ?create mode 100644 lib/gzip.c >>> > ?create mode 100644 lib/zlib/deflate.c >>> > ?create mode 100644 lib/zlib/deflate.h >>> > ?create mode 100644 lib/zlib/trees.c >>> > ?create mode 100644 lib/zlib/trees.h >>> >>> Any comments to this series? >> >> What's the usecase for this code? Did the U-Boot change in size for >> targets that didn't opt for the new command? > > There is one usecase in our usage, that is compressing and upload the > memory content > through the usb, so that it would reduce the total upload time. > Certainly, this also could be used to verify current unzip feature > whether it works well. > Or some other case, like testing the memory speed? > > No, the new gzip feature only shows up if its configuration is opened, > or the uboot size would > not be impacted. Do you have any comment on this series? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] mmc: sdhci: fix the wrong operation when response type is R1b
Hi Jaehoon, On Sat, Mar 31, 2012 at 2:55 PM, Jae hoon Chung wrote: > Hi Lei. > > I will try to test with your opinion. > Just wondering..If apply with my patch, is it something problem? First, you patch limit the original mask which could be extend to other flag to only SDHCI_INT_RESPONSE | SDHCI_INT_DATA_END, second, obviously you just need a timeout, so only two or three lines changes of code to implement it to keep the patch simple. > Anyway i will test and share the result. then resend the patch. > > I want to use the generic sdhci code. That is also my glad to more people to use it. > > Best Regards, > Jaehoon Chung Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] mmc: sdhci: fix the wrong operation when response type is R1b
Hi Jaehoon,
On Fri, Mar 30, 2012 at 2:23 PM, Jaehoon Chung wrote:
> On 03/30/2012 02:24 PM, Lei Wen wrote:
>
>> Hi Jaehoon,
>>
>> On Fri, Mar 30, 2012 at 12:36 PM, Jaehoon Chung
>> wrote:
>>> Hi Lei.
>>>
>>> First, thanks for implemented the generic sdhci controller.
>>
>> It is my pleasure to share this common code, and I'm glad that it is
>> used for other platforms now. :)
>>
>>>
>>> On 03/30/2012 12:33 PM, Lei Wen wrote:
>>>
>>>> Hi Jaehoon,
>>>>
>>>> On Fri, Mar 30, 2012 at 10:39 AM, Jaehoon Chung
>>>> wrote:
>>>>> When response type is R1b, mask value is added the SDHCI_INT_DAT_END.
>>>>> but in while(), didn't check that flag.
>>>>> So sdhci controller didn't work fine.
>>>>> CMD6 didn't always complete.
>>>>
>>>> Could you elaborate it more in details?
>>>> do {
>>>> stat = sdhci_readl(host, SDHCI_INT_STATUS);
>>>> if (stat & SDHCI_INT_ERROR)
>>>> break;
>>>> } while ((stat & mask) != mask);
>>>> Here in the while condition, if the status read out don't contain all mask,
>>>> then the looping would continue.
>>>> Do you mean you just need a retry max time set here?
>>>
>>> I found that didn't initialize the eMMC card.
>>> Because when send CMD6, running infinite loop in there.
>>> CMD6's mask is set to SDHCI_INT_RESPONSE and SDHCI_INT_DATA_END.
>>> (Because response type is R1B).
>>> Then mask value maybe is 0x3...
>>> stat = sdhci_readl(host, SDHCI_INT_STATUS);
>>> stat is 0x1.(cmd is done response).
>>> but in while(), stat & mask is 0x1, and mask is 0x3.
>>> ...doing while().
>>> If just add the timeout, then always produced the timeout error.
>>
>> I see your problems. Your silicon only provide SDHCI_INT_RESPONSE for
>> r1b, while the standard
>> sdhci spec require both the flag is set when the r1b command is finished.
>> So my point is you could add a quirk condition check in the previously
>> endless loop checking.
>> If the quirk is true, and timeout count is met, then you could jump
>> out of original looping.
>> And for later checking, this timeout could be regarded as no error,
>> since the controller would never
>> return the SDHCI_INT_DATA_END in your case.
>
>
> Anyway it's need that use the timeout value. right?
Yes, for the timeout patch here, I am ok with that.
> And in our case, It's means that use the quirks?
Using quirks, or set a timeout value large enough? Maybe latter is
more generic. :)
> I didn't find that the sdhci spec require the flag is set when the r1b
> command is finished.
> where is specified?
The spec I mention is
https://www.sdcard.org/developers/overview/host_controller/simple_spec/Simplified_SD_Host_Controller_Spec.pdf
You could look at page 64, the bit description for "Transfer Complete":
(3) In the case of a command with busy
This bit is set when busy is de-asserted. Refer to DAT Line Active
and Command Inhibit (DAT) in the Present State register
> I just understand that the transfer complete bit should be set to 1,
> when send the command with busy flag or read/write with data.
> Is this means?
Yes, that is what I means, if you send a command with r1b flag, then
you should expect both
transfer complete and command complete bit is set, only command
complete bit set doesn't mean
your command is safely treated, and you could do the next step further.
>
> If you want to use the quirks, i will test with applied your opinion.
I think you only need to add timeout into this while looping, and not
touching other code.
do {
stat = sdhci_readl(host, SDHCI_INT_STATUS);
if (stat & SDHCI_INT_ERROR)
break;
} while ((stat & mask) != mask);
>
> Best Regards,
> Jaehoon Chung
Thanks,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] mmc: sdhci: fix the wrong operation when response type is R1b
Hi Jaehoon,
On Fri, Mar 30, 2012 at 12:36 PM, Jaehoon Chung wrote:
> Hi Lei.
>
> First, thanks for implemented the generic sdhci controller.
It is my pleasure to share this common code, and I'm glad that it is
used for other platforms now. :)
>
> On 03/30/2012 12:33 PM, Lei Wen wrote:
>
>> Hi Jaehoon,
>>
>> On Fri, Mar 30, 2012 at 10:39 AM, Jaehoon Chung
>> wrote:
>>> When response type is R1b, mask value is added the SDHCI_INT_DAT_END.
>>> but in while(), didn't check that flag.
>>> So sdhci controller didn't work fine.
>>> CMD6 didn't always complete.
>>
>> Could you elaborate it more in details?
>> do {
>> stat = sdhci_readl(host, SDHCI_INT_STATUS);
>> if (stat & SDHCI_INT_ERROR)
>> break;
>> } while ((stat & mask) != mask);
>> Here in the while condition, if the status read out don't contain all mask,
>> then the looping would continue.
>> Do you mean you just need a retry max time set here?
>
> I found that didn't initialize the eMMC card.
> Because when send CMD6, running infinite loop in there.
> CMD6's mask is set to SDHCI_INT_RESPONSE and SDHCI_INT_DATA_END.
> (Because response type is R1B).
> Then mask value maybe is 0x3...
> stat = sdhci_readl(host, SDHCI_INT_STATUS);
> stat is 0x1.(cmd is done response).
> but in while(), stat & mask is 0x1, and mask is 0x3.
> ...doing while().
> If just add the timeout, then always produced the timeout error.
I see your problems. Your silicon only provide SDHCI_INT_RESPONSE for
r1b, while the standard
sdhci spec require both the flag is set when the r1b command is finished.
So my point is you could add a quirk condition check in the previously
endless loop checking.
If the quirk is true, and timeout count is met, then you could jump
out of original looping.
And for later checking, this timeout could be regarded as no error,
since the controller would never
return the SDHCI_INT_DATA_END in your case.
>
> How did you test? Is initialize the eMMC card?
> (I tested with eMMC4.41 (exynos4).)
I test on many Marvell platforms, with sd, mmc, emmc, they all works fine.
>
>>
>>
>>>
>>> Signed-off-by: Jaehoon Chung
>>> Signed-off-by: Kyungmin Park
>>> ---
>>> drivers/mmc/sdhci.c | 33 +++--
>>> 1 files changed, 23 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
>>> index fc904b5..0dd08b9 100644
>>> --- a/drivers/mmc/sdhci.c
>>> +++ b/drivers/mmc/sdhci.c
>>> @@ -124,10 +124,11 @@ int sdhci_send_command(struct mmc *mmc, struct
>>> mmc_cmd *cmd,
>>> {
>>> struct sdhci_host *host = (struct sdhci_host *)mmc->priv;
>>> unsigned int stat = 0;
>>> - int ret = 0;
>>> + int i, ret = 0;
>>> int trans_bytes = 0, is_aligned = 1;
>>> u32 mask, flags, mode;
>>> unsigned int timeout, start_addr = 0;
>>> + unsigned int retry = 1;
>>>
>>> /* Wait max 10 ms */
>>> timeout = 10;
>>> @@ -206,19 +207,31 @@ int sdhci_send_command(struct mmc *mmc, struct
>>> mmc_cmd *cmd,
>>> flush_cache(start_addr, trans_bytes);
>>> #endif
>>> sdhci_writew(host, SDHCI_MAKE_CMD(cmd->cmdidx, flags),
>>> SDHCI_COMMAND);
>>> - do {
>>> +
>>> + for (i = 0; i < retry; i++) {
>>> stat = sdhci_readl(host, SDHCI_INT_STATUS);
>>> - if (stat & SDHCI_INT_ERROR)
>>> + if (stat & (SDHCI_INT_RESPONSE | SDHCI_INT_DATA_END)) {
>>> + sdhci_cmd_done(host, cmd);
>>> + sdhci_writel(host, mask, SDHCI_INT_STATUS);
>>> + if (!data) {
>>> + sdhci_writel(host, stat, SDHCI_INT_STATUS);
>>
>> Why do two write?
>
> We can remove the sdhci_writel(host, mask SDHCI_INT_STATUS).
> It's my mistake..i will fix that.
>
> Best Regards,
> Jaehoon Chung
Thanks,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] mmc: sdhci: fix the wrong operation when response type is R1b
Hi Jaehoon,
On Fri, Mar 30, 2012 at 10:39 AM, Jaehoon Chung wrote:
> When response type is R1b, mask value is added the SDHCI_INT_DAT_END.
> but in while(), didn't check that flag.
> So sdhci controller didn't work fine.
> CMD6 didn't always complete.
Could you elaborate it more in details?
do {
stat = sdhci_readl(host, SDHCI_INT_STATUS);
if (stat & SDHCI_INT_ERROR)
break;
} while ((stat & mask) != mask);
Here in the while condition, if the status read out don't contain all mask,
then the looping would continue.
Do you mean you just need a retry max time set here?
>
> Signed-off-by: Jaehoon Chung
> Signed-off-by: Kyungmin Park
> ---
> drivers/mmc/sdhci.c | 33 +++--
> 1 files changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> index fc904b5..0dd08b9 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -124,10 +124,11 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd
> *cmd,
> {
> struct sdhci_host *host = (struct sdhci_host *)mmc->priv;
> unsigned int stat = 0;
> - int ret = 0;
> + int i, ret = 0;
> int trans_bytes = 0, is_aligned = 1;
> u32 mask, flags, mode;
> unsigned int timeout, start_addr = 0;
> + unsigned int retry = 1;
>
> /* Wait max 10 ms */
> timeout = 10;
> @@ -206,19 +207,31 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd
> *cmd,
> flush_cache(start_addr, trans_bytes);
> #endif
> sdhci_writew(host, SDHCI_MAKE_CMD(cmd->cmdidx, flags), SDHCI_COMMAND);
> - do {
> +
> + for (i = 0; i < retry; i++) {
> stat = sdhci_readl(host, SDHCI_INT_STATUS);
> - if (stat & SDHCI_INT_ERROR)
> + if (stat & (SDHCI_INT_RESPONSE | SDHCI_INT_DATA_END)) {
> + sdhci_cmd_done(host, cmd);
> + sdhci_writel(host, mask, SDHCI_INT_STATUS);
> + if (!data) {
> + sdhci_writel(host, stat, SDHCI_INT_STATUS);
Why do two write?
> + }
> break;
> - } while ((stat & mask) != mask);
> + }
> + }
>
> - if ((stat & (SDHCI_INT_ERROR | mask)) == mask) {
> - sdhci_cmd_done(host, cmd);
> - sdhci_writel(host, mask, SDHCI_INT_STATUS);
> - } else
> - ret = -1;
> + if (i == retry) {
> + printf("%s: waiting for status update\n",__func__);
> + return TIMEOUT;
> + }
> +
> + if (stat & SDHCI_INT_TIMEOUT) {
> + return TIMEOUT;
> + } else if (stat & SDHCI_INT_ERROR) {
> + return -1;
> + }
>
> - if (!ret && data)
> + if (data)
> ret = sdhci_transfer_data(host, data, start_addr);
>
> stat = sdhci_readl(host, SDHCI_INT_STATUS);
Thanks,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
Hi Tom, On Wed, Mar 28, 2012 at 2:12 AM, Tom Rini wrote: > On Tue, Mar 27, 2012 at 04:04:29PM +0800, Lei Wen wrote: >> Hi, >> >> On Sun, Mar 25, 2012 at 11:53 PM, wrote: >> > From: Lei Wen >> > >> > This patch set add zip command support for uboot. >> > The first two patches import deflate and trees functions from zlib 1.2.5 >> > without any change. While the third patch did the necessary change to >> > make the import file could be built passed in uboot environment. >> > >> > The fourth patch make us could zip the memory from 0 in the address space. >> > >> > The latter fifth and sixth patch does the adding gzip lib function >> > exporting >> > and zip command support. >> > >> > Patch set test with zip&unzip and compared with original memory content. >> > >> > >> > Lei Wen (6): >> > ?lib: zlib: import deflate source file from 1.2.5 >> > ?lib: zlib: import trees file from 1.2.5 >> > ?lib: zlib: include deflate into zlib build >> > ?lib: zlib: remove the limitation for cannot using 0 as start >> > ?lib: add gzip lib function callback >> > ?common: add zip command support >> > >> > ?common/Makefile ? ? ? | ? ?1 + >> > ?common/cmd_zip.c ? ? ?| ? 60 ++ >> > ?include/common.h ? ? ?| ? ?7 + >> > ?include/u-boot/zlib.h | ? 40 +- >> > ?lib/Makefile ? ? ? ? ?| ? ?1 + >> > ?lib/gzip.c ? ? ? ? ? ?| ?143 >> > ?lib/zlib/deflate.c ? ?| 1831 >> > + >> > ?lib/zlib/deflate.h ? ?| ?342 + >> > ?lib/zlib/trees.c ? ? ?| 1244 + >> > ?lib/zlib/trees.h ? ? ?| ?128 >> > ?lib/zlib/zlib.c ? ? ? | ? ?8 + >> > ?lib/zlib/zutil.h ? ? ?| ? ?4 + >> > ?12 files changed, 3804 insertions(+), 5 deletions(-) >> > ?create mode 100644 common/cmd_zip.c >> > ?create mode 100644 lib/gzip.c >> > ?create mode 100644 lib/zlib/deflate.c >> > ?create mode 100644 lib/zlib/deflate.h >> > ?create mode 100644 lib/zlib/trees.c >> > ?create mode 100644 lib/zlib/trees.h >> >> Any comments to this series? > > What's the usecase for this code? Did the U-Boot change in size for > targets that didn't opt for the new command? There is one usecase in our usage, that is compressing and upload the memory content through the usb, so that it would reduce the total upload time. Certainly, this also could be used to verify current unzip feature whether it works well. Or some other case, like testing the memory speed? No, the new gzip feature only shows up if its configuration is opened, or the uboot size would not be impacted. > > -- > Tom Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] add zip command support for uboot
Hi, On Sun, Mar 25, 2012 at 11:53 PM, wrote: > From: Lei Wen > > This patch set add zip command support for uboot. > The first two patches import deflate and trees functions from zlib 1.2.5 > without any change. While the third patch did the necessary change to > make the import file could be built passed in uboot environment. > > The fourth patch make us could zip the memory from 0 in the address space. > > The latter fifth and sixth patch does the adding gzip lib function exporting > and zip command support. > > Patch set test with zip&unzip and compared with original memory content. > > > Lei Wen (6): > lib: zlib: import deflate source file from 1.2.5 > lib: zlib: import trees file from 1.2.5 > lib: zlib: include deflate into zlib build > lib: zlib: remove the limitation for cannot using 0 as start > lib: add gzip lib function callback > common: add zip command support > > common/Makefile | 1 + > common/cmd_zip.c | 60 ++ > include/common.h | 7 + > include/u-boot/zlib.h | 40 +- > lib/Makefile | 1 + > lib/gzip.c | 143 > lib/zlib/deflate.c | 1831 > + > lib/zlib/deflate.h | 342 + > lib/zlib/trees.c | 1244 + > lib/zlib/trees.h | 128 > lib/zlib/zlib.c | 8 + > lib/zlib/zutil.h | 4 + > 12 files changed, 3804 insertions(+), 5 deletions(-) > create mode 100644 common/cmd_zip.c > create mode 100644 lib/gzip.c > create mode 100644 lib/zlib/deflate.c > create mode 100644 lib/zlib/deflate.h > create mode 100644 lib/zlib/trees.c > create mode 100644 lib/zlib/trees.h > > -- > 1.7.5.4 > Any comments to this series? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: zlib: update to 1.2.6
Hi Wolfgang, On Thu, Mar 8, 2012 at 4:13 PM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message > you > wrote: >> >> > I wonder which benefits we get for this price we are paying? >> >> The main reason I'd like to introduce this upgrade is for I want to >> add the compressing >> feature for uboot. > > This should be make optional code, including any extensions / > additional functions that may be needed for zlib. > > Most users will not need this, and they should not suffer (in terms of > increased memory footprint) from such a change. > >> And the 1.2.6 has some fix for the deflate, so it >> is maybe a good >> base line for introducing it. > > Which exact fix are you referring to? I am referring to the zlib 1.2.5->1.2.6 changelog: Added deflatePending() to return the amount of pending output Allow deflateSetDictionary() and inflateSetDictionary() at any time in raw mode deflatePrime() can now insert bits in the middle of the stream > >> How about define a Macro like CONIFG_ENABLE_GZIP_COMPRESSION to compile >> the compression related code only when this flag is on? > > This makes sense, but please use standard naming rules. You will > probably provide a "zip" command, so make all this depend on > "CONFIG_CMD_ZIP" or so. Yep, that is also what I am thinking. > > Best regards, > > Wolfgang Denk Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: zlib: update to 1.2.6
Hi Wolfgang, On Wed, Mar 7, 2012 at 10:30 PM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message > you > wrote: >> >> I miss add the zconf.h into the patch... >> V2 patch is attached... > > Argh. Please NEVER send patches as attachments. Always send them > inline. See http://www.denx.de/wiki/U-Boot/Patches Sorry for that again. I send the patch as attachment, which is only for RFC, and another reason is the patch itself is very huge and almost all content is kept as it is from zlib main stream. Anyway, I would keep the send patch rule in mind next time. > >> As it copy from zlib home page, the improvement from 1.2.5 to 1.2.6 >> contains following: >> >> gzread() can now read a file that is being written concurrently >> gzgetc() is now a macro for increased speed >> Added a 'T' option to gzopen() for transparent writing (no compression) >> Added deflatePending() to return the amount of pending output >> Allow deflateSetDictionary() and inflateSetDictionary() at any time in >> raw mode >> deflatePrime() can now insert bits in the middle of the stream >> ./configure now creates a configure.log file with all of the results >> Added a ./configure --solo option to compile zlib with no dependency on >> any libraries >> Fixed a problem with large file support macros >> Fixed a bug in contrib/puff >> Many portability improvements > > This is a lot of changes / improvements for genral use, but which of > these are actually useful for U-Boot? > > I. e. what exactly is the motivation to switch to a new version of the > code? Do you want to fix any specific bugs, or improve performance, > or what? > > What I see is that the code size grows by about 2 kB (measured on > ARM): > > -> bloat-o-meter u-boot-before u-boot-after > add/remove: 23/2 grow/shrink: 2/5 up/down: 4523/-2496 (2027) > function old new delta > static.lenfix - 2048 +2048 > inflateCopy - 352 +352 > updatewindow - 308 +308 > inflateSync - 276 +276 > inflateSetDictionary - 192 +192 > static.adler32_combine_ - 156 +156 > inflateReset2 - 152 +152 > inflateResetKeep - 148 +148 > static.distfix - 128 +128 > inflatePrime - 116 +116 > inflateMark - 104 +104 > syncsearch - 84 +84 > zmemcmp - 68 +68 > inflateSyncPoint - 64 +64 > inflateGetHeader - 64 +64 > inflate_copyright - 47 +47 > inflateUndermine - 44 +44 > inflate 5764 5800 +36 > zmemzero - 28 +28 > zmemcpy - 28 +28 > zError - 24 +24 > adler32_combine64 - 20 +20 > adler32_combine - 20 +20 > zlibVersion - 12 +12 > zunzip 264 268 +4 > inflateEnd 108 100 -8 > inflateInit2_ 264 208 -56 > inflate_table 1492 1428 -64 > inflateReset 128 48 -80 > inflate_fast 1480 1368 -112 > distfix 128 - -128 > lenfix 2048 - -2048 > > > I wonder which benefits we get for this price we are paying? The main reason I'd like to introduce this upgrade is for I want to add the compressing feature for uboot. And the 1.2.6 has some fix for the deflate, so it is maybe a good base line for introducing it. Also the reason why I want to enable the compressing is that sometimes we may want to dump whole ram in the uboot, and since the ram grows bigger and bigger, compressing and then send to host is a reasonable method to reduce the dumping time. How about define a Macro like CONIFG_ENABLE_GZIP_COMPRESSION to compile the compression related code only when this flag is on? > > Best regards, > > Wolfgang Denk Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: zlib: update to 1.2.6
Hi Mike, On Wed, Mar 7, 2012 at 12:15 AM, Mike Frysinger wrote: > On Tuesday 06 March 2012 03:55:19 Lei Wen wrote: >> In this patch, I update the current zlib from 1.2.5 to 1.2.6. >> >> There is a lot of warnings when using checkpatch script, I don't know >> whether I should fix it or not... >> Since it is just copy from as it is from upstream zlib 1.2.6, so I didn't >> do the correction, so don't be panic when use checkpatch. > > did you test the performance ? i found it went down a bit which is why i > didn't post a patch to update it to a newer version. improvements in API's we > don't use aren't a good reason for updating ... I didn't do the performance test... Just did the compile and bring up a gziped kernel with the update zlib. Is there some easy test case which could run in the uboot to show the unzip speed? I'd like to help to test it... But your saying is right, we should always focus on our current usage. > -mike Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nand_util: correct YAFFS image write function
On Sat, Jan 21, 2012 at 4:46 AM, Scott Wood wrote: > On 01/20/2012 12:17 AM, Kassey Lee wrote: >> hi, Lei, Scott: >> I think this is correct, >> do you have some comments ? > > Looks right. > > -Scott Also looks fine to me. Acked-by: Lei Wen Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers/mmc/mv_sdhci.c: Fix build warning
Hi Anatolij, On Thu, Dec 8, 2011 at 5:47 AM, Anatolij Gustschin wrote: > Fix: > mv_sdhci.c: In function 'mv_sdh_init': > mv_sdhci.c:47:22: warning: the comparison will always > evaluate as 'true' for the address of 'mv_sdhci_writeb' > will never be NULL [-Waddress] > > Signed-off-by: Anatolij Gustschin > Cc: Lei Wen > Cc: Andy Fleming > --- > drivers/mmc/mv_sdhci.c | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c > index 1501974..2fe34b6 100644 > --- a/drivers/mmc/mv_sdhci.c > +++ b/drivers/mmc/mv_sdhci.c > @@ -44,8 +44,7 @@ int mv_sdh_init(u32 regbase, u32 max_clk, u32 min_clk, u32 > quirks) > host->quirks = quirks; > #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS > memset(&mv_ops, 0, sizeof(struct sdhci_ops)); > - if (mv_sdhci_writeb != NULL) > - mv_ops.write_b = mv_sdhci_writeb; > + mv_ops.write_b = mv_sdhci_writeb; > host->ops = &mv_ops; > #endif > if (quirks & SDHCI_QUIRK_REG32_RW) > -- > 1.7.5.4 > > _______ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Thanks for pointing it out! Acked-by: Lei Wen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "mmc: retry the cmd8 to meet 74 clocks requirement in the spec"
On Tue, Nov 15, 2011 at 5:35 PM, Macpaul Lin wrote:
> This reverts commit 02f3029f1810b99869254d0cf0a71946a008a728.
>
> This patch add 3 times retry to CMD8 because the Marvell mmc controller
> doesn't obey the power ramp up process in the SD specification 6.4.1.
> (Please refer to figure 6.1 and 6.2 in the specification.)
>
> The CMD0 should be send after power ramp up has been finished.
> However, the Marvell mmc contorller must do power ramp up after the
> first CMD0 command has been send.
>
> This patch also affect existing platforms like Nokia N900 and other
> platforms.
>
> Signed-off-by: Macpaul Lin
> ---
> drivers/mmc/mmc.c | 16 ++--
> 1 files changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> index 37ce6e8..21665ec 100644
> --- a/drivers/mmc/mmc.c
> +++ b/drivers/mmc/mmc.c
> @@ -1190,7 +1190,7 @@ block_dev_desc_t *mmc_get_dev(int dev)
>
> int mmc_init(struct mmc *mmc)
> {
> - int err, retry = 3;
> + int err;
>
> if (mmc->has_init)
> return 0;
> @@ -1213,19 +1213,7 @@ int mmc_init(struct mmc *mmc)
> mmc->part_num = 0;
>
> /* Test for SD version 2 */
> - /*
> - * retry here for 3 times, as for some controller it has dynamic
> - * clock gating, and only toggle out clk when the first cmd0 send
> - * out, while some card strictly obey the 74 clocks rule, the interval
> - * may not be sufficient between the cmd0 and this cmd8, retry to
> - * fulfil the clock requirement
> - */
> - do {
> - err = mmc_send_if_cond(mmc);
> - } while (--retry > 0 && err);
> -
> - if (err)
> - return err;
> + err = mmc_send_if_cond(mmc);
>
> /* Now try to get the SD card's operating condition */
> err = sd_send_op_cond(mmc);
> --
> 1.7.3.5
>
>
Acked-by: Lei Wen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
Hi Macpaul, On Tue, Nov 15, 2011 at 11:34 AM, Macpaul Lin wrote: > HI Lei Wen, > > 2011/11/14 Lei Wen : >> Hi Macpaul, >> >>>> It seems some socs always treat cmd8 as failed...? >>>> I think it is reasonable to add a quirk configuration surround the >>>> judgement >>>> of cmd8 execution, so that even it is failed anyway, it could still go on >>>> with >>>> the following cmd sequence. If this quirk is not defined, and return >>>> behavior >>>> is still kept. >>>> >>>> What do you think for this? >>>> >>>> Thanks, >>>> Lei >>>> > > For easily to discuss about this problem, I've stripped the part from > SD specification 3.0 as you mentioned. > > Figure 6.1 > http://i.imgur.com/bmoAX.jpg > Figure 6.2 > http://i.imgur.com/7fxdx.jpg > > As you can see, after the power ramp up to 74 clocks (1msec), the CMD0 > can be send to the card. > > So it seems your controller will do power ramp up (dynamic clock > gating?) "only after" the CMD0 has been send? > Is this correct? However, it is weird and seem not followed the specification. Yes, our controller use dynamic control gating for clock. The clock is not sample out while no command send out. > > Since only SD 2.0 cards can adopted with CMD8, other cards older than > SD 2.0 should treat CMD8 as timeout (I guess). > So CMD8 might be important for us to distinguish the command sequence. > Sending CMD8 many times might really introduce problem for other cards. I realize now we at least cannot directly return err if the cmd8 is not succeed. Please submit a patch to fix it. Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
Hi Macpaul, On Mon, Nov 14, 2011 at 2:36 PM, Macpaul Lin wrote: > Hi Lei Wen, > > 2011/11/14 Lei Wen : >> Hi Macpaul, >> >> I see... >> It seems some socs always treat cmd8 as failed...? >> I think it is reasonable to add a quirk configuration surround the judgement >> of cmd8 execution, so that even it is failed anyway, it could still go on >> with >> the following cmd sequence. If this quirk is not defined, and return behavior >> is still kept. >> >> What do you think for this? >> >> Thanks, >> Lei >> > > I've not check this with the SD phy specification. > The command process should be backward compatible between 3.0 and 1.0. > > Could you please provide this more detail with the specification? > For example, could you please provide what section in the specification > and how the state machine in MMC card should be operated. > Then we can check it more detail and see if the solution is reasonable. The 74 clock requirement is mentioned in both sd[1] and mmc spec[2]. [1] page 91, section 6.4.1 power up, SD specification, part 1, Physical layer Simplificated Specification, version 2.0 [2] page 54, section 7.3.1 Card reset to pre-idle state, JESD84-A44 > > Moreover, if you could provide where the Linux code is related to the problem > and how dose Linux deal with this problem will be good, also. For linux, it would direcly clear the HIGH SPEED flag for following mmc_send_app_op_cond(). Linux v3.2-rc1: drivers/mmc/core/sd.c: line 712 > > As you said in patch, "some card strictly obey the 74 clocks rule", > could you provide the information of the card that you're using? The card we met trouble on is SanDisk 8GB class4 sd card. > > Add #ifdef to the code is a quick solution, but I think the we need to > figure out if there is other method > to help on 74 clock adoptable on more general case. > > -- > Best regards, > Macpaul Lin > Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
Hi Macpaul, On Mon, Nov 14, 2011 at 2:14 PM, Macpaul Lin wrote: > HI Lei Wen, > > 2011/11/12 Macpaul Lin : >> Hi Lei Wen, >> >> 2011/11/12 Lei Wen : >>> Hi Pali, >>> >> I have got 3 times retry fail on CMD8 also with FTSDC010 in recent, too. >> But I'm not sure where the problem is and hasn't start to check bisect >> with the commits. >> It works really fine before. >> That's why I asked Andy to stop review the performance improvement of >> FTSDC010. >> Maybe we'll need to check it again where the affect is started.-- >> Best regards, >> Macpaul Lin >> > > I have done the testing of the commit related to mmc generic stack of > Lei Wen's commit. > The problem indeed occur when we add 3 retry to CMD8. > After reverting this patch with the origin ftsdc010 driver (which is > in master branch alredy), > all works fine again. > > The following is the command flow with origin mmc stack. > When I'm using card which version is SD 1.10, the CMD8 will timeout > directly then card identification will continue. > > cmd 0 > cmd: 8 > ftsdc010_pio_check_status: RSP timeout: sta: 0004 cmd 8 > cmd: 55 > cmd: 41 > cmd: 55... > > If we add 3 retry to CMD8, the card will reply timeout 3 times than stop. > It won't go to CMD55. > cmd: 0 > cmd: 8 > ftsdc010_pio_check_status: RSP timeout: sta: 0404 cmd 8 > cmd: 8 > ftsdc010_pio_check_status: RSP timeout: sta: 0404 cmd 8 > cmd: 8 > ftsdc010_pio_check_status: RSP timeout: sta: 0404 cmd 8 > > I see... It seems some socs always treat cmd8 as failed...? I think it is reasonable to add a quirk configuration surround the judgement of cmd8 execution, so that even it is failed anyway, it could still go on with the following cmd sequence. If this quirk is not defined, and return behavior is still kept. What do you think for this? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728
Hi Pali, On Sat, Nov 12, 2011 at 7:17 AM, Pali Rohár wrote: > Hello, > > after commit 02f3029f1810b99869254d0cf0a71946a008a728 mmc: retry the cmd8 to > meet 74 clocks requirement in the spec > > internal eMMC memory on Nokia N900 in u-boot not working. If I comment code > "if (err) return err;" added by this commit, eMMC working fine. > > More info: mmc_send_if_cond from drivers/mmc/mmc.c is calling function > mmc_send_cmd in drivers/mmc/omap_hsmmc.c which returning TIMEOUT from line > 278: > if ((mmc_stat & IE_CTO) != 0) > return TIMEOUT; > > -- > Pali Rohár > pali.ro...@gmail.com > It is strange that your card would still get failed to send CMD8 after 3 times retry. Does omap mmc controller has some mechanism of mmc dynamic clock gating? I would suggest you to investigate why the emmc cannot response to CMD8 first. If not, I think we could make this err return code included in a ifdef to workaround your issue. Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 0/5] fix and enhancement patches for sdhci
Hi Andy, On Tue, Oct 18, 2011 at 10:58 PM, Lei Wen wrote: > Hi Andy, > > On Sat, Oct 8, 2011 at 10:14 PM, Lei Wen wrote: >> This seris fix several issue like flush cache and build warning. And >> give this generic driver enhancement for timeout when transferring data >> and additional structure member to access in platform self driver. >> >> Changelog: >> V2: code style change. >> V3: add another fix of sdma handling bug including in this series >> V4: minor code style change >> >> Lei Wen (5): >> mmc: sdhci: fix cache flush >> mmc: sdhci: fix build warning >> mmc: sdhci: add mmc structure for host >> mmc: sdhci: add timeout for data transfer >> mmc: sdhci: fix sdma bug for large file transfer >> >> drivers/mmc/sdhci.c | 14 +++--- >> include/sdhci.h | 6 ++ >> 2 files changed, 17 insertions(+), 3 deletions(-) >> > > Any comment for this patch series? > Any comments? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: mv_sdhci: Fix host version read for Armada100
Hi Ajay,
On Tue, Nov 1, 2011 at 5:39 PM, Ajay Bhargav
wrote:
> sdhci_readw does not work for host version read in Armada100 series
> SoCs. This patch fix this issue by making a sdhci_readl call to get host
> version.
>
> Signed-off-by: Ajay Bhargav
> ---
> drivers/mmc/mv_sdhci.c | 6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index f92caeb..c7fd287 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -30,6 +30,7 @@ static inline void mv_sdhci_writeb(struct sdhci_host *host,
> u8 val, int reg)
> #endif /* CONFIG_MMC_SDHCI_IO_ACCESSORS */
>
> static char *MVSDH_NAME = "mv_sdh";
> +
> int mv_sdh_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks)
> {
> struct sdhci_host *host = NULL;
> @@ -48,7 +49,12 @@ int mv_sdh_init(u32 regbase, u32 max_clk, u32 min_clk, u32
> quirks)
> mv_ops.write_b = mv_sdhci_writeb;
> host->ops = &mv_ops;
> #endif
> +#ifdef CONFIG_ARMADA100
You should following my previous fixing sample to add the workaround:
http://patchwork.ozlabs.org/patch/117575/
Just keep in mind that, it is generic driver and don't put private
fixing there. :)
Thanks,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] part_efi: fix build warning
part_efi.c: In function 'print_part_efi':
part_efi.c:133: warning: passing argument 3 of 'is_gpt_valid' from
incompatible pointer type
part_efi.c:95: note: expected 'struct gpt_header *' but argument is of
type 'struct gpt_header **'
part_efi.c: In function 'get_partition_info_efi':
part_efi.c:172: warning: passing argument 3 of 'is_gpt_valid' from
incompatible pointer type
part_efi.c:95: note: expected 'struct gpt_header *' but argument is of
type 'struct gpt_header **'
Signed-off-by: Lei Wen
---
disk/part_efi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index e7f2714..ddf80a7 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -130,7 +130,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
}
/* This function validates AND fills in the GPT header and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
-&(gpt_head), &gpt_pte) != 1) {
+gpt_head, &gpt_pte) != 1) {
printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
return;
}
@@ -169,7 +169,7 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc, int
part,
/* This function validates AND fills in the GPT header and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
- &(gpt_head), &gpt_pte) != 1) {
+ gpt_head, &gpt_pte) != 1) {
printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
return -1;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] armada100: define CONFIG_SYS_CACHELINE_SIZE
By default, on Armada100 SoC DCache Lnd ICache line lengths are 32 bytes long Signed-off-by: Lei Wen --- arch/arm/include/asm/arch-armada100/config.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-armada100/config.h b/arch/arm/include/asm/arch-armada100/config.h index d2094e5..637f313 100644 --- a/arch/arm/include/asm/arch-armada100/config.h +++ b/arch/arm/include/asm/arch-armada100/config.h @@ -33,6 +33,8 @@ #include #define CONFIG_ARM926EJS 1 /* Basic Architecture */ +/* default Dcache Line length for armada100 */ +#define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TCLK(14745600) /* NS16550 clk config */ #define CONFIG_SYS_HZ_CLOCK(325) /* Timer Freq. 3.25MHZ */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] pantheon: define CONFIG_SYS_CACHELINE_SIZE
By default, on Pantheon SoC DCache Lnd ICache line lengths are 32 bytes long Signed-off-by: Lei Wen --- arch/arm/include/asm/arch-pantheon/config.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-pantheon/config.h b/arch/arm/include/asm/arch-pantheon/config.h index d10583d..e4fce7d 100644 --- a/arch/arm/include/asm/arch-pantheon/config.h +++ b/arch/arm/include/asm/arch-pantheon/config.h @@ -28,6 +28,8 @@ #include #define CONFIG_ARM926EJS 1 /* Basic Architecture */ +/* default Dcache Line length for pantheon */ +#define CONFIG_SYS_CACHELINE_SIZE 32 #define CONFIG_SYS_TCLK(14745600) /* NS16550 clk config */ #define CONFIG_SYS_HZ_CLOCK(325) /* Timer Freq. 3.25MHZ */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] fix build error for pantheon and armada100
For the CONFIG_SYS_CACHELINE_SIZE is required to be defined defaultly. Add it to pantheon and armada100 accordingly. Lei Wen (2): pantheon: define CONFIG_SYS_CACHELINE_SIZE armada100: define CONFIG_SYS_CACHELINE_SIZE arch/arm/include/asm/arch-armada100/config.h |2 ++ arch/arm/include/asm/arch-pantheon/config.h |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/4] add mmc support for pantheon platform
Hi Albert, On Tue, Oct 25, 2011 at 2:25 PM, Albert ARIBAUD wrote: > Le 25/10/2011 08:15, Albert ARIBAUD a écrit : >> >> Hi Lei Wen, >> >> Le 25/10/2011 03:21, Lei Wen a écrit : >>> >>> Hi Albert, >>> >>> On Tue, Oct 25, 2011 at 1:20 AM, Albert ARIBAUD >>> wrote: >>>> >>>> Hi Lei Wen, >>>> >>>> Le 04/10/2011 08:33, Lei Wen a écrit : >>>>> >>>>> This patch seris add the mmc support for the pantheon platform. >>>>> Also give platform like dkb and aspenite a workaround when enabling >>>>> the 8bit mode for accessing the mmc. >>>>> >>>>> Changelog: >>>>> V2: remove magic number, and replace it by macro definition and >>>>> structure >>>>> respectively. >>>>> remove enable mmc function into seperated patch >>>>> >>>>> Lei Wen (4): >>>>> ARM: pantheon: add mmc definition >>>>> Marvell: dkb: add mmc support >>>>> dkb: make mmc command as default enabled >>>>> mmc: mv_sdhci: fix 8bus width access for 88SV331xV5 >>>> >>>> This causes a lot of build errors on dkb with ELDK42: >>>> >>>> Configuring for dkb board... >>>> In file included from mv_sdhci.c:3: >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:224: warning: 'struct >>>> sdhci_host' declared inside parameter list >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:224: warning: its scope is >>>> only this definition or declaration, which is probably not what you want >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:225: warning: 'struct >>>> sdhci_host' declared inside parameter list >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:226: warning: 'struct >>>> sdhci_host' declared inside parameter list >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:227: warning: 'struct >>>> sdhci_host' declared inside parameter list >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:228: warning: 'struct >>>> sdhci_host' declared inside parameter list >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:229: warning: 'struct >>>> sdhci_host' declared inside parameter list >>>> /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_writel': >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:247: warning: passing >>>> argument 1 of 'host->ops->write_l' from incompatible pointer type >>>> /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_writew': >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:255: warning: passing >>>> argument 1 of 'host->ops->write_w' from incompatible pointer type >>>> /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_writeb': >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:263: warning: passing >>>> argument 1 of 'host->ops->write_b' from incompatible pointer type >>>> /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_readl': >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:271: warning: passing >>>> argument 1 of 'host->ops->read_l' from incompatible pointer type >>>> /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_readw': >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:279: warning: passing >>>> argument 1 of 'host->ops->read_w' from incompatible pointer type >>>> /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_readb': >>>> /home/uboot/src/u-boot-arm/include/sdhci.h:287: warning: passing >>>> argument 1 of 'host->ops->read_b' from incompatible pointer type >>>> mv_sdhci.c: In function 'mv_sdhci_writeb': >>>> mv_sdhci.c:14: error: 'struct sdhci_host' has no member named 'mmc' >>>> mv_sdhci.c:17: warning: implicit declaration of function 'IS_SD' >>>> mv_sdhci.c:18: error: dereferencing pointer to incomplete type >>>> mv_sdhci.c: In function 'mv_sdh_init': >>>> mv_sdhci.c:48: warning: assignment from incompatible pointer type >>>> >>> >>> Actually, I have post another fixing series before this, so if it got >>> be applied before this merged, >>> the warning would be disappeared. >>> >>> You could refer to: >>> http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/111621 >> >> Thanks for the pointer -- please next time indicate the dependency on >> any patch set not yet applied at the time. > > I've tried applying the patches in the link you refer to, then the patch > series given here, but the latter does not apply properly above the former > on top of u-boot-arm/master. Can you check this? > >>> Best regards, >>> Lei > > I try to rebase the V4 of sdhci fixing patch over latest u-boot-arm.git, and find there is no problem... Could you help check again? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: orion5x: reduce dependence of including platform file
Hi Prafulla, On Thu, Oct 27, 2011 at 5:02 PM, Prafulla Wadaskar wrote: > > >> -Original Message----- >> From: Lei Wen [mailto:lei...@marvell.com] >> Sent: Wednesday, October 26, 2011 7:52 AM >> To: Wolfgang Denk; Albert ARIBAUD; Prafulla Wadaskar; u- >> b...@lists.denx.de >> Subject: [PATCH V2] ARM: orion5x: reduce dependence of >> including platform file >> >> For files like the drivers/serial/serial.c, it must include the >> platform file, as the CONFIG_SYS_NS16550_COM1 must reference to >> the definition in the platform definition files. >> >> Include the platform definition file in the config file, so >> that it >> would decouple the dependence for the driver files. >> >> Signed-off-by: Lei Wen >> --- >> Changelog: >> V2: seperate orion5x define structure as kirkwood and armada >> does >> >> arch/arm/cpu/arm926ejs/orion5x/cpu.c | 2 + >> arch/arm/cpu/arm926ejs/orion5x/dram.c | 1 + >> arch/arm/cpu/arm926ejs/orion5x/timer.c | 1 + >> arch/arm/include/asm/arch-orion5x/config.h | 135 >> ++ >> arch/arm/include/asm/arch-orion5x/orion5x.h | 6 - >> common/cmd_ide.c | 6 - >> include/configs/edminiv2.h | 166 + > > I think you are mixing two objective in one patch here. > > 1. using mv-common.h for orion5x platforms. > 2. orion5x: reduce dependence of including platform file (i.e. ide, serial) > > May you please split them accordingly? > > ...snip >> diff --git a/arch/arm/include/asm/arch-orion5x/config.h >> b/arch/arm/include/asm/arch-orion5x/config.h >> new file mode 100644 >> index 000..6db3554 >> --- /dev/null >> +++ b/arch/arm/include/asm/arch-orion5x/config.h >> @@ -0,0 +1,135 @@ >> +/* >> + * (C) Copyright 2011 >> + * Marvell Semiconductor >> + * Written-by: Lei Wen >> + * >> + * See file CREDITS for list of people who contributed to this >> + * project. >> + * >> + * This program is free software; you can redistribute it >> and/or >> + * modify it under the terms of the GNU General Public License >> as >> + * published by the Free Software Foundation; either version 2 >> of >> + * the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be >> useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty >> of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See >> the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public >> License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, >> + * MA 02110-1301 USA >> + */ >> + >> +/* >> + * This file should be included in board config header file. >> + * >> + * It supports common definitions for Orion platform >> + */ >> + >> +#ifndef _ORION_CONFIG_H >> +#define _ORION_CONFIG_H >> + >> +#include >> +#define MV_UART_CONSOLE_BASE ORION5X_UART0_BASE >> + >> +/* >> + * Board-specific values for Orion5x MPP low level init: >> + * - MPPs 12 to 15 are SATA LEDs (mode 5) >> + * - Others are GPIO/unused (mode 3 for MPP0, mode 5 for >> + * MPP16 to MPP19, mode 0 for others >> + */ >> + >> +#define ORION5X_MPP0_7 0x0003 >> +#define ORION5X_MPP8_15 0x >> +#define ORION5X_MPP16_23 0x >> + >> +/* >> + * Board-specific values for Orion5x GPIO low level init: >> + * - GPIO3 is input (RTC interrupt) >> + * - GPIO16 is Power LED control (0 = on, 1 = off) >> + * - GPIO17 is Power LED source select (0 = CPLD, 1 = GPIO16) >> + * - GPIO18 is Power Button status (0 = Released, 1 = Pressed) >> + * - Last GPIO is 26, further bits are supposed to be 0. >> + * Enable mask has ones for INPUT, 0 for OUTPUT. >> + * Default is LED ON. >> + */ >> + >> +#define ORION5X_GPIO_OUT_ENABLE 0x03fc >> +#define ORION5X_GPIO_OUT_VALUE 0x03fc > > MPP and GPIO configs are specific to each board and must go to board config > file > It seems to me that orion5x fixing patch already merged in both u-boot-marvell.git and u-boot-arm.git. And I try to build the edminiv2_config in both git, no preview warning at all... So it seems this v2 patch could be abondoned... Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: orion5x: reduce dependence of including platform file
Hi Wolfgang, On Wed, Oct 26, 2011 at 2:50 AM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message > you > wrote: >> >> >> +#include >> > >> > I don't like this. >> > >> > >> > Board config files MUST NOT do any such includes. Keep in mind that >> > one day we might want to try something like Kconfig, so board config >> > files should ONLY contain configuration information in the form of >> > #define's and the like. >> > >> > NAK. >> >> I should admit I have some bit of confusing here... >> What I see there are lots of include in the config file, 742 include >> usage case in the config files...: >> $ grep -Rn "#include" include/configs | wc -l >> 742 > > There are includes. Some of them are OK, some aren't and should be > fixed. > > More than half of your number are "#include " > which are perfectly fine. > > > For example, it's also perfectly fine if all boards that are similar > or that provide a similar look & feel (for example, because they come > from a single vendor) include a common configuration file. Such > examples are #include "amcc-common.h", #include "mv-common.h", > #include , #include "manroland/common.h", > etc. etc. etc. > > On the other hand, files from asm/arch/* should never define any > config settings - if it cannot be avoided they may provide register > definitions and the like, but any "#define CONFIG_*" has no place > there. > Thanks for your detailed explanation! I post another patch to address those issues you have mentioned. Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] ARM: orion5x: reduce dependence of including platform file
For files like the drivers/serial/serial.c, it must include the
platform file, as the CONFIG_SYS_NS16550_COM1 must reference to
the definition in the platform definition files.
Include the platform definition file in the config file, so that it
would decouple the dependence for the driver files.
Signed-off-by: Lei Wen
---
Changelog:
V2: seperate orion5x define structure as kirkwood and armada does
arch/arm/cpu/arm926ejs/orion5x/cpu.c|2 +
arch/arm/cpu/arm926ejs/orion5x/dram.c |1 +
arch/arm/cpu/arm926ejs/orion5x/timer.c |1 +
arch/arm/include/asm/arch-orion5x/config.h | 135 ++
arch/arm/include/asm/arch-orion5x/orion5x.h |6 -
common/cmd_ide.c|6 -
include/configs/edminiv2.h | 166 +--
7 files changed, 141 insertions(+), 176 deletions(-)
create mode 100644 arch/arm/include/asm/arch-orion5x/config.h
diff --git a/arch/arm/cpu/arm926ejs/orion5x/cpu.c
b/arch/arm/cpu/arm926ejs/orion5x/cpu.c
index 05bd45c..2b0c760 100644
--- a/arch/arm/cpu/arm926ejs/orion5x/cpu.c
+++ b/arch/arm/cpu/arm926ejs/orion5x/cpu.c
@@ -28,7 +28,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
diff --git a/arch/arm/cpu/arm926ejs/orion5x/dram.c
b/arch/arm/cpu/arm926ejs/orion5x/dram.c
index 5cc31a9..028f046 100644
--- a/arch/arm/cpu/arm926ejs/orion5x/dram.c
+++ b/arch/arm/cpu/arm926ejs/orion5x/dram.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
diff --git a/arch/arm/cpu/arm926ejs/orion5x/timer.c
b/arch/arm/cpu/arm926ejs/orion5x/timer.c
index 17df68f..0b49b69 100644
--- a/arch/arm/cpu/arm926ejs/orion5x/timer.c
+++ b/arch/arm/cpu/arm926ejs/orion5x/timer.c
@@ -25,6 +25,7 @@
*/
#include
+#include
#include
#define UBOOT_CNTR 0 /* counter to use for uboot timer */
diff --git a/arch/arm/include/asm/arch-orion5x/config.h
b/arch/arm/include/asm/arch-orion5x/config.h
new file mode 100644
index 000..6db3554
--- /dev/null
+++ b/arch/arm/include/asm/arch-orion5x/config.h
@@ -0,0 +1,135 @@
+/*
+ * (C) Copyright 2011
+ * Marvell Semiconductor
+ * Written-by: Lei Wen
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+/*
+ * This file should be included in board config header file.
+ *
+ * It supports common definitions for Orion platform
+ */
+
+#ifndef _ORION_CONFIG_H
+#define _ORION_CONFIG_H
+
+#include
+#define MV_UART_CONSOLE_BASE ORION5X_UART0_BASE
+
+/*
+ * Board-specific values for Orion5x MPP low level init:
+ * - MPPs 12 to 15 are SATA LEDs (mode 5)
+ * - Others are GPIO/unused (mode 3 for MPP0, mode 5 for
+ * MPP16 to MPP19, mode 0 for others
+ */
+
+#define ORION5X_MPP0_7 0x0003
+#define ORION5X_MPP8_150x
+#define ORION5X_MPP16_23 0x
+
+/*
+ * Board-specific values for Orion5x GPIO low level init:
+ * - GPIO3 is input (RTC interrupt)
+ * - GPIO16 is Power LED control (0 = on, 1 = off)
+ * - GPIO17 is Power LED source select (0 = CPLD, 1 = GPIO16)
+ * - GPIO18 is Power Button status (0 = Released, 1 = Pressed)
+ * - Last GPIO is 26, further bits are supposed to be 0.
+ * Enable mask has ones for INPUT, 0 for OUTPUT.
+ * Default is LED ON.
+ */
+
+#define ORION5X_GPIO_OUT_ENABLE0x03fc
+#define ORION5X_GPIO_OUT_VALUE 0x03fc
+
+#define CONFIG_SYS_INIT_SP_ADDR\
+ (CONFIG_SYS_SDRAM_BASE + 0x1000 - GENERATED_GBL_DATA_SIZE)
+#define CONFIG_NR_DRAM_BANKS_MAX 1
+/*
+ * FLASH configuration
+ */
+#define CONFIG_SYS_FLASH_CFI
+#define CONFIG_FLASH_CFI_DRIVER
+#define CONFIG_FLASH_CFI_LEGACY
+#define CONFIG_SYS_MAX_FLASH_BANKS 1 /* max num of flash banks */
+#define CONFIG_SYS_MAX_FLASH_SECT 11 /* max num of sects on one chip */
+#define CONFIG_SYS_FLASH_BASE 0xfff8
+#define CONFIG_SYS_FLASH_SECTSZ \
+ {16384, 8192, 8192, 32768, \
+65536, 65536, 65536, 65536, 65536, 65536, 65536}
+
+/*
+ * Network
+ */
+
+#ifdef CONFIG_CMD_NET
+#define CONFIG_MVGBE /* Enable Marvell GbE Driver */
+#define CONFIG_MVGBE_PORTS {1} /* enable port 0 only */
+#define
Re: [U-Boot] [PATCH V2 0/4] add mmc support for pantheon platform
Hi Wolfgang, On Wed, Oct 26, 2011 at 2:51 AM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message > you > wrote: >> >> >> Actually, I have post another fixing series before this, so if it got >> >> be applied before this merged, >> >> the warning would be disappeared. >> > >> > Then please squash your patches and submit a new, bug free patch. >> > >> > We don't add (knowingly) broken code and only fix it later. >> >> This patch seris itself is bug free indeed... >> But like Albert says, this one has a dependency with another, which >> means it should be applied with >> sequence... > > No, this patch and the other one should be squashed. Do you mean that I should merge this mmc adding patch and the sdhci fixing patch together as one patch? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/4] add mmc support for pantheon platform
Hi Wolfgang, On Tue, Oct 25, 2011 at 3:38 PM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message > you > wrote: >> >> Actually, I have post another fixing series before this, so if it got >> be applied before this merged, >> the warning would be disappeared. > > Then please squash your patches and submit a new, bug free patch. > > We don't add (knowingly) broken code and only fix it later. This patch seris itself is bug free indeed... But like Albert says, this one has a dependency with another, which means it should be applied with sequence... So how about hold this patch till its dependency patch set got in? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: orion5x: reduce dependence of including platform file
Hi Wolfgang, On Tue, Oct 25, 2011 at 3:43 PM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message <1319509652-5648-1-git-send-email-lei...@marvell.com> you wrote: >> For files like the drivers/serial/serial.c, it must include the >> platform file, as the CONFIG_SYS_NS16550_COM1 must reference to >> the definition in the platform definition files. >> >> Include the platform definition file in the config file, so that it >> would decouple the dependence for the driver files. > ... > >> --- a/include/configs/edminiv2.h >> +++ b/include/configs/edminiv2.h >> @@ -45,6 +45,7 @@ >> #define CONFIG_88F5182 1 /* SOC Name */ >> #define CONFIG_MACH_EDMINIV2 1 /* Machine type */ >> >> +#include > > I don't like this. > > > Board config files MUST NOT do any such includes. Keep in mind that > one day we might want to try something like Kconfig, so board config > files should ONLY contain configuration information in the form of > #define's and the like. > > NAK. I should admit I have some bit of confusing here... What I see there are lots of include in the config file, 742 include usage case in the config files...: $ grep -Rn "#include" include/configs | wc -l 742 Or should I directly hard coding the CONFIG_SYS_NS16550_COM1 insteading the macro ORION5X_UART0_BASE, since this macro is defined in arch/arm/include/asm/arch-orion5x/orion5x.h... Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: orion5x: reduce dependence of including platform file
For files like the drivers/serial/serial.c, it must include the platform file, as the CONFIG_SYS_NS16550_COM1 must reference to the definition in the platform definition files. Include the platform definition file in the config file, so that it would decouple the dependence for the driver files. Signed-off-by: Lei Wen --- arch/arm/cpu/arm926ejs/orion5x/cpu.c|3 ++- arch/arm/cpu/arm926ejs/orion5x/dram.c |2 +- arch/arm/cpu/arm926ejs/orion5x/timer.c |2 +- arch/arm/include/asm/arch-orion5x/orion5x.h |6 -- common/cmd_ide.c|6 -- include/configs/edminiv2.h |1 + 6 files changed, 5 insertions(+), 15 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/orion5x/cpu.c b/arch/arm/cpu/arm926ejs/orion5x/cpu.c index 05bd45c..792b11d 100644 --- a/arch/arm/cpu/arm926ejs/orion5x/cpu.c +++ b/arch/arm/cpu/arm926ejs/orion5x/cpu.c @@ -28,8 +28,9 @@ #include #include #include +#include #include -#include +#include #include #define BUFLEN 16 diff --git a/arch/arm/cpu/arm926ejs/orion5x/dram.c b/arch/arm/cpu/arm926ejs/orion5x/dram.c index 5cc31a9..c0f7ef1 100644 --- a/arch/arm/cpu/arm926ejs/orion5x/dram.c +++ b/arch/arm/cpu/arm926ejs/orion5x/dram.c @@ -27,7 +27,7 @@ #include #include -#include +#include DECLARE_GLOBAL_DATA_PTR; diff --git a/arch/arm/cpu/arm926ejs/orion5x/timer.c b/arch/arm/cpu/arm926ejs/orion5x/timer.c index 17df68f..e39ecc2 100644 --- a/arch/arm/cpu/arm926ejs/orion5x/timer.c +++ b/arch/arm/cpu/arm926ejs/orion5x/timer.c @@ -25,7 +25,7 @@ */ #include -#include +#include #define UBOOT_CNTR 0 /* counter to use for uboot timer */ diff --git a/arch/arm/include/asm/arch-orion5x/orion5x.h b/arch/arm/include/asm/arch-orion5x/orion5x.h index 9aeef88..18225b9 100644 --- a/arch/arm/include/asm/arch-orion5x/orion5x.h +++ b/arch/arm/include/asm/arch-orion5x/orion5x.h @@ -30,13 +30,7 @@ #ifndef _ASM_ARCH_ORION5X_H #define _ASM_ARCH_ORION5X_H -#ifndef __ASSEMBLY__ -#include -#include -#endif /* __ASSEMBLY__ */ - #if defined(CONFIG_FEROCEON) -#include /* SOC specific definations */ #define ORION5X_REGISTER(x)(ORION5X_REGS_PHY_BASE + x) diff --git a/common/cmd_ide.c b/common/cmd_ide.c index da5189c..d909c54 100644 --- a/common/cmd_ide.c +++ b/common/cmd_ide.c @@ -46,12 +46,6 @@ #include #endif -#ifdef CONFIG_ORION5X -#include -#elif defined CONFIG_KIRKWOOD -#include -#endif - #include #include diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index f8affa8..88d32b2 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -45,6 +45,7 @@ #define CONFIG_88F5182 1 /* SOC Name */ #define CONFIG_MACH_EDMINIV2 1 /* Machine type */ +#include /* * CLKs configurations */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] serial: reduce include platform file for marvell chip
Hi Albert, On Tue, Oct 25, 2011 at 12:46 AM, Albert ARIBAUD wrote: > Hi all, > > Le 02/10/2011 16:16, Lei Wen a écrit : >> >> Build pass with following config: >> dkb_config >> aspenite_config >> edminiv2_config >> openrd_ultimate_config >> sheevaplug_config >> mv88f6281gtw_ge_config >> rd6281a_config >> guruplug_config >> km_kirkwood_config >> >> Signed-off-by: Lei Wen >> --- >> drivers/serial/serial.c | 9 - >> 1 files changed, 0 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c >> index 0d56e78..0d6ad62 100644 >> --- a/drivers/serial/serial.c >> +++ b/drivers/serial/serial.c >> @@ -28,15 +28,6 @@ >> #ifdef CONFIG_NS87308 >> #include >> #endif >> -#ifdef CONFIG_KIRKWOOD >> -#include >> -#elif defined(CONFIG_ORION5X) >> -#include >> -#elif defined(CONFIG_ARMADA100) >> -#include >> -#elif defined(CONFIG_PANTHEON) >> -#include >> -#endif >> >> #if defined (CONFIG_SERIAL_MULTI) >> #include > > This breaks ED Mini V2 (orion5x) with the following message: > > serial.c:65: error: 'ORION5X_UART0_BASE' undeclared here (not in a function) > serial.c: In function 'calc_divisor': > serial.c:152: error: 'CONFIG_SYS_TCLK' undeclared (first use in this > function) > serial.c:152: error: (Each undeclared identifier is reported only once > serial.c:152: error: for each function it appears in.) > > Lei Wen, please provide a patch for orion5x as you provided for armada, > pantheon and kirkwood. > I see... My fault for this... I would post another patch to fix it. Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/4] add mmc support for pantheon platform
Hi Albert, On Tue, Oct 25, 2011 at 1:20 AM, Albert ARIBAUD wrote: > Hi Lei Wen, > > Le 04/10/2011 08:33, Lei Wen a écrit : >> This patch seris add the mmc support for the pantheon platform. >> Also give platform like dkb and aspenite a workaround when enabling >> the 8bit mode for accessing the mmc. >> >> Changelog: >> V2: remove magic number, and replace it by macro definition and structure >> respectively. >> remove enable mmc function into seperated patch >> >> Lei Wen (4): >> ARM: pantheon: add mmc definition >> Marvell: dkb: add mmc support >> dkb: make mmc command as default enabled >> mmc: mv_sdhci: fix 8bus width access for 88SV331xV5 > > This causes a lot of build errors on dkb with ELDK42: > > Configuring for dkb board... > In file included from mv_sdhci.c:3: > /home/uboot/src/u-boot-arm/include/sdhci.h:224: warning: 'struct > sdhci_host' declared inside parameter list > /home/uboot/src/u-boot-arm/include/sdhci.h:224: warning: its scope is > only this definition or declaration, which is probably not what you want > /home/uboot/src/u-boot-arm/include/sdhci.h:225: warning: 'struct > sdhci_host' declared inside parameter list > /home/uboot/src/u-boot-arm/include/sdhci.h:226: warning: 'struct > sdhci_host' declared inside parameter list > /home/uboot/src/u-boot-arm/include/sdhci.h:227: warning: 'struct > sdhci_host' declared inside parameter list > /home/uboot/src/u-boot-arm/include/sdhci.h:228: warning: 'struct > sdhci_host' declared inside parameter list > /home/uboot/src/u-boot-arm/include/sdhci.h:229: warning: 'struct > sdhci_host' declared inside parameter list > /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_writel': > /home/uboot/src/u-boot-arm/include/sdhci.h:247: warning: passing > argument 1 of 'host->ops->write_l' from incompatible pointer type > /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_writew': > /home/uboot/src/u-boot-arm/include/sdhci.h:255: warning: passing > argument 1 of 'host->ops->write_w' from incompatible pointer type > /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_writeb': > /home/uboot/src/u-boot-arm/include/sdhci.h:263: warning: passing > argument 1 of 'host->ops->write_b' from incompatible pointer type > /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_readl': > /home/uboot/src/u-boot-arm/include/sdhci.h:271: warning: passing > argument 1 of 'host->ops->read_l' from incompatible pointer type > /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_readw': > /home/uboot/src/u-boot-arm/include/sdhci.h:279: warning: passing > argument 1 of 'host->ops->read_w' from incompatible pointer type > /home/uboot/src/u-boot-arm/include/sdhci.h: In function 'sdhci_readb': > /home/uboot/src/u-boot-arm/include/sdhci.h:287: warning: passing > argument 1 of 'host->ops->read_b' from incompatible pointer type > mv_sdhci.c: In function 'mv_sdhci_writeb': > mv_sdhci.c:14: error: 'struct sdhci_host' has no member named 'mmc' > mv_sdhci.c:17: warning: implicit declaration of function 'IS_SD' > mv_sdhci.c:18: error: dereferencing pointer to incomplete type > mv_sdhci.c: In function 'mv_sdh_init': > mv_sdhci.c:48: warning: assignment from incompatible pointer type > Actually, I have post another fixing series before this, so if it got be applied before this merged, the warning would be disappeared. You could refer to: http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/111621 Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] eMMC Partitons handling
Hi Ulrich, On Fri, Oct 21, 2011 at 5:53 AM, Ulrich Prinz wrote: > Hi all! > > Is there any support for (e)MMC PARTITION handling in U-Boot anywhere? > I have an eMMC supporting Version 4.41 of JEDEC MMC specification and > I'd like to have PARTITION support to protect some of the MMCs areas > against access from other areas. It interconnects with Reliable Write > and Write Reliability, also from Version 4.x of the JEDEC spec. > > I hope U-Boot already supports this by some console commands? > The partition support is added already, you may use the m2011.09 release. And the command is like "mmc dev ". E.X: if you want to switch to the partition 1 of the first device. You could use as: mmc dev 0 1 Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] enable dcache for pantheon and armada100
Hi Prafulla, On Sat, Oct 8, 2011 at 9:59 PM, Lei Wen wrote: > This patch seris use Marvell its own special op code to flush the dcache > > Lei Wen (3): > ARM: add special dcache flush op code for 88SV331xV5 > ARM: pantheon: enable dcache by default > ARM: armada100: enable dcache by default > > arch/arm/cpu/arm926ejs/armada100/cpu.c | 8 > arch/arm/cpu/arm926ejs/pantheon/cpu.c | 8 > arch/arm/lib/cache.c | 5 + > 3 files changed, 21 insertions(+), 0 deletions(-) > Do you have any comment over this patch series? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 0/5] fix and enhancement patches for sdhci
Hi Andy, On Sat, Oct 8, 2011 at 10:14 PM, Lei Wen wrote: > This seris fix several issue like flush cache and build warning. And > give this generic driver enhancement for timeout when transferring data > and additional structure member to access in platform self driver. > > Changelog: > V2: code style change. > V3: add another fix of sdma handling bug including in this series > V4: minor code style change > > Lei Wen (5): > mmc: sdhci: fix cache flush > mmc: sdhci: fix build warning > mmc: sdhci: add mmc structure for host > mmc: sdhci: add timeout for data transfer > mmc: sdhci: fix sdma bug for large file transfer > > drivers/mmc/sdhci.c | 14 +++--- > include/sdhci.h | 6 ++ > 2 files changed, 17 insertions(+), 3 deletions(-) > Any comment for this patch series? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] mmc: change magic number to macro define
Hi Wolfgang,
On Sat, Oct 15, 2011 at 4:36 AM, Wolfgang Denk wrote:
> Dear Lei Wen,
>
> In message
> you
> wrote:
>>
>> > And both the "index" and "value" arguments are never used in I/O
>> > context, i. e. they are actual plain integer parameters. So just keep
>> > it as
>> >
>> > err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1);
>>
>> Should I also keep the EXT_CSD_HS_TIMING like macro for previous
>> ext_csd parsing?
>> Or just add another ext_csd structure definition to the parse the
>> ext_csd, while keep macros
>> to be called by mmc_switch?
>
> Let's try to understand what we are trying to acchieve. The purpose
> of using C structs instead of a notation of "base address + register
> offset" is that this way the struct entries that represent the
> registers now have types, and the compiler can perform proper type
> checking when using these data in I/O accessors.
>
> So we use structs to describe the "memory map" of the hardware, the
> mapping of device registers to addresses, and the data types give
> information about the width of the register (8, 16, 32, ... bit).
>
> Note that all the time we are talking about device registers and I/O
> operations - that is situations where I/O accessors will be used.
>
>
> On the other hand, when it comes to definitions of bit fields, like
> here:
>
> /*
> * EXT_CSD field definitions
> */
>
> #define EXT_CSD_CMD_SET_NORMAL (1 << 0)
> #define EXT_CSD_CMD_SET_SECURE (1 << 1)
> #define EXT_CSD_CMD_SET_CPSECURE (1 << 2)
> ...
>
> or of indexes, like here:
>
> /*
> * EXT_CSD fields
> */
>
> #define EXT_CSD_PART_CONF 179 /* R/W */
> #define EXT_CSD_BUS_WIDTH 183 /* R/W */
> #define EXT_CSD_HS_TIMING 185 /* R/W */
> ...
>
> ..then a struct makes no sense - we have plain integer constants
> here.
>
>
> To verify, please have a look at the code of mmc_switch():
>
> int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
> {
> struct mmc_cmd cmd;
> int timeout = 1000;
> int ret;
>
> cmd.cmdidx = MMC_CMD_SWITCH;
> cmd.resp_type = MMC_RSP_R1b;
> cmd.cmdarg = (MMC_SWITCH_MODE_WRITE_BYTE << 24) |
> (index << 16) |
> (value << 8);
> ...
> ret = mmc_send_cmd(mmc, &cmd, NULL);
>
>
> As you can see, the arguments are ORed together to form an argument
> to mmc_send_cmd() - they are not used in a I/O accessor or any
> similar function.
>
>
> In short: neither EXT_CSD_CMD_SET_NORMAL nor EXT_CSD_HS_TIMING
> describe a device register that is used in any form of I/O
> operations, so it is OK to leave these as simple #define's; the use
> of a struct would not make sense here.
>
Thanks for your kindly explaination on the c structure usage in UBOOT.
So should I keep the V2 version of this patch, or anything else need
to be modified?
Thanks,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Marvell: reduce dependence files
Hi Prafulla, On Fri, Oct 14, 2011 at 6:19 PM, Prafulla Wadaskar wrote: > Dear Lei > > I was pulling this patch series. > I found certain patches could not be applied, I had resolved them since > gplugd are in. > But I found certain warnings and errors if I build with aspenite_config > > May you please pull the u-boot-marvell.git master and rebase and resend your > patches with above resolution? I have resubmit the patch against latest u-boot-marvell.git, and test with aspenite and dkb config build. Please help to merge again. Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 5/5] gpio: mvmfp: reduce include platform file
Build pass with following config: dkb_config aspenite_config Signed-off-by: Lei Wen --- Changelog: V2: no change drivers/gpio/mvmfp.c |7 --- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/drivers/gpio/mvmfp.c b/drivers/gpio/mvmfp.c index e7830c6..f56c037 100644 --- a/drivers/gpio/mvmfp.c +++ b/drivers/gpio/mvmfp.c @@ -26,13 +26,6 @@ #include #include #include -#ifdef CONFIG_ARMADA100 -#include -#elif defined(CONFIG_PANTHEON) -#include -#else -#error Unsupported SoC... -#endif /* * mfp_config -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 4/5] serial: reduce include platform file for marvell chip
Build pass with following config: dkb_config aspenite_config edminiv2_config openrd_ultimate_config sheevaplug_config mv88f6281gtw_ge_config rd6281a_config guruplug_config km_kirkwood_config Signed-off-by: Lei Wen Acked-by: Wolfgang Denk --- Changelog: V2: no change drivers/serial/serial.c |9 - 1 files changed, 0 insertions(+), 9 deletions(-) diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c index 0d56e78..0d6ad62 100644 --- a/drivers/serial/serial.c +++ b/drivers/serial/serial.c @@ -28,15 +28,6 @@ #ifdef CONFIG_NS87308 #include #endif -#ifdef CONFIG_KIRKWOOD -#include -#elif defined(CONFIG_ORION5X) -#include -#elif defined(CONFIG_ARMADA100) -#include -#elif defined(CONFIG_PANTHEON) -#include -#endif #if defined (CONFIG_SERIAL_MULTI) #include -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/5] ARM: kirkwood: reduce dependence of including platform file
For files like the drivers/serial/serial.c, it must include the platform file, as the CONFIG_SYS_NS16550_COM1 must reference to the definition in the platform definition files. Include the platform definition file in the config file, so that it would decouple the dependence for the driver files. Signed-off-by: Lei Wen --- Changelog: V2: no change arch/arm/cpu/arm926ejs/kirkwood/cpu.c |2 ++ arch/arm/cpu/arm926ejs/kirkwood/dram.c |2 ++ arch/arm/cpu/arm926ejs/kirkwood/mpp.c |2 ++ arch/arm/cpu/arm926ejs/kirkwood/timer.c |1 + arch/arm/include/asm/arch-kirkwood/config.h |1 + arch/arm/include/asm/arch-kirkwood/kirkwood.h |6 -- board/Marvell/guruplug/guruplug.c |1 + board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |1 + board/Marvell/openrd/openrd.c |1 + board/Marvell/rd6281a/rd6281a.c |1 + board/Marvell/sheevaplug/sheevaplug.c |1 + board/keymile/km_arm/km_arm.c |1 + drivers/gpio/kw_gpio.c |1 + drivers/net/mvgbe.c |2 ++ drivers/spi/kirkwood_spi.c |1 + drivers/usb/host/ehci-kirkwood.c|1 + 16 files changed, 19 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/kirkwood/cpu.c b/arch/arm/cpu/arm926ejs/kirkwood/cpu.c index b4a4c04..8f04ddb 100644 --- a/arch/arm/cpu/arm926ejs/kirkwood/cpu.c +++ b/arch/arm/cpu/arm926ejs/kirkwood/cpu.c @@ -26,6 +26,8 @@ #include #include #include +#include +#include #include #include diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c b/arch/arm/cpu/arm926ejs/kirkwood/dram.c index 2441554..181b3e7 100644 --- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c +++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c @@ -24,6 +24,8 @@ #include #include +#include +#include #include DECLARE_GLOBAL_DATA_PTR; diff --git a/arch/arm/cpu/arm926ejs/kirkwood/mpp.c b/arch/arm/cpu/arm926ejs/kirkwood/mpp.c index b2f0ad5..3da6c98 100644 --- a/arch/arm/cpu/arm926ejs/kirkwood/mpp.c +++ b/arch/arm/cpu/arm926ejs/kirkwood/mpp.c @@ -10,6 +10,8 @@ */ #include +#include +#include #include #include diff --git a/arch/arm/cpu/arm926ejs/kirkwood/timer.c b/arch/arm/cpu/arm926ejs/kirkwood/timer.c index b4f6cf8..a98f54c 100644 --- a/arch/arm/cpu/arm926ejs/kirkwood/timer.c +++ b/arch/arm/cpu/arm926ejs/kirkwood/timer.c @@ -22,6 +22,7 @@ */ #include +#include #include #define UBOOT_CNTR 0 /* counter to use for uboot timer */ diff --git a/arch/arm/include/asm/arch-kirkwood/config.h b/arch/arm/include/asm/arch-kirkwood/config.h index b393b1a..f17f82d 100644 --- a/arch/arm/include/asm/arch-kirkwood/config.h +++ b/arch/arm/include/asm/arch-kirkwood/config.h @@ -39,6 +39,7 @@ #error "SOC Name not defined" #endif /* CONFIG_KW88F6281 */ +#include #define CONFIG_ARM926EJS 1 /* Basic Architecture */ #define CONFIG_MD5 /* get_random_hex on krikwood needs MD5 support */ diff --git a/arch/arm/include/asm/arch-kirkwood/kirkwood.h b/arch/arm/include/asm/arch-kirkwood/kirkwood.h index 3c843a0..0035ed5 100644 --- a/arch/arm/include/asm/arch-kirkwood/kirkwood.h +++ b/arch/arm/include/asm/arch-kirkwood/kirkwood.h @@ -27,13 +27,7 @@ #ifndef _ASM_ARCH_KIRKWOOD_H #define _ASM_ARCH_KIRKWOOD_H -#ifndef __ASSEMBLY__ -#include -#include -#endif /* __ASSEMBLY__ */ - #if defined (CONFIG_FEROCEON_88FR131) || defined (CONFIG_SHEEVA_88SV131) -#include /* SOC specific definations */ #define INTREG_BASE0xd000 diff --git a/board/Marvell/guruplug/guruplug.c b/board/Marvell/guruplug/guruplug.c index 1f0e67a..057c558 100644 --- a/board/Marvell/guruplug/guruplug.c +++ b/board/Marvell/guruplug/guruplug.c @@ -24,6 +24,7 @@ #include #include +#include #include #include #include "guruplug.h" diff --git a/board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c b/board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c index 80fd20b..4c41f3b 100644 --- a/board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c +++ b/board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c @@ -26,6 +26,7 @@ #include #include +#include #include #include #include "mv88f6281gtw_ge.h" diff --git a/board/Marvell/openrd/openrd.c b/board/Marvell/openrd/openrd.c index 87939de..2a10e69 100644 --- a/board/Marvell/openrd/openrd.c +++ b/board/Marvell/openrd/openrd.c @@ -29,6 +29,7 @@ #include #include +#include #include #include #include "openrd.h" diff --git a/board/Marvell/rd6281a/rd6281a.c b/board/Marvell/rd6281a/rd6281a.c index ecdea82..9c768bf 100644 --- a/board/Marvell/rd6281a/rd6281a.c +++ b/board/Marvell/rd6281a/rd6281a.c @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include "rd6281a.h" diff --git a/board/Marvell/sheevaplug/sheevaplug.c b/board/Marvell/sheevaplug/sheevaplug.c
[U-Boot] [PATCH V2 2/5] ARM: armada100: reduce dependence of including platform file
For files like the drivers/serial/serial.c, it must include the
platform file, as the CONFIG_SYS_NS16550_COM1 must reference to the
definition in the platform definition files.
Include the platform definition file in the config file, so that it
would decouple the dependence for the driver files.
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
arch/arm/cpu/arm926ejs/armada100/cpu.c |2 +-
arch/arm/cpu/arm926ejs/armada100/dram.c |1 +
arch/arm/cpu/arm926ejs/armada100/timer.c|1 +
arch/arm/include/asm/arch-armada100/armada100.h | 131 ---
arch/arm/include/asm/arch-armada100/config.h|1 +
arch/arm/include/asm/arch-armada100/cpu.h | 57 ++
board/Marvell/aspenite/aspenite.c |1 +
7 files changed, 62 insertions(+), 132 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/armada100/cpu.c
b/arch/arm/cpu/arm926ejs/armada100/cpu.c
index c21938e..14121a0 100644
--- a/arch/arm/cpu/arm926ejs/armada100/cpu.c
+++ b/arch/arm/cpu/arm926ejs/armada100/cpu.c
@@ -24,8 +24,8 @@
*/
#include
+#include
#include
-#include
#define UARTCLK14745KHZ(APBC_APBCLK | APBC_FNCLK | APBC_FNCLKSEL(1))
#define SET_MRVL_ID(1<<8)
diff --git a/arch/arm/cpu/arm926ejs/armada100/dram.c
b/arch/arm/cpu/arm926ejs/armada100/dram.c
index eacec23..8609004 100644
--- a/arch/arm/cpu/arm926ejs/armada100/dram.c
+++ b/arch/arm/cpu/arm926ejs/armada100/dram.c
@@ -24,6 +24,7 @@
*/
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
diff --git a/arch/arm/cpu/arm926ejs/armada100/timer.c
b/arch/arm/cpu/arm926ejs/armada100/timer.c
index 82a6d7b..fbade4b 100644
--- a/arch/arm/cpu/arm926ejs/armada100/timer.c
+++ b/arch/arm/cpu/arm926ejs/armada100/timer.c
@@ -24,6 +24,7 @@
*/
#include
+#include
#include
/*
diff --git a/arch/arm/include/asm/arch-armada100/armada100.h
b/arch/arm/include/asm/arch-armada100/armada100.h
index a8181b6..0ed3a8e 100644
--- a/arch/arm/include/asm/arch-armada100/armada100.h
+++ b/arch/arm/include/asm/arch-armada100/armada100.h
@@ -26,13 +26,7 @@
#ifndef _ASM_ARCH_ARMADA100_H
#define _ASM_ARCH_ARMADA100_H
-#ifndef __ASSEMBLY__
-#include
-#include
-#endif /* __ASSEMBLY__ */
-
#if defined (CONFIG_ARMADA100)
-#include
/* Common APB clock register bit definitions */
#define APBC_APBCLK (1<<0) /* APB Bus Clock Enable */
@@ -69,130 +63,5 @@
#define ARMD1_APMU_BASE0xD4282800
#define ARMD1_CPU_BASE 0xD4282C00
-/*
- * Main Power Management (MPMU) Registers
- * Refer Datasheet Appendix A.8
- */
-struct armd1mpmu_registers {
- u8 pad0[0x08 - 0x00];
- u32 fccr; /*0x0008*/
- u32 pocr; /*0x000c*/
- u32 posr; /*0x0010*/
- u32 succr; /*0x0014*/
- u8 pad1[0x030 - 0x014 - 4];
- u32 gpcr; /*0x0030*/
- u8 pad2[0x200 - 0x030 - 4];
- u32 wdtpcr; /*0x0200*/
- u8 pad3[0x1000 - 0x200 - 4];
- u32 apcr; /*0x1000*/
- u32 apsr; /*0x1004*/
- u8 pad4[0x1020 - 0x1004 - 4];
- u32 aprr; /*0x1020*/
- u32 acgr; /*0x1024*/
- u32 arsr; /*0x1028*/
-};
-
-/*
- * Application Subsystem Power Management
- * Refer Datasheet Appendix A.9
- */
-struct armd1apmu_registers {
- u32 pcr;/* 0x000 */
- u32 ccr;/* 0x004 */
- u32 pad1;
- u32 ccsr; /* 0x00C */
- u32 fc_timer; /* 0x010 */
- u32 pad2;
- u32 ideal_cfg; /* 0x018 */
- u8 pad3[0x04C - 0x018 - 4];
- u32 lcdcrc; /* 0x04C */
- u32 cciccrc;/* 0x050 */
- u32 sd1crc; /* 0x054 */
- u32 sd2crc; /* 0x058 */
- u32 usbcrc; /* 0x05C */
- u32 nfccrc; /* 0x060 */
- u32 dmacrc; /* 0x064 */
- u32 pad4;
- u32 buscrc; /* 0x06C */
- u8 pad5[0x07C - 0x06C - 4];
- u32 wake_clr; /* 0x07C */
- u8 pad6[0x090 - 0x07C - 4];
- u32 core_status;/* 0x090 */
- u32 rfsc; /* 0x094 */
- u32 imr;/* 0x098 */
- u32 irwc; /* 0x09C */
- u32 isr;/* 0x0A0 */
- u8 pad7[0x0B0 - 0x0A0 - 4];
- u32 mhst; /* 0x0B0 */
- u32 msr;/* 0x0B4 */
- u8 pad8[0x0C0 - 0x0B4 - 4];
- u32 msst; /* 0x0C0 */
- u32 pllss; /* 0x0C4 */
- u32 smb;/* 0x0C8 */
- u32 gccrc; /* 0x0CC */
- u8 pad9[0x0D4 - 0x0CC - 4];
- u32 smccrc; /* 0x0D4 */
- u32 pad10;
- u32 xdcrc; /* 0x0DC */
- u32 sd3crc; /* 0x0E0 */
- u32 sd4crc; /* 0x0E4 */
- u8 pad11[0x0F0 - 0x0E4 - 4];
- u32 cfcrc; /* 0x0F0 */
- u32 mspcrc;
[U-Boot] [PATCH V2 1/5] ARM: pantheon: reduce dependence of including platform file
For files like the drivers/serial/serial.c, it must include the platform file, as the CONFIG_SYS_NS16550_COM1 must reference to the definition in the platform definition files. Include the platform definition file in the config file, so that it would decouple the dependence for the driver files. Signed-off-by: Lei Wen --- Changelog: V2: no change arch/arm/cpu/arm926ejs/pantheon/cpu.c |2 +- arch/arm/cpu/arm926ejs/pantheon/dram.c|1 + arch/arm/cpu/arm926ejs/pantheon/timer.c |1 + arch/arm/include/asm/arch-pantheon/config.h |2 ++ arch/arm/include/asm/arch-pantheon/pantheon.h |7 --- 5 files changed, 5 insertions(+), 8 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/pantheon/cpu.c b/arch/arm/cpu/arm926ejs/pantheon/cpu.c index 8b2eafa..efc9395 100644 --- a/arch/arm/cpu/arm926ejs/pantheon/cpu.c +++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c @@ -23,8 +23,8 @@ */ #include +#include #include -#include #define UARTCLK14745KHZ(APBC_APBCLK | APBC_FNCLK | APBC_FNCLKSEL(1)) #define SET_MRVL_ID(1<<8) diff --git a/arch/arm/cpu/arm926ejs/pantheon/dram.c b/arch/arm/cpu/arm926ejs/pantheon/dram.c index bbca7ee..a3d719e 100644 --- a/arch/arm/cpu/arm926ejs/pantheon/dram.c +++ b/arch/arm/cpu/arm926ejs/pantheon/dram.c @@ -23,6 +23,7 @@ */ #include +#include #include DECLARE_GLOBAL_DATA_PTR; diff --git a/arch/arm/cpu/arm926ejs/pantheon/timer.c b/arch/arm/cpu/arm926ejs/pantheon/timer.c index c71162a..17045b1 100644 --- a/arch/arm/cpu/arm926ejs/pantheon/timer.c +++ b/arch/arm/cpu/arm926ejs/pantheon/timer.c @@ -23,6 +23,7 @@ */ #include +#include #include /* diff --git a/arch/arm/include/asm/arch-pantheon/config.h b/arch/arm/include/asm/arch-pantheon/config.h index 5658592..fd23c97 100644 --- a/arch/arm/include/asm/arch-pantheon/config.h +++ b/arch/arm/include/asm/arch-pantheon/config.h @@ -25,6 +25,8 @@ #ifndef _PANTHEON_CONFIG_H #define _PANTHEON_CONFIG_H +#include + #define CONFIG_ARM926EJS 1 /* Basic Architecture */ #define CONFIG_SYS_TCLK(14745600) /* NS16550 clk config */ diff --git a/arch/arm/include/asm/arch-pantheon/pantheon.h b/arch/arm/include/asm/arch-pantheon/pantheon.h index e4ed087..c7fe646 100644 --- a/arch/arm/include/asm/arch-pantheon/pantheon.h +++ b/arch/arm/include/asm/arch-pantheon/pantheon.h @@ -25,13 +25,6 @@ #ifndef _PANTHEON_H #define _PANTHEON_H -#ifndef __ASSEMBLY__ -#include -#include -#endif /* __ASSEMBLY__ */ - -#include - /* Common APB clock register bit definitions */ #define APBC_APBCLK (1<<0) /* APB Bus Clock Enable */ #define APBC_FNCLK (1<<1) /* Functional Clock Enable */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/5] Marvell: reduce dependence files
Changelog: V2: rebase over latest u-boot-marvell.git Lei Wen (5): ARM: pantheon: reduce dependence of including platform file ARM: armada100: reduce dependence of including platform file ARM: kirkwood: reduce dependence of including platform file serial: reduce include platform file for marvell chip gpio: mvmfp: reduce include platform file arch/arm/cpu/arm926ejs/armada100/cpu.c |2 +- arch/arm/cpu/arm926ejs/armada100/dram.c |1 + arch/arm/cpu/arm926ejs/armada100/timer.c|1 + arch/arm/cpu/arm926ejs/kirkwood/cpu.c |2 + arch/arm/cpu/arm926ejs/kirkwood/dram.c |2 + arch/arm/cpu/arm926ejs/kirkwood/mpp.c |2 + arch/arm/cpu/arm926ejs/kirkwood/timer.c |1 + arch/arm/cpu/arm926ejs/pantheon/cpu.c |2 +- arch/arm/cpu/arm926ejs/pantheon/dram.c |1 + arch/arm/cpu/arm926ejs/pantheon/timer.c |1 + arch/arm/include/asm/arch-armada100/armada100.h | 131 --- arch/arm/include/asm/arch-armada100/config.h|1 + arch/arm/include/asm/arch-armada100/cpu.h | 57 ++ arch/arm/include/asm/arch-kirkwood/config.h |1 + arch/arm/include/asm/arch-kirkwood/kirkwood.h |6 - arch/arm/include/asm/arch-pantheon/config.h |2 + arch/arm/include/asm/arch-pantheon/pantheon.h |7 -- board/Marvell/aspenite/aspenite.c |1 + board/Marvell/guruplug/guruplug.c |1 + board/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c |1 + board/Marvell/openrd/openrd.c |1 + board/Marvell/rd6281a/rd6281a.c |1 + board/Marvell/sheevaplug/sheevaplug.c |1 + board/keymile/km_arm/km_arm.c |1 + drivers/gpio/kw_gpio.c |1 + drivers/gpio/mvmfp.c|7 -- drivers/net/mvgbe.c |2 + drivers/serial/serial.c |9 -- drivers/spi/kirkwood_spi.c |1 + drivers/usb/host/ehci-kirkwood.c|1 + 30 files changed, 86 insertions(+), 162 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] mmc: change magic number to macro define
Hi Wolfgang, On Fri, Oct 14, 2011 at 4:09 AM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message > Graeme > Russ wrote: >> >> > So do you means I should keep the EXT_CSD_HS_TIMING? Or I change like >> > below? >> > >> > from >> > err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1); >> > to: >> > err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, &ext_csd.hs_timing - >> > &ext_csd, 1); >> >> I imagine the compiler will complain that the types for &ext_csd.hs_timing >> and &ext_csd are different. >> >> Try: >> struct ext_csd *ext_csd_ptr = 0; >> >> err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, &ext_csd_ptr->hs_timing, >> 1); > > Umm... no. > > The signature of mmc_switch() [as used here - there is also a two > argument version; what a mess!] is: > > int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value) > > The "set" argument is bous, as the function never uses it anywhere. > > And both the "index" and "value" arguments are never used in I/O > context, i. e. they are actual plain integer parameters. So just keep > it as > > err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1); > > Should I also keep the EXT_CSD_HS_TIMING like macro for previous ext_csd parsing? Or just add another ext_csd structure definition to the parse the ext_csd, while keep macros to be called by mmc_switch? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] mmc: change magic number to macro define
Hi Graeme, On Tue, Oct 11, 2011 at 9:09 AM, Graeme Russ wrote: > Hi Lei Wen, > > On Tue, Oct 11, 2011 at 11:48 AM, Lei Wen wrote: >> Hi Wolfgang, >> >> On Tue, Oct 11, 2011 at 1:33 AM, Wolfgang Denk wrote: >>> Dear Lei Wen, >>> >>> In message >>> you >>> wrote: >>>> >>>> >> So macro may looks more concise and could parse from its meaning easily >>>> >> eno= >>>> >> ugh. >>>> > >>>> > We do not accept (typeless) register offset definitions. Please use a >>>> > struct, so the compiler has a chance to perform type checking. >>>> >>>> I check the code again, and find there is a reason for previous >>>> defined macro to use. >>>> That is those register offset defined as macro may need later passing >>>> as a function >>>> parameter like: >>>> err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, >>>> 1); >>> >>> I don;t see that any register (which now would be an address in a >>> struct insteadd of being an offset to be added to a base address) >>> would be passed as parameter to mmc_switch(). >>> >>> So this is not an issue at all. >>> >>>> So if the ext_csd change to structure, maybe the function call here >>>> don't looks like so >>>> concise as before... What do you think for this? >>> >>> The EXT_CSD field definitions are completely independent of the way >>> how you access the registers. >>> >> >> So do you means I should keep the EXT_CSD_HS_TIMING? Or I change like below? >> >> from >> err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1); >> to: >> err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, &ext_csd.hs_timing - &ext_csd, >> 1); > > I imagine the compiler will complain that the types for &ext_csd.hs_timing > and &ext_csd are different. > > Try: > struct ext_csd *ext_csd_ptr = 0; > > err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, &ext_csd_ptr->hs_timing, > 1); Yes, it looks more clear than mine. If have no other suggestion, I would do like this to format my patches. Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] mmc: change magic number to macro define
Hi Wolfgang, On Tue, Oct 11, 2011 at 1:33 AM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message > you > wrote: >> >> >> So macro may looks more concise and could parse from its meaning easily >> >> eno= >> >> ugh. >> > >> > We do not accept (typeless) register offset definitions. Please use a >> > struct, so the compiler has a chance to perform type checking. >> >> I check the code again, and find there is a reason for previous >> defined macro to use. >> That is those register offset defined as macro may need later passing >> as a function >> parameter like: >> err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1); > > I don;t see that any register (which now would be an address in a > struct insteadd of being an offset to be added to a base address) > would be passed as parameter to mmc_switch(). > > So this is not an issue at all. > >> So if the ext_csd change to structure, maybe the function call here >> don't looks like so >> concise as before... What do you think for this? > > The EXT_CSD field definitions are completely independent of the way > how you access the registers. > So do you means I should keep the EXT_CSD_HS_TIMING? Or I change like below? from err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1); to: err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, &ext_csd.hs_timing - &ext_csd, 1); Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] mmc: change magic number to macro define
Hi Wolfgang, On Fri, Oct 7, 2011 at 1:39 AM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message > you > wrote: >> >> The ext_csd current usage in mmc.c is not too much, here I mean only few of >> the fields of the ext_csd is used, also fully definition of ext_csd >> member would seems so huge a structure at its appearence... >> >> So macro may looks more concise and could parse from its meaning easily eno= >> ugh. > > We do not accept (typeless) register offset definitions. Please use a > struct, so the compiler has a chance to perform type checking. > I check the code again, and find there is a reason for previous defined macro to use. That is those register offset defined as macro may need later passing as a function parameter like: err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1); So if the ext_csd change to structure, maybe the function call here don't looks like so concise as before... What do you think for this? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 5/5] mmc: sdhci: fix sdma bug for large file transfer
SDHCI spec need to reset the sdma base address while the software
try to accorss the 512k bytes address boundary. When meet such
accross behavior, sdhci controller would generate a interrupt
automatically, and software need handle this.
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
V3: new added fix for sdma bug
V4: no change
drivers/mmc/sdhci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 77a9e70..fce0ef0 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -104,7 +104,7 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data,
#ifdef CONFIG_MMC_SDMA
if (stat & SDHCI_INT_DMA_END) {
sdhci_writel(host, SDHCI_INT_DMA_END, SDHCI_INT_STATUS);
- start_addr &= SDHCI_DEFAULT_BOUNDARY_SIZE - 1;
+ start_addr &= ~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
start_addr += SDHCI_DEFAULT_BOUNDARY_SIZE;
sdhci_writel(host, start_addr, SDHCI_DMA_ADDRESS);
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 4/5] mmc: sdhci: add timeout for data transfer
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
V3: no change
V4: no change
drivers/mmc/sdhci.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 31c738e..77a9e70 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -81,8 +81,9 @@ static void sdhci_transfer_pio(struct sdhci_host *host,
struct mmc_data *data)
static int sdhci_transfer_data(struct sdhci_host *host, struct mmc_data *data,
unsigned int start_addr)
{
- unsigned int stat, rdy, mask, block = 0;
+ unsigned int stat, rdy, mask, timeout, block = 0;
+ timeout = 1;
rdy = SDHCI_INT_SPACE_AVAIL | SDHCI_INT_DATA_AVAIL;
mask = SDHCI_DATA_AVAILABLE | SDHCI_SPACE_AVAILABLE;
do {
@@ -108,6 +109,12 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data,
sdhci_writel(host, start_addr, SDHCI_DMA_ADDRESS);
}
#endif
+ if (timeout-- > 0)
+ udelay(10);
+ else {
+ printf("Transfer data timeout\n");
+ return -1;
+ }
} while (!(stat & SDHCI_INT_DATA_END));
return 0;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 1/5] mmc: sdhci: fix cache flush
Only flush the memory range needed.
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
V3: no change
V4: no change
drivers/mmc/sdhci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 9ebd33d..4a92453 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -196,7 +196,7 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
sdhci_writel(host, cmd->cmdarg, SDHCI_ARGUMENT);
#ifdef CONFIG_MMC_SDMA
- flush_cache(0, ~0);
+ flush_cache(start_addr, trans_bytes);
#endif
sdhci_writew(host, SDHCI_MAKE_CMD(cmd->cmdidx, flags), SDHCI_COMMAND);
do {
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 3/5] mmc: sdhci: add mmc structure for host
So that sdhci host would tell in the driver that the mmc current
attributes.
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
V3: no change
V4: add empty line after mmc.h include
drivers/mmc/sdhci.c |1 +
include/sdhci.h |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 4a92453..31c738e 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -377,6 +377,7 @@ int add_sdhci(struct sdhci_host *host, u32 max_clk, u32
min_clk)
}
mmc->priv = host;
+ host->mmc = mmc;
sprintf(mmc->name, "%s", host->name);
mmc->send_cmd = sdhci_send_command;
diff --git a/include/sdhci.h b/include/sdhci.h
index e84d2dc..0690938 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -27,6 +27,8 @@
#define __SDHCI_HW_H
#include
+#include
+
/*
* Controller registers
*/
@@ -239,6 +241,7 @@ struct sdhci_host {
unsigned int quirks;
unsigned int version;
unsigned int clock;
+ struct mmc *mmc;
const struct sdhci_ops *ops;
};
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 0/5] fix and enhancement patches for sdhci
This seris fix several issue like flush cache and build warning. And give this generic driver enhancement for timeout when transferring data and additional structure member to access in platform self driver. Changelog: V2: code style change. V3: add another fix of sdma handling bug including in this series V4: minor code style change Lei Wen (5): mmc: sdhci: fix cache flush mmc: sdhci: fix build warning mmc: sdhci: add mmc structure for host mmc: sdhci: add timeout for data transfer mmc: sdhci: fix sdma bug for large file transfer drivers/mmc/sdhci.c | 14 +++--- include/sdhci.h |6 ++ 2 files changed, 17 insertions(+), 3 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V4 2/5] mmc: sdhci: fix build warning
If CONFIG_MMC_SDHCI_IO_ACCESSORS is defined, the following warning would shows up: include/sdhci.h:224: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:224: warning: its scope is only this definition or declaration, which is probably not what you want include/sdhci.h:225: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:226: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:227: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:228: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:229: warning: 'struct sdhci_host' declared inside parameter list Signed-off-by: Lei Wen --- Changelog: V2: code style change V2.1: delete "Change-Id" V3: no change V4: no change include/sdhci.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/sdhci.h b/include/sdhci.h index 6d52ce9..e84d2dc 100644 --- a/include/sdhci.h +++ b/include/sdhci.h @@ -214,6 +214,9 @@ */ #define SDHCI_QUIRK_32BIT_DMA_ADDR (1 << 0) +/* to make gcc happy */ +struct sdhci_host; + /* * Host SDMA buffer boundary. Valid values from 4K to 512K in powers of 2. */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 3/5] mmc: sdhci: add mmc structure for host
Hi Sergei, On Sat, Oct 8, 2011 at 9:52 PM, Sergei Shtylyov wrote: > Hello. > > On 08-10-2011 17:47, Lei Wen wrote: > >> So that sdhci host would tell in the driver that the mmc current >> attributes. > >> Signed-off-by: Lei Wen > [...] > >> diff --git a/include/sdhci.h b/include/sdhci.h >> index e84d2dc..e4e7ebe 100644 >> --- a/include/sdhci.h >> +++ b/include/sdhci.h >> @@ -27,6 +27,7 @@ >> #define __SDHCI_HW_H >> >> #include >> +#include > > Why remove empty line here? > Thanks for pointing that out! I would repost which keep the empty line. Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: pantheon: enable dcache by default
Hi Prafulla,
On Fri, Oct 7, 2011 at 11:53 AM, Prafulla Wadaskar wrote:
>
>
>> -Original Message-----
>> From: Lei Wen [mailto:lei...@marvell.com]
>> Sent: Wednesday, October 05, 2011 8:43 PM
>> To: Prafulla Wadaskar; u-boot@lists.denx.de
>> Subject: [PATCH] ARM: pantheon: enable dcache by default
>>
>> Marvell 88SV331xV5 has its specific arm cp15 opcode, which could
>
> I think this will be applicable to all SoC those fall under this core.
> So we should modify arch/arm/include/asm/cache.h for this.
I modify my original one patch into three small patch series.
And put the op code place as you suggested, please help re-check it.
>
>> flush out whole dcache by only one line of asm code.
>>
>> Signed-off-by: Lei Wen
>> ---
>> arch/arm/cpu/arm926ejs/pantheon/cpu.c | 14 ++
>> 1 files changed, 14 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
>> b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
>> index 2d9c13a..8f94ea9 100644
>> --- a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
>> +++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
>> @@ -105,3 +105,17 @@ void i2c_clk_enable(void)
>> {
>> }
>> #endif
>> +
>> +#ifndef CONFIG_SYS_DCACHE_OFF
>> +void enable_caches(void)
>> +{
>> + /* Enable D-cache. I-cache is already enabled in start.S */
>> + dcache_enable();
>> +}
>> +
>> +void flush_cache(unsigned long start, unsigned long size)
>> +{
>> + /* clean & invalidate all D cache */
>> + asm("mcr p15, 0, %0, c7, c14, 0" : : "r" (0));
>> +}
>> +#endif
>
> Otherwise ack for this change
Thanks,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] ARM: pantheon: enable dcache by default
Signed-off-by: Lei Wen
---
arch/arm/cpu/arm926ejs/pantheon/cpu.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
index 8b2eafa..18da1c1 100644
--- a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
+++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
@@ -88,3 +88,11 @@ void i2c_clk_enable(void)
{
}
#endif
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+void enable_caches(void)
+{
+ /* Enable D-cache. I-cache is already enabled in arch_cpu_init */
+ dcache_enable();
+}
+#endif
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ARM: armada100: enable dcache by default
Signed-off-by: Lei Wen
---
arch/arm/cpu/arm926ejs/armada100/cpu.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/armada100/cpu.c
b/arch/arm/cpu/arm926ejs/armada100/cpu.c
index c21938e..47b764d 100644
--- a/arch/arm/cpu/arm926ejs/armada100/cpu.c
+++ b/arch/arm/cpu/arm926ejs/armada100/cpu.c
@@ -106,3 +106,11 @@ void i2c_clk_enable(void)
{
}
#endif
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+void enable_caches(void)
+{
+ /* Enable D-cache. I-cache is already enabled in arch_cpu_init */
+ dcache_enable();
+}
+#endif
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] enable dcache for pantheon and armada100
This patch seris use Marvell its own special op code to flush the dcache Lei Wen (3): ARM: add special dcache flush op code for 88SV331xV5 ARM: pantheon: enable dcache by default ARM: armada100: enable dcache by default arch/arm/cpu/arm926ejs/armada100/cpu.c |8 arch/arm/cpu/arm926ejs/pantheon/cpu.c |8 arch/arm/lib/cache.c |5 + 3 files changed, 21 insertions(+), 0 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ARM: add special dcache flush op code for 88SV331xV5
Marvell 88SV331xV5 has its specific arm cp15 opcode, which could
flush out whole dcache by only one line of asm code.
Signed-off-by: Lei Wen
---
arch/arm/lib/cache.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c
index b545fb7..bfcbda4 100644
--- a/arch/arm/lib/cache.c
+++ b/arch/arm/lib/cache.c
@@ -33,11 +33,16 @@ void __flush_cache(unsigned long start, unsigned long size)
arm1136_cache_flush();
#endif
#ifdef CONFIG_ARM926EJS
+#ifdef CONFIG_SHEEVA_88SV331xV5
+ /* clean & invalidate all D cache */
+ asm("mcr p15, 0, %0, c7, c14, 0" : : "r" (0));
+#else
/* test and clean, page 2-23 of arm926ejs manual */
asm("0: mrc p15, 0, r15, c7, c10, 3\n\t" "bne 0b\n" : : : "memory");
/* disable write buffer as well (page 2-22) */
asm("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
#endif
+#endif
return;
}
void flush_cache(unsigned long start, unsigned long size)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 4/5] mmc: sdhci: add timeout for data transfer
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
V3: no change
drivers/mmc/sdhci.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 31c738e..77a9e70 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -81,8 +81,9 @@ static void sdhci_transfer_pio(struct sdhci_host *host,
struct mmc_data *data)
static int sdhci_transfer_data(struct sdhci_host *host, struct mmc_data *data,
unsigned int start_addr)
{
- unsigned int stat, rdy, mask, block = 0;
+ unsigned int stat, rdy, mask, timeout, block = 0;
+ timeout = 1;
rdy = SDHCI_INT_SPACE_AVAIL | SDHCI_INT_DATA_AVAIL;
mask = SDHCI_DATA_AVAILABLE | SDHCI_SPACE_AVAILABLE;
do {
@@ -108,6 +109,12 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data,
sdhci_writel(host, start_addr, SDHCI_DMA_ADDRESS);
}
#endif
+ if (timeout-- > 0)
+ udelay(10);
+ else {
+ printf("Transfer data timeout\n");
+ return -1;
+ }
} while (!(stat & SDHCI_INT_DATA_END));
return 0;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 5/5] mmc: sdhci: fix sdma bug for large file transfer
SDHCI spec need to reset the sdma base address while the software
try to accorss the 512k bytes address boundary. When meet such
accross behavior, sdhci controller would generate a interrupt
automatically, and software need handle this.
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
V3: new added fix for sdma bug
drivers/mmc/sdhci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 77a9e70..fce0ef0 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -104,7 +104,7 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data,
#ifdef CONFIG_MMC_SDMA
if (stat & SDHCI_INT_DMA_END) {
sdhci_writel(host, SDHCI_INT_DMA_END, SDHCI_INT_STATUS);
- start_addr &= SDHCI_DEFAULT_BOUNDARY_SIZE - 1;
+ start_addr &= ~(SDHCI_DEFAULT_BOUNDARY_SIZE - 1);
start_addr += SDHCI_DEFAULT_BOUNDARY_SIZE;
sdhci_writel(host, start_addr, SDHCI_DMA_ADDRESS);
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 3/5] mmc: sdhci: add mmc structure for host
So that sdhci host would tell in the driver that the mmc current
attributes.
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
V3: no change
drivers/mmc/sdhci.c |1 +
include/sdhci.h |2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 4a92453..31c738e 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -377,6 +377,7 @@ int add_sdhci(struct sdhci_host *host, u32 max_clk, u32
min_clk)
}
mmc->priv = host;
+ host->mmc = mmc;
sprintf(mmc->name, "%s", host->name);
mmc->send_cmd = sdhci_send_command;
diff --git a/include/sdhci.h b/include/sdhci.h
index e84d2dc..e4e7ebe 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -27,6 +27,7 @@
#define __SDHCI_HW_H
#include
+#include
/*
* Controller registers
*/
@@ -239,6 +240,7 @@ struct sdhci_host {
unsigned int quirks;
unsigned int version;
unsigned int clock;
+ struct mmc *mmc;
const struct sdhci_ops *ops;
};
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/5] mmc: sdhci: fix build warning
If CONFIG_MMC_SDHCI_IO_ACCESSORS is defined, the following warning would shows up: include/sdhci.h:224: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:224: warning: its scope is only this definition or declaration, which is probably not what you want include/sdhci.h:225: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:226: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:227: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:228: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:229: warning: 'struct sdhci_host' declared inside parameter list Signed-off-by: Lei Wen --- Changelog: V2: code style change V2.1: delete "Change-Id" V3: no change include/sdhci.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/sdhci.h b/include/sdhci.h index 6d52ce9..e84d2dc 100644 --- a/include/sdhci.h +++ b/include/sdhci.h @@ -214,6 +214,9 @@ */ #define SDHCI_QUIRK_32BIT_DMA_ADDR (1 << 0) +/* to make gcc happy */ +struct sdhci_host; + /* * Host SDMA buffer boundary. Valid values from 4K to 512K in powers of 2. */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 1/5] mmc: sdhci: fix cache flush
Only flush the memory range needed.
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
V3: no change
drivers/mmc/sdhci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 9ebd33d..4a92453 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -196,7 +196,7 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd,
sdhci_writel(host, cmd->cmdarg, SDHCI_ARGUMENT);
#ifdef CONFIG_MMC_SDMA
- flush_cache(0, ~0);
+ flush_cache(start_addr, trans_bytes);
#endif
sdhci_writew(host, SDHCI_MAKE_CMD(cmd->cmdidx, flags), SDHCI_COMMAND);
do {
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 0/5] fix and enhancement patches for sdhci
This seris fix several issue like flush cache and build warning. And give this generic driver enhancement for timeout when transferring data and additional structure member to access in platform self driver. Changelog: V2: code style change. V3: add another fix of sdma handling bug including in this series Lei Wen (5): mmc: sdhci: fix cache flush mmc: sdhci: fix build warning mmc: sdhci: add mmc structure for host mmc: sdhci: add timeout for data transfer mmc: sdhci: fix sdma bug for large file transfer drivers/mmc/sdhci.c | 14 +++--- include/sdhci.h |5 + 2 files changed, 16 insertions(+), 3 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] mmc: change magic number to macro define
On Fri, Oct 7, 2011 at 4:36 PM, Prafulla Wadaskar wrote:
>
>
>> -Original Message-
>> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
>> On Behalf Of Lei Wen
>> Sent: Thursday, October 06, 2011 8:41 PM
>> To: Marek Vasut
>> Cc: Lei Wen; u-boot@lists.denx.de; Andy Fleming
>> Subject: Re: [U-Boot] [PATCH V2 1/2] mmc: change magic number to macro
>> define
>>
>> Hi Marek,
>>
>> On Tue, Oct 4, 2011 at 8:07 PM, Marek Vasut
>> wrote:
>> > On Tuesday, October 04, 2011 08:35:10 AM Lei Wen wrote:
>> >> Previous magic number is hard to parse its meaning, change it to
>> >> respective macro definition
>> >>
>> >> Signed-off-by: Lei Wen
>> >
>> > [..]
>> >
>> >> --- a/include/mmc.h
>> >> +++ b/include/mmc.h
>> >> @@ -145,13 +145,15 @@
>> >> /*
>> >> * EXT_CSD fields
>> >> */
>> >> -
>> >> -#define EXT_CSD_PART_CONF 179 /* R/W */
>> >> -#define EXT_CSD_BUS_WIDTH 183 /* R/W */
>> >> -#define EXT_CSD_HS_TIMING 185 /* R/W */
>> >> -#define EXT_CSD_CARD_TYPE 196 /* RO */
>> >> -#define EXT_CSD_REV 192 /* RO */
>> >> -#define EXT_CSD_SEC_CNT 212 /* RO, 4 bytes */
>> >> +#define EXT_CSD_PARTITIONING_SUPPORT 160 /* RO */
>> >> +#define EXT_CSD_ERASE_GROUP_DEF 175 /* R/W */
>> >> +#define EXT_CSD_PART_CONF 179 /* R/W */
>> >> +#define EXT_CSD_BUS_WIDTH 183 /* R/W */
>> >> +#define EXT_CSD_HS_TIMING 185 /* R/W */
>> >> +#define EXT_CSD_REV 192 /* RO */
>> >> +#define EXT_CSD_CARD_TYPE 196 /* RO */
>> >> +#define EXT_CSD_SEC_CNT 212 /* RO, 4 bytes
>> */
>> >> +#define EXT_CSD_HC_ERASE_GRP_SIZE 224 /* RO */
>> >>
>> >> /*
>> >> * EXT_CSD field definitions
>> >
>> > Hi Lei,
>> > this is better, but what about structure-based access ?
>> >
>> > struct somrthing {
>> > u8 a1;
>> > u8 a2;
>> > ...
>> > };
>> >
>> > Like this.
>> >
>> > Also, CC Andy.
>> >
>>
>> The ext_csd current usage in mmc.c is not too much, here I mean only few
>> of
>> the fields of the ext_csd is used, also fully definition of ext_csd
>> member would seems so huge a structure at its appearence...
>>
>> So macro may looks more concise and could parse from its meaning easily
>> enough.
>>
>> Anyway, more comments on this welcomes. :)
>
> Dear Lei
> Using c-struct is our strategy, may be full definition is huge, you may skip
> them inserting padding in the c-struct.
>
> Regards..
> Prafulla . .
>
Ok... Got that.
I would send patch soon using the c style.
Thanks,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] mmc: change magic number to macro define
Hi Marek,
On Tue, Oct 4, 2011 at 8:07 PM, Marek Vasut wrote:
> On Tuesday, October 04, 2011 08:35:10 AM Lei Wen wrote:
>> Previous magic number is hard to parse its meaning, change it to
>> respective macro definition
>>
>> Signed-off-by: Lei Wen
>
> [..]
>
>> --- a/include/mmc.h
>> +++ b/include/mmc.h
>> @@ -145,13 +145,15 @@
>> /*
>> * EXT_CSD fields
>> */
>> -
>> -#define EXT_CSD_PART_CONF 179 /* R/W */
>> -#define EXT_CSD_BUS_WIDTH 183 /* R/W */
>> -#define EXT_CSD_HS_TIMING 185 /* R/W */
>> -#define EXT_CSD_CARD_TYPE 196 /* RO */
>> -#define EXT_CSD_REV 192 /* RO */
>> -#define EXT_CSD_SEC_CNT 212 /* RO, 4 bytes */
>> +#define EXT_CSD_PARTITIONING_SUPPORT 160 /* RO */
>> +#define EXT_CSD_ERASE_GROUP_DEF 175 /* R/W */
>> +#define EXT_CSD_PART_CONF 179 /* R/W */
>> +#define EXT_CSD_BUS_WIDTH 183 /* R/W */
>> +#define EXT_CSD_HS_TIMING 185 /* R/W */
>> +#define EXT_CSD_REV 192 /* RO */
>> +#define EXT_CSD_CARD_TYPE 196 /* RO */
>> +#define EXT_CSD_SEC_CNT 212 /* RO, 4 bytes */
>> +#define EXT_CSD_HC_ERASE_GRP_SIZE 224 /* RO */
>>
>> /*
>> * EXT_CSD field definitions
>
> Hi Lei,
> this is better, but what about structure-based access ?
>
> struct somrthing {
> u8 a1;
> u8 a2;
> ...
> };
>
> Like this.
>
> Also, CC Andy.
>
The ext_csd current usage in mmc.c is not too much, here I mean only few of
the fields of the ext_csd is used, also fully definition of ext_csd
member would seems so huge a structure at its appearence...
So macro may looks more concise and could parse from its meaning easily enough.
Anyway, more comments on this welcomes. :)
Best regards,
Lei
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: pantheon: enable dcache by default
Marvell 88SV331xV5 has its specific arm cp15 opcode, which could
flush out whole dcache by only one line of asm code.
Signed-off-by: Lei Wen
---
arch/arm/cpu/arm926ejs/pantheon/cpu.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
index 2d9c13a..8f94ea9 100644
--- a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
+++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
@@ -105,3 +105,17 @@ void i2c_clk_enable(void)
{
}
#endif
+
+#ifndef CONFIG_SYS_DCACHE_OFF
+void enable_caches(void)
+{
+ /* Enable D-cache. I-cache is already enabled in start.S */
+ dcache_enable();
+}
+
+void flush_cache(unsigned long start, unsigned long size)
+{
+ /* clean & invalidate all D cache */
+ asm("mcr p15, 0, %0, c7, c14, 0" : : "r" (0));
+}
+#endif
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] USB: gadaget: add Marvell controller support
Signed-off-by: Lei Wen
---
drivers/usb/gadget/Makefile |1 +
drivers/usb/gadget/gadget_chips.h |7 +
drivers/usb/gadget/mv_udc.c | 499 +
include/usb/mv_udc.h | 151 +++
4 files changed, 658 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/gadget/mv_udc.c
create mode 100644 include/usb/mv_udc.h
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 7d5b504..769b351 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -29,6 +29,7 @@ LIB := $(obj)libusb_gadget.o
ifdef CONFIG_USB_ETHER
COBJS-y += ether.o epautoconf.o config.o usbstring.o
COBJS-$(CONFIG_USB_ETH_RNDIS) += rndis.o
+COBJS-$(CONFIG_MV_UDC) += mv_udc.o
else
# Devices not related to the new gadget layer depend on CONFIG_USB_DEVICE
ifdef CONFIG_USB_DEVICE
diff --git a/drivers/usb/gadget/gadget_chips.h
b/drivers/usb/gadget/gadget_chips.h
index 9bb7e2e..5d7b638 100644
--- a/drivers/usb/gadget/gadget_chips.h
+++ b/drivers/usb/gadget/gadget_chips.h
@@ -150,6 +150,11 @@
#definegadget_is_m66592(g) 0
#endif
+#ifdef CONFIG_USB_GADGET_MV
+#define gadget_is_mv(g)(!strcmp("mv_udc", (g)->name))
+#else
+#define gadget_is_mv(g)0
+#endif
/*
* CONFIG_USB_GADGET_SX2
@@ -216,5 +221,7 @@ static inline int usb_gadget_controller_number(struct
usb_gadget *gadget)
return 0x20;
else if (gadget_is_m66592(gadget))
return 0x21;
+ else if (gadget_is_mv(gadget))
+ return 0x22;
return -ENOENT;
}
diff --git a/drivers/usb/gadget/mv_udc.c b/drivers/usb/gadget/mv_udc.c
new file mode 100644
index 000..cdbdcfa
--- /dev/null
+++ b/drivers/usb/gadget/mv_udc.c
@@ -0,0 +1,499 @@
+/*
+ * Copyright 2011, Marvell Semiconductor Inc.
+ * Lei Wen
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * Back ported to the 8xx platform (from the 8260 platform) by
+ * murray.jen...@cmst.csiro.au, 27-Jan-01.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifndef DEBUG
+#define DBG(x...) do {} while (0)
+#else
+#define DBG(x...) printf(x)
+static const char *reqname(unsigned r)
+{
+ switch (r) {
+ case USB_REQ_GET_STATUS: return "GET_STATUS";
+ case USB_REQ_CLEAR_FEATURE: return "CLEAR_FEATURE";
+ case USB_REQ_SET_FEATURE: return "SET_FEATURE";
+ case USB_REQ_SET_ADDRESS: return "SET_ADDRESS";
+ case USB_REQ_GET_DESCRIPTOR: return "GET_DESCRIPTOR";
+ case USB_REQ_SET_DESCRIPTOR: return "SET_DESCRIPTOR";
+ case USB_REQ_GET_CONFIGURATION: return "GET_CONFIGURATION";
+ case USB_REQ_SET_CONFIGURATION: return "SET_CONFIGURATION";
+ case USB_REQ_GET_INTERFACE: return "GET_INTERFACE";
+ case USB_REQ_SET_INTERFACE: return "SET_INTERFACE";
+ default: return "*UNKNOWN*";
+ }
+}
+#endif
+
+#define PAGE_SIZE 4096
+#define QH_MAXNUM 32
+static struct usb_endpoint_descriptor ep0_out_desc = {
+ .bLength = sizeof(struct usb_endpoint_descriptor),
+ .bDescriptorType = USB_DT_ENDPOINT,
+ .bEndpointAddress = 0,
+ .bmAttributes = USB_ENDPOINT_XFER_CONTROL,
+};
+
+static struct usb_endpoint_descriptor ep0_in_desc = {
+ .bLength = sizeof(struct usb_endpoint_descriptor),
+ .bDescriptorType = USB_DT_ENDPOINT,
+ .bEndpointAddress = USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_CONTROL,
+};
+
+struct ept_queue_head *epts;
+struct ept_queue_item *items[2 * NUM_ENDPOINTS];
+static int mv_pullup(struct usb_gadget *gadget, int is_on);
+static int mv_ep_enable(struct usb_ep *ep,
+ const struct usb_endpoint_descriptor *desc);
+static int mv_ep_disable(struct usb_ep *ep);
+static int mv_ep_queue(struct usb_ep *ep,
+ struct usb_request *req, gfp_t gfp_flags);
+static struct usb_request *
+mv_ep_alloc_request(struct usb_ep *ep, unsigned int gfp_flags);
+static void mv_ep_free_request(struct usb_ep *ep, struct usb_request *_req);
+
+static struct usb_gadget_ops mv_udc_ops = {
+
Re: [U-Boot] [PATCH V3] part: show efi partition name when print out partition info
Hi, On Fri, Sep 30, 2011 at 9:45 AM, Lei Wen wrote: > On Fri, Sep 30, 2011 at 12:16 AM, Marek Vasut wrote: >> On Thursday, September 29, 2011 04:14:40 AM Lei Wen wrote: >>> Hi Wolfgang, >>> >>> On Thu, Sep 8, 2011 at 12:11 PM, Lei Wen wrote: >>> > Previous output: >> >> [...] >> >>> >>> How about merge this patch included in 2011.09 release? :) >>> >>> Thanks, >>> Lei >> >> Hi Lei, >> >> I can't speak for Wolfgang, but I think we're pretty late in rc2 now. > > Em... I understand... > How about queue this patch for the next v2011.12 release? > I just don't know how the patches is managed in uboot now. The > patchwork also cannot get enough info for this. > Any feedback to this?... Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2.1 2/4] mmc: sdhci: fix build warning
If CONFIG_MMC_SDHCI_IO_ACCESSORS is defined, the following warning would shows up: include/sdhci.h:224: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:224: warning: its scope is only this definition or declaration, which is probably not what you want include/sdhci.h:225: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:226: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:227: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:228: warning: 'struct sdhci_host' declared inside parameter list include/sdhci.h:229: warning: 'struct sdhci_host' declared inside parameter list Signed-off-by: Lei Wen --- Changelog: V2: code style change V2.1: delete "Change-Id" include/sdhci.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/sdhci.h b/include/sdhci.h index 6d52ce9..e84d2dc 100644 --- a/include/sdhci.h +++ b/include/sdhci.h @@ -214,6 +214,9 @@ */ #define SDHCI_QUIRK_32BIT_DMA_ADDR (1 << 0) +/* to make gcc happy */ +struct sdhci_host; + /* * Host SDMA buffer boundary. Valid values from 4K to 512K in powers of 2. */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/4] add mmc support for pantheon platform
This patch seris add the mmc support for the pantheon platform. Also give platform like dkb and aspenite a workaround when enabling the 8bit mode for accessing the mmc. Changelog: V2: remove magic number, and replace it by macro definition and structure respectively. remove enable mmc function into seperated patch Lei Wen (4): ARM: pantheon: add mmc definition Marvell: dkb: add mmc support dkb: make mmc command as default enabled mmc: mv_sdhci: fix 8bus width access for 88SV331xV5 arch/arm/cpu/arm926ejs/pantheon/cpu.c | 11 ++ arch/arm/include/asm/arch-pantheon/config.h | 18 ++ arch/arm/include/asm/arch-pantheon/cpu.h | 12 +++ arch/arm/include/asm/arch-pantheon/mfp.h | 12 +++ arch/arm/include/asm/arch-pantheon/pantheon.h |7 board/Marvell/dkb/dkb.c | 43 + drivers/mmc/mv_sdhci.c| 33 +++ include/configs/dkb.h |1 + 8 files changed, 137 insertions(+), 0 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/4] ARM: pantheon: add mmc definition
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
arch/arm/cpu/arm926ejs/pantheon/cpu.c | 11 +++
arch/arm/include/asm/arch-pantheon/config.h | 18 ++
arch/arm/include/asm/arch-pantheon/cpu.h | 12
arch/arm/include/asm/arch-pantheon/mfp.h | 12
arch/arm/include/asm/arch-pantheon/pantheon.h |7 +++
5 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
index efc9395..db9b348 100644
--- a/arch/arm/cpu/arm926ejs/pantheon/cpu.c
+++ b/arch/arm/cpu/arm926ejs/pantheon/cpu.c
@@ -42,6 +42,9 @@ int arch_cpu_init(void)
struct panthmpmu_registers *mpmu =
(struct panthmpmu_registers*) PANTHEON_MPMU_BASE;
+ struct panthapmu_registers *apmu =
+ (struct panthapmu_registers *) PANTHEON_APMU_BASE;
+
/* set SEL_MRVL_ID bit in PANTHEON_CPU_CONF register */
val = readl(&cpuregs->cpu_conf);
val = val | SET_MRVL_ID;
@@ -65,6 +68,14 @@ int arch_cpu_init(void)
writel(APBC_FNCLK | APBC_APBCLK, &apbclkres->twsi);
#endif
+#ifdef CONFIG_MV_SDHCI
+ /* Enable mmc clock */
+ writel(APMU_PERI_CLK | APMU_AXI_CLK | APMU_PERI_RST | APMU_AXI_RST,
+ &apmu->sd1);
+ writel(APMU_PERI_CLK | APMU_AXI_CLK | APMU_PERI_RST | APMU_AXI_RST,
+ &apmu->sd3);
+#endif
+
icache_enable();
return 0;
diff --git a/arch/arm/include/asm/arch-pantheon/config.h
b/arch/arm/include/asm/arch-pantheon/config.h
index fd23c97..d10583d 100644
--- a/arch/arm/include/asm/arch-pantheon/config.h
+++ b/arch/arm/include/asm/arch-pantheon/config.h
@@ -47,4 +47,22 @@
#define CONFIG_SYS_I2C_SLAVE 0xfe
#endif
+/*
+ * MMC definition
+ */
+#ifdef CONFIG_CMD_MMC
+#define CONFIG_CMD_FAT 1
+#define CONFIG_MMC 1
+#define CONFIG_GENERIC_MMC 1
+#define CONFIG_SDHCI 1
+#define CONFIG_MMC_SDHCI_IO_ACCESSORS 1
+#define CONFIG_SYS_MMC_MAX_BLK_COUNT 0x1000
+#define CONFIG_MMC_SDMA1
+#define CONFIG_MV_SDHCI1
+#define CONFIG_DOS_PARTITION 1
+#define CONFIG_EFI_PARTITION 1
+#define CONFIG_SYS_MMC_NUM 2
+#define CONFIG_SYS_MMC_BASE{0xD428, 0xd4281000}
+#endif
+
#endif /* _PANTHEON_CONFIG_H */
diff --git a/arch/arm/include/asm/arch-pantheon/cpu.h
b/arch/arm/include/asm/arch-pantheon/cpu.h
index 60955c5..94e8371 100644
--- a/arch/arm/include/asm/arch-pantheon/cpu.h
+++ b/arch/arm/include/asm/arch-pantheon/cpu.h
@@ -43,6 +43,17 @@ struct panthmpmu_registers {
};
/*
+ * Application Power Management (APMU) Registers
+ * Refer Register Datasheet 9.2
+ */
+struct panthapmu_registers {
+ u8 pad0[0x0054];
+ u32 sd1;/*0x0054*/
+ u8 pad1[0x00e0 - 0x054 - 4];
+ u32 sd3;/*0x00e0*/
+};
+
+/*
* APB Clock Reset/Control Registers
* Refer Register Datasheet 6.14
*/
@@ -77,5 +88,6 @@ struct panthcpu_registers {
*/
u32 panth_sdram_base(int);
u32 panth_sdram_size(int);
+int mv_sdh_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks);
#endif /* _PANTHEON_CPU_H */
diff --git a/arch/arm/include/asm/arch-pantheon/mfp.h
b/arch/arm/include/asm/arch-pantheon/mfp.h
index e939196..b868ab8 100644
--- a/arch/arm/include/asm/arch-pantheon/mfp.h
+++ b/arch/arm/include/asm/arch-pantheon/mfp.h
@@ -38,6 +38,18 @@
#define MFP54_CI2C_SDA (MFP_REG(0x1b4) | MFP_AF2 | MFP_DRIVE_MEDIUM)
/* More macros can be defined here... */
+#define MFP_MMC1_DAT7 (MFP_REG(0x84) | MFP_AF0 | MFP_DRIVE_MEDIUM)
+#define MFP_MMC1_DAT6 (MFP_REG(0x88) | MFP_AF0 | MFP_DRIVE_MEDIUM)
+#define MFP_MMC1_DAT5 (MFP_REG(0x8c) | MFP_AF0 | MFP_DRIVE_MEDIUM)
+#define MFP_MMC1_DAT4 (MFP_REG(0x90) | MFP_AF0 | MFP_DRIVE_MEDIUM)
+#define MFP_MMC1_DAT3 (MFP_REG(0x94) | MFP_AF0 | MFP_DRIVE_FAST)
+#define MFP_MMC1_DAT2 (MFP_REG(0x98) | MFP_AF0 | MFP_DRIVE_FAST)
+#define MFP_MMC1_DAT1 (MFP_REG(0x9c) | MFP_AF0 | MFP_DRIVE_FAST)
+#define MFP_MMC1_DAT0 (MFP_REG(0xa0) | MFP_AF0 | MFP_DRIVE_FAST)
+#define MFP_MMC1_CMD (MFP_REG(0xa4) | MFP_AF0 | MFP_DRIVE_FAST)
+#define MFP_MMC1_CLK (MFP_REG(0xa8) | MFP_AF0 | MFP_DRIVE_FAST)
+#define MFP_MMC1_CD(MFP_REG(0xac) | MFP_AF0 | MFP_DRIVE_MEDIUM)
+#define MFP_MMC1_WP(MFP_REG(0xb0) | MFP_AF0 | MFP_DRIVE_MEDIUM)
#define MFP_PIN_MAX117
#endif
diff --git a/arch/arm/include/asm/arch-pantheon/pantheon.h
b/arch/arm/include/asm/arch-pantheon/pantheon.h
index c7fe646..d5e9ba0 100644
--- a/arch/arm/include/asm/arch-pantheon/pantheon.h
+++ b/arch/arm/include/asm/arch-pantheon/pantheon.h
@@ -32,6 +32,12 @@
/* Functional Clock Selection Mask */
#define APBC_FNCLKSEL(x)(((x) & 0xf) << 4)
+/* Common APM
[U-Boot] [PATCH V2 4/4] mmc: sdhci: add timeout for data transfer
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
drivers/mmc/sdhci.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 31c738e..77a9e70 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -81,8 +81,9 @@ static void sdhci_transfer_pio(struct sdhci_host *host,
struct mmc_data *data)
static int sdhci_transfer_data(struct sdhci_host *host, struct mmc_data *data,
unsigned int start_addr)
{
- unsigned int stat, rdy, mask, block = 0;
+ unsigned int stat, rdy, mask, timeout, block = 0;
+ timeout = 1;
rdy = SDHCI_INT_SPACE_AVAIL | SDHCI_INT_DATA_AVAIL;
mask = SDHCI_DATA_AVAILABLE | SDHCI_SPACE_AVAILABLE;
do {
@@ -108,6 +109,12 @@ static int sdhci_transfer_data(struct sdhci_host *host,
struct mmc_data *data,
sdhci_writel(host, start_addr, SDHCI_DMA_ADDRESS);
}
#endif
+ if (timeout-- > 0)
+ udelay(10);
+ else {
+ printf("Transfer data timeout\n");
+ return -1;
+ }
} while (!(stat & SDHCI_INT_DATA_END));
return 0;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] mmc: test mmc bus width on startup
For we don't know mmc bus width from reading registers, the only way
to check is to test.
Current compare offset is:
EXT_CSD_PARTITIONING_SUPPORT
EXT_CSD_ERASE_GROUP_DEF
EXT_CSD_REV
EXT_CSD_HC_ERASE_GRP_SIZE
EXT_CSD_SEC_CNT
Signed-off-by: Lei Wen
---
Changelog:
V2: change all magic number for ext_csd to macro definition
drivers/mmc/mmc.c | 45 ++---
1 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 1d75940..ea19d27 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -631,8 +631,6 @@ int mmc_change_freq(struct mmc *mmc)
if (mmc->version < MMC_VERSION_4)
return 0;
- mmc->card_caps |= MMC_MODE_4BIT;
-
err = mmc_send_ext_csd(mmc, ext_csd);
if (err)
@@ -856,11 +854,11 @@ void mmc_set_bus_width(struct mmc *mmc, uint width)
int mmc_startup(struct mmc *mmc)
{
- int err;
+ int err, width;
uint mult, freq;
u64 cmult, csize, capacity;
struct mmc_cmd cmd;
- char ext_csd[512];
+ char ext_csd[512], test_csd[512];
int timeout = 1000;
#ifdef CONFIG_MMC_SPI_CRC_ON
@@ -1080,26 +1078,35 @@ int mmc_startup(struct mmc *mmc)
else
mmc_set_clock(mmc, 2500);
} else {
- if (mmc->card_caps & MMC_MODE_4BIT) {
+ for (width = EXT_CSD_BUS_WIDTH_8; width >= 0; width--) {
/* Set the card to use 4 bit*/
err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_BUS_WIDTH,
- EXT_CSD_BUS_WIDTH_4);
-
- if (err)
- return err;
-
- mmc_set_bus_width(mmc, 4);
- } else if (mmc->card_caps & MMC_MODE_8BIT) {
- /* Set the card to use 8 bit*/
- err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_BUS_WIDTH,
- EXT_CSD_BUS_WIDTH_8);
+ EXT_CSD_BUS_WIDTH, width);
if (err)
- return err;
+ continue;
- mmc_set_bus_width(mmc, 8);
+ if (!width) {
+ mmc_set_bus_width(mmc, 1);
+ break;
+ } else
+ mmc_set_bus_width(mmc, 4 * width);
+
+ err = mmc_send_ext_csd(mmc, test_csd);
+ 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_REV] \
+ == test_csd[EXT_CSD_REV]
+&& ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] \
+ == test_csd[EXT_CSD_HC_ERASE_GRP_SIZE]
+&& memcmp(&ext_csd[EXT_CSD_SEC_CNT], \
+ &test_csd[EXT_CSD_SEC_CNT], 4) == 0) {
+
+ mmc->card_caps |= width;
+ break;
+ }
}
if (mmc->card_caps & MMC_MODE_HS) {
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] mmc: change magic number to macro define
Previous magic number is hard to parse its meaning, change it to
respective macro definition
Signed-off-by: Lei Wen
---
Changelog:
V2: change all magic number for ext_csd to macro definition
drivers/mmc/mmc.c | 21 -
include/mmc.h | 16 +---
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 391bc2b..1d75940 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -638,7 +638,7 @@ int mmc_change_freq(struct mmc *mmc)
if (err)
return err;
- cardtype = ext_csd[196] & 0xf;
+ cardtype = ext_csd[EXT_CSD_CARD_TYPE] & 0xf;
err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1);
@@ -652,7 +652,7 @@ int mmc_change_freq(struct mmc *mmc)
return err;
/* No high-speed support */
- if (!ext_csd[185])
+ if (!ext_csd[EXT_CSD_HS_TIMING])
return 0;
/* High Speed is set, there are two types: 52MHz and 26MHz */
@@ -1006,14 +1006,16 @@ int mmc_startup(struct mmc *mmc)
if (!IS_SD(mmc) && (mmc->version >= MMC_VERSION_4)) {
/* check ext_csd version and capacity */
err = mmc_send_ext_csd(mmc, ext_csd);
- if (!err & (ext_csd[192] >= 2)) {
+ if (!err & (ext_csd[EXT_CSD_REV] >= 2)) {
/*
* According to the JEDEC Standard, the value of
* ext_csd's capacity is valid if the value is more
* than 2GB
*/
- capacity = ext_csd[212] << 0 | ext_csd[213] << 8 |
- ext_csd[214] << 16 | ext_csd[215] << 24;
+ capacity = ext_csd[EXT_CSD_SEC_CNT] << 0
+ | ext_csd[EXT_CSD_SEC_CNT + 1] << 8
+ | ext_csd[EXT_CSD_SEC_CNT + 2] << 16
+ | ext_csd[EXT_CSD_SEC_CNT + 3] << 24;
capacity *= 512;
if ((capacity >> 20) > 2 * 1024)
mmc->capacity = capacity;
@@ -1024,8 +1026,9 @@ int mmc_startup(struct mmc *mmc)
* group size from ext_csd directly, or calculate
* the group size from the csd value.
*/
- if (ext_csd[175])
- mmc->erase_grp_size = ext_csd[224] * 512 * 1024;
+ if (ext_csd[EXT_CSD_ERASE_GROUP_DEF])
+ mmc->erase_grp_size =
+ ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] * 512 * 1024;
else {
int erase_gsz, erase_gmul;
erase_gsz = (mmc->csd[2] & 0x7c00) >> 10;
@@ -1035,8 +1038,8 @@ int mmc_startup(struct mmc *mmc)
}
/* store the partition info of emmc */
- if (ext_csd[160] & PART_SUPPORT)
- mmc->part_config = ext_csd[179];
+ if (ext_csd[EXT_CSD_PARTITIONING_SUPPORT] & PART_SUPPORT)
+ mmc->part_config = ext_csd[EXT_CSD_PART_CONF];
}
if (IS_SD(mmc))
diff --git a/include/mmc.h b/include/mmc.h
index 53aff9b..015a7f3 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -145,13 +145,15 @@
/*
* EXT_CSD fields
*/
-
-#define EXT_CSD_PART_CONF 179 /* R/W */
-#define EXT_CSD_BUS_WIDTH 183 /* R/W */
-#define EXT_CSD_HS_TIMING 185 /* R/W */
-#define EXT_CSD_CARD_TYPE 196 /* RO */
-#define EXT_CSD_REV192 /* RO */
-#define EXT_CSD_SEC_CNT212 /* RO, 4 bytes */
+#define EXT_CSD_PARTITIONING_SUPPORT 160 /* RO */
+#define EXT_CSD_ERASE_GROUP_DEF175 /* R/W */
+#define EXT_CSD_PART_CONF 179 /* R/W */
+#define EXT_CSD_BUS_WIDTH 183 /* R/W */
+#define EXT_CSD_HS_TIMING 185 /* R/W */
+#define EXT_CSD_REV192 /* RO */
+#define EXT_CSD_CARD_TYPE 196 /* RO */
+#define EXT_CSD_SEC_CNT212 /* RO, 4 bytes */
+#define EXT_CSD_HC_ERASE_GRP_SIZE 224 /* RO */
/*
* EXT_CSD field definitions
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/2] test mmc bus on startup
Changelog: V2: Clean up mmc.c to change all magic number for ext_csd to the macro definition Lei Wen (2): mmc: change magic number to macro define mmc: test mmc bus width on startup drivers/mmc/mmc.c | 66 ++-- include/mmc.h | 16 +++- 2 files changed, 47 insertions(+), 35 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 4/4] mmc: mv_sdhci: fix 8bus width access for 88SV331xV5
Marvell 88SV331xV5 platform's sdhci host control is not very standard
with the spec in the 8bit handling. It need to set its private register
to switch to the 8bit mode which is not included in the standard sdhci
registers.
This patch mainly hacks the writeb method, and set its private register
if it find the driver is going to switch to the 8bit mode.
Signed-off-by: Lei Wen
---
Changelog:
V2: no change
drivers/mmc/mv_sdhci.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
index 9e59951..f92caeb 100644
--- a/drivers/mmc/mv_sdhci.c
+++ b/drivers/mmc/mv_sdhci.c
@@ -2,6 +2,33 @@
#include
#include
+#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
+static struct sdhci_ops mv_ops;
+
+#if defined(CONFIG_SHEEVA_88SV331xV5)
+#define SD_CE_ATA_20xEA
+#define MMC_CARD 0x1000
+#define MMC_WIDTH 0x0100
+static inline void mv_sdhci_writeb(struct sdhci_host *host, u8 val, int reg)
+{
+ struct mmc *mmc = host->mmc;
+ u32 ata = (u32)host->ioaddr + SD_CE_ATA_2;
+
+ if (!IS_SD(mmc) && reg == SDHCI_HOST_CONTROL) {
+ if (mmc->bus_width == 8)
+ writew(readw(ata) | (MMC_CARD | MMC_WIDTH), ata);
+ else
+ writew(readw(ata) & ~(MMC_CARD | MMC_WIDTH), ata);
+ }
+
+ writeb(val, host->ioaddr + reg);
+}
+
+#else
+#define mv_sdhci_writebNULL
+#endif /* CONFIG_SHEEVA_88SV331xV5 */
+#endif /* CONFIG_MMC_SDHCI_IO_ACCESSORS */
+
static char *MVSDH_NAME = "mv_sdh";
int mv_sdh_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks)
{
@@ -15,6 +42,12 @@ int mv_sdh_init(u32 regbase, u32 max_clk, u32 min_clk, u32
quirks)
host->name = MVSDH_NAME;
host->ioaddr = (void *)regbase;
host->quirks = quirks;
+#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
+ memset(&mv_ops, 0, sizeof(struct sdhci_ops));
+ if (mv_sdhci_writeb != NULL)
+ mv_ops.write_b = mv_sdhci_writeb;
+ host->ops = &mv_ops;
+#endif
host->version = sdhci_readw(host, SDHCI_HOST_VERSION);
add_sdhci(host, max_clk, min_clk);
return 0;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 3/4] dkb: make mmc command as default enabled
Signed-off-by: Lei Wen --- Changelog: V2: remove enable mmc function into seperated patch include/configs/dkb.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/configs/dkb.h b/include/configs/dkb.h index 3d27c58..fb02d92 100644 --- a/include/configs/dkb.h +++ b/include/configs/dkb.h @@ -47,6 +47,7 @@ #define CONFIG_SYS_NO_FLASH/* Declare no flash (NOR/SPI) */ #include #define CONFIG_CMD_I2C +#define CONFIG_CMD_MMC #undef CONFIG_CMD_NET #undef CONFIG_CMD_NFS /* -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
