Re: [U-Boot] [PATCH v2] OMAP3: add CM-T35 board
Dear Mike Rapoport,
In message 4cff26b0.1080...@compulab.co.il you wrote:
This patch adds support for CM-T35 board
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
...
diff --git a/MAKEALL b/MAKEALL
index c54c6e8..e0fe12f 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -412,6 +412,7 @@ LIST_ARM11= \
LIST_ARMV7= \
am3517_evm \
ca9x4_ct_vxp\
+ cm_t35 \
devkit8000 \
igep0020\
igep0030\
Boards don't get added to MAKEALL any more. Please verify that your
board automatically gets picked up from boards.cfg
+/*
+ * Routine: misc_init_r
+ * Description: Init ethernet (done here so udelay works)
+ */
+int misc_init_r(void)
+{
+#ifdef CONFIG_DRIVER_OMAP34XX_I2C
+ i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+#endif
+
+ dieid_num_r();
+
+ return 0;
+}
Comment and code don't appear to match.
+/*
+ * Routine: set_muxconf_regs
+ * Description: Setting up the configuration Mux registers specific to the
+ * hardware. Many pins need to be moved from protect to primary
+ * mode.
+ */
+void set_muxconf_regs(void)
+{
+ MUX_CM_T35();
+}
Why don't you write this code here directly? Adding another macro
level here just obfuscates the code. Or what is your rationale for
moving this into a header file ?
+#ifdef CONFIG_GENERIC_MMC
+int board_mmc_init(bd_t *bis)
+{
+ omap_mmc_init(0);
+ return 0;
Error handling?
+static int handle_mac_address(void)
+{
+ unsigned char enetaddr[6];
+ int rc;
+
+ memset(enetaddr, 0, 6);
+ rc = eth_getenv_enetaddr(ethaddr, enetaddr);
What exactly is the memset() good for?
diff --git a/board/cm_t35/config.mk b/board/cm_t35/config.mk
new file mode 100644
index 000..e81e283
--- /dev/null
+++ b/board/cm_t35/config.mk
...
+CONFIG_SYS_TEXT_BASE = 0x80008000
Please move to board config file and get rid of config.mk
--- /dev/null
+++ b/include/configs/cm_t35.h
...
+/*
+ * select serial console configuration
+ */
+#define CONFIG_CONS_INDEX3
+#define CONFIG_SYS_NS16550_COM3 OMAP34XX_UART3
+#define CONFIG_SERIAL3 3 /* UART3 on Beagle Rev
2 */
Beagle Rev 2?
+#undef CONFIG_CMD_IMI/* iminfo */
What is the exact reson for disabling iminfo ?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You see but you do not observe.
Sir Arthur Conan Doyle, in The Memoirs of Sherlock Holmes
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] Add hash table support as base for new environment code
On Saturday, July 17, 2010 15:45:46 Wolfgang Denk wrote: This implementation is based on code from uClibc-0.9.30.3 but was modified and extended for use within U-Boot. unless i'm missing something, the non-reentrant versions operate on a single shared hash table. so while this works today because there is only one consumer (the env code), wont this cause problems as soon as someone else tries to use the non-reentrant hash table code ? as such, wouldnt it make sense to punt all of the non-reentrant versions and thus force everyone to maintain their own struct hsearch_data instance ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] New environment code
On Saturday, July 17, 2010 15:45:43 Wolfgang Denk wrote: TODO: - drop default env as implemented now; provide a text file based initialization instead (eventually using several text files to incrementally build it from common blocks) and a tool to convert it into a binary blob / object file. - It would be nice if we could add wildcard support for environment variables; this is needed for variable name auto-completion, but it would also be nice to be able to say printenv ip* or printenv *addr* - Some boards don't link any more due to the grown code size: AR405, CANBT, DU405, PMC440, canyonlands, sc3, sequoia, socrates. = cc: Matthias Fuchs matthias.fu...@esd-electronics.com, Stefan Roese s...@denx.de, Heiko Schocher h...@denx.de - Dropping forceenv() causes build problems on schmoogie = cc: Sergey Kubushyn k...@koi8.net - Build tested on PPC and ARM only; runtime tested with NOR and NAND flash only = needs testing!! seems that some todo items are missing, or not well implied. for example, it seems that gd-env_addr needs to be punted, and these functions get a _f appended to their name since they only work on default_environment[] now: env_get_addr() env_get_char() env_get_char_memory() envmatch() -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] Add hash table support as base for new environment code
Dear Mike Frysinger, In message 201012080444.30675.vap...@gentoo.org you wrote: unless i'm missing something, the non-reentrant versions operate on a single shared hash table. so while this works today because there is only one Correct. consumer (the env code), wont this cause problems as soon as someone else tries to use the non-reentrant hash table code ? as such, wouldnt it make sense to punt all of the non-reentrant versions and thus force everyone to maintain their own struct hsearch_data instance ? This could be done, but I don't see an immediate need. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I've already got a female to worry about. Her name is the Enterprise. -- Kirk, The Corbomite Maneuver, stardate 1514.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] New environment code
Dear Mike Frysinger, In message 201012080456.41492.vap...@gentoo.org you wrote: seems that some todo items are missing, or not well implied. for example, it seems that gd-env_addr needs to be punted, and these functions get a _f appended to their name since they only work on default_environment[] now: env_get_addr() env_get_char() env_get_char_memory() envmatch() I'm not sure I understand what you mean. These functions not NOT only operate on the default_environment[]; they are also used to access the normal environment before relocation. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If that makes any sense to you, you have a big problem. -- C. Durance, Computer Science 234 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] New environment code
On Wednesday, December 08, 2010 05:04:42 Wolfgang Denk wrote: Mike Frysinger wrote: seems that some todo items are missing, or not well implied. for example, it seems that gd-env_addr needs to be punted, and these functions get a _f appended to their name since they only work on default_environment[] now: env_get_addr() env_get_char() env_get_char_memory() envmatch() I'm not sure I understand what you mean. These functions not NOT only operate on the default_environment[]; they are also used to access the normal environment before relocation. my point is that they cannot be used after relocation and once the env is moved into the hash table. currently, they dont return any errors if someone attempts to do so and while it might seem like the funcs are working, they only parse the default env. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] Add hash table support as base for new environment code
On Wednesday, December 08, 2010 05:02:38 Wolfgang Denk wrote: Mike Frysinger wrote: unless i'm missing something, the non-reentrant versions operate on a single shared hash table. so while this works today because there is only one Correct. consumer (the env code), wont this cause problems as soon as someone else tries to use the non-reentrant hash table code ? as such, wouldnt it make sense to punt all of the non-reentrant versions and thus force everyone to maintain their own struct hsearch_data instance ? This could be done, but I don't see an immediate need. off the top of my head: - it isnt obvious to people today that this issue exists, so anyone attempting to use the fun new hashtable code could conceivably use it without running into a problem (as long as their keys dont happen to collide with env names). so people could possibly waste quite a bit of their time trying to track down bugs that only crop up when certain env vars are set. - i imagine a bit of space is being wasted here. - i re-implemented env-autocomplete, but i need access to the hashtable structure where everything is stored. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 1/2] hashtable: drop all non-reentrant versions
The non-reentrant versions of the hashtable functions operate on a single
shared hashtable. So if two different people try using these funcs for
two different purposes, they'll cause problems for the other.
Avoid this by converting all existing hashtable consumers over to the
reentrant versions and then punting the non-reentrant ones.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
common/cmd_nvedit.c| 18 +-
common/env_common.c|6 --
common/env_dataflash.c |2 +-
common/env_eeprom.c|2 +-
common/env_flash.c |4 ++--
common/env_mmc.c |2 +-
common/env_nand.c |4 ++--
common/env_nvram.c |2 +-
common/env_onenand.c |2 +-
common/env_sf.c|4 ++--
include/environment.h |8
include/search.h | 18 +-
lib/hashtable.c| 40 ++--
13 files changed, 35 insertions(+), 77 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index dcc93c1..d8d314e 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -111,7 +111,7 @@ static int env_print(char *name)
e.key = name;
e.data = NULL;
- ep = hsearch (e, FIND);
+ hsearch_r(e, FIND, ep, env_htab);
if (ep == NULL)
return 0;
len = printf (%s=%s\n, ep-key, ep-data);
@@ -119,7 +119,7 @@ static int env_print(char *name)
}
/* print whole list */
- len = hexport('\n', res, 0);
+ len = hexport_r(env_htab, '\n', res, 0);
if (len 0) {
puts(res);
@@ -184,7 +184,7 @@ int _do_env_set (int flag, int argc, char * const argv[])
*/
e.key = name;
e.data = NULL;
- ep = hsearch (e, FIND);
+ hsearch_r(e, FIND, ep, env_htab);
/* Check for console redirection */
if (strcmp(name,stdin) == 0) {
@@ -267,7 +267,7 @@ int _do_env_set (int flag, int argc, char * const argv[])
/* Delete only ? */
if ((argc 3) || argv[2] == NULL) {
- int rc = hdelete(name);
+ int rc = hdelete_r(name, env_htab);
return !rc;
}
@@ -293,7 +293,7 @@ int _do_env_set (int flag, int argc, char * const argv[])
e.key = name;
e.data = value;
- ep = hsearch(e, ENTER);
+ hsearch_r(e, ENTER, ep, env_htab);
free(value);
if (!ep) {
printf(## Error inserting \%s\ variable, errno=%d\n,
@@ -456,7 +456,7 @@ char *getenv (char *name)
e.key = name;
e.data = NULL;
- ep = hsearch (e, FIND);
+ hsearch_r(e, FIND, ep, env_htab);
return (ep ? ep-data : NULL);
}
@@ -651,7 +651,7 @@ static int do_env_export(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
}
if (sep) { /* export as text file */
- len = hexport(sep, addr, size);
+ len = hexport_r(env_htab, sep, addr, size);
if (len 0) {
error(Cannot export environment: errno = %d\n,
errno);
@@ -670,7 +670,7 @@ static int do_env_export(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
else/* export as raw binary data */
res = addr;
- len = hexport('\0', res, ENV_SIZE);
+ len = hexport_r(env_htab, '\0', res, ENV_SIZE);
if (len 0) {
error(Cannot export environment: errno = %d\n,
errno);
@@ -790,7 +790,7 @@ static int do_env_import(cmd_tbl_t * cmdtp, int flag, int
argc, char * const arg
addr = (char *)ep-data;
}
- if (himport(addr, size, sep, del ? 0 : H_NOCLEAR) == 0) {
+ if (himport_r(env_htab, addr, size, sep, del ? 0 : H_NOCLEAR) == 0) {
error(Environment import failed: errno = %d\n, errno);
return 1;
}
diff --git a/common/env_common.c b/common/env_common.c
index a276efc..ae710e5 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -129,6 +129,8 @@ uchar default_environment[] = {
\0
};
+struct hsearch_data env_htab;
+
static uchar env_get_char_init (int index)
{
uchar c;
@@ -187,7 +189,7 @@ void set_default_env(const char *s)
puts(Using default environment\n\n);
}
- if (himport((char *)default_environment,
+ if (himport_r(env_htab, (char *)default_environment,
sizeof(default_environment), '\0', 0) == 0) {
error(Environment import failed: errno = %d\n, errno);
}
@@ -213,7 +215,7 @@ int env_import(const char *buf, int check)
}
}
- if (himport((char *)ep-data, ENV_SIZE, '\0', 0)) {
+ if (himport_r(env_htab, (char *)ep-data, ENV_SIZE, '\0', 0)) {
gd-flags |=
[U-Boot] [RFC PATCH 2/2] env: re-add support for auto-completion
Currently, only basic completion is supported (no globs), but this is what
we had previously. The downside is that the results are not returned in
any sorted order. The upside is that we get any results at all.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
common/command.c|3 +--
common/env_common.c | 34 +++---
include/search.h|7 +++
lib/hashtable.c | 20
4 files changed, 39 insertions(+), 25 deletions(-)
diff --git a/common/command.c b/common/command.c
index 0b1a3fb..aaebaca 100644
--- a/common/command.c
+++ b/common/command.c
@@ -162,7 +162,6 @@ int cmd_usage(cmd_tbl_t *cmdtp)
int var_complete(int argc, char * const argv[], char last_char, int maxv, char
*cmdv[])
{
-#if 0 /* need to reimplement */
static char tmp_buf[512];
int space;
@@ -173,7 +172,7 @@ int var_complete(int argc, char * const argv[], char
last_char, int maxv, char *
if (!space argc == 2)
return env_complete(argv[1], maxv, cmdv, sizeof(tmp_buf),
tmp_buf);
-#endif
+
return 0;
}
diff --git a/common/env_common.c b/common/env_common.c
index ae710e5..6c694c5 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -246,40 +246,28 @@ void env_relocate (void)
}
}
-#if 0 /* need to reimplement - def CONFIG_AUTO_COMPLETE */
+#ifdef CONFIG_AUTO_COMPLETE
int env_complete(char *var, int maxv, char *cmdv[], int bufsz, char *buf)
{
- int i, nxt, len, vallen, found;
- const char *lval, *rval;
+ ENTRY *match;
+ int found, idx;
+ idx = 0;
found = 0;
cmdv[0] = NULL;
- len = strlen(var);
- /* now iterate over the variables and select those that match */
- for (i=0; env_get_char(i) != '\0'; i=nxt+1) {
+ while ((idx = hmatch_r(var, idx, match, env_htab))) {
+ int vallen = strlen(match-key) + 1;
- for (nxt=i; env_get_char(nxt) != '\0'; ++nxt)
- ;
-
- lval = (char *)env_get_addr(i);
- rval = strchr(lval, '=');
- if (rval != NULL) {
- vallen = rval - lval;
- rval++;
- } else
- vallen = strlen(lval);
-
- if (len 0 (vallen len || memcmp(lval, var, len) != 0))
- continue;
-
- if (found = maxv - 2 || bufsz vallen + 1) {
+ if (found = maxv - 2 || bufsz vallen) {
cmdv[found++] = ...;
break;
}
+
cmdv[found++] = buf;
- memcpy(buf, lval, vallen); buf += vallen; bufsz -= vallen;
- *buf++ = '\0'; bufsz--;
+ memcpy(buf, match-key, vallen);
+ buf += vallen;
+ bufsz -= vallen;
}
cmdv[found] = NULL;
diff --git a/include/search.h b/include/search.h
index 81ced7f..a7c1293 100644
--- a/include/search.h
+++ b/include/search.h
@@ -74,6 +74,13 @@ extern void hdestroy_r(struct hsearch_data *__htab);
extern int hsearch_r(ENTRY __item, ACTION __action, ENTRY ** __retval,
struct hsearch_data *__htab);
+/*
+ * Search for an entry matching `MATCH'. Otherwise, Same semantics
+ * as hsearch_r().
+ */
+extern int hmatch_r(const char *__match, int __last_idx, ENTRY ** __retval,
+ struct hsearch_data *__htab);
+
/* Search and delete entry matching ITEM.key in internal hash table. */
extern int hdelete_r(const char *__key, struct hsearch_data *__htab);
diff --git a/lib/hashtable.c b/lib/hashtable.c
index b47f3b6..9f069c0 100644
--- a/lib/hashtable.c
+++ b/lib/hashtable.c
@@ -202,6 +202,26 @@ void hdestroy_r(struct hsearch_data *htab)
* example for functions like hdelete().
*/
+int hmatch_r(const char *match, int last_idx, ENTRY ** retval,
+struct hsearch_data *htab)
+{
+ unsigned int idx;
+ size_t key_len = strlen(match);
+
+ for (idx = last_idx + 1; idx htab-size; ++idx) {
+ if (!htab-table[idx].used)
+ continue;
+ if (!strncmp(match, htab-table[idx].entry.key, key_len)) {
+ *retval = htab-table[idx].entry;
+ return idx;
+ }
+ }
+
+ __set_errno(ESRCH);
+ *retval = NULL;
+ return 0;
+}
+
int hsearch_r(ENTRY item, ACTION action, ENTRY ** retval,
struct hsearch_data *htab)
{
--
1.7.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/2] hashtable: drop all non-reentrant versions
On Wednesday, December 08, 2010 06:26:04 Mike Frysinger wrote: The non-reentrant versions of the hashtable functions operate on a single shared hashtable. So if two different people try using these funcs for two different purposes, they'll cause problems for the other. Avoid this by converting all existing hashtable consumers over to the reentrant versions and then punting the non-reentrant ones. oh, and this does shrink the final u-boot a little, so that's good -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/2] hashtable: drop all non-reentrant versions
Dear Joakim Tjernlund, In message of280890af.2970da02-onc12577f3.004474f0-c12577f3.0044d...@transmode.se you wrote: oh, and this does shrink the final u-boot a little, so that's good -mike Nice, over the last years I have noticed that u-boot has grown a lot. I had to disable a few non essential commands to make it it fit. Does anyone else share my concern about the rapid growth of u-boot? I do, and always did. It's mainly features that drive the code size. Some recent changes (gc-sections on PPC) help a bit. And users submitting optimizations like above. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In general, they do what you want, unless you want consistency. - Larry Wall in the perl man page ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/2] hashtable: drop all non-reentrant versions
Wolfgang Denk w...@denx.de wrote on 2010/12/08 15:23:17:
Dear Joakim Tjernlund,
In message
of280890af.2970da02-onc12577f3.004474f0-c12577f3.0044d...@transmode.se you
wrote:
oh, and this does shrink the final u-boot a little, so that's good
-mike
Nice, over the last years I have noticed that u-boot has grown a lot.
I had to disable a few non essential commands to make it it fit.
Does anyone else share my concern about the rapid growth of u-boot?
I do, and always did. It's mainly features that drive the code size.
Some recent changes (gc-sections on PPC) help a bit. And users
submitting optimizations like above.
Yes, but I don't see any discussion about it. Just the occasional improvement
that pop by every now and then.
I got my own theory were some of the growth come from: string literals
Especially when using them in tables:
static struct {
ulong mask;
char *desc;
} bits[] = {
{
RSR_SWSR, Software Soft}, {
RSR_SWHR, Software Hard}, {
RSR_JSRS, JTAG Soft}, {
RSR_CSHR, Check Stop}, {
RSR_SWRS, Software Watchdog}, {
RSR_BMRS, Bus Monitor}, {
RSR_SRS, External/Internal Soft}, {
RSR_HRS, External/Internal Hard}
};
Obviously the strings consume space, but there is an hidden extra cost too:
each string gets an fixup entry(4 bytes) and a GOT entry(4 bytes) too.
Jocke
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/7] those series patches for add ben nanonote board
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All I just got one email form Ingenic people. the Peter jl...@ingenic.cn doesn't work for Ingenic any more, mean the email address is abandon. and there are another two ingenic people for contact window. Daniel z...@ingenic.cn ChangWei Jia cw...@ingenic.cn I have sended those patches to them. should I add Acked-by: Daniel z...@ingenic.cn Acked-by: ChangWei Jia cw...@ingenic.cn in next version patch, (I think this patch v4 still not good enough merge to upstream :) Please give me some feedback. very thanks. On 12/08/2010 02:20 PM, Xiangfu Liu wrote: Hi Wolfgang those patches are for add xburst jz4740 and Ben NanoNote(named qi_lb60) to U-Boot some info about xburst jz4740: the xburst jz4740 is recently added to linux 2.6.36 and it's support the device Ben NanoNote out of box, this xburst jz4740 cpu have one feature is Boot From USB, there is a small rom in jz4740, but LOW some PIN, the cpu will boot to this small rom, then init cpu and USB module, then we can send 8KB bin file to the cpu by USB(by using 'xbboot' or 'usbboot'[1]). which means if your bootloader is borken,(the first few KBs in NAND) you can always boot the device from usb, then reflash the nand. in OpenMoko FreeRunner, there are NOR and NAND. when people broken the nand bootloader, it's must boot from NOR, reflash the bootloader back when people broken the NAND and NOR, he(she) must reflash by using JTAG but in Ben NanoNote, we just need boot from usb. flash the nand again :) BTW:there are a lot of PMP, Audio device in China use the Xburst cpu, but I think they are all base on u-boot 1.1.6. by working on Ben NanoNote (http://en.qi-hardware.com) one year, we try to update the u-boot to last version and send it to upstream. :) for more info about Ingenic Xburst JZ4740 http://www.ingenic.cn/eng/default.aspx http://www.linux-mips.org/wiki/Ingenic FIXED in [PATCH v3] 1. describe what Jz4740 SoC 2. remove the ENDIANNESS in config.mk 3. don't breaks the 80-charcter-wide rule 4. get rid of #if 0 5. use proper I/O accessors to access registers. 6. remove C++ comments, cleanup code style. FIXED in [PATCH v4] 1. add Entry to MAINTAINERS and boards.cfg 2. add ben nanonote(qi_lb60) to Makefile 3. tested with CROSS_COMPILE=mips_4KCle- ./MAKEALL mips_el - -- Best Regards Xiangfu Liu http://www.openmobilefree.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz/nhUACgkQRRAEFRxkgLSR5QCgk2ry72Dz5k40LyE8qPEETqfD S5MAnjmGgkoYN4nI5eJ7k+X3GMZuj77Z =RCUG -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/7] those series patches for add ben nanonote board
Dear Xiangfu Liu, In message 4cff9e15.2040...@openmobilefree.net you wrote: I have sended those patches to them. should I add Acked-by: Daniel z...@ingenic.cn Acked-by: ChangWei Jia cw...@ingenic.cn Please do so if and only if they explicitly send you their ACK. Normally these ACKs schould be sent to the mailing list so we all can see them. And please do not top post / full quote. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Status quo. Latin for the mess we're in. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/7] those series patches for add ben nanonote board
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Wolfgang Denk On 12/08/2010 11:44 PM, Wolfgang Denk wrote: Dear Xiangfu Liu, In message 4cff9e15.2040...@openmobilefree.net you wrote: I have sended those patches to them. should I add Acked-by: Daniel z...@ingenic.cn Acked-by: ChangWei Jia cw...@ingenic.cn Please do so if and only if they explicitly send you their ACK. ok. got it. Normally these ACKs schould be sent to the mailing list so we all can oh. the patches I send to them is just the same [PATCH v4 ...] I send to mailing list. just for them easy review the code. I will CC to them next time. :) see them. And please do not top post / full quote. sorry. - -- Best Regards Xiangfu Liu http://www.openmobilefree.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz/qZwACgkQRRAEFRxkgLS7XQCfTaR+NC5twU5d8B26On8s9m7I Pq4An3+zRWvmcdgbYjKwp/ffv80BJ+V+ =wuSD -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
On 12/07/2010 11:09 AM, Wolfgang Denk wrote: There are many board vendors who shipt boards with different configurations - with or without NAND flash; with or without other peripherals like CAN contollers, LCD, etc.; with different LCD sizes and types, in portrait or landscape orientation, etc. Some of these features can be determined by probing the hardware, others (like the orientation of a LCD) cannot. It is sometimes a maintenance nightmare to provide tens of different configurations of U-Boot for a single product. Being able to cinfigure available hardware through the DT, and using a single common binary image of U-Boot for such systems would be a great benefit. That's fine, but so far I don't see how it's related. This is information u-boot needs during its own initialization, right? We need a way for our tools to specify information to the kernels' initialization, and still want u-boot to do all the hardware configuration it does today. It really doesn't matter to us if in the future u-boot uses device trees for that configuration: we just need a way to interact with the kernels. Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
On 12/07/2010 11:09 AM, Wolfgang Denk wrote: So far we usually had pretty static board configurations, and a static compile time description was all we needed. Some developers consider even simple extensions like auto-sizing the available RAM as unnecessary luxury that just inreases the boot time and memory footprint. When it comes to more complicated setups we should provide means for a more dynamic configuration - this has been discussed before, and there was a general agreement that the device tree would be a usable way to implement such a description of the hardware. So what I'm proposing is not an opposite to what you have in mind, it just takes it one step further, and makes the whole system consistent again. Waht I don't like is the tunneling of information through U-Boot, while U-Boot actually needs and uses this very information as well. I won't argue with you on this front. Having U-Boot determine some board information from the DT and determine other board information at run-time is not consistent and confusing. While we could provide a method to provide this information at build time to make U-Boot, this forces a static memory partitioning on the system and does not mesh well with use cases where developers may This is NOT what I suggested. Thanks for clarifying that. You had stated pass make U-Boot process this information and I read that as in passing the information to the build (make) process. In the multi-node environments, we can't simply tell U-Boot to process the DTB to determine how much memory is in the system as there is one DTB per AMP node. One idea that comes to mind but that I think is not Please explain: you can use the DT to tell Linux (or other OS) how much memory they shoulduse, but you cannot use the same mechanism to pass the same information to U-Boot? I'm not against U-Boot using this information, I'm just not sure how to do this without adding quite a bit of complexity to the code base. We would have to have U-Boot parse the memory nodes, validate them, check for overlapping regions, check for holes, etc. I'm not arguing that it is not doable, but wondering if adding this complexity is worth if the scanning of memory and passing that information to the kernel works for the majority of use cases. What I'm trying to do is support a special use case, so what about wrapping support for simply passing the memory nodes from the DT to the kernel around a CONFIG option (CONFIG_OF_MEMORY_PASSTHROUGH?) that can be enabled by system implementers who need this and are running on fairly controlled environments while the larger issue of how to use the DT is hashed out? the right way to go due to complexity is to have the concept of nested DTBs that can define multiple operational machines and U-Boot knows how to read this and send the right sub-DTB to the right kernel image. This is a technical details that can and should be discussed when we have an agreement about the basic mechanism. I'm new to U-Boot development so would like to hear about the other use cases you mentioned (pointer to email threads are OK) so I can have a better understanding of the overall issues. There are many board vendors who shipt boards with different configurations - with or without NAND flash; with or without other peripherals like CAN contollers, LCD, etc.; with different LCD sizes and types, in portrait or landscape orientation, etc. Some of these features can be determined by probing the hardware, others (like the orientation of a LCD) cannot. It is sometimes a maintenance nightmare to provide tens of different configurations of U-Boot for a single product. Being able to cinfigure available hardware through the DT, and using a single common binary image of U-Boot for such systems would be a great benefit. I completely understand your perspective here and agree with it. DT has made the kernel easier to maintain across multiple similar platforms so it makes sense to leverage the same technology in U-Boot. Partitioning for AMP operation is about managing what and how is running on top of the bootloader. How much knowledge should the bootloader have about this? The approach of providing the memory partitioning in the DTB basically removes any of this knowledge from U-Boot, while the I see many use cases where this is simply not possible, because you need need the help of the bootloader to determine parameters that are not known in advance, and that thus cannot be encoded in the DT. Memory size if a very typical example for such a parameter. It may be OK for the use case you have currently in mind to use a fixed size, but this covers just a few systems and is not flexible enough for general use. Again, I understand this, though I am not 100% sure there is a way to do this in a completely generic way off the top of my head. There are use cases where we must rely on U-Boot to scan and determine memory size and there
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
On 12/07/2010 01:22 PM, Scott Wood wrote: On Mon, 6 Dec 2010 16:56:26 -0800 Deepak Saxena deepak_sax...@mentor.com wrote: +/* + * Check to see if an valid memory/reg property exists + * in the fdt. If so, we do not overwrite it with what's + * been scanned. + * + * Valid mean all the following: + * + * - Memory node has a device-type of memory + * - A reg property exists which: + * + has exactly as many cells as #address-cells + #size-cells + * + provides a range that is within [bi_memstart, bi_memstart + bi_memsize] + */ This will get false positives -- a lot of existing device tree templates have something like this: ACK. The code in the patch actually checks for this, just didn't point it out in the comments. ~deepak ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
On Wed, 8 Dec 2010 10:59:44 -0800
Deepak Saxena deepak_sax...@mentor.com wrote:
On 12/07/2010 01:22 PM, Scott Wood wrote:
On Mon, 6 Dec 2010 16:56:26 -0800
Deepak Saxena deepak_sax...@mentor.com wrote:
+/*
+ * Check to see if an valid memory/reg property exists
+ * in the fdt. If so, we do not overwrite it with what's
+ * been scanned.
+ *
+ * Valid mean all the following:
+ *
+ * - Memory node has a device-type of memory
+ * - A reg property exists which:
+ * + has exactly as many cells as #address-cells + #size-cells
+ * + provides a range that is within [bi_memstart, bi_memstart +
bi_memsize]
+ */
This will get false positives -- a lot of existing device tree
templates have something like this:
ACK. The code in the patch actually checks for this, just didn't point
it out in the comments.
Ah, I looked for that and missed it. But there are also some boards
that have socketed RAM, but for some reason have a real memory size in
the device tree (corresponding to what the board ships with,
probably). I think this is something that should have to be selectable
by the board config (for image size reasons as well).
Also some nits:
+static int ft_validate_memory(void *blob, bd_t *bd)
+{
+ int nodeoffset;
+ u32 *addrcell = (u32*)fdt_getprop(blob, 0, #address-cells, NULL);
+ u32 *sizecell = (u32*)fdt_getprop(blob, 0, #size-cells, NULL);
const u32 *, and eliminate the cast.
+ u64 reg_base, reg_size;
+ void *reg, *dtype;
+ int len;
+
+ if ((nodeoffset = fdt_path_offset(blob, /memory)) = 0)
+ {
Brace on same line as if
Don't put the assignment inside the if statement.
+ dtype = fdt_getprop(blob, nodeoffset, device_type, len);
+ if (!dtype || (strcmp(dtype, memory) != 0))
+ return 0;
+
+ reg = fdt_getprop(blob, nodeoffset, reg, len);
+ if (reg len == ((*addrcell + *sizecell) * 4)) {
+ if (*addrcell == 2) {
+ reg_base = ((u64*)reg)[0];
+ reg_size = ((u64*)reg)[1];
+ } else {
+ reg_base = ((u32*)reg)[0];
+ reg_size = ((u32*)reg)[1];
+ }
This only works on big-endian.
+ if ((reg_size)
+ (reg_base = (u64)bd-bi_memstart)
+ ((reg_size + reg_base)
+ = ((u64)bd-bi_memstart + (u64)bd-bi_memsize)))
+ return 1;
+ }
Probably want to complain to the user if reg is invalid and not zero/missing.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
On Dec 8, 2010, at 11:11 AM, Scott Wood wrote: Probably want to complain to the user if reg is invalid and not zero/missing. I think you guys are making this too complicated. There are many ways to pass stupid mistakes via a device tree, don't get carried away trying to single out this one for error checking where the user is likely to really know what they are doing. This isn't a required specification to get correct, without anything u-boot will provide the proper information. Thanks. -- Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
On Wed, 8 Dec 2010 11:22:59 -0800 Dan Malek ppc6...@digitaldans.com wrote: On Dec 8, 2010, at 11:11 AM, Scott Wood wrote: Probably want to complain to the user if reg is invalid and not zero/missing. I think you guys are making this too complicated. There are many ways to pass stupid mistakes via a device tree, don't get carried away trying to single out this one for error checking where the user is likely to really know what they are doing. This isn't a required specification to get correct, without anything u-boot will provide the proper information. I don't think that's what this is for. I think it's for AMP scenarios where you want to carve up memory between guests -- in which case you want U-Boot to not overwrite the device tree with its own idea of how much memory is present. This patch was trying to guess whether that's the case based on whether the existing value looks reasonable, but I think it has to be an explicit configuration (board config, environment variable, etc). Once that is done, then the test should either go away, or complain -- don't just silently do something different if it's been told that the memory node is supposed to be complete and correct. As for the merits of error checking in general, obviously it's not going to be complete. But it can be useful to check for some common errors, such as when a board has multiple DTSes and the user has to pick the right one for how U-Boot has been configured. Maybe granting an AMP partition a memory region beyond the bounds of detected memory is another such case. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Port to at91sam9g45-ekes
Hi U-boot members. I have ported u-boot to the AT91SAM9G45-EKES board. I have, however, run into a little problem. The internal boot-ROM in the SAM9G45 processor only accepts boot-loaders up to 60K and the loader I have is already 70K. I therefore need an chainloader in between. Is there a recommended approach for this, something like 1. Use some other smaller bootloader to boot u-boot. 2. Use a tiny version of u-boot to boot the real u-boot. 3. Use pieces u-boot, e.g. by replacing start_armboot ... or should I just use man fantasy? ;-) Regards, Morten Kristiansen -- All opinions are not equal. Some are a very great deal more robust, sophisticated and well supported in logic and argument than others. --Douglas Adams ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Port to at91sam9g45-ekes
Dear Morten Kristiansen, Hi U-boot members. I have ported u-boot to the AT91SAM9G45-EKES board. I have, however, run into a little problem. The internal boot-ROM in the SAM9G45 processor only accepts boot-loaders up to 60K and the loader I have is already 70K. I therefore need an chainloader in between. Is there a recommended approach for this, something like You are likely to end near 200k... 1. Use some other smaller bootloader to boot u-boot. That would usually be AT91BOOTSTRAP, which initializes SDRAM and loads software from NAND, SPI, MMC etc. 2. Use a tiny version of u-boot to boot the real u-boot. We don't have that (yet) for AT91. 3. Use pieces u-boot, e.g. by replacing start_armboot Are you using current u-boot, like at least the released 2010.09 ? Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gen_atmel_mci freeze on at91sam9g45
Dear eric cariat, First make sure the clock values are correct: Assuming the system is running at 400MHz, this would make sense if the MCI is clocked by system clock / 3. Then the minimum clock would indeed be 260416. Clock values are OK (running from 12 Mhz like the 9g45 eval kit), system running at 400 Mhz. 260416 Hz is exactly what I probe on the hardware. Good. Is the 9G45 (H)MCI is really identical to the 9260 MCI or are there subtle differences? I checked the datasheet of the 9260, most register seems to be the same... I suppose you have been testing the gen_atmel_mci on the 9260 ? Correct, on 9xe which is like 9260 Have you tested whether a udelay() serves the same purpose? It would seem that there is an issue when mci_data_op() is called too frequently. However, quite the same code exists a few lines above and it did not hang there. I added a udelay(1) and udelay(50) - it freeze If I put a udelay(100) - everything is OK (same effect as printf) 100us is a significant slowdown, that means 10kWords per second... Is your data cache on? I suppose it is enabled by default, so I added #define CONFIG_SYS_NO_CP15_CACHE in my config file - but that still freeze That define seems odd to me, it should be CONFIG_SYS_NO_DCACHE. My observation are the following : It seems that we are trying to read too many data byte : for ACMD 51 : the data reply is not a full 512 bytes data packet, but only 8 bytes len (checked with oscillo). Actually when in function mci_send_cmd() with ACMD 51, we first read the 8 useful byte ... then we try to fill the rest of block = we try to read 512 - 8 = 504 more bytes (which never comes on the DAT0 ) as there are no more data we should exit from mci_data_read() with a timeout error, but this never happen (I have to check error_flags about that) That should not hurt, and even if, it should not depend on the speed at which we are trying to read the dummy data. Doing a pause or printf in the while change the RXRDY flag (set to 1) and so we exit from the while without any error... ( I could not understand why ? ). It seems that when we don't read the correct number of byte, the MCI controller behave incorrectly (the status register seems to be incoherent) This sounds very fishy to me. Actually the driver set a block len of 512 byte only once (at initialization) in the mode register (mr) in gen_atmel_mci:mci_set_mode(). So I suppose we need to change dynamically the block len for each command (most command will use the 512 byte data block reply, but some (like ACMD51) are using a specific len - I think we don't need to change the block len in the SDCard see comment [1] below ) snip But this is not correct because it must be done only for specific command (with a fixed data size reply), Here, the filling the rest of block is never used again - the code is working using mmcinfo, rescan and fatls (I d'ont need the printf or udelay anymore in the while loop), but unfortunately If I remove all other debug information - It freeze again ! Which again suggests its not due to the way the Card is handled. So I suppose we have to modify the code for every command - we need to know if the data reply is a fixed size or if we have to fill the rest of loop (to fill a 512 byte data packet). But the number of data byte reply for each command is not really clear in the specification (Simplified_Physical_Layer_Spec.pdf) I don't know if there are some more documentation on that ... Google for SDCard and license restrictions... So I 'm not sure if I'm looking in the right direction ? am I missing something about the length on data reply ? just wanted to know what you think about all that ? any other advice ? I would think to look more in the hardware/memory/cache direction and less in the driver direction. The 9xe/9260 here runs at 200MHz and the MCI at 100 MHz, which is close to your 133MHz, and there are no such effects here whatsoever from old 1GB Cards to 32GB SDHC Cards. Best regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Elf relocation issues with jornada
Greetings, Im obviously doing something wrong. This is what I get at bootup: U-Boot 2010.12-rc2-00029-g49733aa-dirty (Dec 08 2010 - 21:04:16) DRAM: 361.9 MiB The DRAM is pulling some random number each time, so Ive gotten 0,0,146.2,361.8.Patch attached. Best wishes Kristoffer Ericson diff --git a/include/configs/jornada.h b/include/configs/jornada.h index 41b09aa..a8efb02 100644 --- a/include/configs/jornada.h +++ b/include/configs/jornada.h @@ -29,7 +29,7 @@ #define CONFIG_JORNADA700 1 /* on an HP Jornada 700 series */ #define CONFIG_SYS_FLASH_PROTECTION1 -#define CONFIG_SYS_TEXT_BASE 0xC1F0 +#define CONFIG_SYS_TEXT_BASE 0x0 /* we will never enable dcache, because we have to setup MMU first */ #define CONFIG_SYS_NO_DCACHE @@ -71,7 +71,6 @@ #define CONFIG_BOOTARGSroot=/dev/hda1 console=ttySA0,19200n8 console=tty1 #define CONFIG_BOOTCOMMAND run boot_kernel #define CONFIG_SYS_AUTOLOADn /* No autoload */ -#define CONFIG_SYS_LOAD_ADDR 0xc000 /* * Miscellaneous configurable options @@ -128,15 +127,19 @@ */ #define CONFIG_NR_DRAM_BANKS 2 -#define CONFIG_SYS_SDRAM_BASE 0x -#define CONFIG_SYS_INTRAM_BASE INTERNAL_SRAM_BASE -#define CONFIG_SYS_INTRAM_SIZE INTERNAL_SRAM_SIZE -#define CONFIG_SYS_INIT_SP_ADDR0x0 #define PHYS_SDRAM_1 0xc000 /* SDRAM Bank #1 */ #define PHYS_SDRAM_2 0xc400 /* SDRAM Bank #2 */ #define PHYS_SDRAM_1_SIZE 0x0400 /* 64 MB */ #define PHYS_SDRAM_2_SIZE 0x0400 /* 64 MB */ +#define CONFIG_NR_DRAM_BANKS 2 +#define CONFIG_SYS_DRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_DRAM_SIZE 0x0400 + +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR(PHYS_SDRAM_1 + GENERATED_GBL_DATA_SIZE + 0x2048) +#define CONFIG_SYS_LOAD_ADDR (CONFIG_SYS_DRAM_BASE + 0x8000) + #define CONFIG_CMD_MTDPARTS #define CONFIG_MTD_DEVICE #define CONFIG_FLASH_CFI_MTD ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
Dear Hollis Blanchard, In message 4cffcec1.6000...@mentor.com you wrote: On 12/07/2010 11:09 AM, Wolfgang Denk wrote: There are many board vendors who shipt boards with different configurations - with or without NAND flash; with or without other peripherals like CAN contollers, LCD, etc.; with different LCD sizes and types, in portrait or landscape orientation, etc. Some of these features can be determined by probing the hardware, others (like the orientation of a LCD) cannot. It is sometimes a maintenance nightmare to provide tens of different configurations of U-Boot for a single product. Being able to cinfigure available hardware through the DT, and using a single common binary image of U-Boot for such systems would be a great benefit. That's fine, but so far I don't see how it's related. This is information u-boot needs during its own initialization, right? Right. We need a way for our tools to specify information to the kernels' initialization, and still want u-boot to do all the hardware configuration it does today. It really doesn't matter to us if in the future u-boot uses device trees for that configuration: we just need a way to interact with the kernels. When U-boot is supposed to do the hardware initialization, you probably include memory initialization, right? If so, should we then not make sure that U-Boot and the OS we're booting use the same information about this resource? If, on the other hand, you really want to make U-Boot ignore any /memory nodes in the device tree, then this should be done straight and without additional magic. In this case the DT should be responsible to provide all information the OS needs, and U-Boot should not touch this in any way. Then just do not call fdt_fixup_memory() at all for such configurations. I dislike the idea that U-Boot will not touch the DT entry in one situation, but will do so in another, without any visibility to (and eventually without awareness by) the user. If there is really a good reason for such magic, then this should be clearly documented (not only in some comment in some source file), and eventually fdt_fixup_memory() (or fdt_fixup_memory_banks() ?) should be made weak so it can be redefined by board-specific implementations. In any case, any such changes should be implemented in a generic way, i. e. not only for one specific processor family. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. - Frederick Brooks Jr., The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
Dear Deepak Saxena, In message 4cffd57c.1010...@mentor.com you wrote: Please explain: you can use the DT to tell Linux (or other OS) how much memory they shoulduse, but you cannot use the same mechanism to pass the same information to U-Boot? I'm not against U-Boot using this information, I'm just not sure how to do this without adding quite a bit of complexity to the code base. We would have to have U-Boot parse the memory nodes, validate them, check for overlapping regions, check for holes, etc. I'm not arguing that it is not doable, but wondering if adding this complexity is worth if the scanning of memory and passing that information to the kernel works for the majority of use cases. What I'm trying to do is support a special use case, so what about wrapping support for simply passing the memory nodes from the DT to the kernel around a CONFIG option (CONFIG_OF_MEMORY_PASSTHROUGH?) that can be enabled by system implementers who need this and are running on fairly controlled environments while the larger issue of how to use the DT is hashed out? See my previous message to Hollis. If you really want U-Boot to keep it's fingers off the /memory nodes in the DT, then simply do that. But then please be consequent, add it for all architectures, and if enabled, then without magic where U-Boot will sometimes to this and other times do that. And provide documentation to the end user. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can observe a lot just by watchin'. - Yogi Berra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
On 12/08/2010 12:53 PM, Wolfgang Denk wrote: Dear Hollis Blanchard, In message4cffcec1.6000...@mentor.com you wrote: On 12/07/2010 11:09 AM, Wolfgang Denk wrote: There are many board vendors who shipt boards with different configurations - with or without NAND flash; with or without other peripherals like CAN contollers, LCD, etc.; with different LCD sizes and types, in portrait or landscape orientation, etc. Some of these features can be determined by probing the hardware, others (like the orientation of a LCD) cannot. It is sometimes a maintenance nightmare to provide tens of different configurations of U-Boot for a single product. Being able to cinfigure available hardware through the DT, and using a single common binary image of U-Boot for such systems would be a great benefit. That's fine, but so far I don't see how it's related. This is information u-boot needs during its own initialization, right? Right. We need a way for our tools to specify information to the kernels' initialization, and still want u-boot to do all the hardware configuration it does today. It really doesn't matter to us if in the future u-boot uses device trees for that configuration: we just need a way to interact with the kernels. When U-boot is supposed to do the hardware initialization, you probably include memory initialization, right? If so, should we then not make sure that U-Boot and the OS we're booting use the same information about this resource? Yes, I do include memory initialization. In our use case, u-boot must know about all memory (to configure the memory controller), but each OS is only made aware of a piece of it. They really do have different information about the resource. If, on the other hand, you really want to make U-Boot ignore any /memory nodes in the device tree, then this should be done straight and without additional magic. In this case the DT should be responsible to provide all information the OS needs, and U-Boot should not touch this in any way. Then just do not call fdt_fixup_memory() at all for such configurations. I think the current way that u-boot updates the memory node is valuable for other use cases. In particular, it is very convenient for single-OS systems. Our goal is to avoid affecting those use cases. I dislike the idea that U-Boot will not touch the DT entry in one situation, but will do so in another, without any visibility to (and eventually without awareness by) the user. I see it as allowing the user to optionally override auto-detected information. The user has to go out of their way to request this behavior, so I think the visibility/awareness is there. The existing bootm_low/bootm_size facility does exactly this, but I think we can improve on its design. If there is really a good reason for such magic, then this should be clearly documented (not only in some comment in some source file), and eventually fdt_fixup_memory() (or fdt_fixup_memory_banks() ?) should be made weak so it can be redefined by board-specific implementations. In any case, any such changes should be implemented in a generic way, i. e. not only for one specific processor family. I agree that all (device tree aware) systems should behave consistently in this regard. Of course, in that case, we don't need weak functions? Documenting the behavior is a very good point. Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
Dear Hollis, In message 4cfff3c4.20...@mentor.com you wrote: I think the current way that u-boot updates the memory node is valuable for other use cases. In particular, it is very convenient for single-OS systems. Our goal is to avoid affecting those use cases. I dislike the idea that U-Boot will not touch the DT entry in one situation, but will do so in another, without any visibility to (and eventually without awareness by) the user. I see it as allowing the user to optionally override auto-detected information. The user has to go out of their way to request this behavior, so I think the visibility/awareness is there. OK - but then the user should really be requested to select the beviour. This should be done in an explicit and documented way, ant not based on some magic properties of the DT. The existing bootm_low/bootm_size facility does exactly this, but I think we can improve on its design. I have to admit that I also dislike the bootm_low / bootm_size stuff as it's really confusing to users, especially as the difference between bootm_size and CONFIG_SYS_BOOTMAPSZ (and BOOTMAPSZ, which is sometimes used instead) is not really clear. I agree that all (device tree aware) systems should behave consistently in this regard. Of course, in that case, we don't need weak functions? If you want to make this switchable at runtime, then we should probably use an environment setting. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Data is a lot like humans: It is born. Matures. Gets married to other data, divorced. Gets old. One thing that it doesn't do is die. It has to be killed. - Arthur Miller ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] V2: Please pull u-boot-atmel/for2010.12
Dear Reinhard Meyer, In message 4cfe9ff0.7000...@emk-elektronik.de you wrote: Dear Wolfgang, compiled TOT git. Now it handles the ß in e-Mails correctly The following changes since commit 52eb2c79110151b9017a0829c4d44ee7b8e2ca04: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-samsung are available in the git repository at: git://git.denx.de/u-boot-atmel.git for2010.12 Andreas Bießmann (5): at91rm9200ek: fix SDRAM initialistation values at91rm9200ek: add configure target for RAM boot MAKEALL: fix AT91 arm920t/at91/reset: board_reset: define weak symbol arm920t/at91/timer: replace bss variables by gd Reinhard Meyer (3): AT91: gen_atmel_mci.c: fix bug when Slot B is used AT91: fix EMAC gpio init in at91sam9260_devices.c AT91: add TOP9000 support MAINTAINERS |3 +- MAKEALL | 18 +- arch/arm/cpu/arm920t/at91/reset.c |8 +- arch/arm/cpu/arm920t/at91/timer.c | 29 +- arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c |5 + arch/arm/include/asm/global_data.h|1 + board/atmel/at91rm9200ek/config.mk|2 - board/emk/top9000/Makefile| 54 board/emk/top9000/spi.c | 61 board/emk/top9000/top9000.c | 290 +++ boards.cfg|5 +- drivers/mmc/gen_atmel_mci.c |1 + include/configs/at91rm9200ek.h| 18 ++- include/configs/top9000.h | 314 + 14 files changed, 771 insertions(+), 38 deletions(-) delete mode 100644 board/atmel/at91rm9200ek/config.mk create mode 100644 board/emk/top9000/Makefile create mode 100644 board/emk/top9000/spi.c create mode 100644 board/emk/top9000/top9000.c create mode 100644 include/configs/top9000.h Thanks, applied. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When properly administered, vacations do not diminish productivity: for every week you're away and get nothing done, there's another when your boss is away and you get twice as much done. -- Daniel B. Luten ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Installing UBoot on X86 architecture with BIOS
Hi I am newbie on Uboot or other boot loaders context.we intend to install our Linux based OS on Portwell (is not Embedded ) appliances and want to choose one boot loader with some features.Of course our appliances have BIOS. before any argue, one question arises: Is it possible to install Uboot on system that has BIOS? if so, Is it reasonable ? Some features we have need : 1- show detail information about hardware before loading kernel,such as storage system,ram capacity,CPU family and so on. 2- boot over net. 3-load kernel from storage. I have had some search on LILO, but before any decision, I want to make sure about other boot loaders. Thanks for any help or guidance -- N.Chavoshi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
Hi Wolfgang. On Dec 8, 2010, at 1:38 PM, Wolfgang Denk wrote: If you want to make this switchable at runtime, then we should probably use an environment setting. I experimented with this, but could never determine the best way to cover all behavior. Do we have a variable that indicates don't update DT? If so, it means we have to place all values in the DT, when it's really nice for U-Boot to do some of that for us. In fact, we want U-Boot to update many things it discovers, just not the few we wish to actually (sometimes) define for ourselves. The other alternative (granted, I'm not as smart as I used to be :-)) was to have an environment variable that specified which node we didn't want updated by U-Boot. For now, that seems reasonable since there is only one, but is that the general approach we want in the future? It also presents the challenge of having to update both environment and the provided DT. I just wanted to make these points, as I did try some alternatives but never found anything acceptable. By looking at key values in the DT, at least it was confined to one place. This feature is needed, so I propose we let it exist in the form we have found useful and let it evolve over time as others gain some experience. Thanks. -- Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm (master)
The following changes since commit 52eb2c79110151b9017a0829c4d44ee7b8e2ca04: Merge branch 'master' of git://git.denx.de/u-boot-samsung (2010-11-30 21:30:13 +0100) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Andreas Bießmann (5): at91rm9200ek: fix SDRAM initialistation values at91rm9200ek: add configure target for RAM boot MAKEALL: fix AT91 arm920t/at91/reset: board_reset: define weak symbol arm920t/at91/timer: replace bss variables by gd Reinhard Meyer (3): AT91: gen_atmel_mci.c: fix bug when Slot B is used AT91: fix EMAC gpio init in at91sam9260_devices.c AT91: add TOP9000 support MAINTAINERS |3 +- MAKEALL | 18 +- arch/arm/cpu/arm920t/at91/reset.c |8 +- arch/arm/cpu/arm920t/at91/timer.c | 29 +- arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c |5 + arch/arm/include/asm/global_data.h|1 + board/atmel/at91rm9200ek/config.mk|2 - board/emk/top9000/Makefile| 54 board/emk/top9000/spi.c | 61 board/emk/top9000/top9000.c | 290 +++ boards.cfg|5 +- drivers/mmc/gen_atmel_mci.c |1 + include/configs/at91rm9200ek.h| 18 ++- include/configs/top9000.h | 314 + 14 files changed, 771 insertions(+), 38 deletions(-) delete mode 100644 board/atmel/at91rm9200ek/config.mk create mode 100644 board/emk/top9000/Makefile create mode 100644 board/emk/top9000/spi.c create mode 100644 board/emk/top9000/top9000.c create mode 100644 include/configs/top9000.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: nand flash
Dear Scott Wood, In message 20101207220511.ga31...@udp111988uds.am.freescale.net you wrote: The following changes since commit f12af1f38dc59a6dfe0fed1359e1a05e700a43= 5b: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-video are available in the git repository at: git://git.denx.de/u-boot-nand-flash.git master David M=FCller (ELSOFT AG) (1): fix s3c2410_nand timing default values Lei Wen (1): onenand: fix oob print out issue Scott Wood (1): 83xx NAND boot: fix boards.cfg Steve Sakoman (1): env_nand: Use nand_read_skip_bad instead of nand_read boards.cfg |6 +++--- common/cmd_onenand.c|4 +++- common/env_nand.c |2 +- drivers/mtd/nand/s3c2410_nand.c | 12 +--- 4 files changed, 16 insertions(+), 8 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The human race is faced with a cruel choice: work or daytime tele- vision. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
Dear Dan, In message 0ddcbda1-188f-433d-bdcc-5fdcf709a...@digitaldans.com you wrote: If you want to make this switchable at runtime, then we should probably use an environment setting. I experimented with this, but could never determine the best way to cover all behavior. Do we have a variable that indicates don't update DT? If so, it means we have to place all values in the DT, when it's really nice for U-Boot to do some of that for us. In fact, we want U-Boot to update many things it discovers, just not the few we wish to actually (sometimes) define for ourselves. You can please all the people some of the time and some of the people all of the time but you can't please all the people all of the time. The other alternative (granted, I'm not as smart as I used to be :-)) was to have an environment variable that specified which node we didn't want updated by U-Boot. For now, that seems reasonable since there is only one, but is that the general approach we want in the future? It also presents the challenge of having to update both environment and the provided DT. I guess we can argue that the normal situation is that U-Boot will know how to update the DT such as needed to boot the OS. So what we are dealing with is a small percentage of cases where we need special behaviour, and where it may be acceptable if the solution is only semi-perfect ;-) My current thinking is to introduce something like dt_skip=memory,mac-address including eventually dt_skip=ALL. This should cover most of the current use cases. If someone gets fancy he can add wildcard support. And if we need even more flexibility, we can add some dt_include with higher priority, so one could do for example dt_skip=ALL dt_include=memory to have only the memory node updated. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you can't beat it or corrupt it, you pretend it was your idea in the first place. - Terry Pratchett, _Guards! Guards!_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm (master)
Dear Wolfgang Denk, In message 20101208220832.c2877cf5...@gemini.denx.de you wrote: The following changes since commit 52eb2c79110151b9017a0829c4d44ee7b8e2ca04: Merge branch 'master' of git://git.denx.de/u-boot-samsung (2010-11-30 21:= 30:13 +0100) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Andreas Bießmann (5): at91rm9200ek: fix SDRAM initialistation values at91rm9200ek: add configure target for RAM boot MAKEALL: fix AT91 arm920t/at91/reset: board_reset: define weak symbol arm920t/at91/timer: replace bss variables by gd Reinhard Meyer (3): AT91: gen_atmel_mci.c: fix bug when Slot B is used AT91: fix EMAC gpio init in at91sam9260_devices.c AT91: add TOP9000 support MAINTAINERS |3 +- MAKEALL | 18 +- arch/arm/cpu/arm920t/at91/reset.c |8 +- arch/arm/cpu/arm920t/at91/timer.c | 29 +- arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c |5 + arch/arm/include/asm/global_data.h|1 + board/atmel/at91rm9200ek/config.mk|2 - board/emk/top9000/Makefile| 54 board/emk/top9000/spi.c | 61 board/emk/top9000/top9000.c | 290 +++ boards.cfg|5 +- drivers/mmc/gen_atmel_mci.c |1 + include/configs/at91rm9200ek.h| 18 ++- include/configs/top9000.h | 314 + 14 files changed, 771 insertions(+), 38 deletions(-) delete mode 100644 board/atmel/at91rm9200ek/config.mk create mode 100644 board/emk/top9000/Makefile create mode 100644 board/emk/top9000/spi.c create mode 100644 board/emk/top9000/top9000.c create mode 100644 include/configs/top9000.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I mean, I . . . think to understand you, I just don't know what you are saying ...- Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Vexpress build errors
Dear matt.wad...@linaro.org, In message 1291318994-31573-1-git-send-email-matt.wad...@linaro.org you wrote: From: Matt Waddel matt.wad...@linaro.org This patch fixes build errors in the vexpress system: - Removed sys_proto.h requirement from syslib.c. - Switched vexpress to the default armv7 linker script. - Renamed TEXT_BASE to CONFIG_SYS_TEXT_BASE. Signed-off-by: Matt Waddel matt.wad...@linaro.org --- Change log v2: Removed the new arch/arm/include/asm/arch-armv7/sys_proto.h file. arch/arm/cpu/armv7/syslib.c |1 - board/armltd/vexpress/config.mk |3 +- board/armltd/vexpress/u-boot.lds | 65 -- 3 files changed, 1 insertions(+), 68 deletions(-) delete mode 100644 board/armltd/vexpress/u-boot.lds Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Another megabytes the dust. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARMV7: Vexpress compile warnings
Dear matt.wad...@linaro.org, In message 1288740321-1341-3-git-send-email-matt.wad...@linaro.org you wrote: From: Matt Waddel matt.wad...@linaro.org Fixed pointer from integer without a cast warnings in Vexpress. Signed-off-by: Matt Waddel matt.wad...@linaro.org --- board/armltd/vexpress/ca9x4_ct_vxp.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The bad reputation UNIX has gotten is totally undeserved, laid on by people who don't understand, who have not gotten in there and tried anything. -- Jim Joyce, owner of Jim Joyce's UNIX Bookstore ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] ARMV7: Fixing Vexpress build errors and warnings
Dear Dirk Behme, In message 4cf3f77b.9080...@googlemail.com you wrote: With recent master, besides the two patches above, I additionally need something like below to get ca9x4_ct_vxp build: ARMV7: Vexpress: Fix build error Fix ca9x4_ct_vxp build error Configuring for ca9x4_ct_vxp board... board/armltd/vexpress/libvexpress.o: In function `udelay': u-boot.git/board/armltd/vexpress/ca9x4_ct_vxp.c:161: multiple definition of `udelay' lib/libgeneric.o:u-boot.git/lib/time.c:34: first defined here lib/libgeneric.o: In function `udelay': zlib.c:(.text+0x1ee8): undefined reference to `__udelay' Signed-of-by: Dirk Behme dirk.be...@googlemail.com --- board/armltd/vexpress/ca9x4_ct_vxp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Many Myths are based on truth -- Spock, The Way to Eden, stardate 5832.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Installing UBoot on X86 architecture with BIOS
On Thu, Dec 9, 2010 at 9:00 AM, nima chavooshi nima0...@gmail.com wrote: Hi I am newbie on Uboot or other boot loaders context.we intend to install our Linux based OS on Portwell (is not Embedded ) appliances and want to choose one boot loader with some features.Of course our appliances have BIOS. before any argue, one question arises: Is it possible to install Uboot on system that has BIOS? if so, Is it Not yet reasonable ? Not really Some features we have need : 1- show detail information about hardware before loading kernel,such as storage system,ram capacity,CPU family and so on. 2- boot over net. 3-load kernel from storage. I have had some search on LILO, but before any decision, I want to make sure about other boot loaders. Have you had a look at GRUB? Now let me explain a little further... U-Boot for the x86 architecture is designed to begin execution from the CPU's reset vector so it essentially replaces the BIOS. That being said, U-Boot does have a 'warm' entry point which, in theory, means it could be loaded into memory (by GRUB for example) but by this stage, the CPU has been put into 'Protected Mode' and the BIOS is no longer available (it can only be accessed by 'Real Mode' interrupts. I do intend to make x86 U-Boot loadable from GRUB, but only as an intermediate step towards porting U-Boot to single-board PCs. So yes, one day U-Boot will be loadable (via GRUB) on PCs, but it is only ever going to be a 'development step' towards removing the BIOS completely. Note that CoreBoot already offers up a PC BIOS replacement for mainstream PC motherboards - I intend to target U-Boot more towards industrial PC / Single-Board-Computers Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: add 8-byte alignment for ABI compliance before board_init_f
Dear Heiko Schocher, In message 1289544835-24425-1-git-send-email...@denx.de you wrote: suggested from Daniel Hobidaniel.h...@schmid-telecom.ch Tested on following boards: arm1136: qong armv7: omap3_beagle arm926ejs: magnesium, tx25 Signed-off-by: Heiko Schocher h...@denx.de cc: Daniel Hobi daniel.h...@schmid-telecom.ch cc: Albert ARIBAUD albert.arib...@free.fr --- arch/arm/cpu/arm1136/start.S |1 + arch/arm/cpu/arm1176/start.S |1 + arch/arm/cpu/arm720t/start.S |1 + arch/arm/cpu/arm920t/start.S |1 + arch/arm/cpu/arm925t/start.S |1 + arch/arm/cpu/arm926ejs/start.S |1 + arch/arm/cpu/arm946es/start.S |1 + arch/arm/cpu/arm_intcm/start.S |1 + arch/arm/cpu/armv7/start.S |1 + arch/arm/cpu/ixp/start.S |1 + arch/arm/cpu/lh7a40x/start.S |1 + arch/arm/cpu/pxa/start.S |1 + arch/arm/cpu/s3c44b0/start.S |1 + arch/arm/cpu/sa1100/start.S|1 + arch/arm/lib/board.c |2 +- 15 files changed, 15 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Our way is peace. -- Septimus, the Son Worshiper, Bread and Circuses, stardate 4040.7. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] arm920t: fix linker skript for -pie linking
Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message 1291099039-49672-4-git-send-email-andreas.de...@googlemail.com you wrote: Without this patch the linker will SEGFAULT on some undefined weak symbols. Suggested-by: Sebastien Carlier sebastien.carl...@gmail.com Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- arch/arm/cpu/arm920t/u-boot.lds |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de They say a little knowledge is a dangerous thing, but it is not one half so bad as a lot of ignorance. - Terry Pratchett, _Equal Rites_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] hwconfig: Fix handling of env_hwconfig, board_hwconfig, and cpu_hwconfig
Dear Kumar Gala, In message 1291154307-21377-1-git-send-email-ga...@kernel.crashing.org you wrote: The handling of env_hwconfig, board_hwconfig, and cpu_hwconfig got broken when we removed the boards defining dummy board_hwconfig cpu_hwconfig values. We fix this by handling the various strings in priority order. If hwconfig_parse returns NULL for a given string we check the next one in order (env_hwconfig, board_hwconfig, followed by cpu_hwconfig). Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- common/hwconfig.c | 15 +-- 1 files changed, 9 insertions(+), 6 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To IBM, 'open' means there is a modicum of interoperability among some of their equipment.- Harv Masterson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm: copy_loop(): use scratch register
Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message 1291161516-21861-2-git-send-email-andreas.de...@googlemail.com you wrote: This patch uses r1 as scratch register for copy_loop(). Therefore we do not longer need r7 for the storage of relocate_code()'s 'addr_moni' (the destination address of relocation). Therefore r7 can be used later on for other purposes. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- arch/arm/cpu/arm1136/start.S | 10 +- arch/arm/cpu/arm1176/start.S | 10 +- arch/arm/cpu/arm720t/start.S | 10 +- arch/arm/cpu/arm920t/start.S | 10 +- arch/arm/cpu/arm925t/start.S | 10 +- arch/arm/cpu/arm926ejs/start.S | 10 +- arch/arm/cpu/arm946es/start.S | 10 +- arch/arm/cpu/arm_intcm/start.S | 10 +- arch/arm/cpu/armv7/start.S | 10 +- arch/arm/cpu/ixp/start.S | 10 +- arch/arm/cpu/lh7a40x/start.S | 10 +- arch/arm/cpu/pxa/start.S | 10 +- arch/arm/cpu/s3c44b0/start.S | 10 +- arch/arm/cpu/sa1100/start.S| 10 +- 14 files changed, 70 insertions(+), 70 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Computers are not intelligent. They only think they are. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] arm: relocate_code(): do not set register useless
Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message 1291161516-21861-3-git-send-email-andreas.de...@googlemail.com you wrote: In case we are still at relocation target address before relocation we do not need to load the registers needed for relocation. We should instead skip the whole relocation part and jump over to clear_bss immediately. Signed-off-by: Andreas BieÃmann andreas.de...@googlemail.com --- arch/arm/cpu/arm1136/start.S |4 ++-- arch/arm/cpu/arm1176/start.S |4 ++-- arch/arm/cpu/arm720t/start.S |4 ++-- arch/arm/cpu/arm920t/start.S |4 ++-- arch/arm/cpu/arm925t/start.S |4 ++-- arch/arm/cpu/arm926ejs/start.S |4 ++-- arch/arm/cpu/arm946es/start.S |4 ++-- arch/arm/cpu/arm_intcm/start.S |4 ++-- arch/arm/cpu/armv7/start.S |8 arch/arm/cpu/ixp/start.S |4 ++-- arch/arm/cpu/lh7a40x/start.S |4 ++-- arch/arm/cpu/pxa/start.S |4 ++-- arch/arm/cpu/s3c44b0/start.S |4 ++-- arch/arm/cpu/sa1100/start.S|4 ++-- 14 files changed, 30 insertions(+), 30 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A little knowledge is a dangerous thing.- Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] arm: fixloop(): do not use r8 for relocation
Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message 1291161516-21861-4-git-send-email-andreas.de...@googlemail.com you wrote: r8 is used for global_data and should therefore be left alone! For C code the compiler flag --fixed-r8 does the job, but in assembler we need to be aware of that fact. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- arch/arm/cpu/arm1136/start.S |6 +++--- arch/arm/cpu/arm1176/start.S |6 +++--- arch/arm/cpu/arm720t/start.S |6 +++--- arch/arm/cpu/arm920t/start.S |6 +++--- arch/arm/cpu/arm925t/start.S |6 +++--- arch/arm/cpu/arm926ejs/start.S |6 +++--- arch/arm/cpu/arm946es/start.S |6 +++--- arch/arm/cpu/arm_intcm/start.S |6 +++--- arch/arm/cpu/armv7/start.S |6 +++--- arch/arm/cpu/ixp/start.S |6 +++--- arch/arm/cpu/lh7a40x/start.S |6 +++--- arch/arm/cpu/pxa/start.S |6 +++--- arch/arm/cpu/s3c44b0/start.S |6 +++--- arch/arm/cpu/sa1100/start.S|6 +++--- 14 files changed, 42 insertions(+), 42 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The IQ of the group is the lowest IQ of a member of the group divided by the number of people in the group. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] armv7: fix relocation skip
Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message 1291161516-21861-5-git-send-email-andreas.de...@googlemail.com you wrote: I doubt the stack_setup() was defective before: we load the current location of _start and compare against destination of relocate_code(). If we are already there we shoud skip the relocation and jump over to clear_bss. Before the clear_bss was also skipped. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- Dear Albert, (or whoever works with armv7 currently) However I doubt there is another issue when CONFIG_PRELOADER is not set! Then the bss will never be setup, is that correct? arch/arm/cpu/armv7/start.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have never understood the female capacity to avoid a direct answer to any question. -- Spock, This Side of Paradise, stardate 3417.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: make timer variables in gt_t available for all ARM platforms
Dear Prafulla Wadaskar, In message 1291205812-5491-1-git-send-email-prafu...@marvell.com you wrote: After ARM relocation, any code executed directly or indirectly by board_init_f() have global (BSS) variables need to be fixed. mostly timer.c needs to fix on most of the ARM platforms. This patch makes timer related variables in gd_t available for all ARM implementation Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- arch/arm/include/asm/global_data.h |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Do you know about being with somebody? Wanting to be? If I had the whole universe, I'd give it to you, Janice. When I see you, I feel like I'm hungry all over. Do you know how that feels? -- Charlie Evans, Charlie X, stardate 1535.8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] include/linux/mii.h: update for supporting GE
Dear Macpaul Lin, In message 129134-18586-1-git-send-email-macp...@andestech.com you wrote: This file has been synced (copy) from Linux source code. This commit was based on kernel 2.6.32. It updates gigabit related phy registers and basic definitions. Signed-off-by: Macpaul Lin macp...@andestech.com --- Change v1: pull header file from Linux. Change v2: clean up unused code for u-boot. include/linux/mii.h | 181 ++- 1 files changed, 107 insertions(+), 74 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Plans break down. You cannot plan the future. Only presumptuous fools plan. The wise man _steers_.- Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
On Wed, 2010-12-08 at 23:34 +0100, Wolfgang Denk wrote: Dear Dan, In message 0ddcbda1-188f-433d-bdcc-5fdcf709a...@digitaldans.com you wrote: If you want to make this switchable at runtime, then we should probably use an environment setting. I experimented with this, but could never determine the best way to cover all behavior. Do we have a variable that indicates don't update DT? If so, it means we have to place all values in the DT, when it's really nice for U-Boot to do some of that for us. In fact, we want U-Boot to update many things it discovers, just not the few we wish to actually (sometimes) define for ourselves. You can please all the people some of the time and some of the people all of the time but you can't please all the people all of the time. The other alternative (granted, I'm not as smart as I used to be :-)) was to have an environment variable that specified which node we didn't want updated by U-Boot. For now, that seems reasonable since there is only one, but is that the general approach we want in the future? It also presents the challenge of having to update both environment and the provided DT. I guess we can argue that the normal situation is that U-Boot will know how to update the DT such as needed to boot the OS. So what we are dealing with is a small percentage of cases where we need special behaviour, and where it may be acceptable if the solution is only semi-perfect ;-) My current thinking is to introduce something like dt_skip=memory,mac-address I haven't followed the this thread too closely, but I was curious if you could do manual tweaks by using the 'bootm' and 'fdt' sub-commands. This could allow more fine grained control of the boot process and let you manually modify the DTB before booting to Linux. Eg make the 'bootcmd' environment variable be something like: bootm start $loadaddr; \ bootm loados; \ bootm ramdisk; \ bootm fdt; \ fdt boardsetup; \ fdt set memory reg 0 1000; \ bootm prep; \ bootm go Some dual core Freescale board's do somewhat similar operations for AMP operation (see doc/README.p2020rdb), although I haven't personally tried AMP. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Honor /memory/reg node in DTB files
On Dec 8, 2010, at 2:34 PM, Wolfgang Denk wrote: You can please all the people some of the time and some of the people all of the time but you can't please all the people all of the time. Yes, I'm sometimes pleased :-) My current thinking is to introduce something like . Well, that is pretty cool. dt_skip=memory,mac-address Do we have to write a parser now, or is there something that currently exists to help out? :-) Thanks. -- Dan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] pca953x: support 16-pin devices
The patch looks good. I had a few minor nitpicky style comments below:
As suggested by Peter I've implemented the 16-pin support in the existing
pca953x driver. So this is pretty much a re-write of the v1 patch. Is the
commit
message sufficient to document CONFIG_SYS_I2C_PCA953X_WIDTH or is
there something under doc/ that I should be adding to.
You could add a brief description to the top-level README file. There
is currently a bit of info in the GPIO Support section that could be
added to.
#include common.h
@@ -38,22 +38,78 @@ enum {
PCA953X_CMD_INVERT,
};
+#ifdef CONFIG_SYS_I2C_PCA953X_WIDTH
+struct chip_ngpio {
+ uint8_t chip;
+ uint8_t ngpio;
+};
Since this structure is 953x-specific I'd rename chip_ngpio
pca953x_chip_ngpio to clarify its a driver-specific structure and to
prevent the (unlikely) name collision down the road.
The same comment applies to ngpio()-pca953x_ngpio(),
chip_ngpios[]-pca953x_chip_ngpios[].
+static struct chip_ngpio chip_ngpios[] = CONFIG_SYS_I2C_PCA953X_WIDTH;
+#define NUM_CHIP_GPIOS (sizeof(chip_ngpios) / sizeof(struct chip_ngpio))
+
+/*
+ * Determine the number of GPIO pins supported. If we don't know we assume
+ * 8 pins.
+ */
+static int ngpio(uint8_t chip)
+{
+ int i;
+
+ for (i = 0; i NUM_CHIP_GPIOS; i++) {
+ if (chip_ngpios[i].chip == chip)
+ return chip_ngpios[i].ngpio;
+ }
I'd remove the for loop braces above per the Linux CodingStyle
documentation that U-Boot adheres to.
There should also be an empty line above the return 8 below.
+ return 8;
+}
+#else
+#define ngpio(chip) 8
+#endif
+
/*
* Modify masked bits in register
*/
static int pca953x_reg_write(uint8_t chip, uint addr, uint mask, uint data)
{
- uint8_t val;
+ uint8_t valb;
+ uint16_t valw;
I'd remove one of the spaces between valb above. My understanding is
spaces shouldn't be used for such vertical alignment.
- if (i2c_read(chip, addr, 1, val, 1))
- return -1;
+ if (ngpio(chip) = 8) {
+ if (i2c_read(chip, addr, 1, valb, 1))
+ return -1;
+
+ valb = ~mask;
+ valb |= data;
+
+ return i2c_write(chip, addr, 1, valb, 1);
+ } else {
+ if (i2c_read(chip, addr 1, 1, (u8*)valw, 2))
+ return -1;
+
+ valw = ~mask;
+ valw |= data;
+
+ return i2c_write(chip, addr 1, 1, (u8*)valw, 2);
+ }
+}
- val = ~mask;
- val |= data;
+static int pca953x_reg_read(uint8_t chip, uint addr, uint *data)
+{
+ uint8_t valb;
+ uint16_t valw;
- return i2c_write(chip, addr, 1, val, 1);
+ if (ngpio(chip) = 8) {
+ if (i2c_read(chip, addr, 1, valb, 1))
+ return -1;
+ *data = (int) valb;
The space in (int) valb should be removed. Same below.
+ } else {
+ if (i2c_read(chip, addr 1, 1, (u8*)valw, 2))
+ return -1;
+ *data = (int) valw;
+ }
+ return 0;
}
snip
+ for (i = msb; i = 0; i--)
+ printf(%x,i);
+ printf(\n);
+ if (nr_gpio 8)
+ printf();
printf(---\n);
What about changing the printing of '-'s to a for loop like
for (i = 19 + nr_gpio; i 0; i++)
puts(-);
I'll give the next iteration of the patch a shot, it looks like it
should work just fine.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/2] hashtable: drop all non-reentrant versions
On Wednesday, December 08, 2010 07:31:54 Joakim Tjernlund wrote: On Wednesday, December 08, 2010 06:26:04 Mike Frysinger wrote: The non-reentrant versions of the hashtable functions operate on a single shared hashtable. So if two different people try using these funcs for two different purposes, they'll cause problems for the other. Avoid this by converting all existing hashtable consumers over to the reentrant versions and then punting the non-reentrant ones. oh, and this does shrink the final u-boot a little, so that's good Nice, over the last years I have noticed that u-boot has grown a lot. I had to disable a few non essential commands to make it it fit. Does anyone else share my concern about the rapid growth of u-boot? i try to go through things about once a release to see about culling crap, but i focus on things that affect Blackfin, so relocation isnt one -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: 460SX Eegier board support
From: Tirumala Marri tma...@apm.com Adding Eiger board support for 460SX SoC. Signed-off-by: Tirumala R Marri tma...@apm.com --- MAINTAINERS|4 + board/amcc/eiger/Makefile | 48 +++ board/amcc/eiger/config.mk | 30 +++ board/amcc/eiger/eiger.c | 91 + board/amcc/eiger/init.S| 67 +++ boards.cfg |1 + include/configs/eiger.h| 192 7 files changed, 433 insertions(+), 0 deletions(-) create mode 100644 board/amcc/eiger/Makefile create mode 100644 board/amcc/eiger/config.mk create mode 100644 board/amcc/eiger/eiger.c create mode 100644 board/amcc/eiger/init.S create mode 100644 include/configs/eiger.h diff --git a/MAINTAINERS b/MAINTAINERS index f47fca5..9012092 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -310,6 +310,10 @@ Tirumala Marri tma...@apm.com bluestone APM821XX +Tirumala Marri tma...@apm.com + + eiger 460SX + Reinhard Meyer r.me...@emk-elektronik.de TOP860 MPC860T diff --git a/board/amcc/eiger/Makefile b/board/amcc/eiger/Makefile new file mode 100644 index 000..a381de0 --- /dev/null +++ b/board/amcc/eiger/Makefile @@ -0,0 +1,48 @@ +# Adding Makefile for Eiger board +# +# Copyright (c) 2010, Applied Micro Circuits Corporation +# Authors: Tirumala R Marri tma...@apm.com +# +# 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 $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).o + +COBJS = $(BOARD).o +SOBJS = init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend *~ + +# + +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + + diff --git a/board/amcc/eiger/config.mk b/board/amcc/eiger/config.mk new file mode 100644 index 000..aa6cbda --- /dev/null +++ b/board/amcc/eiger/config.mk @@ -0,0 +1,30 @@ +# Adding config.mk for Eiger board +# +# Copyright (c) 2010, Applied Micro Circuits Corporation +# Authors: Tirumala R Marri tma...@apm.com +# +# 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 +# + +PLATFORM_CPPFLAGS += -DCONFIG_440=1 + +ifeq ($(debug),1) +PLATFORM_CPPFLAGS += -DDEBUG +endif + +ifeq ($(dbcr),1) +PLATFORM_CPPFLAGS += -DCONFIG_SYS_INIT_DBCR=0x8cff +endif diff --git a/board/amcc/eiger/eiger.c b/board/amcc/eiger/eiger.c new file mode 100644 index 000..d5b569d --- /dev/null +++ b/board/amcc/eiger/eiger.c @@ -0,0 +1,91 @@ +/* + * Adding board support for Eiger board + * + * Copyright (c) 2010, Applied Micro Circuits Corporation + * Author: Tirumala R Marri tma...@apm.com + * + * 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
[U-Boot] [PATCH 01/10] Display RDIMM if detected
Print a message when a RDIMM is detected.
Signed-off-by: York Sun york...@freescale.com
---
.../cpu/mpc8xxx/ddr/lc_common_dimm_params.c| 19 +++
1 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/lc_common_dimm_params.c
b/arch/powerpc/cpu/mpc8xxx/ddr/lc_common_dimm_params.c
index 029e566..af0250d 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/lc_common_dimm_params.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/lc_common_dimm_params.c
@@ -98,7 +98,7 @@ compute_lowest_common_dimm_parameters(const dimm_params_t
*dimm_params,
unsigned int tDQSQ_max_ps = 0;
unsigned int tQHS_ps = 0;
- unsigned int temp1, temp2, temp3;
+ unsigned int temp1, temp2;
unsigned int additive_latency = 0;
#if !defined(CONFIG_FSL_DDR3)
const unsigned int mclk_ps = get_memory_clk_period_ps();
@@ -215,21 +215,16 @@ compute_lowest_common_dimm_parameters(const dimm_params_t
*dimm_params,
}
outpdimm-all_DIMMs_registered = 0;
+ outpdimm-all_DIMMs_unbuffered = 0;
if (temp1 !temp2) {
outpdimm-all_DIMMs_registered = 1;
- }
-
- outpdimm-all_DIMMs_unbuffered = 0;
- if (!temp1 temp2) {
+ printf(Detected RDIMM(s)\n);
+ } else if (!temp1 temp2) {
outpdimm-all_DIMMs_unbuffered = 1;
- }
-
- /* CHECKME: */
- if (!outpdimm-all_DIMMs_registered
-!outpdimm-all_DIMMs_unbuffered) {
+ printf(Detected UDIMM(s)\n);
+ } else
printf(ERROR: Mix of registered buffered and unbuffered
DIMMs detected!\n);
- }
temp1 = 0;
if (outpdimm-all_DIMMs_registered)
@@ -237,7 +232,7 @@ compute_lowest_common_dimm_parameters(const dimm_params_t
*dimm_params,
outpdimm-rcw[j] = dimm_params[0].rcw[j];
for (i = 1; i number_of_dimms; i++)
if (dimm_params[i].rcw[j] !=
dimm_params[0].rcw[j]) {
- temp3 = 1;
+ temp1 = 1;
break;
}
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/10] Enable ECC on/off control in hwconfig
Add fsl_ddr:ecc=on in hwconfig. If ECC is enabled in board configuration file,
ECC can be turned on/off by this switch. If this switch is omitted, it is ON by
default.
Syntax is
hwconfig=fsl_ddr:ecc=on
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc8xxx/ddr/options.c |9 ++---
doc/README.fsl-ddr |7 +++
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
index ca5f63e..f876e20 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
@@ -82,10 +82,13 @@ unsigned int populate_memctl_options(int
all_DIMMs_registered,
/* Operational Mode Paramters */
/* Pick ECC modes */
-#ifdef CONFIG_DDR_ECC
- popts-ECC_mode = 1; /* 0 = disabled, 1 = enabled */
-#else
popts-ECC_mode = 0; /* 0 = disabled, 1 = enabled */
+#ifdef CONFIG_DDR_ECC
+ if (hwconfig_sub(fsl_ddr, ecc)) {
+ if (hwconfig_subarg_cmp(fsl_ddr, ecc, on))
+ popts-ECC_mode = 1;
+ } else
+ popts-ECC_mode = 1;
#endif
popts-ECC_init_using_memctl = 1; /* 0 = use DMA, 1 = use memctl */
diff --git a/doc/README.fsl-ddr b/doc/README.fsl-ddr
index 1657ef6..9e3c539 100644
--- a/doc/README.fsl-ddr
+++ b/doc/README.fsl-ddr
@@ -78,6 +78,13 @@ If the DDR controller supports address hashing, it can be
enabled by hwconfig.
Syntax is:
hwconfig=fsl_ddr:addr_hash=true
+Memory controller ECC on/off
+
+If ECC is enabled in board configuratoin file, i.e. #define CONFIG_DDR_ECC,
+ECC can be turned on/off by hwconfig.
+
+Syntax is
+hwconfig=fsl_ddr:ecc=off
Memory testing options for mpc85xx
==
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/10] make the hwconfig buffer deeper
To temporarily fix buffer issue when running at flash, use bigger buffer
to push down the stack deeper.
Signed-off-by: York Sun york...@freescale.com
---
common/hwconfig.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/hwconfig.c b/common/hwconfig.c
index 3c9759f..1b33d95 100644
--- a/common/hwconfig.c
+++ b/common/hwconfig.c
@@ -71,7 +71,7 @@ next:
const char *cpu_hwconfig __attribute__((weak));
const char *board_hwconfig __attribute__((weak));
-#define HWCONFIG_PRE_RELOC_BUF_SIZE128
+#define HWCONFIG_PRE_RELOC_BUF_SIZE256
static const char *__hwconfig(const char *opt, size_t *arglen)
{
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/10] Adding more registers and options
Add writing to cdr1, cdr2, err_disable, err_int_en and debug registers
Add options to override rcw, address parity to RDIMMs.
Use array for debug registeres.
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc85xx/ddr-gen3.c | 10 --
arch/powerpc/include/asm/fsl_ddr_sdram.h | 12
arch/powerpc/include/asm/immap_85xx.h| 19 +--
3 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
index 5805b3f..14a905d 100644
--- a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
+++ b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
@@ -80,6 +80,13 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
out_be32(ddr-ddr_sr_cntr, regs-ddr_sr_cntr);
out_be32(ddr-ddr_sdram_rcw_1, regs-ddr_sdram_rcw_1);
out_be32(ddr-ddr_sdram_rcw_2, regs-ddr_sdram_rcw_2);
+ out_be32(ddr-ddr_cdr1, regs-ddr_cdr1);
+ out_be32(ddr-ddr_cdr2, regs-ddr_cdr2);
+ out_be32(ddr-err_disable, regs-err_disable);
+ out_be32(ddr-err_int_en, regs-err_int_en);
+ for (i = 0; i 18; i++)
+ out_be32(ddr-debug[i], regs-debug[i]);
+
#ifdef CONFIG_SYS_P4080_ERRATUM_DDR7
/*
* Do not use automatic driver calibration, Instead of
@@ -104,8 +111,7 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
if in_be32(ddr-sdram_cfg) 24) 0x7) == SDRAM_TYPE_DDR2)
in_be32(ddr-sdram_cfg) 0x8) {
/* set DEBUG_1[31] */
- u32 temp = in_be32(ddr-debug_1);
- out_be32(ddr-debug_1, temp | 1);
+ setbits_be32(ddr-debug[0], 1);
}
#endif
diff --git a/arch/powerpc/include/asm/fsl_ddr_sdram.h
b/arch/powerpc/include/asm/fsl_ddr_sdram.h
index 17d4b31..6ec95b6 100644
--- a/arch/powerpc/include/asm/fsl_ddr_sdram.h
+++ b/arch/powerpc/include/asm/fsl_ddr_sdram.h
@@ -120,6 +120,11 @@ typedef struct fsl_ddr_cfg_regs_s {
unsigned int ddr_sdram_rcw_1;
unsigned int ddr_sdram_rcw_2;
unsigned int ddr_eor;
+ unsigned int ddr_cdr1;
+ unsigned int ddr_cdr2;
+ unsigned int err_disable;
+ unsigned int err_int_en;
+ unsigned int debug[18];
} fsl_ddr_cfg_regs_t;
typedef struct memctl_options_partial_s {
@@ -175,6 +180,7 @@ typedef struct memctl_options_s {
/* mirrior DIMMs for DDR3 */
unsigned int mirrored_dimm;
unsigned int quad_rank_present;
+ unsigned int ap_en; /* address parity enable for RDIMM */
/* Global Timing Parameters */
unsigned int cas_latency_override;
@@ -210,6 +216,12 @@ typedef struct memctl_options_s {
unsigned int zq_en;
/* Write leveling */
unsigned int wrlvl_en;
+ /* RCW override for RDIMM */
+ unsigned int rcw_override;
+ unsigned int rcw_1;
+ unsigned int rcw_2;
+ /* control register 1 */
+ unsigned int ddr_cdr1;
} memctl_options_t;
extern phys_size_t fsl_ddr_sdram(void);
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index ee7338a..474082f 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -222,24 +222,7 @@ typedef struct ccsr_ddr {
u32 capture_ext_address;/* Error Extended Addr Capture */
u32 err_sbe;/* Single-Bit ECC Error Management */
u8 res11[164];
- u32 debug_1;
- u32 debug_2;
- u32 debug_3;
- u32 debug_4;
- u32 debug_5;
- u32 debug_6;
- u32 debug_7;
- u32 debug_8;
- u32 debug_9;
- u32 debug_10;
- u32 debug_11;
- u32 debug_12;
- u32 debug_13;
- u32 debug_14;
- u32 debug_15;
- u32 debug_16;
- u32 debug_17;
- u32 debug_18;
+ u32 debug[18]; /* debug_1 to debug_18 */
u8 res12[184];
} ccsr_ddr_t;
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/10] Adding more SPD registers
Adding byte 32 and 33
Signed-off-by: York Sun york...@freescale.com
---
include/ddr_spd.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/ddr_spd.h b/include/ddr_spd.h
index 710e528..9fa305e 100644
--- a/include/ddr_spd.h
+++ b/include/ddr_spd.h
@@ -219,7 +219,9 @@ typedef struct ddr3_spd_eeprom_s {
Delay Time*/
unsigned char opt_features;/* 30 SDRAM Optional Features */
unsigned char therm_ref_opt; /* 31 SDRAM Thermal and Refresh Opts */
- unsigned char res_32_59[28]; /* 32-59 Reserved, General Section */
+ unsigned char therm_sensor;/* 32 Module Thermal Sensor */
+ unsigned char device_type; /* SDRAM device type */
+ unsigned char res_34_59[26]; /* 34-59 Reserved, General Section */
/* Module-Specific Section: Bytes 60-116 */
union {
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/10] Enable unique mode registers and dynamic ODT for DDR3
Added fsl_ddr_get_version() function to poll DDRC IP version (major, minor,
errata) to determine if unique mode registers are available. This function may
be needed for future other platforms if such a feature exists. If true, always
use unique mode registers. Dynamic ODT is enabled if needed. The table is
documented in doc/README.fsl-ddr.
Enable address parity and RCW by default for RDIMMs.
Change default output driver impedance from 34 ohm to 40ohm. Make it 34ohm for
quad-rank RDIMMs.
Use a formula to calculate rodt_on for timing_cfg_5.
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc85xx/ddr-gen3.c | 18 ++
arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 305 +
arch/powerpc/cpu/mpc8xxx/ddr/options.c | 308 +-
arch/powerpc/include/asm/fsl_ddr_sdram.h | 18 ++
board/freescale/corenet_ds/ddr.c | 125 ++---
doc/README.fsl-ddr | 67 +++-
6 files changed, 723 insertions(+), 118 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
index 14a905d..568f9f4 100644
--- a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
+++ b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
@@ -66,6 +66,12 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
out_be32(ddr-sdram_cfg_2, regs-ddr_sdram_cfg_2);
out_be32(ddr-sdram_mode, regs-ddr_sdram_mode);
out_be32(ddr-sdram_mode_2, regs-ddr_sdram_mode_2);
+ out_be32(ddr-sdram_mode_3, regs-ddr_sdram_mode_3);
+ out_be32(ddr-sdram_mode_4, regs-ddr_sdram_mode_4);
+ out_be32(ddr-sdram_mode_5, regs-ddr_sdram_mode_5);
+ out_be32(ddr-sdram_mode_6, regs-ddr_sdram_mode_6);
+ out_be32(ddr-sdram_mode_7, regs-ddr_sdram_mode_7);
+ out_be32(ddr-sdram_mode_8, regs-ddr_sdram_mode_8);
out_be32(ddr-sdram_md_cntl, regs-ddr_sdram_md_cntl);
out_be32(ddr-sdram_interval, regs-ddr_sdram_interval);
out_be32(ddr-sdram_data_init, regs-ddr_data_init);
@@ -133,3 +139,15 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t
*regs,
udelay(1); /* throttle polling rate */
}
}
+
+u32 fsl_ddr_get_version(void)
+{
+ ccsr_ddr_t *ddr;
+ u32 ver_major_minor_errata;
+
+ ddr = (void *)CONFIG_SYS_MPC85xx_DDR_ADDR;
+ ver_major_minor_errata = (in_be32(ddr-ip_rev1) 0x) 8;
+ ver_major_minor_errata |= (in_be32(ddr-ip_rev2) 0xFF00) 8;
+
+ return ver_major_minor_errata;
+}
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
index 3fec100..2132986 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
@@ -18,7 +18,13 @@
#include ddr.h
-extern unsigned int picos_to_mclk(unsigned int picos);
+u32 __attribute__((weak)) fsl_ddr_get_version(void)
+{
+ return 0;
+}
+
+unsigned int picos_to_mclk(unsigned int picos);
+
/*
* Determine Rtt value.
*
@@ -187,7 +193,8 @@ static void set_csn_config_2(int i, fsl_ddr_cfg_regs_t *ddr)
* Avoid writing for DDR I. The new PQ38 DDR controller
* dreams up non-zero default values to be backwards compatible.
*/
-static void set_timing_cfg_0(fsl_ddr_cfg_regs_t *ddr)
+static void set_timing_cfg_0(fsl_ddr_cfg_regs_t *ddr,
+ const memctl_options_t *popts)
{
unsigned char trwt_mclk = 0; /* Read-to-write turnaround */
unsigned char twrt_mclk = 0; /* Write-to-read turnaround */
@@ -204,7 +211,7 @@ static void set_timing_cfg_0(fsl_ddr_cfg_regs_t *ddr)
/* Mode register set cycle time (tMRD). */
unsigned char tmrd_mclk;
-#if defined(CONFIG_FSL_DDR3)
+#ifdef CONFIG_FSL_DDR3
/*
* (tXARD and tXARDS). Empirical?
* The DDR3 spec has not tXARD,
@@ -214,13 +221,21 @@ static void set_timing_cfg_0(fsl_ddr_cfg_regs_t *ddr)
* tAXPD=1, need design to confirm.
*/
int tXP = max((get_memory_clk_period_ps() * 3), 7500); /* unit=ps */
- act_pd_exit_mclk = picos_to_mclk(tXP);
- /* Mode register MR0[A12] is '1' - fast exit */
- pre_pd_exit_mclk = act_pd_exit_mclk;
- taxpd_mclk = 1;
tmrd_mclk = 4;
/* set the turnaround time */
trwt_mclk = 1;
+
+ if (popts-dynamic_power == 0) {/* powerdown is not used */
+ act_pd_exit_mclk = 1;
+ pre_pd_exit_mclk = 1;
+ taxpd_mclk = 1;
+ } else {
+ /* act_pd_exit_mclk = tXARD, see above */
+ act_pd_exit_mclk = picos_to_mclk(tXP);
+ /* Mode register MR0[A12] is '1' - fast exit */
+ pre_pd_exit_mclk = act_pd_exit_mclk;
+ taxpd_mclk = 1;
+ }
#else /* CONFIG_FSL_DDR2 */
/*
* (tXARD and tXARDS). Empirical?
@@ -450,28 +465,34 @@ static void set_timing_cfg_2(fsl_ddr_cfg_regs_t *ddr,
/* DDR SDRAM Register Control Word */
static void
[U-Boot] [PATCH 10/10] Extend board specific parameters
Extend board specific parameters to include write leveling start override
Extend write leveling sample to 0xf
Adding rcw overrid for quad-rank RDIMMs
Signed-off-by: York Sun york...@freescale.com
---
board/freescale/corenet_ds/ddr.c | 120 +-
1 files changed, 66 insertions(+), 54 deletions(-)
diff --git a/board/freescale/corenet_ds/ddr.c b/board/freescale/corenet_ds/ddr.c
index 0eb290d..74339b5 100644
--- a/board/freescale/corenet_ds/ddr.c
+++ b/board/freescale/corenet_ds/ddr.c
@@ -145,6 +145,7 @@ typedef struct {
u32 datarate_mhz_high;
u32 n_ranks;
u32 clk_adjust;
+ u32 wrlvl_start;
u32 cpo;
u32 write_data_delay;
u32 force_2T;
@@ -164,57 +165,57 @@ typedef struct {
/* XXX: Single rank at 800 MHz is OK. */
const board_specific_parameters_t board_specific_parameters[][30] = {
{
- /* memory controller 0 */
- /*lo| hi| num| clk| cpo|wrdata|2T*/
- /* mhz| mhz|ranks|adjst|| delay| */
- { 0, 333,4,5, 0xff,2, 0},
- {334, 400,4,5, 0xff,2, 0},
- {401, 549,4,5, 0xff,2, 0},
- {550, 680,4,5, 0xff,2, 0},
- {681, 850,4,5, 0xff,2, 0},
- {851, 1050, 4,5, 0xff,2, 0},
- {1051, 1250, 4,5, 0xff,2, 0},
- {1251, 1350, 4,5, 0xff,2, 0},
- { 0, 333,2,5, 0xff,2, 0},
- {334, 400,2,5, 0xff,2, 0},
- {401, 549,2,5, 0xff,2, 0},
- {550, 680,2,5, 0xff,2, 0},
- {681, 850,2,5, 0xff,2, 0},
- {851, 1050, 2,5, 0xff,2, 0},
- {1051, 1250, 2,5, 0xff,2, 0},
- {1251, 1350, 2,5, 0xff,2, 0},
- { 0, 333,1,5, 0xff,2, 0},
- {334, 400,1,5, 0xff,2, 0},
- {401, 549,1,5, 0xff,2, 0},
- {550, 680,1,5, 0xff,2, 0},
- {681, 850,1,5, 0xff,2, 0}
+ /* memory controller 0 */
+ /* lo| hi| num| clk| wrlvl | cpo |wrdata|2T */
+ /* mhz| mhz|ranks|adjst| start | delay|*/
+ { 0, 333,4,5, 7, 0xff,2, 0},
+ {334, 400,4,5, 7, 0xff,2, 0},
+ {401, 549,4,5, 7, 0xff,2, 0},
+ {550, 680,4,5, 7, 0xff,2, 0},
+ {681, 850,4,5, 7, 0xff,2, 0},
+ {851, 1050, 4,5, 7, 0xff,2, 0},
+ {1051, 1250, 4,5, 8, 0xff,2, 0},
+ {1251, 1350, 4,5, 9, 0xff,2, 0},
+ { 0, 333,2,5, 7, 0xff,2, 0},
+ {334, 400,2,5, 7, 0xff,2, 0},
+ {401, 549,2,5, 7, 0xff,2, 0},
+ {550, 680,2,5, 7, 0xff,2, 0},
+ {681, 850,2,5, 7, 0xff,2, 0},
+ {851, 1050, 2,5, 7, 0xff,2, 0},
+ {1051, 1250, 2,5, 7, 0xff,2, 0},
+ {1251, 1350, 2,5, 7, 0xff,2, 0},
+ { 0, 333,1,5, 7, 0xff,2, 0},
+ {334, 400,1,5, 7, 0xff,2, 0},
+ {401, 549,1,5, 7, 0xff,2, 0},
+ {550, 680,1,5, 7, 0xff,2, 0},
+ {681, 850,1,5, 7, 0xff,2, 0}
},
{
- /* memory controller 1 */
- /*lo| hi| num| clk| cpo|wrdata|2T*/
- /* mhz| mhz|ranks|adjst|| delay| */
- { 0, 333,4,5, 0xff,2, 0},
- {334, 400,4,5, 0xff,2, 0},
- {401, 549,4,5, 0xff,2, 0},
- {550, 680,4,5, 0xff,2, 0},
- {681, 850,4,5, 0xff,2, 0},
- {851, 1050, 4,5, 0xff,2, 0},
- {1051, 1250, 4,5, 0xff,2, 0},
- {1251, 1350, 4,5, 0xff,2, 0},
- { 0, 333,2,5, 0xff,2, 0},
- {334, 400,2,5, 0xff,2, 0},
- {401, 549,2,5, 0xff,2, 0},
- {550, 680,2,5, 0xff,2, 0},
- {681, 850,2,5, 0xff,2, 0},
- {851, 1050, 2,5, 0xff,2, 0},
- {1051, 1250, 2,5, 0xff,2, 0},
- {1251, 1350, 2,5, 0xff,2, 0},
- { 0, 333,1,5, 0xff,2, 0},
- {334, 400,1,
[U-Boot] [PATCH 08/10] Implement workaround for erratum DDRA003
Erratum DDRA003 requires workaround to correctly set RCW10 for registered DIMM.
Also adding polling after enabling DDR controller to ensure completion.
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc85xx/ddr-gen3.c | 53 ++-
include/configs/P4080DS.h |1 +
2 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
index 568f9f4..0815ba4 100644
--- a/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
+++ b/arch/powerpc/cpu/mpc85xx/ddr-gen3.c
@@ -108,6 +108,55 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t
*regs,
temp_sdram_cfg = regs-ddr_sdram_cfg;
temp_sdram_cfg = ~(SDRAM_CFG_MEM_EN);
out_be32(ddr-sdram_cfg, temp_sdram_cfg);
+#ifdef CONFIG_SYS_P4080_ERRATUM_DDRA003
+ if (regs-ddr_sdram_rcw_2 0x00f0) {
+ out_be32(ddr-timing_cfg_2, regs-timing_cfg_2 0xf07f);
+ out_be32(ddr-debug[2], 0x0400);
+ out_be32(ddr-ddr_zq_cntl, regs-ddr_zq_cntl 0x7fff);
+ out_be32(ddr-ddr_wrlvl_cntl, regs-ddr_wrlvl_cntl
0x7fff);
+ out_be32(ddr-sdram_cfg_2, regs-ddr_sdram_cfg_2 0xffeb);
+ out_be32(ddr-mtcr, 0);
+ out_be32(ddr-debug[12], 0x0015);
+ out_be32(ddr-debug[21], 0x2400);
+ out_be32(ddr-sdram_interval, regs-ddr_sdram_interval
0x);
+ out_be32(ddr-sdram_cfg, temp_sdram_cfg | SDRAM_CFG_BI |
SDRAM_CFG_MEM_EN);
+
+ asm volatile(sync;isync);
+ while (!(in_be32(ddr-debug[1]) 0x2));
+
+ switch (regs-ddr_sdram_rcw_2 0x00f0) {
+ case 0x:
+ out_be32(ddr-sdram_md_cntl, 0xc4080002);
+ break;
+ case 0x0010:
+ out_be32(ddr-sdram_md_cntl, 0xc408000a);
+ break;
+ case 0x0020:
+ out_be32(ddr-sdram_md_cntl, 0xc4080012);
+ break;
+ case 0x0030:
+ out_be32(ddr-sdram_md_cntl, 0xc408001a);
+ break;
+ default:
+ out_be32(ddr-sdram_md_cntl, 0xc4080002);
+ printf(Unsupported RC10\n);
+ break;
+ }
+
+ while (in_be32(ddr-sdram_md_cntl) 0x8000);
+ udelay(6);
+ out_be32(ddr-sdram_cfg, temp_sdram_cfg);
+ out_be32(ddr-timing_cfg_2, regs-timing_cfg_2);
+ out_be32(ddr-debug[2], 0x0);
+ out_be32(ddr-ddr_zq_cntl, regs-ddr_zq_cntl);
+ out_be32(ddr-ddr_wrlvl_cntl, regs-ddr_wrlvl_cntl);
+ out_be32(ddr-sdram_cfg_2, regs-ddr_sdram_cfg_2);
+ out_be32(ddr-debug[12], 0x0);
+ out_be32(ddr-debug[21], 0x0);
+ out_be32(ddr-sdram_interval, regs-ddr_sdram_interval);
+
+ }
+#endif
/*
* For 8572 DDR1 erratum - DDR controller may enter illegal state
* when operatiing in 32-bit bus mode with 4-beat bursts,
@@ -131,8 +180,10 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t
*regs,
asm volatile(sync;isync);
/* Let the controller go */
- temp_sdram_cfg = in_be32(ddr-sdram_cfg);
+ temp_sdram_cfg = in_be32(ddr-sdram_cfg) ~SDRAM_CFG_BI;
out_be32(ddr-sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
+ asm volatile(sync;isync);
+ while (!(in_be32(ddr-debug[1]) 0x2));
/* Poll DDR_SDRAM_CFG_2[D_INIT] bit until auto-data init is done. */
while (in_be32(ddr-sdram_cfg_2) 0x10) {
diff --git a/include/configs/P4080DS.h b/include/configs/P4080DS.h
index d210016..c19bd39 100644
--- a/include/configs/P4080DS.h
+++ b/include/configs/P4080DS.h
@@ -45,6 +45,7 @@
#define CONFIG_SYS_P4080_ERRATUM_CPC9
#define CONFIG_SYS_P4080_ERRATUM_DDR1
#define CONFIG_SYS_P4080_ERRATUM_DDR7
+#define CONFIG_SYS_P4080_ERRATUM_DDRA003
#define CONFIG_SYS_P4080_ERRATUM_ESDHC1
#define CONFIG_SYS_P4080_ERRATUM_ESDHC9
#define CONFIG_SYS_P4080_ERRATUM_ESDHC11
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/10] Enable ECC for corenet_ds
ECC can be turned on/off by hwconfig without recompiling. So enable it by default. Signed-off-by: York Sun york...@freescale.com --- include/configs/corenet_ds.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h index 454a30a..49f0a26 100644 --- a/include/configs/corenet_ds.h +++ b/include/configs/corenet_ds.h @@ -76,7 +76,7 @@ #define CONFIG_BACKSIDE_L2_CACHE #define CONFIG_SYS_INIT_L2CSR0 L2CSR0_L2E #define CONFIG_BTB /* toggle branch predition */ -/*#define CONFIG_DDR_ECC*/ +#defineCONFIG_DDR_ECC #ifdef CONFIG_DDR_ECC #define CONFIG_ECC_INIT_VIA_DDRCONTROLLER #define CONFIG_MEM_INIT_VALUE 0xdeadbeef -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2] pca953x: support 16-pin devices
On Thu, Dec 9, 2010 at 1:08 PM, Peter Tyser pty...@xes-inc.com wrote:
The patch looks good. I had a few minor nitpicky style comments below:
As suggested by Peter I've implemented the 16-pin support in the existing
pca953x driver. So this is pretty much a re-write of the v1 patch. Is the
commit
message sufficient to document CONFIG_SYS_I2C_PCA953X_WIDTH or is
there something under doc/ that I should be adding to.
You could add a brief description to the top-level README file. There
is currently a bit of info in the GPIO Support section that could be
added to.
#include common.h
@@ -38,22 +38,78 @@ enum {
PCA953X_CMD_INVERT,
};
+#ifdef CONFIG_SYS_I2C_PCA953X_WIDTH
+struct chip_ngpio {
+ uint8_t chip;
+ uint8_t ngpio;
+};
Since this structure is 953x-specific I'd rename chip_ngpio
pca953x_chip_ngpio to clarify its a driver-specific structure and to
prevent the (unlikely) name collision down the road.
The same comment applies to ngpio()-pca953x_ngpio(),
chip_ngpios[]-pca953x_chip_ngpios[].
+static struct chip_ngpio chip_ngpios[] = CONFIG_SYS_I2C_PCA953X_WIDTH;
+#define NUM_CHIP_GPIOS (sizeof(chip_ngpios) / sizeof(struct chip_ngpio))
+
+/*
+ * Determine the number of GPIO pins supported. If we don't know we assume
+ * 8 pins.
+ */
+static int ngpio(uint8_t chip)
+{
+ int i;
+
+ for (i = 0; i NUM_CHIP_GPIOS; i++) {
+ if (chip_ngpios[i].chip == chip)
+ return chip_ngpios[i].ngpio;
+ }
I'd remove the for loop braces above per the Linux CodingStyle
documentation that U-Boot adheres to.
There should also be an empty line above the return 8 below.
+ return 8;
+}
+#else
+#define ngpio(chip) 8
+#endif
+
/*
* Modify masked bits in register
*/
static int pca953x_reg_write(uint8_t chip, uint addr, uint mask, uint data)
{
- uint8_t val;
+ uint8_t valb;
+ uint16_t valw;
I'd remove one of the spaces between valb above. My understanding is
spaces shouldn't be used for such vertical alignment.
- if (i2c_read(chip, addr, 1, val, 1))
- return -1;
+ if (ngpio(chip) = 8) {
+ if (i2c_read(chip, addr, 1, valb, 1))
+ return -1;
+
+ valb = ~mask;
+ valb |= data;
+
+ return i2c_write(chip, addr, 1, valb, 1);
+ } else {
+ if (i2c_read(chip, addr 1, 1, (u8*)valw, 2))
+ return -1;
+
+ valw = ~mask;
+ valw |= data;
+
+ return i2c_write(chip, addr 1, 1, (u8*)valw, 2);
+ }
+}
- val = ~mask;
- val |= data;
+static int pca953x_reg_read(uint8_t chip, uint addr, uint *data)
+{
+ uint8_t valb;
+ uint16_t valw;
- return i2c_write(chip, addr, 1, val, 1);
+ if (ngpio(chip) = 8) {
+ if (i2c_read(chip, addr, 1, valb, 1))
+ return -1;
+ *data = (int) valb;
The space in (int) valb should be removed. Same below.
+ } else {
+ if (i2c_read(chip, addr 1, 1, (u8*)valw, 2))
+ return -1;
+ *data = (int) valw;
+ }
+ return 0;
}
snip
+ for (i = msb; i = 0; i--)
+ printf(%x,i);
+ printf(\n);
+ if (nr_gpio 8)
+ printf();
printf(---\n);
What about changing the printing of '-'s to a for loop like
for (i = 19 + nr_gpio; i 0; i++)
puts(-);
I'll give the next iteration of the patch a shot, it looks like it
should work just fine.
Best,
Peter
Hi Peter,
I'll try and get an updated patch through as soon as I can. I'm on a
training course today and tomorrow but it won't take me long to make
the changes you've suggested once I find some time.
Thanks,
Chris
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] can't build u-boot-2010.12-rc2 for at91rm9200ek
I download u-boot-2010.12-rc2 and make at91rm9200ek use the flowwing command make O=../build at91rm9200ek and get error message like this arm-linux-gcc -D__ASSEMBLY__ -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x1000 -I/home/zzs/DownLoad/uboot/xx/build/include2 -I/home/zzs/DownLoad/uboot/xx/build/include -I/home/zzs/DownLoad/uboot/xx/u-boot-2010.12-rc2/include -fno-builtin -ffreestanding -nostdinc -isystem /home/zzs/work/tools/eldk4.1/usr/bin/../lib/gcc/arm-linux/4.0.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm-mabi=apcs-gnu -mno-thumb-interwork -march=armv4 \ -o /home/zzs/DownLoad/uboot/xx/build/arch/arm/cpu/arm920t/start.o start.S -c start.S: Assembler messages: start.S:251: Error: bad arguments to instruction -- `add r1,r9' It looks a illegal instruction in start.S my toolchain is eldk4.1 anybody help me!! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can't build u-boot-2010.12-rc2 for at91rm9200ek
Le 09/12/2010 06:56, zzs213 a écrit : I download u-boot-2010.12-rc2 and make at91rm9200ek use the flowwing command make O=../build at91rm9200ek and get error message like this arm-linux-gcc -D__ASSEMBLY__ -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x1000 -I/home/zzs/DownLoad/uboot/xx/build/include2 -I/home/zzs/DownLoad/uboot/xx/build/include -I/home/zzs/DownLoad/uboot/xx/u-boot-2010.12-rc2/include -fno-builtin -ffreestanding -nostdinc -isystem /home/zzs/work/tools/eldk4.1/usr/bin/../lib/gcc/arm-linux/4.0.0/include -pipe -DCONFIG_ARM -D__ARM__ -marm-mabi=apcs-gnu -mno-thumb-interwork -march=armv4 \ -o /home/zzs/DownLoad/uboot/xx/build/arch/arm/cpu/arm920t/start.o start.S -c start.S: Assembler messages: start.S:251: Error: bad arguments to instruction -- `add r1,r9' It looks a illegal instruction in start.S my toolchain is eldk4.1 ELDK 4.1 seems a bit old -- 4.2 has been available for some time now and does not have the issue with this instruction. If you really cannot use 4.2, then you can rewrite the instruction in its canonical form: 'add r1,r1,r9'. anybody help me!! HTH. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/7] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
Hi, Le 07/12/2010 18:39, Albert ARIBAUD a écrit : Le 07/12/2010 18:10, Prafulla Wadaskar a écrit : + val= ~MFP_AF_MASK; Do we need to do this here? For val is only 0 here... This can be removed. OTOH, with the, this line makes no assumption about val, and thus will work regardless of it. If the is removed, and if later val is set to non-zero before reaching this instruction, it will cause a bug. IOW, the makes the statement more resilient. If val really is zero then the result will always be zero :( Simply removing the would give a different result. It would be better to remove the whole bloody line ;-) I haven't followed this thread but I suspect the original code was wrong. Cheers, Chris ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can't build u-boot-2010.12-rc2 for at91rm9200ek
I chang 'adr r1, r9' to 'add r1, r1, r9' and then rebuild it but I gave another error. the error message is: arm-linux-ld: -static and -shared may not be used together make[1]: *** [/home/zzs/DownLoad/uboot/xx/build/u-boot] Is this caused by the toolchain too? thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/7] gpio: Add Multi-Function-Pin configuration driver for Marvell SoCs
Hi Chris, Le 09/12/2010 07:11, Chris Moore a écrit : Hi, Le 07/12/2010 18:39, Albert ARIBAUD a écrit : Le 07/12/2010 18:10, Prafulla Wadaskar a écrit : + val= ~MFP_AF_MASK; Do we need to do this here? For val is only 0 here... This can be removed. OTOH, with the, this line makes no assumption about val, and thus will work regardless of it. If the is removed, and if later val is set to non-zero before reaching this instruction, it will cause a bug. IOW, the makes the statement more resilient. If val really is zero then the result will always be zero :( Simply removing the would give a different result. It would be better to remove the whole bloody line ;-) I haven't followed this thread but I suspect the original code was wrong. Good point as to the removal if the removal must be done :) I still think that the original is functionally more correct *if we are not sure that val will always be zero. I'll have a second look tonight. Cheers, Chris Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] hwmon init
Hello, Is there a reason why the dtt sensors are initialized and accessed on u-boot startup? The U-Boot Design Principles[1] clearly say: Initialize devices only when they are needed within U-Boot, i.e. don't initialize the Ethernet interface(s) unless U-Boot performs a download over Ethernet; don't initialize any IDE or USB devices unless U-Boot actually tries to load files from these, etc. (and don't forget to shut down these devices after using them - otherwise nasty things may happen when you try to boot your OS). Should that be changed? bye, Heiko [1] http://www.denx.de/wiki/U-Boot/DesignPrinciples -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can't build u-boot-2010.12-rc2 for at91rm9200ek
I chang 'adr r1, r9' to 'add r1, r1, r9' and then rebuild it but I got another error. the error message is: arm-linux-ld: -static and -shared may not be used together make[1]: *** [/home/zzs/DownLoad/uboot/xx/build/u-boot] Error 1 make[1]: Leaving directory `/home/zzs/DownLoad/uboot/xx/u-boot-2010.12-rc2' make: *** [at91rm9200ek] Error 2 Is this caused by the toolchain too? thanks! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] arm920t: fix linker skript for -pie linking
Dear Wolfgang Denk, Am 08.12.2010 um 23:52 schrieb Wolfgang Denk: Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message 1291099039-49672-4-git-send-email-andreas.de...@googlemail.com you wrote: Without this patch the linker will SEGFAULT on some undefined weak symbols. Suggested-by: Sebastien Carlier sebastien.carl...@gmail.com Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- arch/arm/cpu/arm920t/u-boot.lds |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Applied, thanks. Please do not apply that patch! I'm sorry I have split up the thread cause it lead to a generic timer discussion. Therefore I posted v2 of this patch series here: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89974 This patch is not needed, if no undefined weak symbol is available. This patch adds .plt/.rel.plt section which has R_ARM_JUMP_SLOT which is not handled in code. Therefore we do not really know what this patch does to the code, it was mostly a patch to handle the linker segfault described several times. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can't build u-boot-2010.12-rc2 for at91rm9200ek
Hi 'zzs213', Le 09/12/2010 08:07, zzs213 a ??crit : I chang 'adr r1, r9' to 'add r1, r1, r9' and then rebuild it but I got another error. the error message is: arm-linux-ld: -static and -shared may not be used together make[1]: *** [/home/zzs/DownLoad/uboot/xx/build/u-boot] Error 1 make[1]: Leaving directory `/home/zzs/DownLoad/uboot/xx/u-boot-2010.12-rc2' make: *** [at91rm9200ek] Error 2 Is this caused by the toolchain too? Apparently it is. Building v2010.12-rc2 for at91rm9200ek with ELDK 4.2 gives: alb...@lilith:~/src/u-boot$ ./MAKEALL at91rm9200ek Configuring for at91rm9200ek board... at91rm9200_usart.c:39:2: warning: #warning Please update to use C structur SoC access ! textdata bss dec hex filename 1965645576 287296 489436 777dc ./u-boot - SUMMARY Boards compiled: 1 Boards with warnings or errors: 1 ( at91rm9200ek ) -- alb...@lilith:~/src/u-boot$ thanks! You're welcome. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can't build u-boot-2010.12-rc2 for at91rm9200ek
Dear zzs213, Am 09.12.2010 um 08:07 schrieb zzs213: I chang 'adr r1, r9' to 'add r1, r1, r9' and then rebuild it but I got another error. the error message is: arm-linux-ld: -static and -shared may not be used together make[1]: *** [/home/zzs/DownLoad/uboot/xx/build/u-boot] Error 1 make[1]: Leaving directory `/home/zzs/DownLoad/uboot/xx/u-boot-2010.12-rc2' make: *** [at91rm9200ek] Error 2 I can not remember any part defining -shared for the linker. Maybe it is implied by the linker when using -pie switch for the linker. That is what we do for current relocation implemented by Albert. Is this caused by the toolchain too? I guess it is your toolchain. Can you try e.g. a current codesourcery build? regards Andreas Bießmann BTW: One thing to mention. The at91rm9200ek board is _not_ fully functional a.t.m! I do only boot via JTAG currently, the same may be possible via preloader, e.g. one at91loader or a selfmade one. Booting from NOR Flash is ongoing but not working a.t.m., booting from dataflash may come in the future (fully supported by u-boot, via SPL; using preloader and copy to ram should work currently). ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] arm920t: fix linker skript for -pie linking
Le 09/12/2010 08:24, Andreas Bießmann a écrit : Dear Wolfgang Denk, Am 08.12.2010 um 23:52 schrieb Wolfgang Denk: Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message1291099039-49672-4-git-send-email-andreas.de...@googlemail.com you wrote: Without this patch the linker will SEGFAULT on some undefined weak symbols. Suggested-by: Sebastien Carliersebastien.carl...@gmail.com Signed-off-by: Andreas Bießmannandreas.de...@googlemail.com --- arch/arm/cpu/arm920t/u-boot.lds |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Applied, thanks. Please do not apply that patch! I'm sorry I have split up the thread cause it lead to a generic timer discussion. Therefore I posted v2 of this patch series here: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/89974 This patch is not needed, if no undefined weak symbol is available. This patch adds .plt/.rel.plt section which has R_ARM_JUMP_SLOT which is not handled in code. Therefore we do not really know what this patch does to the code, it was mostly a patch to handle the linker segfault described several times. Thanks for pointing this out. My bad: I did not relate the two series when going through patchwork. Wolfgang, I was about to send out a revert but after pulling u-boot.git and u-boot-arm.git I don't see Andreas' patch in there. If you haven't committed it yet, maybe you can fix this yourself? regards Andreas Bießmann Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can't build u-boot-2010.12-rc2 for at91rm9200ek
Yes. I just build it use eldk4.2. It's all right!! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
