[U-Boot] [PATCH] jffs2: cache data_crc results
As we moved data_crc() invocation from jffs2_1pass_build_lists() to
jffs2_1pass_read_inode() data_crc is going to be calculated on each
inode access. This patch adds caching of data_crc() results. There
is no significant improvement in speed (because of flash access
caching added in previous patch I think, crc in RAM is really fast)
but this patch impacts memory usage -- every b_node structure uses
12 bytes instead of 8.
Signed-off-by: Alexey Neyman <[EMAIL PROTECTED]>
Signed-off-by: Ilya Yanok <[EMAIL PROTECTED]>
---
fs/jffs2/jffs2_1pass.c |5 -
fs/jffs2/jffs2_private.h |1 +
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c
index 9d9ac1a..b41c299 100644
--- a/fs/jffs2/jffs2_1pass.c
+++ b/fs/jffs2/jffs2_1pass.c
@@ -768,7 +768,10 @@ jffs2_1pass_read_inode(struct b_lists *pL, u32 inode, char
*dest)
put_fl_mem(jNode, pL->readbuf);
continue;
}
- if (!data_crc(jNode)) {
+ if (b->datacrc == CRC_UNKNOWN)
+ b->datacrc = data_crc(jNode) ?
+ CRC_OK : CRC_BAD;
+ if (b->datacrc == CRC_BAD) {
put_fl_mem(jNode, pL->readbuf);
continue;
}
diff --git a/fs/jffs2/jffs2_private.h b/fs/jffs2/jffs2_private.h
index b3fab1c..7a9eda6 100644
--- a/fs/jffs2/jffs2_private.h
+++ b/fs/jffs2/jffs2_private.h
@@ -7,6 +7,7 @@
struct b_node {
u32 offset;
struct b_node *next;
+ enum { CRC_UNKNOWN = 0, CRC_OK, CRC_BAD } datacrc;
};
struct b_list {
--
1.5.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] jffs2: fix searching for latest version in jffs2_1pass_list_inodes()
We need to update i_version inside cycle to find really latest version
inside jffs2_1pass_list_inodes(). With that fixed we can use isize inside
dump_inode() instead of calling expensive jffs2_1pass_read_inode().
Signed-off-by: Alexey Neyman <[EMAIL PROTECTED]>
Signed-off-by: Ilya Yanok <[EMAIL PROTECTED]>
---
fs/jffs2/jffs2_1pass.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c
index 58298c0..94f8468 100644
--- a/fs/jffs2/jffs2_1pass.c
+++ b/fs/jffs2/jffs2_1pass.c
@@ -937,9 +937,7 @@ static inline u32 dump_inode(struct b_lists * pL, struct
jffs2_raw_dirent *d, st
st.st_mtime = i->mtime;
st.st_mode = i->mode;
st.st_ino = i->ino;
-
- /* neither dsize nor isize help us.. do it the long way */
- st.st_size = jffs2_1pass_read_inode(pL, i->ino, NULL);
+ st.st_size = i->isize;
dump_stat(&st, fname);
@@ -973,6 +971,7 @@ jffs2_1pass_list_inodes(struct b_lists * pL, u32 pino)
jNode = (struct jffs2_raw_inode *)
get_fl_mem(b2->offset, sizeof(ojNode),
&ojNode);
if (jNode->ino == jDir->ino && jNode->version
>= i_version) {
+ i_version = jNode->version;
if (i)
put_fl_mem(i);
--
1.5.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] jffs2: summary support
This patch adds support for reading fs information from summary
node instead of scanning full eraseblock.
Signed-off-by: Ilya Yanok <[EMAIL PROTECTED]>
---
fs/jffs2/jffs2_1pass.c | 187 +++-
fs/jffs2/summary.h | 163 +
include/jffs2/jffs2.h | 19 +
3 files changed, 368 insertions(+), 1 deletions(-)
create mode 100644 fs/jffs2/summary.h
diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c
index 61a0459..58298c0 100644
--- a/fs/jffs2/jffs2_1pass.c
+++ b/fs/jffs2/jffs2_1pass.c
@@ -138,6 +138,8 @@
# define DEBUGF(fmt,args...)
#endif
+#include "summary.h"
+
/* keeps pointer to currentlu processed partition */
static struct part_info *current_part;
@@ -1202,6 +1204,132 @@ jffs2_1pass_rescan_needed(struct part_info *part)
return 0;
}
+#define dbg_summary(...) do {} while (0);
+/* Process the stored summary information - helper function for
+ * jffs2_sum_scan_sumnode()
+ */
+
+static int jffs2_sum_process_sum_data(struct part_info *part, uint32_t offset,
+ struct jffs2_raw_summary *summary,
+ struct b_lists *pL)
+{
+ void *sp;
+ int i;
+
+ sp = summary->sum;
+
+ for (i = 0; i < summary->sum_num; i++) {
+ dbg_summary("processing summary index %d\n", i);
+
+ switch (((struct jffs2_sum_unknown_flash *)sp)->nodetype) {
+ case JFFS2_NODETYPE_INODE: {
+ struct jffs2_sum_inode_flash *spi;
+ spi = sp;
+
+ dbg_summary("Inode at 0x%08x-0x%08x\n",
+ offset + spi->offset,
+ offset + spi->offset + spi->totlen);
+
+ if (insert_node(&pL->frag, (u32) part->offset +
+ offset + spi->offset) == NULL)
+ return -1;
+
+ sp += JFFS2_SUMMARY_INODE_SIZE;
+
+ break;
+ }
+
+ case JFFS2_NODETYPE_DIRENT: {
+ struct jffs2_sum_dirent_flash *spd;
+ spd = sp;
+
+ dbg_summary("Dirent at 0x%08x-0x%08x\n",
+ offset + spd->offset,
+ offset + spd->offset + spd->totlen);
+
+ if (insert_node(&pL->dir, (u32) part->offset +
+ offset + spd->offset) == NULL)
+ return -1;
+
+ sp += JFFS2_SUMMARY_DIRENT_SIZE(spd->nsize);
+
+ break;
+ }
+ default : {
+ uint16_t nodetype =
+ ((struct jffs2_sum_unknown_flash *)
+sp)->nodetype;
+ printf("Unsupported node type %x found in "
+ "summary!\n", nodetype);
+ break;
+ }
+ }
+ }
+ return 0;
+}
+
+/* Process the summary node - called from jffs2_scan_eraseblock() */
+int jffs2_sum_scan_sumnode(struct part_info *part, uint32_t offset,
+ struct jffs2_raw_summary *summary, uint32_t sumsize,
+ struct b_lists *pL)
+{
+ struct jffs2_unknown_node crcnode;
+ int ret, ofs;
+ uint32_t crc;
+
+ ofs = part->sector_size - sumsize;
+
+ dbg_summary("summary found for 0x%08x at 0x%08x (0x%x bytes)\n",
+ offset, offset + ofs, sumsize);
+
+ /* OK, now check for node validity and CRC */
+ crcnode.magic = JFFS2_MAGIC_BITMASK;
+ crcnode.nodetype = JFFS2_NODETYPE_SUMMARY;
+ crcnode.totlen = summary->totlen;
+ crc = crc32_no_comp(0, (uchar *)&crcnode, sizeof(crcnode)-4);
+
+ if (summary->hdr_crc != crc) {
+ dbg_summary("Summary node header is corrupt (bad CRC or "
+ "no summary at all)\n");
+ goto crc_err;
+ }
+
+ if (summary->totlen != sumsize) {
+ dbg_summary("Summary node is corrupt (wrong erasesize?)\n");
+ goto crc_err;
+ }
+
+ crc = crc32_no_comp(0, (uchar *)summary,
+ sizeof(struct jffs2_raw_summary)-8);
+
+ if (summary->node_crc != crc) {
+ dbg_summary("Summary node is corrupt (bad CRC)\n");
+ goto crc_err;
+ }
+
+ crc = crc32_no_comp(0, (uchar *)summary->sum,
+ sumsize - sizeof(struct jffs2_raw_summary));
+
+ if (summary-
[U-Boot] [PATCH] jffs2: add sector_size field to part_info structure
This patch adds sector_size field to part_info structure (used
by new JFFS2 code).
Signed-off-by: Ilya Yanok <[EMAIL PROTECTED]>
---
common/cmd_jffs2.c | 13 -
include/jffs2/load_kernel.h |1 +
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c
index c6920c9..e7f07bf 100644
--- a/common/cmd_jffs2.c
+++ b/common/cmd_jffs2.c
@@ -339,11 +339,13 @@ static int part_validate_nor(struct mtdids *id, struct
part_info *part)
extern flash_info_t flash_info[];
flash_info_t *flash;
int offset_aligned;
- u32 end_offset;
+ u32 end_offset, sector_size = 0;
int i;
flash = &flash_info[id->num];
+ part->sector_size = 0;
+
offset_aligned = 0;
for (i = 0; i < flash->sector_count; i++) {
if ((flash->start[i] - flash->start[0]) == part->offset) {
@@ -359,6 +361,11 @@ static int part_validate_nor(struct mtdids *id, struct
part_info *part)
end_offset = part->offset + part->size;
for (i = 0; i < flash->sector_count; i++) {
+ if (i) {
+ sector_size = flash->start[i] - flash->start[i-1];
+ if (part->sector_size < sector_size)
+ part->sector_size = sector_size;
+ }
if ((flash->start[i] - flash->start[0]) == end_offset)
return 0;
}
@@ -389,6 +396,8 @@ static int part_validate_nand(struct mtdids *id, struct
part_info *part)
nand = &nand_info[id->num];
+ part->sector_size = nand->erasesize;
+
if ((unsigned long)(part->offset) % nand->erasesize) {
printf("%s%d: partition (%s) start offset alignment
incorrect\n",
MTD_DEV_TYPE(id->type), id->num, part->name);
@@ -424,6 +433,8 @@ static int part_validate_onenand(struct mtdids *id, struct
part_info *part)
mtd = &onenand_mtd;
+ part->sector_size = mtd->erasesize;
+
if ((unsigned long)(part->offset) % mtd->erasesize) {
printf("%s%d: partition (%s) start offset"
"alignment incorrect\n",
diff --git a/include/jffs2/load_kernel.h b/include/jffs2/load_kernel.h
index 551fd0c..c0442a2 100644
--- a/include/jffs2/load_kernel.h
+++ b/include/jffs2/load_kernel.h
@@ -50,6 +50,7 @@ struct part_info {
u32 offset; /* offset within device */
void *jffs2_priv; /* used internaly by jffs2 */
u32 mask_flags; /* kernel MTD mask flags */
+ u32 sector_size;/* size of sector */
struct mtd_device *dev; /* parent device */
};
--
1.5.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH/RFC] Some speed improvements to U-Boot JFFS2 code
Hello everybody, here is a set of changes we made to improve U-Boot JFFS2 code performance. We still can't reach Linux's performance but improvements are significant. Any comments are welcome. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] jffs2: rewrite jffs2 scanning code based on Linux one
Rewrites jffs2_1pass_build_lists() function in style of Linux's
jffs2_scan_medium() and jffs2_scan_eraseblock().
This includes:
- Caching flash acceses
- Smart dealing with free space
Signed-off-by: Alexey Neyman <[EMAIL PROTECTED]>
Signed-off-by: Ilya Yanok <[EMAIL PROTECTED]>
---
fs/jffs2/jffs2_1pass.c | 227
1 files changed, 171 insertions(+), 56 deletions(-)
diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c
index 57f5582..61a0459 100644
--- a/fs/jffs2/jffs2_1pass.c
+++ b/fs/jffs2/jffs2_1pass.c
@@ -389,6 +389,12 @@ static inline void *get_fl_mem_nor(u32 off)
return (void*)addr;
}
+static inline void *get_fl_mem_nor_copy(u32 off, u32 size, void *ext_buf)
+{
+ memcpy(ext_buf, get_fl_mem_nor(off), size);
+ return ext_buf;
+}
+
static inline void *get_node_mem_nor(u32 off)
{
return (void*)get_fl_mem_nor(off);
@@ -405,8 +411,11 @@ static inline void *get_fl_mem(u32 off, u32 size, void
*ext_buf)
struct mtdids *id = current_part->dev->id;
#if defined(CONFIG_CMD_FLASH)
- if (id->type == MTD_DEV_TYPE_NOR)
+ if (id->type == MTD_DEV_TYPE_NOR) {
+ if (ext_buf)
+ return get_fl_mem_nor_copy(off, size, ext_buf);
return get_fl_mem_nor(off);
+ }
#endif
#if defined(CONFIG_JFFS2_NAND) && defined(CONFIG_CMD_NAND)
@@ -480,9 +489,6 @@ static char *compr_names[] = {
#endif
};
-/* Spinning wheel */
-static char spinner[] = { '|', '/', '-', '\\' };
-
/* Memory management */
struct mem_block {
u32 index;
@@ -653,23 +659,6 @@ static int compare_dirents(struct b_node *new, struct
b_node *old)
}
#endif
-static u32
-jffs2_scan_empty(u32 start_offset, struct part_info *part)
-{
- char *max = (char *)(part->offset + part->size - sizeof(struct
jffs2_raw_inode));
- char *offset = (char *)(part->offset + start_offset);
- u32 off;
-
- while (offset < max &&
- *(u32*)get_fl_mem((u32)offset, sizeof(u32), &off) == 0x)
{
- offset += sizeof(u32);
- /* return if spinning is due */
- if (((u32)offset & ((1 << SPIN_BLKSIZE)-1)) == 0) break;
- }
-
- return (u32)offset - part->offset;
-}
-
void
jffs2_free_cache(struct part_info *part)
{
@@ -768,6 +757,10 @@ jffs2_1pass_read_inode(struct b_lists *pL, u32 inode, char
*dest)
put_fl_mem(jNode);
continue;
}
+ if (!data_crc(jNode)) {
+ put_fl_mem(jNode);
+ continue;
+ }
lDest = (uchar *) (dest + jNode->offset);
#if 0
@@ -1271,17 +1264,33 @@ dump_dirents(struct b_lists *pL)
}
#endif
+#define min_t(type, x, y) ({\
+ type __min1 = (x); \
+ type __min2 = (y); \
+ __min1 < __min2 ? __min1: __min2; })
+
+#define DEFAULT_EMPTY_SCAN_SIZE4096
+
+static inline uint32_t EMPTY_SCAN_SIZE(uint32_t sector_size)
+{
+ if (sector_size < DEFAULT_EMPTY_SCAN_SIZE)
+ return sector_size;
+ else
+ return DEFAULT_EMPTY_SCAN_SIZE;
+}
+
static u32
jffs2_1pass_build_lists(struct part_info * part)
{
struct b_lists *pL;
struct jffs2_unknown_node *node;
- u32 offset, oldoffset = 0;
- u32 max = part->size - sizeof(struct jffs2_raw_inode);
- u32 counter = 0;
+ u32 nr_sectors = part->size/part->sector_size;
+ u32 i;
u32 counter4 = 0;
u32 counterF = 0;
u32 counterN = 0;
+ u32 buf_size = DEFAULT_EMPTY_SCAN_SIZE;
+ char *buf;
/* turn off the lcd. Refreshing the lcd adds 50% overhead to the */
/* jffs2 list building enterprise nope. in newer versions the overhead
is */
@@ -1291,70 +1300,176 @@ jffs2_1pass_build_lists(struct part_info * part)
/* if we are building a list we need to refresh the cache. */
jffs_init_1pass_list(part);
pL = (struct b_lists *)part->jffs2_priv;
- offset = 0;
+ buf = malloc(buf_size);
puts ("Scanning JFFS2 FS: ");
/* start at the beginning of the partition */
- while (offset < max) {
- if ((oldoffset >> SPIN_BLKSIZE) != (offset >> SPIN_BLKSIZE)) {
- printf("\b\b%c ", spinner[counter++ % sizeof(spinner)]);
- oldoffset = offset;
- }
+ for (i = 0; i < nr_sectors; i++) {
+ uint32_t sector_ofs = i * part->sector_size;
+ uint32_t buf_ofs = sector_ofs;
+ uint32_t buf_len = EMPTY_SCAN_SIZE(part->sector_size);
+ uint32_t ofs, prevofs;
WATCHDOG_RESET();
+ get_fl_mem((u32)part->offset +
[U-Boot] [PATCH] jffs2: add buffer to cache flash accesses
With this patch JFFS2 code allocates memory buffer of max_totlen size
(size of the largest node, calculated during scan time) and uses it to
store entire node. Speeds up loading. If malloc fails we use old ways
to do things.
Signed-off-by: Alexey Neyman <[EMAIL PROTECTED]>
Signed-off-by: Ilya Yanok <[EMAIL PROTECTED]>
---
fs/jffs2/jffs2_1pass.c | 121 -
fs/jffs2/jffs2_private.h |2 +-
2 files changed, 76 insertions(+), 47 deletions(-)
diff --git a/fs/jffs2/jffs2_1pass.c b/fs/jffs2/jffs2_1pass.c
index 94f8468..9d9ac1a 100644
--- a/fs/jffs2/jffs2_1pass.c
+++ b/fs/jffs2/jffs2_1pass.c
@@ -247,7 +247,7 @@ static void *get_fl_mem_nand(u32 off, u32 size, void
*ext_buf)
return buf;
}
-static void *get_node_mem_nand(u32 off)
+static void *get_node_mem_nand(u32 off, void *ext_buf)
{
struct jffs2_unknown_node node;
void *ret = NULL;
@@ -257,7 +257,7 @@ static void *get_node_mem_nand(u32 off)
if (!(ret = get_fl_mem_nand(off, node.magic ==
JFFS2_MAGIC_BITMASK ? node.totlen : sizeof(node),
- NULL))) {
+ ext_buf))) {
printf("off = %#x magic %#x type %#x node.totlen = %d\n",
off, node.magic, node.nodetype, node.totlen);
}
@@ -346,7 +346,7 @@ static void *get_fl_mem_onenand(u32 off, u32 size, void
*ext_buf)
return buf;
}
-static void *get_node_mem_onenand(u32 off)
+static void *get_node_mem_onenand(u32 off, void *ext_buf)
{
struct jffs2_unknown_node node;
void *ret = NULL;
@@ -356,7 +356,7 @@ static void *get_node_mem_onenand(u32 off)
ret = get_fl_mem_onenand(off, node.magic ==
JFFS2_MAGIC_BITMASK ? node.totlen : sizeof(node),
- NULL);
+ ext_buf);
if (!ret) {
printf("off = %#x magic %#x type %#x node.totlen = %d\n",
off, node.magic, node.nodetype, node.totlen);
@@ -379,7 +379,7 @@ static void put_fl_mem_onenand(void *buf)
* NOR flash memory is mapped in processor's address space,
* just return address.
*/
-static inline void *get_fl_mem_nor(u32 off)
+static inline void *get_fl_mem_nor(u32 off, u32 size, void *ext_buf)
{
u32 addr = off;
struct mtdids *id = current_part->dev->id;
@@ -388,18 +388,22 @@ static inline void *get_fl_mem_nor(u32 off)
flash_info_t *flash = &flash_info[id->num];
addr += flash->start[0];
+ if (ext_buf) {
+ memcpy(ext_buf, (void *)addr, size);
+ return ext_buf;
+ }
return (void*)addr;
}
-static inline void *get_fl_mem_nor_copy(u32 off, u32 size, void *ext_buf)
+static inline void *get_node_mem_nor(u32 off, void *ext_buf)
{
- memcpy(ext_buf, get_fl_mem_nor(off), size);
- return ext_buf;
-}
+ struct jffs2_unknown_node *pNode;
-static inline void *get_node_mem_nor(u32 off)
-{
- return (void*)get_fl_mem_nor(off);
+ /* pNode will point directly to flash - don't provide external buffer
+ and don't care about size */
+ pNode = get_fl_mem_nor(off, 0, NULL);
+ return (void *)get_fl_mem_nor(off, pNode->magic == JFFS2_MAGIC_BITMASK ?
+ pNode->totlen : sizeof(*pNode), ext_buf);
}
#endif
@@ -414,9 +418,7 @@ static inline void *get_fl_mem(u32 off, u32 size, void
*ext_buf)
#if defined(CONFIG_CMD_FLASH)
if (id->type == MTD_DEV_TYPE_NOR) {
- if (ext_buf)
- return get_fl_mem_nor_copy(off, size, ext_buf);
- return get_fl_mem_nor(off);
+ return get_fl_mem_nor(off, size, ext_buf);
}
#endif
@@ -434,44 +436,48 @@ static inline void *get_fl_mem(u32 off, u32 size, void
*ext_buf)
return (void*)off;
}
-static inline void *get_node_mem(u32 off)
+static inline void *get_node_mem(u32 off, void *ext_buf)
{
struct mtdids *id = current_part->dev->id;
#if defined(CONFIG_CMD_FLASH)
if (id->type == MTD_DEV_TYPE_NOR)
- return get_node_mem_nor(off);
+ return get_node_mem_nor(off, ext_buf);
#endif
#if defined(CONFIG_JFFS2_NAND) && \
defined(CONFIG_CMD_NAND)
if (id->type == MTD_DEV_TYPE_NAND)
- return get_node_mem_nand(off);
+ return get_node_mem_nand(off, ext_buf);
#endif
#if defined(CONFIG_CMD_ONENAND)
if (id->type == MTD_DEV_TYPE_ONENAND)
- return get_node_mem_onenand(off);
+ return get_node_mem_onenand(off, ext_buf);
#endif
printf("get_node_mem: unknown device type, using raw offset!\n");
return (void*)off;
}
-static inline void put_fl_mem(void *buf)
+static inline void put_fl_mem(void *buf, void *ext_buf)
{
#if defined(CONFIG_JFFS2_NAND) && \
defined(CONFIG_CMD_NAND)
struct mtdids *id = current_part->dev->id;
- if (id->
Re: [U-Boot] [PATCH v3 2/6] i.MX31: Make the SPI bus and chip select configurable for MC13783
On 00:27 Mon 13 Oct , Wolfgang Denk wrote: > Dear Jean-Christophe, > > In message <[EMAIL PROTECTED]> you wrote: > > On 10:36 Fri 29 Aug , Magnus Lilja wrote: > > > The i.MX31 has three SPI buses and each bus has several chip selects > > > and the MC13783 chip can be connected to any of these. The current > > > RTC driver for MC13783 is hardcoded for CSPI2/SS2. > > > > > > This patch makes make MC13783 SPI bus and chip select configurable > > > via CONFIG_MC13783_SPI_BUS and CONFIG_MC13783_SPI_CS. > > > > > > Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]> > > > --- > > > doc/README.mx31 | 19 +++ > > > drivers/rtc/mc13783-rtc.c |6 -- > > > include/configs/imx31_litekit.h |3 +++ > > > include/configs/mx31ads.h |3 +++ > > > 4 files changed, 29 insertions(+), 2 deletions(-) > > > > > applied to u-boot-arm > > Yet it never made it into mainline yet. > > What happened to this patch series? Please comment. It is 1a6337b01351b82a45b0defa76f08744511c580b Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/6] i.MX31: Add basic support for Freescale's i.MX31 PDK board.
On 00:27 Mon 13 Oct , Wolfgang Denk wrote: > Dear Jean-Christophe, > > In message <[EMAIL PROTECTED]> you wrote: > > On 10:36 Fri 29 Aug , Magnus Lilja wrote: > > > Add support for the Freescale i.MX31 PDK (a.k.a 3DS) board. Ethernet and > > > MC13873 RTC support is enabled by this patch. > > > > > > Booting from NAND is not supported yet so U-boot relies on some other > > > initial boot loader to set up SDRAM and clocks and copying U-boot to > > > SDRAM. > > > > > > Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]> > > > --- > > > MAKEALL |1 + > > > Makefile|3 + > > > board/freescale/mx31pdk/Makefile| 53 ++ > > > board/freescale/mx31pdk/config.mk |1 + > > > board/freescale/mx31pdk/lowlevel_init.S | 30 ++ > > > board/freescale/mx31pdk/mx31pdk.c | 76 +++ > > > board/freescale/mx31pdk/u-boot.lds | 59 > > > include/configs/mx31pdk.h | 159 > > > +++ > > > 8 files changed, 382 insertions(+), 0 deletions(-) > > > > > applied to u-boot-arm branch testing > > This patch (and all the others of this patch series) was sumbitted > while the merge window was open. > > Is there any special reason it was not added to the master branch > yet? > As we discuss on IRC this board will be merge when it can boot from a storage Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PATCH: U-Boot support for Olimex SAM9L-9260 development board
On 00:19 Mon 13 Oct , Wolfgang Denk wrote: > Dear Jean-Christophe, > > In message <[EMAIL PROTECTED]> Markus Kammerstetter wrote: > > Hi, > > > > I added support for the Olimex SAM9L-9260 development board to the > > current git source tree. > > The original code is from the at91sam9260ek implementation and has been > > modified > > to work with the Olimex board. > > > > I also changed cpu/arm926ejs/at91/ether.c to be able to specify a custom > > PHY address > > with CONFIG_EMAC_PHY_ADDR instead of having the fixed address "0x00" in the > > code. > > > > Signed-off-by: Markus Kammerstetter tbmn.org> > > This patch was sumbitted while the merge window was open. > > Is there any special reason it was not added, and the submitter > received no feedback? I'm currently reviewing it Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] Some speed improvements to U-Boot JFFS2 code
Dear Ilya, In message <[EMAIL PROTECTED]> you wrote: > > here is a set of changes we made to improve U-Boot JFFS2 code > performance. We still can't reach Linux's performance but improvements > are significant. > > Any comments are welcome. Are these patches independent of each other, or are all of them needed, and if so, is there any specific order in which they have to be 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: [EMAIL PROTECTED] You humans have that emotional need to express gratitude. "You're welcome," I believe, is the correct response. -- Spock, "Bread and Circuses", stardate 4041.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/6] i.MX31: Make the SPI bus and chip select configurable for MC13783
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <[EMAIL PROTECTED]> you wrote: > > > > > doc/README.mx31 | 19 +++ > > > > drivers/rtc/mc13783-rtc.c |6 -- > > > > include/configs/imx31_litekit.h |3 +++ > > > > include/configs/mx31ads.h |3 +++ > > > > 4 files changed, 29 insertions(+), 2 deletions(-) > > > > > > > applied to u-boot-arm > > > > Yet it never made it into mainline yet. > > > > What happened to this patch series? Please comment. > It is 1a6337b01351b82a45b0defa76f08744511c580b Ah, I see. I was looking for doc/README.mx31 and didn;t see that it got merged/renamed later. Sorry. 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: [EMAIL PROTECTED] The thing is, as you progress in the Craft, you'll learn there is another rule... When you break rules, break 'em good and hard. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/6] i.MX31: Add basic support for Freescale's i.MX31 PDK board.
Dear Jean-Christophe PLAGNIOL-VILLARD, In message <[EMAIL PROTECTED]> you wrote: > > > > On 10:36 Fri 29 Aug , Magnus Lilja wrote: > > > > Add support for the Freescale i.MX31 PDK (a.k.a 3DS) board. Ethernet and > > > > MC13873 RTC support is enabled by this patch. > > > > > > > > Booting from NAND is not supported yet so U-boot relies on some other > > > > initial boot loader to set up SDRAM and clocks and copying U-boot to > > > > SDRAM. ... > > This patch (and all the others of this patch series) was sumbitted > > while the merge window was open. > > > > Is there any special reason it was not added to the master branch > > yet? ... > As we discuss on IRC this board will be merge when it can boot from a storage IRC may be fine for finding a quick agreement, but please *always* post a response to the patches on the mailing list. Only then everybody (including me) can know what's going on. 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: [EMAIL PROTECTED] The important thing about being a leader is not being right or wrong, but being *certain*.- Terry Pratchett, _Truckers_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] jffs2: add sector_size field to part_info structure
Dear Ilya,
In message <[EMAIL PROTECTED]> you wrote:
> This patch adds sector_size field to part_info structure (used
> by new JFFS2 code).
...
> @@ -359,6 +361,11 @@ static int part_validate_nor(struct mtdids *id, struct
> part_info *part)
>
> end_offset = part->offset + part->size;
> for (i = 0; i < flash->sector_count; i++) {
> + if (i) {
> + sector_size = flash->start[i] - flash->start[i-1];
> + if (part->sector_size < sector_size)
> + part->sector_size = sector_size;
> + }
What about the size of the last sector?
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: [EMAIL PROTECTED]
God is real, unless declared integer.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/6] i.MX31: Add basic support for Freescale's i.MX31 PDK board.
On 10:25 Mon 13 Oct , Wolfgang Denk wrote: > Dear Jean-Christophe PLAGNIOL-VILLARD, > > In message <[EMAIL PROTECTED]> you wrote: > > > > > > On 10:36 Fri 29 Aug , Magnus Lilja wrote: > > > > > Add support for the Freescale i.MX31 PDK (a.k.a 3DS) board. Ethernet > > > > > and > > > > > MC13873 RTC support is enabled by this patch. > > > > > > > > > > Booting from NAND is not supported yet so U-boot relies on some other > > > > > initial boot loader to set up SDRAM and clocks and copying U-boot to > > > > > SDRAM. > ... > > > This patch (and all the others of this patch series) was sumbitted > > > while the merge window was open. > > > > > > Is there any special reason it was not added to the master branch > > > yet? > ... > > As we discuss on IRC this board will be merge when it can boot from a > > storage > > IRC may be fine for finding a quick agreement, but please *always* > post a response to the patches on the mailing list. > > Only then everybody (including me) can know what's going on. I've done it in this reply F Sep03 Cc [EMAIL PROTECTED] └─>Re: [U-Boot] [PATCH v3 0/6] i.MX31: Add NAND support and new PDK?board. Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cfi_flash write fix for AMD legacy
On Thursday 09 October 2008, Ed Swarthout wrote: > The flash_unlock_seq requires a sector for AMD_LEGACY. > Fix a retcode check typeo. Applied to cfi/master. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [cfi-flash] Please pull git://www.denx.de/git/u-boot-cfi-flash.git
The following changes since commit df4a0796e86662536df2387ddcf969c2a704bcc2: Wolfgang Denk (1): Merge branch 'master' of ssh://10.10.0.7/home/wd/git/u-boot/master are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git master Ed Swarthout (1): CFI: cfi_flash write fix for AMD legacy drivers/mtd/cfi_flash.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [cfi-flash] Please pull git://www.denx.de/git/u-boot-cfi-flash.git
Dear Stefan Roese, In message <[EMAIL PROTECTED]> you wrote: > The following changes since commit df4a0796e86662536df2387ddcf969c2a704bcc2: > Wolfgang Denk (1): > Merge branch 'master' of ssh://10.10.0.7/home/wd/git/u-boot/master > > are available in the git repository at: > > git://www.denx.de/git/u-boot-cfi-flash.git master > > Ed Swarthout (1): > CFI: cfi_flash write fix for AMD legacy > > drivers/mtd/cfi_flash.c |8 +--- > 1 files changed, 5 insertions(+), 3 deletions(-) Done, 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: [EMAIL PROTECTED] "Just Say No." - Nancy Reagan "No."- Ronald Reagan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 86xx: remove redudant code with lib_ppc/interrupts.c
Dear Kumar, In message <[EMAIL PROTECTED]> you wrote: > For some reason we duplicated the majority of code in lib_ppc/interrupts.c > not show how that happened, but there is no good reason for it. > > Use the interrupt_init_cpu() and timer_interrupt_cpu() since its why > they exist. > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > --- > cpu/mpc86xx/interrupts.c | 131 > +++--- > 1 files changed, 7 insertions(+), 124 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: [EMAIL PROTECTED] "Obviously, a major malfunction has occurred." -- Steve Nesbitt, voice of Mission Control, January 28, 1986, as the shuttle Challenger exploded within view of the grandstands. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 V3] Add support for LZMA uncompression algorithm.
Dear "Luigi 'Comio' Mantellini", In message <[EMAIL PROTECTED]> you wrote: > > Date: Sat, 13 Sep 2008 10:04:32 +0200 > Subject: [PATCH] Fix lzma uncompress call (image_start wrongly used instead= > image_len) > > > Signed-off-by: Luigi 'Comio' Mantellini <[EMAIL PROTECTED]> > --- > common/cmd_bootm.c |2 +- > 1 files changed, 1 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: [EMAIL PROTECTED] Children begin by loving their parents. After a time they judge them. Rarely, if ever, do they forgive them. - Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM DaVinci: Remove redundant setting of GD_FLG_RELOC for sffsdr board.
Dear Hugo Villeneuve, In message <[EMAIL PROTECTED]> you wrote: > ARM DaVinci: Remove redundant setting of GD_FLG_RELOC for sffsdr board. > > This is no longer necessary now that the GD_FLG_RELOC flag is set for all ARM > boards. > > Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]> > --- > > This is a cleanup following Jean-Christophe Plagniol-Villard patch. > > board/davinci/sffsdr/sffsdr.c |4 > 1 files changed, 0 insertions(+), 4 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: [EMAIL PROTECTED] "Probably the best operating system in the world is the [operating system] made for the PDP-11 by Bell Laboratories." - Ted Nelson, October 1977 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM DaVinci: Remove redundant setting ofGD_FLG_RELOC for sffsdr board.
Dear "Hugo Villeneuve", In message <[EMAIL PROTECTED]> you wrote: > > > ARM DaVinci: Remove redundant setting of GD_FLG_RELOC for sffsdr > > board. ... > Jean-Christophe, > did you integrate that patch in your tree? Obviously not, but since this is a board-specific patch I pulled it directly. 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: [EMAIL PROTECTED] In an infinite universe all things are possible, including the possi- bility that the universe does not exist. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] mpc8572ds relocatable
On Mon, 2008-10-13 at 00:53 +0200, Wolfgang Denk wrote: > Dear Ed Swarthout, > > In message <[EMAIL PROTECTED]> you wrote: > > Fixes boot crash from bad string pointers in get_table_entry_name > > when flash is erased or differs from current u-boot image. > > > > Signed-off-by: Ed Swarthout <[EMAIL PROTECTED]> > > --- > > > > Fix was pointed out by Peter Tyser in Image.c get_table_entry_name thread. > > > > This redoes Grant Likey's relocation change, but leaves control to each > > board. > > This also fixes the "mii dump" command when flash is erased. > > Tested with gcc 4.2 Just wanted to point out that the problems from Grants relocation change might come from something I found a while back, quoting from previous mail: For fun I had a look into eabi.asm code at http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/eabi.asm?rev=1.13&content-type=text/x-cvsweb-markup and I noticed one difference: The __eabi_uconvert() function skips NULL ptrs. Perhaps this is the missing piece needed in start.S for PPC? __eabi_convert pasted below for convenience. Jocke FUNC_START(__eabi_convert) cmplw 1,3,4/* any pointers to convert? */ subf5,3,4/* calculate number of words to convert */ bclr4,4/* return if no pointers */ srawi 5,5,2 addi3,3,-4/* start-4 for use with lwzu */ mtctr 5 .Lcvt: lwzu6,4(3)/* pointer to convert */ cmpwi0,6,0 beq-.Lcvt2/* if pointer is null, don't convert */ add 6,6,12/* convert pointer */ stw 6,0(3) .Lcvt2: bdnz+ .Lcvt blr ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Add 1.0 & 1.066 GHz to canyonlands bootstrap command for PLL setup
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
board/amcc/canyonlands/bootstrap.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/board/amcc/canyonlands/bootstrap.c
b/board/amcc/canyonlands/bootstrap.c
index 1d125b6..5d832de 100644
--- a/board/amcc/canyonlands/bootstrap.c
+++ b/board/amcc/canyonlands/bootstrap.c
@@ -40,6 +40,8 @@
static char *config_labels[] = {
"CPU: 600 PLB: 200 OPB: 100 EBC: 100",
"CPU: 800 PLB: 200 OPB: 100 EBC: 100",
+ "CPU:1000 PLB: 200 OPB: 100 EBC: 100",
+ "CPU:1066 PLB: 266 OPB: 88 EBC: 88",
NULL
};
@@ -55,6 +57,16 @@ static u8 boot_configs[][17] = {
0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
},
{
+ (NAND_COMPATIBLE | NOR_COMPATIBLE),
+ 0x86, 0x82, 0x96, 0x19, 0xb9, 0x80, 0x00, 0xa0, 0x40, 0x08,
+ 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ },
+ {
+ (NAND_COMPATIBLE | NOR_COMPATIBLE),
+ 0x86, 0x80, 0xb3, 0x01, 0x9d, 0x80, 0x00, 0xa0, 0x40, 0x08,
+ 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ },
+ {
0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
}
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC86xx unapplied patches
Dear Jon, In message <[EMAIL PROTECTED]> you wrote: > > > 6185 08/19 Kumar Gala [U-Boot] [PATCH] 86xx: remove redudant code > > with lib_ppc/interrupts.c > > 6767 08/28 Nick Spence[U-Boot] [PATCH] mpc86xx: use r4 instead of > > r2 in lock_ram_in_cache a > > Sorry, got buried here. If these are still outstanding, > please directly apply them. Understood, applied these two. Let me know if there are more. 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: [EMAIL PROTECTED] Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Can u-boot load WinCE kernel image?
hello, Does anyone ever try to load a WinCE kernel image(NK.bin or NK.nb0)? Thanks! Jerry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ppc4xx] Please pull git://www.denx.de/git/u-boot-ppc4xx.git
The following changes since commit 50a874b3b0272f32e3627732fab90b27fbd35066: Stefan Roese (1): Merge branch 'master' of /home/stefan/git/u-boot/u-boot are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Adam Graham (1): ppc4xx: Reset and relock memory DLL after SDRAM_CLKTR change Matthias Fuchs (4): ppc4xx: Update DU440 config ppc4xx: Fix DU440 GPIO configuration ppc4xx: Add strapping mode for 667MHz CPU frequency on DU440 board ppc4xx: Fix USB 2.0 phy reset sequence board/esd/du440/du440.c | 51 +- cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c | 21 ++ include/configs/DU440.h |6 +++- 3 files changed, 68 insertions(+), 10 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ppc4xx] Please pull git://www.denx.de/git/u-boot-ppc4xx.git
Dear Stefan Roese, In message <[EMAIL PROTECTED]> you wrote: > The following changes since commit 50a874b3b0272f32e3627732fab90b27fbd35066: > Stefan Roese (1): > Merge branch 'master' of /home/stefan/git/u-boot/u-boot > > are available in the git repository at: > > git://www.denx.de/git/u-boot-ppc4xx.git master > > Adam Graham (1): > ppc4xx: Reset and relock memory DLL after SDRAM_CLKTR change > > Matthias Fuchs (4): > ppc4xx: Update DU440 config > ppc4xx: Fix DU440 GPIO configuration > ppc4xx: Add strapping mode for 667MHz CPU frequency on DU440 board > ppc4xx: Fix USB 2.0 phy reset sequence > > board/esd/du440/du440.c | 51 +- > cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c | 21 ++ > include/configs/DU440.h |6 +++- > 3 files changed, 68 insertions(+), 10 deletions(-) Done, 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: [EMAIL PROTECTED] Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: mpc8360emds: rework LBC SDRAM setup
Dear Kim, In message <[EMAIL PROTECTED]> Anton Vorontsov wrote: > Currently 64M of LBC SDRAM are mapped at 0xF000 which makes > it difficult to use (b/c then the memory is discontinuous and > there is quite big memory hole between the DDR/SDRAM regions). > > This patch reworks LBC SDRAM setup so that now we dynamically > place the LBC SDRAM near the DDR (or at 0x0 if there isn't any > DDR memory). > > With this patch we're able to: > > - Boot without external DDR memory; > - Use most "DDR + SDRAM" setups without need to support for > sparse/discontinuous memory model in the software. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > --- > board/freescale/mpc8360emds/mpc8360emds.c | 39 > - > include/configs/MPC8360EMDS.h | 25 -- > 2 files changed, 38 insertions(+), 26 deletions(-) I think this patch was not added, nor was any feedback sent? Please comment. 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: [EMAIL PROTECTED] "There are three principal ways to lose money: wine, women, and en- gineers. While the first two are more pleasant, the third is by far the more certain." -- Baron Rothschild, ca. 1800 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Correctly setup ranges property in ebc node
Previously only the NOR flash mapping was written into the ranges
property of the ebc node. This patch now writes all enabled chip
select areas into the ranges property.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
cpu/ppc4xx/fdt.c | 45 ++---
include/asm-ppc/ppc4xx-ebc.h | 31
2 files changed, 59 insertions(+), 17 deletions(-)
diff --git a/cpu/ppc4xx/fdt.c b/cpu/ppc4xx/fdt.c
index a97484f..c55e1cf 100644
--- a/cpu/ppc4xx/fdt.c
+++ b/cpu/ppc4xx/fdt.c
@@ -37,29 +37,40 @@ DECLARE_GLOBAL_DATA_PTR;
void __ft_board_setup(void *blob, bd_t *bd)
{
- u32 val[4];
int rc;
+ int i;
+ u32 bxcr;
+ u32 ranges[EBC_NUM_BANKS * 4];
+ u32 *p = ranges;
+ char *ebc_path = "/plb/opb/ebc";
ft_cpu_setup(blob, bd);
- /* Fixup NOR mapping */
- val[0] = 0; /* chip select number */
- val[1] = 0; /* always 0 */
- val[2] = gd->bd->bi_flashstart;
- val[3] = gd->bd->bi_flashsize;
- if (fdt_path_offset(blob, "/plb/opb/ebc") >= 0) {
- rc = fdt_find_and_setprop(blob, "/plb/opb/ebc", "ranges",
- val, sizeof(val), 1);
- } else {
- /*
-* Some 405 PPC's have EBC as direct PLB child in the dts
-*/
- rc = fdt_find_and_setprop(blob, "/plb/ebc", "ranges",
- val, sizeof(val), 1);
+ /*
+* Read 4xx EBC bus bridge registers to get mappings of the
+* peripheral banks into the OPB/PLB address space
+*/
+ for (i = 0; i < EBC_NUM_BANKS; i++) {
+ mtdcr(ebccfga, EBC_BXCR(i));
+ bxcr = mfdcr(ebccfgd);
+
+ if ((bxcr & EBC_BXCR_BU_MASK) != EBC_BXCR_BU_NONE) {
+ *p++ = i;
+ *p++ = 0;
+ *p++ = bxcr & EBC_BXCR_BAS_MASK;
+ *p++ = EBC_BXCR_BANK_SIZE(bxcr);
+ }
}
- if (rc)
- printf("Unable to update property NOR mapping, err=%s\n",
+
+ /* Some 405 PPC's have EBC as direct PLB child in the dts */
+ if (fdt_path_offset(blob, "/plb/opb/ebc") < 0)
+ strcpy(ebc_path, "/plb/ebc");
+ rc = fdt_find_and_setprop(blob, ebc_path, "ranges", ranges,
+ (p - ranges) * sizeof(u32), 1);
+ if (rc) {
+ printf("Unable to update property EBC mappings, err=%s\n",
fdt_strerror(rc));
+ }
}
void ft_board_setup(void *blob, bd_t *bd) __attribute__((weak,
alias("__ft_board_setup")));
diff --git a/include/asm-ppc/ppc4xx-ebc.h b/include/asm-ppc/ppc4xx-ebc.h
index d180e04..9680f70 100644
--- a/include/asm-ppc/ppc4xx-ebc.h
+++ b/include/asm-ppc/ppc4xx-ebc.h
@@ -35,7 +35,38 @@
#define CONFIG_EBC_PPC4xx_IBM_VER1
#endif
+/*
+ * Define the max number of EBC banks (chip selects)
+ */
+#if defined(CONFIG_405CR) || defined(CONFIG_405GP) || \
+defined(CONFIG_405EZ) || \
+defined(CONFIG_440GP) || defined(CONFIG_440GX)
+#define EBC_NUM_BANKS 8
+#endif
+
+#if defined(CONFIG_405EP)
+#define EBC_NUM_BANKS 5
+#endif
+
+#if defined(CONFIG_405EX) || \
+defined(CONFIG_460SX)
+#define EBC_NUM_BANKS 4
+#endif
+
+#if defined(CONFIG_440EP) || defined(CONFIG_440GR) || \
+defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \
+defined(CONFIG_460EX) || defined(CONFIG_460GT)
+#define EBC_NUM_BANKS 6
+#endif
+
+#if defined(CONFIG_440SP) || defined(CONFIG_440SPE)
+#define EBC_NUM_BANKS 3
+#endif
+
/* Bank Configuration Register */
+#define EBC_BXCR(n)(n)
+#define EBC_BXCR_BANK_SIZE(n) (0x10 << (((n) & EBC_BXCR_BS_MASK) >> 17))
+
#defineEBC_BXCR_BAS_MASK PPC_REG_VAL(11, 0xFFF)
#define EBC_BXCR_BAS_ENCODE(n) (((static_cast(u32, n)) & EBC_BXCR_BAS_MASK))
#define EBC_BXCR_BS_MASK PPC_REG_VAL(14, 0x7)
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/13 v3] ARM: OMAP3: Add NAND support
On Sat, Oct 11, 2008 at 10:55:37AM +0200, Dirk Behme wrote:
> >It's looking decent. I have some concerns about the ECC switching,
> >though.
>
> Yes, I know, agreed. But changing existing kernels isn't easy, too.
I meant the implementation (specifically, the re-init of things done by
nand_scan_tail()).
> >>+static unsigned char cs;
> >>+static void __iomem *gpmc_cs_base_add;
> >
> >
> >I'd prefer an actual data type rather than void, but I won't hold it up
> >for that.
>
> I took the data type of IO_ADDR_W & IO_ADDR_R where gpmc_cs_base_add
> is assigned to.
>
> void __iomem *IO_ADDR_W;
But the actual data is of a certain size, not void.
> >Is GPMC_BASE an integer or a pointer?
>
> Nothing. A macro:
>
> #define OMAP34XX_GPMC_BASE(0x6E00)
> #define GPMC_BASE (OMAP34XX_GPMC_BASE)
So it's an integer.
> It's then casted to volatile pointer by ARM's readx/writex.
The cast should be done by the driver, or you'll get warnings if
readx/writex ever become inline functions (as they are on other arches).
> >Make sure that anything that the generic layer calculates that would
> >change is updated (e.g. oobavail, read_page, write_page, read_oob,
> >write_oob).
>
> What about calling nand_scan_tail() for this? Proposal in attachment
> (omap_nand_switch_ecc()).
You'll leak chip->buffers. Better to factor nand_scan_tail() into two
functions, one which allocates memory and any other non-repeatable init,
and another which does init based on ECC type. The former function would
call the latter.
> +static void omap_nand_hwcontrol(struct mtd_info *mtd, int cmd,
> + unsigned int ctrl)
> +{
> + register struct nand_chip *this = mtd->priv;
The "register" keyword is superfluous when not specifying a specific
register (such as for use with inline assembly).
> + /* Check if calc_ecc corresponds to a blank page.
> + * If so, treat read_ecc as correct. See comment at omap_calculate_ecc.
> + */
> + if((*(unsigned int *)calc_ecc == 0x) &&
> +(*(unsigned int *)read_ecc == 0x))
> + return 0;
This assumes 32-bit alignment of the ECC -- and aren't there four
steps of 3 bytes each?
Also, not being overly familiar with ECC, is it possible for one or two
bit flips to cause the computed ECC to go from all-ones to all-zeroes?
If it is, then we may want to follow this up by checking the data.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc86xx: use r4 instead of r2 in lock_ram_in_cache and unlock_ram_in_cache
Dear Nick Spence, In message <[EMAIL PROTECTED]> you wrote: > This is needed in unlock_ram_in_cache() because it is called from C and > will corrupt the small data area anchor that is kept in R2. > > lock_ram_in_cache() is modified similarly as good coding practice, but > is not called from C. > > Signed-off-by: Nick Spence <[EMAIL PROTECTED]> > --- > cpu/mpc86xx/start.S |8 > 1 files changed, 4 insertions(+), 4 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: [EMAIL PROTECTED] GUIs are virtually useless. Learn tools. They're configurable, scriptable, automatable, cron-able, interoperable, etc. We don't need no brain-dead winslurping monolithic claptrap. -- Tom Christiansen in [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC86xx unapplied patches
On Mon, 2008-10-13 at 13:58 +0200, Wolfgang Denk wrote: > Dear Jon, > > In message <[EMAIL PROTECTED]> you wrote: > > > > > 6185 08/19 Kumar Gala [U-Boot] [PATCH] 86xx: remove redudant > > > code with lib_ppc/interrupts.c > > > 6767 08/28 Nick Spence[U-Boot] [PATCH] mpc86xx: use r4 instead > > > of r2 in lock_ram_in_cache a > > > > Sorry, got buried here. If these are still outstanding, > > please directly apply them. > > Understood, applied these two. Excellent! Thank you! > Let me know if there are more. I don't think so. Thanks, jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] Minor fixes for I2C address on MPC8572DS
On Fri, Oct 3, 2008 at 10:46 AM, Haiying Wang <[EMAIL PROTECTED]> wrote: > MPC8572DS has two i2c buses. This patch moves the DDR SPD_EEPROM to i2c bus 1 > according to the board spec, and adds the 2nd i2c bus offset. > > Signed-off-by: Haiying Wang <[EMAIL PROTECTED]> Applied 1-3, and they were pulled. :) Thanks, Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] Make DDR interleaving mode work correctly
On Fri, Oct 3, 2008 at 11:36 AM, Haiying Wang <[EMAIL PROTECTED]> wrote: > Fix some bugs: > 1. Correctly set intlv_ctl in cs_config. > 2. Correctly set sa, ea in cs_bnds when bank interleaving mode is enabled. > 3. Set base_address and total memory for each ddr controller in memory > controller interleaving mode. > > Signed-off-by: Haiying Wang <[EMAIL PROTECTED]> Applied 1-6 to 85xx-next with some modifications from Kumar, thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MPC8572DS: Fix compile warnings
On Wed, Oct 8, 2008 at 3:36 PM, Kumar Gala <[EMAIL PROTECTED]> wrote: > Commit 445a7b38308eb05b41de74165b20855db58c7ee5 introduced the following > compile warnings: > > cmd_i2c.c:112: warning: missing braces around initializer > cmd_i2c.c:112: warning: (near initialization for 'i2c_no_probes[0]') > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> Applied, thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Fix the incorrect DDR clk freq reporting on 8536DS
On Sat, Sep 27, 2008 at 1:40 AM, Jason Jin <[EMAIL PROTECTED]> wrote: > On 8536DS board, When the DDR clk is set async mode(SW3[6:8] != 111), > The display is still sync mode DDR freq. This patch try to fix > this. The display DDR freq is now the actual freq in both > sync and async mode. > > Signed-off-by: Jason Jin <[EMAIL PROTECTED]> Applied, thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] FSL: Fix get_cpu_board_revision() return value.
On Wed, Oct 8, 2008 at 6:41 AM, Rafal Czubak <[EMAIL PROTECTED]> wrote: > get_cpu_board_revision() returned board revision based on information stored > in global static struct eeprom. It should instead use one from local struct > board_eeprom, to which the data is actually read from EEPROM. The bug led to > system hang after printing L1 cache information on U-Boot startup. The problem > was observed on MPC8555CDS system and possibly affects other Freescale MPC85xx > boards using CFG_I2C_EEPROM_CCID. > > The change has been successfully tested on MPC8555CDS system. > > Signed-off-by: Rafal Czubak <[EMAIL PROTECTED]> Applied, thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] enable 10/100M at VSC8601 at tsec driver
On Sun, Oct 12, 2008 at 11:18 PM, Ben Warren <[EMAIL PROTECTED]> wrote: > Wolfgang Denk wrote: >> Dear Ben, >> >> In message <[EMAIL PROTECTED]> Andre Schwarz wrote: >> >>> Currently VSC8601 doesn't link with 10/100M partners if the >>> EEPROM/Strapping is not set up. >>> Setting the auto-neg register fixes this. >>> >> >> I think this patch was not added, nor was any feedback sent? >> > Sorry, that was the week after my daughter was born and it's all a > blur. This is innocuous and I'll pull it right away. Excuses, excuses! ;) Congratulations! Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH v4] bootm: Add sub commands
On Oct 8, 2008, at 8:48 PM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> * Use new find_cmd_tbl() to process sub-commands
>>
>> If this looks good I'll go ahead and clean it up for the other
>> arches and OSes.
>
> Hi Kumar,
>
> Thanks to your sequence hint, interrupt command hint, and one
> additional
> piece, I have this working now.
>
> The missing piece is reserving memory for the stack before copying the
> ramdisk to high mem. It looks like this was lost when you
> consolidated
> the machine-specific lib_*/bootm.c do_bootm_linux() functions into
> one.
> Without the reservation code, the copy overwrites the stack.
> Seriously bad karma.
>
> See below for a proof-of-concept hack.
>
>> ---
>> common/cmd_bootm.c | 142 -
>> include/image.h| 20 -
>> lib_ppc/bootm.c| 262 +
>> +--
>> 3 files changed, 330 insertions(+), 94 deletions(-)
>>
>> diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
>> index 19257bb..e6dcb7a 100644
>> --- a/common/cmd_bootm.c
>> +++ b/common/cmd_bootm.c
>> @@ -34,6 +34,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #if defined(CONFIG_CMD_USB)
>> @@ -273,7 +274,7 @@ static int bootm_start(cmd_tbl_t *cmdtp, int
>> flag, int argc, char *argv[])
>> }
>>
>> images.os.start = (ulong)os_hdr;
>> -images.valid = 1;
>> +images.state = BOOTM_STATE_START;
>>
>> return 0;
>> }
>> @@ -376,6 +377,113 @@ static int bootm_load_os(image_info_t os,
>> ulong *load_end, int boot_progress)
>> return 0;
>> }
>>
>> +/* we over load the cmd field with our state machine info instead
>> of a
>> + * function pointer */
>
> Nitpick: comment format and s/over load/overload/
> /*
> * We overload the cmd field with our state machine info instead of a
> * function pointer
> */
ack.
> [snip]
>
>> +int do_bootm_subcommand (cmd_tbl_t *cmdtp, int flag, int argc,
>> char *argv[])
>> +{
>
> [snip]
>
>>
>> @@ -782,6 +907,21 @@ U_BOOT_CMD(
>> "\tUse iminfo command to get the list of existing component\n"
>> "\timages and configurations.\n"
>> #endif
>> +"\nSub-commands to do part of the bootm sequence. The sub-
>> commands "
>> +"must be\n"
>> +"issued in the order below (its ok to not issue all sub-commands):
>> \n"
>
> s/its/it's/ (contraction "it is", not possessive like "his")
ack
>
>
>> +"\tstart [addr [arg ...]]\n"
>
> The following is more descriptive?
> start [(-|) []]
nack. I left this as is to match the bootm help
>> +"\tloados - load OS image\n"
>> +#if defined(CONFIG_PPC) || defined(CONFIG_M68K) ||
>> defined(CONFIG_SPARC)
>> +"\tramdisk - relocate initrd, set env initrd_start/initrd_end\n"
>> +#endif
>> +#if defined(CONFIG_OF_LIBFDT)
>> +"\tfdt - relocate flat device tree\n"
>> +#endif
>> +"\tbdt - OS specific bd_t processing\n"
>> +"\tcmdline - OS specific command line processing/setup\n"
>> +"\tprepos - OS specific prep before relocation or go\n"
>> +"\tgo - start OS\n"
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8555CDS broken on TOT (commit 8fd4166c, ELDK 4.2)
On Tue, Sep 23, 2008 at 5:05 AM, Bartlomiej Sieka <[EMAIL PROTECTED]> wrote: > Hello, > > TOT U-Boot (commit 8fd4166c, compiled with ELDK 4.2) for the MPC8555CDS > target is broken with the following symptoms: > > > [flash the 8fd4166c image and reset the board] > > U-Boot 2008.10-rc2-00018-g8fd4166 (Sep 23 2008 - 10:23:59) > > CPU: 8555E, Version: 1.1, (0x80790011) > Core: E500, Version: 2.0, (0x80200020) > Clock Configuration: >CPU: 825 MHz, CCB: 330 MHz, >DDR: 165 MHz (330 MT/s data rate), LBC: 82 MHz > CPM: 330 Mhz > L1:D-cache 32 kB enabled >I-cache 32 kB enabled > Board: CDS Version 0x11, PCI Slot 1 > CPU Board Revision 0.0 (0x) > PCI1: 32 bit, 33 MHz, sync > PCI2: 32 bit, 66 MHz, sync > I2C: ready > DRAM: Initializing > SDRAM: 64 MB > DDR: 256 MB > > > And the output stops here, console is dead. Can't give more details as > to what's going on the board -- don't have a HW debugger available. > > After a power-cycle, the board doesn't go as far as the first time after > reset: > > U-Boot 2008.10-rc2-00018-g8fd4166 (Sep 23 2008 - 10:23:59) > > CPU: 8555E, Version: 1.1, (0x80790011) > Core: E500, Version: 2.0, (0x80200020) > Clock Configuration: >CPU: 825 MHz, CCB: 330 MHz, >DDR: 165 MHz (330 MT/s data rate), LBC: 82 MHz > CPM: 330 Mhz > L1:D-cache 32 kB enabled >I-cache 32 kB enabled > > Subsequent power-cycles result in the same output, i.e., the output dies > after the "I-cache 32 kB enabled" line. > > The U-Boot works fine as of commit 71074abb, but can't do a full > bisection at the moment (can't flash the board easily). > > Brief search of the ML archives didn't reveal any such issue reported, > so I'm posting this as a data point, and in the hopes that someone can > take further investigation from here. I'll be happy to provide more > details if needed, and might also be able to test a potential fix. Did Rafal Czubak's patch solve your problem? Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5] bootm: Add sub commands
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
common/cmd_bootm.c | 149 -
include/image.h| 20 -
lib_ppc/bootm.c| 272 ++--
3 files changed, 347 insertions(+), 94 deletions(-)
* Added flushing the data cache in multicore cases so images are visible to
both cores
* Added an arch_lmb_reserve() as a way for arch's to reserve regions of memory
that shouldnt
get loaded on to (like the stack)
* fixed up some comments pointed by Jerry
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 19257bb..5a48111 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#if defined(CONFIG_CMD_USB)
@@ -128,6 +129,12 @@ void __board_lmb_reserve(struct lmb *lmb)
}
void board_lmb_reserve(struct lmb *lmb) __attribute__((weak,
alias("__board_lmb_reserve")));
+void __arch_lmb_reserve(struct lmb *lmb)
+{
+ /* please define platform specific arch_lmb_reserve() */
+}
+void arch_lmb_reserve(struct lmb *lmb) __attribute__((weak,
alias("__arch_lmb_reserve")));
+
#if defined(__ARM__)
#define IH_INITRD_ARCH IH_ARCH_ARM
#elif defined(__avr32__)
@@ -173,6 +180,7 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int
argc, char *argv[])
lmb_add(&images.lmb, (phys_addr_t)mem_start, mem_size);
+ arch_lmb_reserve(&images.lmb);
board_lmb_reserve(&images.lmb);
/* get kernel image header, start address and length */
@@ -273,7 +281,7 @@ static int bootm_start(cmd_tbl_t *cmdtp, int flag, int
argc, char *argv[])
}
images.os.start = (ulong)os_hdr;
- images.valid = 1;
+ images.state = BOOTM_STATE_START;
return 0;
}
@@ -376,6 +384,113 @@ static int bootm_load_os(image_info_t os, ulong
*load_end, int boot_progress)
return 0;
}
+/* we overload the cmd field with our state machine info instead of a
+ * function pointer */
+cmd_tbl_t cmd_bootm_sub[] = {
+ U_BOOT_CMD_MKENT(start, 0, 1, (void *)BOOTM_STATE_START, "", ""),
+ U_BOOT_CMD_MKENT(loados, 0, 1, (void *)BOOTM_STATE_LOADOS, "", ""),
+#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+ U_BOOT_CMD_MKENT(ramdisk, 0, 1, (void *)BOOTM_STATE_RAMDISK, "", ""),
+#endif
+#ifdef CONFIG_OF_LIBFDT
+ U_BOOT_CMD_MKENT(fdt, 0, 1, (void *)BOOTM_STATE_FDT, "", ""),
+#endif
+ U_BOOT_CMD_MKENT(bdt, 0, 1, (void *)BOOTM_STATE_OS_BD_T, "", ""),
+ U_BOOT_CMD_MKENT(cmdline, 0, 1, (void *)BOOTM_STATE_OS_CMDLINE, "", ""),
+ U_BOOT_CMD_MKENT(prep, 0, 1, (void *)BOOTM_STATE_OS_PREP, "", ""),
+ U_BOOT_CMD_MKENT(go, 0, 1, (void *)BOOTM_STATE_OS_GO, "", ""),
+};
+
+int do_bootm_subcommand (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ int ret = 0;
+ int state;
+ cmd_tbl_t *c;
+
+ c = find_cmd_tbl(argv[1], &cmd_bootm_sub[0], ARRAY_SIZE(cmd_bootm_sub));
+
+ if (c) {
+ state = (int)c->cmd;
+
+ /* treat start special since it resets the state machine */
+ if (state == BOOTM_STATE_START) {
+ argc--;
+ argv++;
+ return bootm_start(cmdtp, flag, argc, argv);
+ }
+ }
+ /* Unrecognized command */
+ else {
+ printf ("Usage:\n%s\n", cmdtp->usage);
+ return 1;
+ }
+
+ if (images.state >= state) {
+ printf ("Trying to execute a command out of order\n");
+ printf ("Usage:\n%s\n", cmdtp->usage);
+ return 1;
+ }
+
+ images.state |= state;
+
+ switch (state) {
+ ulong load_end;
+ case BOOTM_STATE_START:
+ /* should never occur */
+ break;
+ case BOOTM_STATE_LOADOS:
+ ret = bootm_load_os(images.os, &load_end, 0);
+ if (ret)
+ return ret;
+
+ lmb_reserve(&images.lmb, images.os.load,
+ (load_end - images.os.load));
+ break;
+#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_SPARC)
+ case BOOTM_STATE_RAMDISK:
+ {
+ ulong rd_len = images.rd_end - images.rd_start;
+ char str[17];
+
+ ret = boot_ramdisk_high(&images.lmb, images.rd_start,
+ rd_len, &images.initrd_start,
&images.initrd_end);
+ if (ret)
+ return ret;
+
+ sprintf(str, "%lx", images.initrd_start);
+ setenv("initrd_start", str);
+ sprintf(str, "%lx", images.initrd_end);
+ setenv("initrd_end", str);
+ }
+ break;
[U-Boot] [PATCH] 74xx/7xx/86xx: Rename flush_data_cache to flush_dcache to match 85xx version
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- cpu/74xx_7xx/cache.S | 10 +- cpu/mpc86xx/cache.S | 10 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/cpu/74xx_7xx/cache.S b/cpu/74xx_7xx/cache.S index eac4544..62a6683 100644 --- a/cpu/74xx_7xx/cache.S +++ b/cpu/74xx_7xx/cache.S @@ -52,7 +52,7 @@ _GLOBAL(invalidate_l1_data_cache) /* * Flush data cache. */ -_GLOBAL(flush_data_cache) +_GLOBAL(flush_dcache) lis r3,0 lis r5,CACHE_LINE_SIZE flush: @@ -303,12 +303,12 @@ _GLOBAL(dcache_enable) /* * Disable data cache(s) - L1 and optionally L2 - * Calls flush_data_cache and l2cache_disable_no_flush. + * Calls flush_dcache and l2cache_disable_no_flush. * LR saved in r4 */ _GLOBAL(dcache_disable) mflrr4 /* save link register */ - bl flush_data_cache/* uses r3 and r5 */ + bl flush_dcache/* uses r3 and r5 */ sync mfspr r3, HID0 li r5, HID0_DCFI|HID0_DLOCK @@ -389,11 +389,11 @@ _GLOBAL(l2cache_enable) /* * Disable L2 cache - * Calls flush_data_cache. LR is saved in r4 + * Calls flush_dcache. LR is saved in r4 */ _GLOBAL(l2cache_disable) mflrr4 /* save link register */ - bl flush_data_cache/* uses r3 and r5 */ + bl flush_dcache/* uses r3 and r5 */ sync mtlrr4 /* restore link register */ l2cache_disable_no_flush: /* provide way to disable L2 w/o flushing */ diff --git a/cpu/mpc86xx/cache.S b/cpu/mpc86xx/cache.S index 80ff688..dd38806 100644 --- a/cpu/mpc86xx/cache.S +++ b/cpu/mpc86xx/cache.S @@ -53,7 +53,7 @@ _GLOBAL(invalidate_l1_data_cache) /* * Flush data cache. */ -_GLOBAL(flush_data_cache) +_GLOBAL(flush_dcache) lis r3,0 lis r5,CACHE_LINE_SIZE flush: @@ -290,12 +290,12 @@ _GLOBAL(dcache_enable) /* * Disable data cache(s) - L1 and optionally L2 - * Calls flush_data_cache and l2cache_disable_no_flush. + * Calls flush_dcache and l2cache_disable_no_flush. * LR saved in r4 */ _GLOBAL(dcache_disable) mflrr4 /* save link register */ - bl flush_data_cache/* uses r3 and r5 */ + bl flush_dcache/* uses r3 and r5 */ sync mfspr r3, HID0 li r5, HID0_DCFI|HID0_DLOCK @@ -363,11 +363,11 @@ _GLOBAL(l2cache_enable) /* * Disable L2 cache - * Calls flush_data_cache. LR is saved in r4 + * Calls flush_dcache. LR is saved in r4 */ _GLOBAL(l2cache_disable) mflrr4 /* save link register */ - bl flush_data_cache/* uses r3 and r5 */ + bl flush_dcache/* uses r3 and r5 */ sync mtlrr4 /* restore link register */ l2cache_disable_no_flush: /* provide way to disable L2 w/o flushing */ -- 1.5.5.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH v4] bootm: Add sub commands
On Oct 8, 2008, at 8:48 PM, Jerry Van Baren wrote: > Kumar Gala wrote: >> * Use new find_cmd_tbl() to process sub-commands >> >> If this looks good I'll go ahead and clean it up for the other >> arches and OSes. > > Hi Kumar, > > Thanks to your sequence hint, interrupt command hint, and one > additional > piece, I have this working now. > > The missing piece is reserving memory for the stack before copying the > ramdisk to high mem. It looks like this was lost when you > consolidated > the machine-specific lib_*/bootm.c do_bootm_linux() functions into > one. > Without the reservation code, the copy overwrites the stack. > Seriously bad karma. > > See below for a proof-of-concept hack. I think my solution is a bit cleaner for us (adding arch_lmb_reserve). Take a look and see how that works for you. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_pci_init do not scan bus when configured as an end-point
On Wed, Oct 8, 2008 at 11:38 PM, Ed Swarthout <[EMAIL PROTECTED]> wrote: > Signed-off-by: Ed Swarthout <[EMAIL PROTECTED]> Acked-by: Andy Fleming <[EMAIL PROTECTED]> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pixis do not print long help if not configured
On Wed, Oct 8, 2008 at 11:38 PM, Ed Swarthout <[EMAIL PROTECTED]> wrote: > Signed-off-by: Ed Swarthout <[EMAIL PROTECTED]> Applied to 85xx-next ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx if NUM_CPUS>1, print cpu number
On Wed, Oct 8, 2008 at 11:37 PM, Ed Swarthout <[EMAIL PROTECTED]> wrote: > Signed-off-by: Ed Swarthout <[EMAIL PROTECTED]> Applied to 85xx-next ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3] mpc8572 additional end-point mode
On Thu, Oct 9, 2008 at 12:29 AM, Ed Swarthout <[EMAIL PROTECTED]> wrote: > mpc8572 supports all pcie controllers as end-points with cfg_host_agent=0. > Include host_agent == 0 decode for end-point determination. > > This is not needed for the ds reference board since pcie3 will be a host > in order to connect to the uli chip. Include it here as a reference for > other mpc8572 boards. > > Signed-off-by: Ed Swarthout <[EMAIL PROTECTED]> Applied to 85xx-next, thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_law clear enable before changing.
On Thu, Oct 9, 2008 at 1:25 AM, Ed Swarthout <[EMAIL PROTECTED]> wrote: > Debug sessions may have left enabled laws. > Changing lawbar with an unkown enabled tgtid could cause problems. > > Signed-off-by: Ed Swarthout <[EMAIL PROTECTED]> Applied to 85xx-next ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx do not reset PIC if already configured
On Thu, Oct 9, 2008 at 1:26 AM, Ed Swarthout <[EMAIL PROTECTED]> wrote: > This allows a second core to restart without causing a PIC reset. > > Internal interupt changes: > Enable L2 error interrupt IIVPR0 and give it vector 0x100. > Use correct interrupt (8) for mpc8572 pcie3. > Add pcie3 interrupt (11) for mpc8536ds. > > Signed-off-by: Ed Swarthout <[EMAIL PROTECTED]> Hrm. There's a notable increase in #ifdefs, here. It might be time to add some CONFIG values to make this scale for future parts. As it is, the values being written to the iivprs are awfully magical. It might also be time to define some constants for those bitfields. Whatever makes sense for making it fairly easy to see what's happening at a high level, and to extend it next time the hardware designers change the interrupt numbers on us. :) Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_pci_init do not scan bus when configured as an end-point
On Mon, 2008-10-13 at 14:14 -0500, Andy Fleming wrote: > On Wed, Oct 8, 2008 at 11:38 PM, Ed Swarthout > <[EMAIL PROTECTED]> wrote: > > Signed-off-by: Ed Swarthout <[EMAIL PROTECTED]> > > Acked-by: Andy Fleming <[EMAIL PROTECTED]> When agent/end-point, I thought the CPU must enable inbound PCI configuration cycles by poking the PBFR Register (offset 0x44) for PCI, or the Configuration Ready Register (offset 0x4b0 for PCIe) after configuring its own inbound BARs. I believe without these PCI config writes, the agent/end-point device will not be able to be enumerated by the PCI/PCIe host/root-comples as any config cycle to the device will be retried. Would it make sense to add the unlocking of inbound PCI configuration cycles with this patch, or as a separate one? I have some basic code to do this, but wasn't sure of a clean way to determine if an interface is PCI or PCIe to determine how the interface should be unlocked (ie, the patch is a bit "dirty":). Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Denali ddr controlle: how i can reset?
Hi ML, i'm working on a SoC (mips based) that uses a denali ddr2 controller. I noticed that also ppc4xx uses the same IP (or it's very similar). I have a stupid trouble: i need to do a software reset of the denali, but I cannot reconfigure it twice... losting the ddr memory space. Of course, at the first time the configuration is ok... Does anyone have information about this controller (I have just the registers list...) or have noticed the same problem? Thanks in advance, ciao luigi -- Luigi 'Comio' Mantellini R&D - Software Industrie Dial Face S.p.A. Via Canzo, 4 20068 Peschiera Borromeo (MI), Italy Tel.: +39 02 5167 2813 Fax: +39 02 5167 2459 web: www.idf-hit.com mail: [EMAIL PROTECTED] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add cpu/8xxx to TAGS_SUBDIRS
On Wed, Oct 8, 2008 at 11:38 PM, Ed Swarthout <[EMAIL PROTECTED]> wrote: > > Signed-off-by: Ed Swarthout <[EMAIL PROTECTED]> Applied to 85xx-next ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_pci_init do not scan bus when configured as an end-point
Dear Ed Swarthout, In message <[EMAIL PROTECTED]> you wrote: > Signed-off-by: Ed Swarthout <[EMAIL PROTECTED]> > --- > drivers/pci/fsl_pci_init.c | 17 +++-- > 1 files changed, 15 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: [EMAIL PROTECTED] "There are things that are so serious that you can only joke about them"- Heisenberg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] flash: factor out adjusting of Flash address to the end of sector
Dear Stefan Roese, In message <[EMAIL PROTECTED]> you wrote: > > OK, I added this patch [1/6] to the u-boot-cfi-flash next branch. Here the > pull > request for the *next* branch: > > The following changes since commit 8fd4166c467a46773f80208bda1ec3b4757747bc: > Stefan Roese (1): > ppc4xx: Canyonlands: Remove unnecessary FDT warning upon DTB fixup > > are available in the git repository at: > > git://www.denx.de/git/u-boot-cfi-flash.git next > > Bartlomiej Sieka (1): > flash: factor out adjusting of Flash address to the end of sector > > common/cmd_flash.c | 75 > +--- > include/flash.h|1 + > 2 files changed, 43 insertions(+), 33 deletions(-) Thanks. Applied to "next" branch. 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: [EMAIL PROTECTED] People are always a lot more complicated than you think. It's very important to remember that. - Terry Pratchett, _Truckers_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/6] flash: factor out adjusting of Flash address to the end of sector
Dear Ben Warren, In message <[EMAIL PROTECTED]> you wrote: > > You can pull net/next now if you'd like. I'm not able to generate a > pull request from here, so if you need that you'll have to wait maybe 10 > or 11 hours. Done. Pulled into "next" branch. 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: [EMAIL PROTECTED] Power is danger. -- The Centurion, "Balance of Terror", stardate 1709.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/6] Automatic software update from TFTP server
Dear Bartlomiej Sieka, In message <[EMAIL PROTECTED]> you wrote: > The auto-update feature allows to automatically download software updates > from a TFTP server and store them in Flash memory during boot. Updates are > contained in a FIT file and protected with SHA-1 checksum. > > More detailed description can be found in doc/README.update. > > Signed-off-by: Rafal Czubak <[EMAIL PROTECTED]> > Signed-off-by: Bartlomiej Sieka <[EMAIL PROTECTED]> > --- > README | 12 ++ > common/Makefile |1 + > common/main.c |7 + > common/update.c | 315 > +++ > doc/README.update | 90 +++ > doc/uImage.FIT/update3.its | 41 + > doc/uImage.FIT/update_uboot.its | 21 +++ > 7 files changed, 487 insertions(+), 0 deletions(-) > create mode 100644 common/update.c > create mode 100644 doc/README.update > create mode 100644 doc/uImage.FIT/update3.its > create mode 100644 doc/uImage.FIT/update_uboot.its Applied to "next" branch. 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: [EMAIL PROTECTED] Syntactic sugar causes cancer of the semicolon. - Epigrams in Programming, ACM SIGPLAN Sept. 1982 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Make pixis_set_sgmii more general to support MPC85xx boards.
On Thu, Oct 9, 2008 at 10:40 PM, Jason Jin <[EMAIL PROTECTED]> wrote: > From: Liu Yu <[EMAIL PROTECTED]> > > The pixis sgmii command depend on the FPGA support on the board, some 85xx > boards support SGMII riser card but did not support this command, define > CONFIG_PIXIS_SGMII_CMD for those boards which support the sgmii command. > > Not like 8544, 8572 has 4 eTsec so that the other two's pixis bits > are not supported by 8544. Therefor, define PIXIS_VSPEED2_MASK and > PIXIS_VCFGEN1_MASK in header file for both boards. > > Signed-off-by: Liu Yu <[EMAIL PROTECTED]> Applied to 85xx-next ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Automatic software updates in U-Boot -- version 2
Dear Bartek, in message <[EMAIL PROTECTED]> you wrote: > > This is the second version of the patch series adding support for automatic > software updates from a TFTP server. V2 adds millisecond granularity of the > TFTP timeouts and addresses comments posted to the ML for the first version. > > First three patches make some general changes required by the new feature, > first one in the Flash subsystem, second and third in the networking code. > Then follows a minor clean-up, with the feature proper in fifth patch. Last > patch provides minor enhancements to the iminfo output that can become handy > when using the new feature. > > Please see newly added doc/README.update for more details. > > Code has been compile-tested on several ppc, arm and mips targets. The feature > itself has been tested on TQM8555 and MPC8555CDS and trab boards. All patches have been checked in into the "next" branch of the U-Boot repository. Can you please check if everything is correct in place and working as expected? Thanks in advance. 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: [EMAIL PROTECTED] Certain old men prefer to rise at dawn, taking a cold bath and a long walk with an empty stomach and otherwise mortifying the flesh. They then point with pride to these practices as the cause of their sturdy health and ripe years; the truth being that they are hearty and old, not because of their habits, but in spite of them. The reason we find only robust persons doing this thing is that it has killed all the others who have tried it. - Ambrose Bierce, "The Devil's Dictionary" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] Enabled the Freescale SGMII riser card on 8572DS
On Thu, Oct 9, 2008 at 10:40 PM, Jason Jin <[EMAIL PROTECTED]> wrote: > From: Liu Yu <[EMAIL PROTECTED]> > > This patch based on Andy's work. > Including command 'pixis_set_sgmii' support. > > Signed-off-by: Liu Yu <[EMAIL PROTECTED]> Applied to 85xx-next ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] Enabled the Freescale SGMII riser card on 8536DS
On Thu, Oct 9, 2008 at 10:41 PM, Jason Jin <[EMAIL PROTECTED]> wrote: > Signed-off-by: Jason Jin <[EMAIL PROTECTED]> Applied to 85xx-next Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_pci_init do not scan bus when configuredas an end-point
From: Peter Tyser [mailto:[EMAIL PROTECTED] > > When agent/end-point, I thought the CPU must enable inbound > PCI configuration cycles by poking the PBFR Register (offset > 0x44) for PCI, or the Configuration Ready Register (offset > 0x4b0 for PCIe) after configuring its own inbound BARs. That is true if any of the CPUs are allowed to boot immediately after hreset. If all the CPUs have boot-holdoff set, hardware will enable inbound config. > I believe without these PCI config writes, the agent/end-point > device will not be able to be enumerated by the PCI/PCIe > host/root-comples as any config cycle to the device will be > retried. True. > Would it make sense to add the unlocking of inbound PCI > configuration cycles with this patch, or as a separate one? Separate. Are there use cases where this should not be done in u-boot, but postponed until Linux is booted? > I have some basic code to do this, but wasn't sure of a clean > way to determine if an interface is PCI or PCIe to determine > how the interface should be unlocked (ie, the patch is a bit > "dirty":). I'm not sure of the best way for this determination. It looks like a non-zero value for the "PCI Express Capability ID Register" at 4c can be use to detect PCIe. -Ed ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/11 v1] ARM: OMAP3: Add assembly startup and sys_info common files
Dear Dirk,
In message <[EMAIL PROTECTED]> you wrote:
>
> Wolfgang Denk wrote:
> > Dear Dirk Behme,
>
> Just Dirk ;)
Sorry, my MUA is not that clever (yet). And in many cases I don't
have time enough to manually edit this. [If you have a clever
replcomps setup (i. e. more clever than "Dear %(friendly {from}),")
that would be definitely welcome.]
> > Instead, we might probably have just a "cpu/arm_cortexa8/" with common
> > code for "omap3" and "xxx" ?
>
> Hmm, sorry, I'm not sure I completely understood.
>
> Do you want to say that you want a directory "cpu/arm_cortexa8/" where
> the common files for Corex-A8 CPUs are located and then a directory
> "cpu/arm_cortexa8/omap3" where the OMAP3 common stuff is stored?
Yes.
> If this is correct, from theory I completely agree. *But*: From
> practical point of view regarding the patch we are talking about here,
> we just don't know what Corex-A8 CPU common code might be. As I know
> there is no "xxx" (with xxx != OMAP3) yet, so it's hard to know what
> will be common. So we moved all OMAP3 common code for all three buards
> we currently support to omap3 directory.
You are a pessimist. You think everything is OMAP3 specific.
I am an optimist. I think everything is common code. At least that's
the way it should be :-)
So my suggestion is to put all code into cpu/arm_cortexa8/, unless
you are not absolutely sure that some file is strictly
cpu/arm_cortexa8/omap3 only.
If this assessment later turns out to be wrong, it is much easier to
split the file into SoC specific parts that to factor out the common
parts from N different SoC implementations.
> So for the time being, I propose to create /cpu/arm_cortexa8/omap3
> with all files in this directory and no files in /cpu/arm_cortexa8
> yet. This can change later, files from omap3/ can move to
> /cpu/arm_cortexa8/ when we get more Cortex-A8 SoCs/chips and get an
> idea what might be common.
Nope. I disagree. Thjsi way will cause much more maitnenance effort
and result in lots of duplicated code.
> But my question here was if we can do directory moves/renames in git
> after/while patch is applied or if new patches with directory changes
> are needed on mailing list? Directory move/rename is easy in git,
> while doing this with patches to mailing list may result in
> unnecessary traffic.
It makes no difference. Just make sure to tell git to create patches
that contain renames. See options like '-M' and '-C' to
git-format-patch.
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: [EMAIL PROTECTED]
We're all sorry for the other guy when he loses his job to a machine.
But when it comes to your job -- that's different. And it always will
be different.
-- McCoy, "The Ultimate Computer", stardate 4729.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] Convert MPC85xx platforms to a single linker script
This patch series does $SUBJ. The first patch changes the way the existing linker scripts locate the boot page, reset vector, and bss section. This method works for any size of u-boot image (the previous one didn't work images that weren't 512K) and any location flash is mapped to. At this point all the mpc85xx linker scripts are exactly the same, except for one line that defines the flash bank size, so they are combined into one script in cpu/mpc85xx/u-boot.lds. A common flash bank size that will work for all boards is used. If a board in the future needs something different (either very small flash or a very large u-boot), then it can easily be overridden by using a two line board/*/config.mk file that defines the flash bank size and then includes cpu/mpc85xx/u-boot.lds. The next two patches clean up the common boot script some more. I imagine there is more cruft in the script still, like the .data.init and .text.init sections that are 256 byte aligned but have nothing in them. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Convert MPC85xx platforms to a single linker script
Dear Trent, In message <[EMAIL PROTECTED]> you wrote: > > At this point all the mpc85xx linker scripts are exactly the same, except for > one line that defines the flash bank size, so they are combined into one > script in cpu/mpc85xx/u-boot.lds. A common flash bank size that will work for > all boards is used. If a board in the future needs something different Umm... This is not how it should be done. U-Boot should *never* assume static flash bank sizes. The whole design is based on the idea to automatically determine the actual size of flash and RAM that is fit on a specific board, and to auto-adjust for this. There are many vendors out there who manufacture boards in different memory configurations. For these it is essential that they can use only one U-Boot image on all boards, no matter what the exact memory configuration of this board is. I am aware that there are ports out there which violate this design principle, but if we touch this area, thenplease only to make more boards conformant, not to make things worse. 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: [EMAIL PROTECTED] Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] Improve mpc85xx link script rodata section
A recent gcc added a new unaligned rodata section called '.rodata.str1.1'
and that needs to be added the the linker script.
Rather than just add that one section, instead use '*(.rodata*)' to catch
that section and any future rodata sections.
'*(.rodata*)' by itself will result in sub-optimal section ordering. The
section will be sorted by object file, which causes extra padding between
the unaligned rodata.str.1.1 of one object file and the aligned rotdata of
the next object file. This is easy to fix by using the SORT_BY_ALIGNMENT
command.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
cpu/mpc85xx/u-boot.lds |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/cpu/mpc85xx/u-boot.lds b/cpu/mpc85xx/u-boot.lds
index 404606a..f7aedc0 100644
--- a/cpu/mpc85xx/u-boot.lds
+++ b/cpu/mpc85xx/u-boot.lds
@@ -84,10 +84,8 @@ SECTIONS
PROVIDE (etext = .);
.rodata:
{
-*(.rodata)
-*(.rodata1)
-*(.rodata.str1.4)
*(.eh_frame)
+*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
} :text
.fini : { *(.fini)} =0
.ctors : { *(.ctors) }
--
1.5.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] Merge all mpc85xx platforms to use a single ld script
They are all the same except for the flash size and some copyright
comments.
The combined script assumes a flash bank size of 4 MB, which work for all
current platforms. This assumtion is only a problem if:
A) The flash bank is less than 4 MB and it is mapped to a location that not
aligned to the top of a 4 MB boundary. E.g., a 1 MB bank mapped to
0xefff is ok, but if it were mapped at 0xeffd then it would be a
problem.
B) The U-Boot image is over 4MB in size. The image size for this is from
TEXT_BASE to the end of the reset vector. It's not the size of the U-Boot
code as there could be a huge gap between the end of the code and the reset
vector. The BSS section does not count for this size, as it goes after the
reset vector (and it not actually present in the image). This should be
the same as the size of the u-boot.bin file.
If someone ever has one of these problems, they can create a custom
ld script that overrides the flash bank size and then just include
the common mpc85xx script. It would look something like this:
__flash_mask = 2M - 1;/* For a 2MB flash bank */
INCLUDE cpu/mpc85xx/u-boot.lds
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
board/freescale/mpc8536ds/u-boot.lds | 144 -
board/freescale/mpc8540ads/u-boot.lds | 147 -
board/freescale/mpc8541cds/u-boot.lds | 144 -
board/freescale/mpc8544ds/u-boot.lds | 145 -
board/freescale/mpc8548cds/u-boot.lds | 144 -
board/freescale/mpc8555cds/u-boot.lds | 144 -
board/freescale/mpc8560ads/u-boot.lds | 147 -
board/freescale/mpc8568mds/u-boot.lds | 144 -
board/freescale/mpc8572ds/u-boot.lds | 144 -
cpu/mpc85xx/config.mk |3 +
cpu/mpc85xx/u-boot.lds| 163 +
11 files changed, 166 insertions(+), 1303 deletions(-)
delete mode 100644 board/freescale/mpc8536ds/u-boot.lds
delete mode 100644 board/freescale/mpc8540ads/u-boot.lds
delete mode 100644 board/freescale/mpc8541cds/u-boot.lds
delete mode 100644 board/freescale/mpc8544ds/u-boot.lds
delete mode 100644 board/freescale/mpc8548cds/u-boot.lds
delete mode 100644 board/freescale/mpc8555cds/u-boot.lds
delete mode 100644 board/freescale/mpc8560ads/u-boot.lds
delete mode 100644 board/freescale/mpc8568mds/u-boot.lds
delete mode 100644 board/freescale/mpc8572ds/u-boot.lds
create mode 100644 cpu/mpc85xx/u-boot.lds
diff --git a/board/freescale/mpc8536ds/u-boot.lds
b/board/freescale/mpc8536ds/u-boot.lds
deleted file mode 100644
index 05c8d4d..000
--- a/board/freescale/mpc8536ds/u-boot.lds
+++ /dev/null
@@ -1,144 +0,0 @@
-/*
- * Copyright 2008 Freescale Semiconductor, Inc.
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-OUTPUT_ARCH(powerpc)
-/* Do we need any of these for elf?
- __DYNAMIC = 0;*/
-PHDRS
-{
- text PT_LOAD;
- bss PT_LOAD;
-}
-
-SECTIONS
-{
- /* Read-only sections, merged into text segment: */
- . = + SIZEOF_HEADERS;
- .interp : { *(.interp) }
- .hash : { *(.hash) }
- .dynsym: { *(.dynsym)}
- .dynstr: { *(.dynstr)}
- .rel.text : { *(.rel.text) }
- .rela.text : { *(.rela.text) }
- .rel.data : { *(.rel.data) }
- .rela.data : { *(.rela.data) }
- .rel.rodata: { *(.rel.rodata)}
- .rela.rodata : { *(.rela.rodata) }
- .rel.got : { *(.rel.got) }
- .rela.got : { *(.rela.got) }
- .rel.ctors : { *(.rel.ctors) }
- .rela.ctors: { *(.rela.ctors)}
- .rel.dtors : { *(.rel.dtors) }
- .rela.dtors: { *(.rela.dtors)}
- .rel.bss : { *(.rel.bss) }
- .rela.bss : { *(.rela.bss) }
- .rel.plt : { *(.rel.plt) }
- .rela.plt : { *(.rela.plt) }
- .init : { *(.init) }
- .plt : { *(.plt) }
- .text :
- {
-*(.text)
-*(.fixup)
-*(.got1)
- } :text
-_etext = .;
-PRO
[U-Boot] [PATCH 4/4] Use ALIGN() in mpc85xx linker script
It wasn't used in one instance where the end of the rotext section is
aligned to 256 bytes.
Maybe this alignment isn't necessary? I have to wonder about the alignment
of the .data.init and .text.init sections too, since they don't appear to
even exist.
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
cpu/mpc85xx/u-boot.lds |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cpu/mpc85xx/u-boot.lds b/cpu/mpc85xx/u-boot.lds
index f7aedc0..8af35da 100644
--- a/cpu/mpc85xx/u-boot.lds
+++ b/cpu/mpc85xx/u-boot.lds
@@ -92,7 +92,7 @@ SECTIONS
.dtors : { *(.dtors) }
/* Read-write section, merged into data segment: */
- . = (. + 0x00FF) & 0xFF00;
+ . = ALIGN(0x100);
_erotext = .;
PROVIDE (erotext = .);
.reloc :
--
1.5.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] Use absolute addressing for mpc85xx boot page
The boot page and reset vector need to be at the absolute address
0xf000 and 0xfffc, respectively, when the CPU boots.
However, their location in the U-Boot image is relative to the address that
flash is mapped at. For instance, mpc8572ds maps the 128MB flash boot bank
to 0xe800, which means the boot page is at 0xe000 in the U-Boot
image.
Currently the linker scripts use ADDR(.text) + 0x7f000 to location the boot
page, but this only works if .text starts 512kB from the end of the flash
window, e.g. TEXT_BASE is 0xeff8 for mpc8572ds. If TEXT_BASE is
somewhere else, such as when creating a 256kB image, the boot page will be
at the wrong location.
To handle to both different U-Boot image sizes and flash locations, what we
do is take the upper bits of the boot page from the location of .text and
the lower bits are taken from the absolute address 0xf000. How many
bits to take depends on the size of the flash bank. In effect the upper
bits come from the location of the flash bank in the CPU address space and
the lower bits come from the fixed location of the boot page within the
flash bank.
The bss segment should go after the end of the u-boot image. Which is only
at the fixed address 0 for platforms that don't remap flash. For those
that do it's somewhere else, e.g. on mpc8572ds it's at 0xf000. The
easiest way to locate bss is to say it starts 4k after the boot page, since
we already put that in the final 4k of the image.
Since this part of the linker script is the same for all mpc85xx targets,
maybe it should be placed into an include file instead of duplicated?
Signed-off-by: Trent Piepho <[EMAIL PROTECTED]>
---
board/freescale/mpc8536ds/u-boot.lds | 11 +--
board/freescale/mpc8540ads/u-boot.lds | 11 +--
board/freescale/mpc8541cds/u-boot.lds | 11 +--
board/freescale/mpc8544ds/u-boot.lds | 12 ++--
board/freescale/mpc8548cds/u-boot.lds | 11 +--
board/freescale/mpc8555cds/u-boot.lds | 11 +--
board/freescale/mpc8560ads/u-boot.lds | 11 +--
board/freescale/mpc8568mds/u-boot.lds | 11 +--
board/freescale/mpc8572ds/u-boot.lds | 11 +--
9 files changed, 46 insertions(+), 54 deletions(-)
diff --git a/board/freescale/mpc8536ds/u-boot.lds
b/board/freescale/mpc8536ds/u-boot.lds
index 901f633..05c8d4d 100644
--- a/board/freescale/mpc8536ds/u-boot.lds
+++ b/board/freescale/mpc8536ds/u-boot.lds
@@ -118,21 +118,20 @@ SECTIONS
. = ALIGN(256);
__init_end = .;
- .bootpg ADDR(.text) + 0x7f000 :
+ __flash_mask = 128M - 1;
+ .bootpg (ADDR(.text) & ~(__flash_mask)) | (0xf000 & __flash_mask) :
{
cpu/mpc85xx/start.o(.bootpg)
} :text = 0x
- .resetvec ADDR(.text) + 0x7fffc :
+ .resetvec ADDR(.bootpg) + 0xffc :
{
*(.resetvec)
} :text = 0x
- . = ADDR(.text) + 0x8;
-
- __bss_start = .;
- .bss (NOLOAD) :
+ .bss ADDR(.bootpg) + 0x1000 (NOLOAD) :
{
+ __bss_start = ABSOLUTE(.);
*(.sbss) *(.scommon)
*(.dynbss)
*(.bss)
diff --git a/board/freescale/mpc8540ads/u-boot.lds
b/board/freescale/mpc8540ads/u-boot.lds
index 515d320..2148e12 100644
--- a/board/freescale/mpc8540ads/u-boot.lds
+++ b/board/freescale/mpc8540ads/u-boot.lds
@@ -121,21 +121,20 @@ SECTIONS
. = ALIGN(256);
__init_end = .;
- .bootpg ADDR(.text) + 0x7f000 :
+ __flash_mask = 16M - 1;
+ .bootpg (ADDR(.text) & ~(__flash_mask)) | (0xf000 & __flash_mask) :
{
cpu/mpc85xx/start.o(.bootpg)
} :text = 0x
- .resetvec ADDR(.text) + 0x7fffc :
+ .resetvec ADDR(.bootpg) + 0xffc :
{
*(.resetvec)
} :text = 0x
- . = ADDR(.text) + 0x8;
-
- __bss_start = .;
- .bss (NOLOAD) :
+ .bss ADDR(.bootpg) + 0x1000 (NOLOAD) :
{
+ __bss_start = ABSOLUTE(.);
*(.sbss) *(.scommon)
*(.dynbss)
*(.bss)
diff --git a/board/freescale/mpc8541cds/u-boot.lds
b/board/freescale/mpc8541cds/u-boot.lds
index d728d8b..13ec8bf 100644
--- a/board/freescale/mpc8541cds/u-boot.lds
+++ b/board/freescale/mpc8541cds/u-boot.lds
@@ -118,21 +118,20 @@ SECTIONS
. = ALIGN(256);
__init_end = .;
- .bootpg ADDR(.text) + 0x7f000 :
+ __flash_mask = 8M - 1; /* Flash bank is 8 MB */
+ .bootpg (ADDR(.text) & ~(__flash_mask)) | (0xf000 & __flash_mask) :
{
cpu/mpc85xx/start.o(.bootpg)
} :text = 0x
- .resetvec ADDR(.text) + 0x7fffc :
+ .resetvec ADDR(.bootpg) + 0xffc :
{
*(.resetvec)
} :text = 0x
- . = ADDR(.text) + 0x8;
-
- __bss_start = .;
- .bss (NOLOAD) :
+ .bss ADDR(.bootpg) + 0x1000 (NOLOAD) :
{
+ __bss_start = ABSOLUTE(.);
*(.sbss) *(.scommon)
*(.dynbss)
*(.bss)
diff --git a/board/freescale/mpc8544ds/u-boot.lds
b/board/freescale/mpc8544ds/u-boot.lds
index a05ece5..10a333b 100644
--- a/board/freescale/mpc8544ds/u-boot.lds
+++ b/board/freescale/mpc8544ds/u-boot.lds
@@ -118,21 +118,21 @@ SECTIONS
. = ALIGN(256);
__init_end = .;
-
Re: [U-Boot] [PATCH 0/4] Convert MPC85xx platforms to a single linker script
On Tue, 14 Oct 2008, Wolfgang Denk wrote: > Dear Trent, > > In message <[EMAIL PROTECTED]> you wrote: >> >> At this point all the mpc85xx linker scripts are exactly the same, except for >> one line that defines the flash bank size, so they are combined into one >> script in cpu/mpc85xx/u-boot.lds. A common flash bank size that will work >> for >> all boards is used. If a board in the future needs something different > > Umm... This is not how it should be done. > > U-Boot should *never* assume static flash bank sizes. The whole > design is based on the idea to automatically determine the actual > size of flash and RAM that is fit on a specific board, and to > auto-adjust for this. The bank size here is only used for linking u-boot. The actual u-boot code is no different that it is now. In order to boot on mpc85xx, the u-boot image must be linked to locate the boot page as the last page in the flash bank. There is no way to do this at run time, it's the boot page. All existing 85xx platforms hard code the location of the boot page in the u-boot image one way or another. I'm just changing the linker script to do it in a way where the same script will work on all 85xx boards. Right now changing the u-boot image size and/or the boot flash bank mapping requires changes to the linker script. Since not all boards have the same image size and/or flash bank mapping, they can't use the same script. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: fix PCI scan hang on the standalone MPC837xE-MDS boards
On Thu, 2 Oct 2008 19:17:33 +0400 Anton Vorontsov <[EMAIL PROTECTED]> wrote: > The MPC837xE-MDS board's CPLD can auto-detect if the board is on the PIB, > standalone or acting as a PCI agent. User's Guide says: > > - When the CPLD recognizes its location on the PIB it automatically > configures RCW to the PCI Host. > - If the CPLD fails to recognize its location then it is automatically > configured as an Agent and the PCI is configured to an external arbiter. > > This sounds good. Though in the standalone setup the CPLD sets PCI_HOST > flag (it's ok, we can't act as PCI agents since we receive CLKIN, not > PCICLK), but the CPLD doesn't set the ARBITER_ENABLE flag, and without > any arbiter bad things will happen (here the board hangs during any config > space reads). > > In this situation we must disable the PCI. And in case of anybody really > want to use an external arbiter, we provide "pci_external_aribter" > environment variable. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> applied to mpc83xx/next. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: add ELBC NAND support for the MPC837XEMDSboards
On Wed, 8 Oct 2008 21:26:34 -0700 "Liu Dave-R63238" <[EMAIL PROTECTED]> wrote: > It is due to hardware design and logic defect, that is the > I/O[0:7] of NAND chip is connected to LAD[7:0], so when > the NAND chip connected to nLCS3, you have to set up the > OR3[BCTLD] = '1' for normal operation, otherwise it will have > bus contention due to the pin 48/25 of U60 is enabled. > > Setup the OR3[BCTLD] = '1' , that meaning the LBCTL is not > asserted upon access to the NAND chip, keep the default state. > > Acked-by: Dave Liu <[EMAIL PROTECTED]> > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Anton Vorontsov > > Sent: 2008?10?9? 12:53 AM > > To: Phillips Kim-R1AAHA > > Cc: u-boot@lists.denx.de > > Subject: [U-Boot] [PATCH] mpc83xx: add ELBC NAND support for > > the MPC837XEMDSboards > > > > Though NAND chip is replaceable on the MPC837XE-MDS boards, the > > current settings don't work with the default chip on the board. > > Nevertheless Freescale's U-Boot sets the option register correctly, > > so I just dumped the register from the working u-boot. My guess is > > that the old settings were applicable for some pilot boards, not > > found in the production. > > > > This patch also enables FSL ELBC driver so that we could access > > the NAND storage in the u-boot. > > > > The NAND support costs about 45KB, so the u-boot no longer fits > > into two 128KB NOR flash sectors, thus we also have to adjust > > environment location: add another 128KB to the monitor length. > > > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> applied to 83xx-next. thanks guys, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Wait till UPM completes the write to array.
On Thu, 9 Oct 2008 10:29:14 +0530 Selvamuthukumar <[EMAIL PROTECTED]> wrote: > Reference manual states that MxMR[MAD] increment is the indication > of write to UPM array is complete. Honour that. Also, make the dummy > write explicit. > > Signed-off-by: Selvamuthukumar <[EMAIL PROTECTED]> > --- > Ignore the previous patch. Sequence of doing things were wroing in > that. applied to mpc83xx/next. Thanks, Kim p.s. prepending your Subject lines with "mpc83xx: " makes your mpc83xx-destined patches easier to spot. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: mpc8360emds: rework LBC SDRAM setup
On Mon, 13 Oct 2008 14:40:02 +0200 Wolfgang Denk <[EMAIL PROTECTED]> wrote: > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > > --- > > board/freescale/mpc8360emds/mpc8360emds.c | 39 > > - > > include/configs/MPC8360EMDS.h | 25 -- > > 2 files changed, 38 insertions(+), 26 deletions(-) > > I think this patch was not added, nor was any feedback sent? It had slipped whilst I was migrating to a new mailer, sorry. Anton, feel free to ping me in case something like this happens again. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: mpc8360emds: rework LBC SDRAM setup
On Wed, 10 Sep 2008 18:12:37 +0400 Anton Vorontsov <[EMAIL PROTECTED]> wrote: > Currently 64M of LBC SDRAM are mapped at 0xF000 which makes > it difficult to use (b/c then the memory is discontinuous and > there is quite big memory hole between the DDR/SDRAM regions). > > This patch reworks LBC SDRAM setup so that now we dynamically > place the LBC SDRAM near the DDR (or at 0x0 if there isn't any > DDR memory). > > With this patch we're able to: > > - Boot without external DDR memory; > - Use most "DDR + SDRAM" setups without need to support for > sparse/discontinuous memory model in the software. > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > --- applied to mpc83xx/next. Thanks, and sorry for the delay - this must've slipped during an email migration I did recently. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] SGMII support for MPC8378E-MDS boards
On Thu, 2 Oct 2008 18:31:17 +0400 Anton Vorontsov <[EMAIL PROTECTED]> wrote: > Hi all, > > Here are the updated patches. > > v2: > - Addressed Andy Fleming's comments. Now we don't need the exported > tsec_info struct. applied 1-4 to mpc83xx/next. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH v4] bootm: Add sub commands
Kumar Gala wrote: > > On Oct 8, 2008, at 8:48 PM, Jerry Van Baren wrote: > >> Kumar Gala wrote: >>> * Use new find_cmd_tbl() to process sub-commands >>> >>> If this looks good I'll go ahead and clean it up for the other arches >>> and OSes. >> >> Hi Kumar, >> >> Thanks to your sequence hint, interrupt command hint, and one additional >> piece, I have this working now. >> >> The missing piece is reserving memory for the stack before copying the >> ramdisk to high mem. It looks like this was lost when you consolidated >> the machine-specific lib_*/bootm.c do_bootm_linux() functions into one. >> Without the reservation code, the copy overwrites the stack. >> Seriously bad karma. >> >> See below for a proof-of-concept hack. > > I think my solution is a bit cleaner for us (adding arch_lmb_reserve). > Take a look and see how that works for you. > > - k Oh yes, my hack was just to verify that reserving the stack space solved my problem. It was not a solution. Thanks, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] Do not init SATA when disabled on 8536DS.
On Oct 9, 2008, at 10:41 PM, Jason Jin wrote: > SGMII and SATA share the serdes on MPC8536 CPU, When SATA disabled > and the > driver still try to access the SATA registers, the cpu will hangup. > This patch try to fix this by reading the serdes status before the > SATA > initialize. > > Signed-off-by: Jason Jin <[EMAIL PROTECTED]> > --- > board/freescale/mpc8536ds/mpc8536ds.c | 12 > lib_ppc/board.c | 16 ++-- > 2 files changed, 26 insertions(+), 2 deletions(-) Wolfgang, I think this was a patch for v2008.10.. Andy was looking for you to ack or apply. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] Do not init SATA when disabled on 8536DS.
On Mon, Oct 13, 2008 at 8:49 PM, Kumar Gala <[EMAIL PROTECTED]> wrote: > > On Oct 9, 2008, at 10:41 PM, Jason Jin wrote: > >> SGMII and SATA share the serdes on MPC8536 CPU, When SATA disabled >> and the >> driver still try to access the SATA registers, the cpu will hangup. >> This patch try to fix this by reading the serdes status before the >> SATA >> initialize. >> >> Signed-off-by: Jason Jin <[EMAIL PROTECTED]> Acked-by: Andy Fleming <[EMAIL PROTECTED]> Wolfgang, if you want, I can apply this to my master branch, and push it out for 2008-10. Whichever is more convenient for you. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sh: rsk7203: Add smc911x driver support to board config file
Signed-off-by: Nobuhiro Iwamatsu <[EMAIL PROTECTED]> --- include/configs/rsk7203.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/configs/rsk7203.h b/include/configs/rsk7203.h index d99e4f3..1f20e57 100644 --- a/include/configs/rsk7203.h +++ b/include/configs/rsk7203.h @@ -104,4 +104,9 @@ #define CMT_CLK_DIVIDER32 /* 8 (default), 32, 128 or 512 */ #define CFG_HZ (CONFIG_SYS_CLK_FREQ / CMT_CLK_DIVIDER) +/* Network interface */ +#define CONFIG_DRIVER_SMC911X +#define CONFIG_DRIVER_SMC911X_16_BIT +#define CONFIG_DRIVER_SMC911X_BASE (0x2400) + #endif /* __RSK7203_H */ -- 1.5.6.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] mpc8572ds relocatable
From: Wolfgang Denk [mailto:[EMAIL PROTECTED] > > NAK. > > Sorry, this doesn't work. We cannot have one board compile > this way, and another one another way - one working with that > tool chain and the other with another tool chain only. Is there a list of the toolchains that -mrelocatable must be tested against for each board? > The problem you're addressing is a bug, and not only on this > single board, but everywhere. So it must be fixed everywhere. > > Either we add manual relocation to these pointers like > we do elsewhere (that would be my recommendation for a > quick workaround aka bug fix for this release), or we should > find a clean way to get real relocation working (that would > be much better, but probably it is too late for this release). I know of pointers in structures in cmd_mii.c and image.c that need relocation, but how many more are there? And where should the manual relocation code reside? I think the effort should be applied to making sure the toolchain can work with relocatable instead. In my testing of this patch, I found a crash with the Radeon driver because the x86emu code forces entries into got2 - which get double relocated when using -mrelocatedable. See: [PATCH 1/2] Make mpc8572ds, mpc8544ds, mpc8536ds relocatable [PATCH 2/2] Leave x86emu op code tables in default section Here: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/48102 For a new version of this patch. -Ed ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] mpc8572ds relocatable
From: Joakim Tjernlund [mailto:[EMAIL PROTECTED] > > The __eabi_uconvert() function skips NULL ptrs. > > Perhaps this is the missing piece needed in start.S for PPC? I'm not seeing any zeros in the .got2 or .fixup entries in the .reloc section on 85xx when compiling with -mrelocatable. So I don't think that would help. -Ed ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-sh
Dear Wolfgang, Please pull u-boot-sh. Best regards, Nobuhiro The following changes since commit b3ed233198c5ac54aa83dd51f05fcb44ee75f42b: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-cfi-flash are available in the git repository at: git://git.denx.de/u-boot-sh.git master Nobuhiro Iwamatsu (2): sh: Fix cannot execute a stand-alone application sh: rsk7203: Add smc911x driver support to board config file examples/stubs.c |6 -- include/configs/rsk7203.h |5 + 2 files changed, 9 insertions(+), 2 deletions(-) -- Nobuhiro Iwamatsu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-boot] [PATCHv2 1/2] NET: QE: UEC: Make uec_miiphy_read() and uec_miiphy_write() use the devname arg.
richardretanubun wrote: > richardretanubun wrote: > >> The current uec_miiphy_read and uec_miiphy_write hardcode access >> devlist[0] >> This patch makes these function use the devname argument that is >> passed in to >> allow access to the phy registers of other devices in devlist[]. >> >> Signed-of-by: Richard Retanubun <[EMAIL PROTECTED]> >> --- >> Hi Ben, >> >> I'm hoping the 7th try will do it. I forgot to add the commit message >> before. > [snip] > > > Hi Ben, > Apologies for nagging, just checking if you get a chance to > re-re-re-apply my 7th attempt? :) > > Gratefully-Embarrassed, > > - Richard > > Applied to net/next. Lucky #7 cheers, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] [83xx] Adds two more ethernet interface to 83xx
richardretanubun wrote:
> Fixed compiler warning "declared but unused" eth5_uec_info and
> eth6_uec_info.
> Signed-off-by: Richard Retanubun <[EMAIL PROTECTED]>
> ---
> Hi Ben,
>
> Thanks for applying the patch. I got a compiler warning when using it,
> here is a patch to fix that.
>
> Thanks for all the help
>
> Richard
>
> drivers/qe/uec.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
> index e1dec5e..582a1c0 100644
> --- a/drivers/qe/uec.c
> +++ b/drivers/qe/uec.c
> @@ -1414,6 +1414,14 @@ int uec_initialize(int index)
> #ifdef CONFIG_UEC_ETH4
> uec_info = ð4_uec_info;
> #endif
> +} else if (index == 4) {
> +#ifdef CONFIG_UEC_ETH5
> +uec_info = ð5_uec_info;
> +#endif
> +} else if (index == 5) {
> +#ifdef CONFIG_UEC_ETH6
> +uec_info = ð6_uec_info;
> +#endif
> } else {
> printf("%s: index is illegal.\n", __FUNCTION__);
> return -EINVAL;
Applied to net/next
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request - net
Wolfgang, The following changes since commit b3ed233198c5ac54aa83dd51f05fcb44ee75f42b: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-cfi-flash are available in the git repository at: git://git.denx.de/u-boot-net master Andre Schwarz (1): enable 10/100M at VSC8601 at tsec driver Louis Su (1): AX88180: new gigabit network driver Nobuhiro Iwamatsu (1): net: ne2000: Divided a function of NE2000 driver drivers/net/Makefile |7 +- drivers/net/ax88180.c | 727 +++ drivers/net/ax88180.h | 412 drivers/net/ax88796.c |2 +- drivers/net/ne2000.c | 719 +-- drivers/net/ne2000_base.c | 757 + drivers/net/ne2000_base.h | 36 ++- drivers/net/tsec.c|2 + 8 files changed, 1939 insertions(+), 723 deletions(-) create mode 100644 drivers/net/ax88180.c create mode 100644 drivers/net/ax88180.h create mode 100644 drivers/net/ne2000_base.c regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM926EJ-S: relocate OMAP specific 'cpuinfo.c' into OMAP directory
OMAP identification is implemented in 'cpuinfo.c' and located in
ARM926EJ-S directory. It makes sense to place this file in OMAP
specific subdirectory, i.e. cpu/arm926ejs/omap
Signed-off-by: Roman Mashak <[EMAIL PROTECTED]>
---
cpu/arm926ejs/Makefile |2 +-
cpu/arm926ejs/cpuinfo.c | 242 ---
cpu/arm926ejs/omap/Makefile |2 +-
3 files changed, 2 insertions(+), 244 deletions(-)
diff --git a/cpu/arm926ejs/Makefile b/cpu/arm926ejs/Makefile
index 0facce4..d5ac7d3 100644
--- a/cpu/arm926ejs/Makefile
+++ b/cpu/arm926ejs/Makefile
@@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(CPU).a
START = start.o
-COBJS = interrupts.o cpu.o cpuinfo.o
+COBJS = interrupts.o cpu.o
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
diff --git a/cpu/arm926ejs/cpuinfo.c b/cpu/arm926ejs/cpuinfo.c
deleted file mode 100644
index 35ba7db..000
--- a/cpu/arm926ejs/cpuinfo.c
+++ /dev/null
@@ -1,242 +0,0 @@
-/*
- * OMAP1 CPU identification code
- *
- * Copyright (C) 2004 Nokia Corporation
- * Written by Tony Lindgren <[EMAIL PROTECTED]>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include
-#include
-#include
-
-#if defined(CONFIG_DISPLAY_CPUINFO) && defined(CONFIG_OMAP)
-
-#define omap_readw(x) *(volatile unsigned short *)(x)
-#define omap_readl(x) *(volatile unsigned long *)(x)
-
-#define OMAP_DIE_ID_0 0xfffe1800
-#define OMAP_DIE_ID_1 0xfffe1804
-#define OMAP_PRODUCTION_ID_0 0xfffe2000
-#define OMAP_PRODUCTION_ID_1 0xfffe2004
-#define OMAP32_ID_00xfffed400
-#define OMAP32_ID_10xfffed404
-
-struct omap_id {
- u16 jtag_id;/* Used to determine OMAP type */
- u8 die_rev;/* Processor revision */
- u32 omap_id;/* OMAP revision */
- u32 type; /* Cpu id bits [31:08], cpu class bits [07:00]
*/
-};
-
-/* Register values to detect the OMAP version */
-static struct omap_id omap_ids[] = {
- { .jtag_id = 0xb574, .die_rev = 0x2, .omap_id = 0x03310315, .type =
0x0310},
- { .jtag_id = 0x355f, .die_rev = 0x0, .omap_id = 0x0332, .type =
0x07300100},
- { .jtag_id = 0xb55f, .die_rev = 0x0, .omap_id = 0x0332, .type =
0x07300300},
- { .jtag_id = 0xb470, .die_rev = 0x0, .omap_id = 0x03310100, .type =
0x1510},
- { .jtag_id = 0xb576, .die_rev = 0x0, .omap_id = 0x0332, .type =
0x1610},
- { .jtag_id = 0xb576, .die_rev = 0x2, .omap_id = 0x03320100, .type =
0x1611},
- { .jtag_id = 0xb576, .die_rev = 0x3, .omap_id = 0x03320100, .type =
0x16100c00},
- { .jtag_id = 0xb576, .die_rev = 0x0, .omap_id = 0x03320200, .type =
0x16100d00},
- { .jtag_id = 0xb613, .die_rev = 0x0, .omap_id = 0x03320300, .type =
0x1610ef00},
- { .jtag_id = 0xb613, .die_rev = 0x0, .omap_id = 0x03320300, .type =
0x1610ef00},
- { .jtag_id = 0xb576, .die_rev = 0x1, .omap_id = 0x03320100, .type =
0x1611},
- { .jtag_id = 0xb58c, .die_rev = 0x2, .omap_id = 0x03320200, .type =
0x16110b00},
- { .jtag_id = 0xb58c, .die_rev = 0x3, .omap_id = 0x03320200, .type =
0x16110c00},
- { .jtag_id = 0xb65f, .die_rev = 0x0, .omap_id = 0x03320400, .type =
0x16212300},
- { .jtag_id = 0xb65f, .die_rev = 0x1, .omap_id = 0x03320400, .type =
0x16212300},
- { .jtag_id = 0xb65f, .die_rev = 0x1, .omap_id = 0x03320500, .type =
0x16212300},
- { .jtag_id = 0xb5f7, .die_rev = 0x0, .omap_id = 0x0333, .type =
0x1710},
- { .jtag_id = 0xb5f7, .die_rev = 0x1, .omap_id = 0x03330100, .type =
0x1710},
- { .jtag_id = 0xb5f7, .die_rev = 0x2, .omap_id = 0x03330100, .type =
0x1710},
-};
-
-/*
- * Get OMAP type from PROD_ID.
- * 1710 has the PROD_ID in bits 15:00, not in 16:01 as documented in TRM.
- * 1510 PROD_ID is empty, and 1610 PROD_ID does not make sense.
- * Undocumented register in TEST BLOCK is used as fallback; This seems to
- * work on 1510, 1610 & 1710. The official way hopefully will work in future
- * processors.
- */
-static u16 omap_get_jtag_id(void)
-{
- u32 prod_id, omap_id;
-
- prod_id = omap_readl(OMAP_PRODUCTION_ID_1);
- omap_id = omap_readl(OMAP32_ID_1);
-
- /* Check for unusable OMAP_PRODUCTION_ID_1 on 1611B/5912 and 730 */
- if (((prod_id >> 20) == 0) || (prod_id == omap_id))
- prod_id = 0;
- else
- prod_id &= 0x;
-
- if (prod_id)
- return prod_id;
-
- /* Use OMAP32_ID_1 as fallback */
- prod_id = ((omap_id >> 12) & 0x);
-
- return prod_id;
-}
-
-/*
- * Get OMAP revision from DIE_REV.
- * Early 1710 processors may have broken OMAP_DIE_ID, it contains PROD_ID.
- * Undocumented register in the TEST BLOCK is used as fallba
[U-Boot] [PATCH] mpc83xx: Fix the wrong comment.
--- cpu/mpc83xx/cpu.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cpu/mpc83xx/cpu.c b/cpu/mpc83xx/cpu.c index 63aa8a4..697482c 100644 --- a/cpu/mpc83xx/cpu.c +++ b/cpu/mpc83xx/cpu.c @@ -124,8 +124,8 @@ int checkcpu(void) * The 'dummy' variable is used to increment the MAD. 'dummy' is * supposed to be a pointer to the memory of the device being * programmed by the UPM. The data in the MDR is written into - * memory and the MAD is incremented every time there's a read - * from 'dummy'. Unfortunately, the current prototype for this + * memory and the MAD is incremented every time there's a write + * to 'dummy'. Unfortunately, the current prototype for this * function doesn't allow for passing the address of this * device, and changing the prototype will break a number lots * of other code, so we need to use a round-about way of finding -- 1.5.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
