[U-Boot] [PATCH 3/5] readline(): Add ability to modify a string buffer
If the 'buf' parameter is a non-0-length string, its contents will be
edited. Previously, the initial value of 'buf' was ignored and the
user entered its contents from scratch.
Signed-off-by: Peter Tyser
---
common/main.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/common/main.c b/common/main.c
index b47e443..10d8904 100644
--- a/common/main.c
+++ b/common/main.c
@@ -720,6 +720,10 @@ static int cread_line(const char *const prompt, char *buf,
unsigned int *len)
int insert = 1;
int esc_len = 0;
char esc_save[8];
+ int init_len = strlen(buf);
+
+ if (init_len)
+ cread_add_str(buf, init_len, 1, &num, &eol_num, buf, *len);
while (1) {
#ifdef CONFIG_BOOT_RETRY_TIME
@@ -937,6 +941,12 @@ static int cread_line(const char *const prompt, char *buf,
unsigned int *len)
*/
int readline (const char *const prompt)
{
+ /*
+* If console_buffer isn't 0-length the user will be prompted to modify
+* it instead of entering it from scratch as desired.
+*/
+ console_buffer[0] = '\0';
+
return readline_into_buffer(prompt, console_buffer);
}
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] cread_line(): Remove unused variables
Signed-off-by: Peter Tyser
---
common/main.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/common/main.c b/common/main.c
index 298982a..b47e443 100644
--- a/common/main.c
+++ b/common/main.c
@@ -715,16 +715,13 @@ static int cread_line(const char *const prompt, char
*buf, unsigned int *len)
{
unsigned long num = 0;
unsigned long eol_num = 0;
- unsigned long rlen;
unsigned long wlen;
char ichar;
int insert = 1;
int esc_len = 0;
- int rc = 0;
char esc_save[8];
while (1) {
- rlen = 1;
#ifdef CONFIG_BOOT_RETRY_TIME
while (!tstc()) { /* while no incoming data */
if (retry_time >= 0 && get_ticks() > endtime)
@@ -923,7 +920,7 @@ static int cread_line(const char *const prompt, char *buf,
unsigned int *len)
cread_add_to_hist(buf);
hist_cur = hist_add_idx;
- return (rc);
+ return 0;
}
#endif /* CONFIG_CMDLINE_EDITING */
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] Check for NULL prompt in readline_into_buffer()
Previously, passing readline() or readline_into_buffer() a NULL 'prompt' parameter would result in puts() printing garbage when CONFIG_CMDLINE_EDITING was enabled. Signed-off-by: Peter Tyser --- common/main.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/common/main.c b/common/main.c index 026edd1..298982a 100644 --- a/common/main.c +++ b/common/main.c @@ -964,7 +964,8 @@ int readline_into_buffer (const char *const prompt, char * buffer) initted = 1; } - puts (prompt); + if (prompt) + puts (prompt); rc = cread_line(prompt, p, &len); return rc < 0 ? rc : len; -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] Add check for ECC errors during SDRAM POST and mtest
Add a CONFIG_CHECK_ECC_ERRORS define which causes the SDRAM POST and
mtest command to check for ECC errors during execution.
The 85xx and 86xx architectures currently support enabling
CONFIG_CHECK_ECC_ERRORS. Other architectures/boards can use it if they
implement an ecc_count() and ecc_info() function.
Signed-off-by: Peter Tyser
---
common/cmd_mem.c | 10 ++
cpu/mpc8xxx/ddr/Makefile |2 +-
cpu/mpc8xxx/ddr/ecc.c|4
include/common.h |6 ++
post/drivers/memory.c|5 +
5 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index a34b342..efedf79 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -691,6 +691,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
__FUNCTION__, __LINE__, start, end);
for (;;) {
+#ifdef CONFIG_CHECK_ECC_ERRORS
+ if (ecc_count())
+ ecc_info();
+#endif
+
if (ctrlc()) {
putc ('\n');
return 1;
@@ -917,6 +922,11 @@ int do_mem_mtest (cmd_tbl_t *cmdtp, int flag, int argc,
char *argv[])
#else /* The original, quickie test */
incr = 1;
for (;;) {
+#ifdef CONFIG_CHECK_ECC_ERRORS
+ if (ecc_count())
+ ecc_info();
+#endif
+
if (ctrlc()) {
putc ('\n');
return 1;
diff --git a/cpu/mpc8xxx/ddr/Makefile b/cpu/mpc8xxx/ddr/Makefile
index f073779..935d72a 100644
--- a/cpu/mpc8xxx/ddr/Makefile
+++ b/cpu/mpc8xxx/ddr/Makefile
@@ -22,7 +22,7 @@ COBJS-$(CONFIG_FSL_DDR3) += main.o util.o ctrl_regs.o
options.o \
lc_common_dimm_params.o
COBJS-$(CONFIG_FSL_DDR3) += ddr3_dimm_params.o
-COBJS-$(CONFIG_DDR_ECC_CMD)+= ecc.o
+COBJS-$(CONFIG_DDR_ECC)+= ecc.o
SRCS := $(START:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
diff --git a/cpu/mpc8xxx/ddr/ecc.c b/cpu/mpc8xxx/ddr/ecc.c
index bc80d7c..9db5cef 100644
--- a/cpu/mpc8xxx/ddr/ecc.c
+++ b/cpu/mpc8xxx/ddr/ecc.c
@@ -21,6 +21,7 @@
*/
#include
+#if (defined(CONFIG_DDR_ECC_CMD) || defined(CONFIG_CHECK_ECC_ERRORS))
#include
#if defined(CONFIG_MPC85xx)
#include
@@ -279,7 +280,9 @@ void ecc_info(void)
in_be32(&ddr[controller]->err_sbe) & ~0xff);
}
}
+#endif /* CONFIG_DDR_ECC_CMD || CONFIG_CHECK_ECC_ERRORS */
+#ifdef CONFIG_DDR_ECC_CMD
static int do_ecc(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
{
static uint controller = 0;
@@ -369,3 +372,4 @@ U_BOOT_CMD(ecc, 5, 0, do_ecc,
"ecc inject off\n"
"\t- disable error injection\n"
);
+#endif /* CONFIG_DDR_ECC_CMD */
diff --git a/include/common.h b/include/common.h
index 7df9afa..b9e0fb1 100644
--- a/include/common.h
+++ b/include/common.h
@@ -556,6 +556,12 @@ intprt_8260_rsr (void);
intprt_83xx_rsr (void);
#endif
+/* $(CPU)/ecc.c */
+#ifdef CONFIG_CHECK_ECC_ERRORS
+void ecc_info(void);
+int ecc_count(void);
+#endif
+
/* $(CPU)/interrupts.c */
intinterrupt_init (void);
void timer_interrupt(struct pt_regs *);
diff --git a/post/drivers/memory.c b/post/drivers/memory.c
index 0062360..b8bbac5 100644
--- a/post/drivers/memory.c
+++ b/post/drivers/memory.c
@@ -477,6 +477,11 @@ int memory_post_test (int flags)
}
}
+#ifdef CONFIG_CHECK_ECC_ERRORS
+ if (ecc_count())
+ printf("WARNING: %d ECC errors detected!!\n", ecc_count());
+#endif
+
return ret;
}
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] 8xxx: Add 'ecc' command
Add a new 'ecc' command to interact with the 85xx and 86xx DDR ECC
registers. The 'ecc' command can inject data/ECC errors to simulate
errors and provides an 'info' subcommand which displays ECC error
information such as failure address, read vs expected data/ECC,
physical signal which failed, single-bit error count, and multiple bit
error occurrence. An example of the 'ecc info' command follows:
WARNING: ECC error in DDR Controller 0
Addr: 0x0_01001000
Data: 0x0001_ ECC:0x00
Expect: 0x_ ECC:0x00
Net:DATA32
Syndrome: 0xce
Single-Bit errors: 0x40
Attrib: 0x30112001
Detect: 0x8004 (MME, SBE)
Signed-off-by: Peter Tyser
Signed-off-by: John Schmoller
---
This code was tested on a 8572, 8640, and P2020. A board with a
32-bit data bus was not tested however.
cpu/mpc8xxx/ddr/Makefile |2 +
cpu/mpc8xxx/ddr/ecc.c| 371 ++
include/asm-ppc/immap_85xx.h |4 +
include/asm-ppc/immap_86xx.h |3 +
4 files changed, 380 insertions(+), 0 deletions(-)
create mode 100644 cpu/mpc8xxx/ddr/ecc.c
diff --git a/cpu/mpc8xxx/ddr/Makefile b/cpu/mpc8xxx/ddr/Makefile
index cb7f856..f073779 100644
--- a/cpu/mpc8xxx/ddr/Makefile
+++ b/cpu/mpc8xxx/ddr/Makefile
@@ -22,6 +22,8 @@ COBJS-$(CONFIG_FSL_DDR3) += main.o util.o ctrl_regs.o
options.o \
lc_common_dimm_params.o
COBJS-$(CONFIG_FSL_DDR3) += ddr3_dimm_params.o
+COBJS-$(CONFIG_DDR_ECC_CMD)+= ecc.o
+
SRCS := $(START:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
diff --git a/cpu/mpc8xxx/ddr/ecc.c b/cpu/mpc8xxx/ddr/ecc.c
new file mode 100644
index 000..bc80d7c
--- /dev/null
+++ b/cpu/mpc8xxx/ddr/ecc.c
@@ -0,0 +1,371 @@
+/*
+ * Copyright 2009 Extreme Engineering Solutions, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#if defined(CONFIG_MPC85xx)
+#include
+#elif defined(CONFIG_MPC86xx)
+#include
+#endif
+
+/* Provide a common define for DDR addresses on 85xx/86xx */
+#if defined(CONFIG_MPC85xx)
+#define MPC8xxx_DDR_ADDR CONFIG_SYS_MPC85xx_DDR_ADDR
+#define MPC8xxx_DDR2_ADDR CONFIG_SYS_MPC85xx_DDR2_ADDR
+#elif defined(CONFIG_MPC86xx)
+#define MPC8xxx_DDR_ADDR CONFIG_SYS_MPC86xx_DDR_ADDR
+#define MPC8xxx_DDR2_ADDR CONFIG_SYS_MPC86xx_DDR2_ADDR
+#else
+#error "ECC not supported on this platform"
+#endif
+
+/*
+ * Taken from table 8-55 in the MPC8641 User's Manual and/or 9-61 in the
+ * MPC8572 User's Manual. Each line represents a syndrome bit column as a
+ * 64-bit value, but split into an upper and lower 32-bit chunk. The labels
+ * below correspond to Freescale's manuals.
+ */
+static unsigned int ecc_table[16] = {
+ /* MSB LSB */
+ /* [0:31][32:63] */
+ 0xf00fe11e, 0xc33c0ff7, /* Syndrome bit 7 */
+ 0x00ff00ff, 0x00fff0ff,
+ 0x0f0f0f0f, 0x0f0fff00,
+ 0x, 0x000f,
+ 0x, 0x222f,
+ 0x, 0x4441,
+ 0x, 0x8882,
+ 0x, 0x1114, /* Syndrome bit 0 */
+};
+
+/*
+ * Calculate the correct ECC value for a 64-bit integer specified by high:low
+ */
+static uint8_t calculate_ecc(uint32_t high, uint32_t low)
+{
+ uint32_t mask_low;
+ uint32_t mask_high;
+ int bit_cnt;
+ uint8_t ecc = 0;
+ int i;
+ int j;
+
+ for (i = 0; i < 8; i++) {
+ mask_high = ecc_table[i * 2];
+ mask_low = ecc_table[i * 2 + 1];
+ bit_cnt = 0;
+
+ for (j = 0; j < 32; j++) {
+ if ((mask_high >> j) & 1)
+ bit_cnt ^= (high >> j) & 1;
+ if ((mask_low >> j) & 1)
+ bit_cnt ^= (low >> j) & 1;
+ }
+
+ ecc |= bit_cnt << i;
+ }
+
+ return ecc;
+}
+
+/*
+ * Create the syndrome code which is generated if the data line specified by
+ * 'bit'
[U-Boot] [PATCH 4/5] xes: Enable memory POST
Note that SPRG4 is used to store U-Boot's post 'word'.
Signed-off-by: Peter Tyser
---
board/xes/common/Makefile|1 +
board/xes/common/fsl_8xxx_post.c | 36
include/configs/XPEDITE5170.h|1 +
include/configs/XPEDITE5200.h|1 +
include/configs/XPEDITE5370.h|1 +
5 files changed, 40 insertions(+), 0 deletions(-)
create mode 100644 board/xes/common/fsl_8xxx_post.c
diff --git a/board/xes/common/Makefile b/board/xes/common/Makefile
index d022831..b6297ed 100644
--- a/board/xes/common/Makefile
+++ b/board/xes/common/Makefile
@@ -33,6 +33,7 @@ COBJS-$(CONFIG_FSL_PCI_INIT) += fsl_8xxx_pci.o
COBJS-$(CONFIG_MPC8572)+= fsl_8xxx_clk.o
COBJS-$(CONFIG_MPC86xx)+= fsl_8xxx_clk.o
COBJS-$(CONFIG_FSL_DDR2) += fsl_8xxx_ddr.o
+COBJS-$(CONFIG_HAS_POST) += fsl_8xxx_post.o
COBJS-$(CONFIG_NAND_ACTL) += actl_nand.o
SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
diff --git a/board/xes/common/fsl_8xxx_post.c b/board/xes/common/fsl_8xxx_post.c
new file mode 100644
index 000..179f970
--- /dev/null
+++ b/board/xes/common/fsl_8xxx_post.c
@@ -0,0 +1,36 @@
+/*
+ * Copyright 2008 Extreme Engineering Solutions, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+
+int post_hotkeys_pressed(void) {
+ return 0;
+}
+
+void post_word_store(ulong a) {
+ mtspr(SPRG4, a);
+}
+
+ulong post_word_load(void) {
+ return mfspr(SPRG4);
+}
diff --git a/include/configs/XPEDITE5170.h b/include/configs/XPEDITE5170.h
index f7615db..6967754 100644
--- a/include/configs/XPEDITE5170.h
+++ b/include/configs/XPEDITE5170.h
@@ -107,6 +107,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy);
#define CONFIG_SYS_ALT_MEMTEST
#define CONFIG_SYS_MEMTEST_START 0x1000
#define CONFIG_SYS_MEMTEST_END 0x2000
+#define CONFIG_POST(CONFIG_SYS_POST_MEMORY)
/*
* Memory map
diff --git a/include/configs/XPEDITE5200.h b/include/configs/XPEDITE5200.h
index bc28b61..ca333b7 100644
--- a/include/configs/XPEDITE5200.h
+++ b/include/configs/XPEDITE5200.h
@@ -90,6 +90,7 @@
#define CONFIG_SYS_ALT_MEMTEST
#define CONFIG_SYS_MEMTEST_START 0x1000
#define CONFIG_SYS_MEMTEST_END 0x2000
+#define CONFIG_POST(CONFIG_SYS_POST_MEMORY)
/*
* Memory map
diff --git a/include/configs/XPEDITE5370.h b/include/configs/XPEDITE5370.h
index e24d1d3..4a4b48f 100644
--- a/include/configs/XPEDITE5370.h
+++ b/include/configs/XPEDITE5370.h
@@ -101,6 +101,7 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy);
#define CONFIG_SYS_ALT_MEMTEST
#define CONFIG_SYS_MEMTEST_START 0x1000
#define CONFIG_SYS_MEMTEST_END 0x2000
+#define CONFIG_POST(CONFIG_SYS_POST_MEMORY)
/*
* Memory map
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] xes: Enable the 'ecc' command
Enable the 'ecc' command for XES's 85xx and 86xx boards. Signed-off-by: Peter Tyser --- include/configs/XPEDITE5170.h |1 + include/configs/XPEDITE5200.h |1 + include/configs/XPEDITE5370.h |1 + 3 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/XPEDITE5170.h b/include/configs/XPEDITE5170.h index 1a810e4..f7615db 100644 --- a/include/configs/XPEDITE5170.h +++ b/include/configs/XPEDITE5170.h @@ -62,6 +62,7 @@ #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL 1 #define CONFIG_DDR_ECC +#define CONFIG_DDR_ECC_CMD #define CONFIG_ECC_INIT_VIA_DDRCONTROLLER #define CONFIG_SYS_DDR_SDRAM_BASE 0x /* DDR is system memory*/ #define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_DDR_SDRAM_BASE diff --git a/include/configs/XPEDITE5200.h b/include/configs/XPEDITE5200.h index 3f73780..bc28b61 100644 --- a/include/configs/XPEDITE5200.h +++ b/include/configs/XPEDITE5200.h @@ -59,6 +59,7 @@ #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL 2 #define CONFIG_DDR_ECC +#define CONFIG_DDR_ECC_CMD #define CONFIG_ECC_INIT_VIA_DDRCONTROLLER #define CONFIG_SYS_DDR_SDRAM_BASE 0x #define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_DDR_SDRAM_BASE diff --git a/include/configs/XPEDITE5370.h b/include/configs/XPEDITE5370.h index 26b798b..e24d1d3 100644 --- a/include/configs/XPEDITE5370.h +++ b/include/configs/XPEDITE5370.h @@ -63,6 +63,7 @@ #define CONFIG_DIMM_SLOTS_PER_CTLR 1 #define CONFIG_CHIP_SELECTS_PER_CTRL 1 #define CONFIG_DDR_ECC +#define CONFIG_DDR_ECC_CMD #define CONFIG_ECC_INIT_VIA_DDRCONTROLLER #define CONFIG_SYS_DDR_SDRAM_BASE 0x /* DDR is system memory*/ #define CONFIG_SYS_SDRAM_BASE CONFIG_SYS_DDR_SDRAM_BASE -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] xes: Enable ECC error checks during SDRAM POST and mtest
Enable ECC error checking on XES's 85xx and 86xx boards. Signed-off-by: Peter Tyser --- include/configs/XPEDITE5170.h |1 + include/configs/XPEDITE5200.h |1 + include/configs/XPEDITE5370.h |1 + 3 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/XPEDITE5170.h b/include/configs/XPEDITE5170.h index 6967754..2778c04 100644 --- a/include/configs/XPEDITE5170.h +++ b/include/configs/XPEDITE5170.h @@ -108,6 +108,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_SYS_MEMTEST_START 0x1000 #define CONFIG_SYS_MEMTEST_END 0x2000 #define CONFIG_POST(CONFIG_SYS_POST_MEMORY) +#define CONFIG_CHECK_ECC_ERRORS/* Check ECC count during POST/mtest */ /* * Memory map diff --git a/include/configs/XPEDITE5200.h b/include/configs/XPEDITE5200.h index ca333b7..993b011 100644 --- a/include/configs/XPEDITE5200.h +++ b/include/configs/XPEDITE5200.h @@ -91,6 +91,7 @@ #define CONFIG_SYS_MEMTEST_START 0x1000 #define CONFIG_SYS_MEMTEST_END 0x2000 #define CONFIG_POST(CONFIG_SYS_POST_MEMORY) +#define CONFIG_CHECK_ECC_ERRORS/* Check ECC count during POST/mtest */ /* * Memory map diff --git a/include/configs/XPEDITE5370.h b/include/configs/XPEDITE5370.h index 4a4b48f..c374605 100644 --- a/include/configs/XPEDITE5370.h +++ b/include/configs/XPEDITE5370.h @@ -102,6 +102,7 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy); #define CONFIG_SYS_MEMTEST_START 0x1000 #define CONFIG_SYS_MEMTEST_END 0x2000 #define CONFIG_POST(CONFIG_SYS_POST_MEMORY) +#define CONFIG_CHECK_ECC_ERRORS/* Check ECC count during POST/mtest */ /* * Memory map -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] cmd_help: General cleanup
Shorten the overly-verbose help message of 'help' and clean up some
redundant ifdefery while we're at it.
Signed-off-by: Peter Tyser
---
common/cmd_help.c | 21 +++--
1 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/common/cmd_help.c b/common/cmd_help.c
index f01d14e..e860dfb 100644
--- a/common/cmd_help.c
+++ b/common/cmd_help.c
@@ -33,25 +33,18 @@ int do_help(cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
U_BOOT_CMD(
help, CONFIG_SYS_MAXARGS, 1, do_help,
- "print online help",
- "[command ...]\n"
- "- show help information (for 'command')\n"
- "'help' prints online help for the monitor commands.\n\n"
- "Without arguments, it prints a short usage message for all
commands.\n\n"
- "To get detailed help information for specific commands you can type\n"
- "'help' with one or more command names as arguments."
+ "print command description/usage",
+ "\n"
+ " - print brief description of all commands\n"
+ "help command ...\n"
+ " - print detailed usage of 'command'"
);
/* This does not use the U_BOOT_CMD macro as ? can't be used in symbol names */
-#ifdef CONFIG_SYS_LONGHELP
cmd_tbl_t __u_boot_cmd_question_mark Struct_Section = {
"?",CONFIG_SYS_MAXARGS, 1, do_help,
"alias for 'help'",
+#ifdef CONFIG_SYS_LONGHELP
""
-};
-#else
-cmd_tbl_t __u_boot_cmd_question_mark Struct_Section = {
- "?",CONFIG_SYS_MAXARGS, 1, do_help,
- "alias for 'help'"
-};
#endif /* CONFIG_SYS_LONGHELP */
+};
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] command.c: Break commands out to appropriate cmd_*.c files
command.c should contain common code related to commands, not
miscellaneous command implementations.
Signed-off-by: Peter Tyser
---
common/Makefile |5 +
common/cmd_echo.c| 58 +
common/cmd_exit.c| 42 +
common/cmd_help.c| 57
common/cmd_test.c| 151
common/cmd_version.c | 40 +
common/command.c | 233 --
7 files changed, 353 insertions(+), 233 deletions(-)
create mode 100644 common/cmd_echo.c
create mode 100644 common/cmd_exit.c
create mode 100644 common/cmd_help.c
create mode 100644 common/cmd_test.c
create mode 100644 common/cmd_version.c
diff --git a/common/Makefile b/common/Makefile
index 3781738..35af8ae 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -45,7 +45,9 @@ COBJS-y += xyzModem.o
# core command
COBJS-y += cmd_boot.o
COBJS-y += cmd_bootm.o
+COBJS-y += cmd_help.o
COBJS-y += cmd_nvedit.o
+COBJS-y += cmd_version.o
# environment
COBJS-y += env_common.o
@@ -84,9 +86,11 @@ COBJS-$(CONFIG_CMD_DIAG) += cmd_diag.o
endif
COBJS-$(CONFIG_CMD_DISPLAY) += cmd_display.o
COBJS-$(CONFIG_CMD_DTT) += cmd_dtt.o
+COBJS-$(CONFIG_CMD_ECHO) += cmd_echo.o
COBJS-$(CONFIG_ENV_IS_IN_EEPROM) += cmd_eeprom.o
COBJS-$(CONFIG_CMD_EEPROM) += cmd_eeprom.o
COBJS-$(CONFIG_CMD_ELF) += cmd_elf.o
+COBJS-$(CONFIG_SYS_HUSH_PARSER) += cmd_exit.o
COBJS-$(CONFIG_CMD_EXT2) += cmd_ext2.o
COBJS-$(CONFIG_CMD_FAT) += cmd_fat.o
COBJS-$(CONFIG_CMD_FDC)$(CONFIG_CMD_FDOS) += cmd_fdc.o
@@ -135,6 +139,7 @@ COBJS-$(CONFIG_CMD_SPI) += cmd_spi.o
COBJS-$(CONFIG_CMD_SPIBOOTLDR) += cmd_spibootldr.o
COBJS-$(CONFIG_CMD_STRINGS) += cmd_strings.o
COBJS-$(CONFIG_CMD_TERMINAL) += cmd_terminal.o
+COBJS-$(CONFIG_SYS_HUSH_PARSER) += cmd_test.o
COBJS-$(CONFIG_CMD_TSI148) += cmd_tsi148.o
COBJS-$(CONFIG_CMD_UBI) += cmd_ubi.o
COBJS-$(CONFIG_CMD_UBIFS) += cmd_ubifs.o
diff --git a/common/cmd_echo.c b/common/cmd_echo.c
new file mode 100644
index 000..3ec4d48
--- /dev/null
+++ b/common/cmd_echo.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright 2000-2009
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+
+int do_echo(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ int i;
+ int putnl = 1;
+
+ for (i = 1; i < argc; i++) {
+ char *p = argv[i], c;
+
+ if (i > 1)
+ putc(' ');
+ while ((c = *p++) != '\0') {
+ if (c == '\\' && *p == 'c') {
+ putnl = 0;
+ p++;
+ } else {
+ putc(c);
+ }
+ }
+ }
+
+ if (putnl)
+ putc('\n');
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ echo, CONFIG_SYS_MAXARGS, 1, do_echo,
+ "echo args to console",
+ "[args..]\n"
+ "- echo args to console; \\c suppresses newline"
+);
diff --git a/common/cmd_exit.c b/common/cmd_exit.c
new file mode 100644
index 000..ed876d8
--- /dev/null
+++ b/common/cmd_exit.c
@@ -0,0 +1,42 @@
+/*
+ * Copyright 2000-2009
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
[U-Boot] [PATCH 3/3] Add 'true' and 'false' commands
These commands are only enabled when the hush shell is enabled and can
be useful in scripts such as:
while true do
echo "Booting OS...";
run $bootcmd;
echo "Booting OS failed";
sleep 10;
done
Signed-off-by: Peter Tyser
---
This could be added as a hush builtin command if people don't want to
pollute the top-level help listing. Its debatable if 'false' should
be added also, but I threw it in to be consistent.
common/cmd_test.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/common/cmd_test.c b/common/cmd_test.c
index 3cdd07b..d886f89 100644
--- a/common/cmd_test.c
+++ b/common/cmd_test.c
@@ -149,3 +149,25 @@ U_BOOT_CMD(
"minimal test like /bin/sh",
"[args..]"
);
+
+int do_false(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ return 1;
+}
+
+U_BOOT_CMD(
+ false, CONFIG_SYS_MAXARGS, 1, do_false,
+ "do nothing, unsuccessfully",
+ NULL
+);
+
+int do_true(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+ return 0;
+}
+
+U_BOOT_CMD(
+ true, CONFIG_SYS_MAXARGS, 1, do_true,
+ "do nothing, successfully",
+ NULL
+);
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] cmd_nand: Move conditional compilation to Makefile
Hi Vimal, On Fri, 2009-10-16 at 17:03 +0530, vimal singh wrote: > Could you please add some description? I personally think the patch title has plenty of description. The change is trivial, and similar changes (with similar titles/descriptions) have been accepted many times in the past. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] cmd_nand: Move conditional compilation to Makefile
Signed-off-by: Peter Tyser --- common/Makefile |2 +- common/cmd_nand.c |4 2 files changed, 1 insertions(+), 5 deletions(-) diff --git a/common/Makefile b/common/Makefile index 35af8ae..ec025ed 100644 --- a/common/Makefile +++ b/common/Makefile @@ -120,7 +120,7 @@ COBJS-$(CONFIG_CMD_MISC) += cmd_misc.o COBJS-$(CONFIG_CMD_MMC) += cmd_mmc.o COBJS-$(CONFIG_MP) += cmd_mp.o COBJS-$(CONFIG_CMD_MTDPARTS) += cmd_mtdparts.o -COBJS-y += cmd_nand.o +COBJS-$(CONFIG_CMD_NAND) += cmd_nand.o COBJS-$(CONFIG_CMD_NET) += cmd_net.o COBJS-$(CONFIG_CMD_ONENAND) += cmd_onenand.o COBJS-$(CONFIG_CMD_OTP) += cmd_otp.o diff --git a/common/cmd_nand.c b/common/cmd_nand.c index 404ef9c..075a8af 100644 --- a/common/cmd_nand.c +++ b/common/cmd_nand.c @@ -10,9 +10,6 @@ #include #include - -#if defined(CONFIG_CMD_NAND) - #include #include #include @@ -678,4 +675,3 @@ U_BOOT_CMD(nboot, 4, 1, do_nandboot, "boot from NAND device", "[partition] | [[[loadAddr] dev] offset]" ); -#endif -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] cmd_nand: Remove duplicate include
Also remove vague, unnecessary comment Signed-off-by: Peter Tyser --- common/cmd_nand.c |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/common/cmd_nand.c b/common/cmd_nand.c index 158a55f..404ef9c 100644 --- a/common/cmd_nand.c +++ b/common/cmd_nand.c @@ -9,14 +9,6 @@ */ #include - - -/* - * - * New NAND support - * - */ -#include #include #if defined(CONFIG_CMD_NAND) -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sh: Remove malloc_bin_reloc from SH
> diff --git a/lib_sh/board.c b/lib_sh/board.c
> index 5ed40e9..c97e20c 100644
> --- a/lib_sh/board.c
> +++ b/lib_sh/board.c
> @@ -32,7 +32,6 @@
> #include
> #endif
>
> -extern void malloc_bin_reloc (void);
> extern int cpu_init(void);
> extern int board_init(void);
> extern int dram_init(void);
> @@ -92,7 +91,6 @@ static int sh_mem_env_init(void)
> {
> mem_malloc_init(TEXT_BASE - CONFIG_SYS_GBL_DATA_SIZE -
> CONFIG_SYS_MALLOC_LEN, CONFIG_SYS_MALLOC_LEN - 16);
> - malloc_bin_reloc();
> env_relocate();
> jumptable_init();
> return 0;
Hi Nobuhiro,
Thanks for catching that. Would you mind sending a patch that made the
same change for sh as well as nios, and nios2? All 3 seem to have the
same issue.
Thanks,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] ppc: Fix relocation
On Mon, 2009-10-12 at 11:30 -0700, Swarthout Edward L-SWARTHOU wrote: > From: Edward > > Sent: Thursday, September 24, 2009 11:05 AM > > To: Wolfgang Denk; Peter Tyser > > > > With -m relocatable, x86emu crashes because the op codes > > tables are forced to GOT2 section: > > > > Video: ATI Radeon video card (1002, 5b60) found @(6:0:0) > > videoboot: Booting PCI video card bus 6, function 0, dev 0 > > NIP: 8FFA8120 LR: 3FFB40F8 REGS: 3fe6dbd0 TRAP: 0700 DAR: 0 > > MSR: 00021200 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 > > > > GPR00: 8FFA8120 3FE6DCC0 3FE6DF68 009A 0003 > > GPR08: 4000 3FE75800 3F00 3FE6DCC0 8424 81C5D766 > > GPR16: 3FFF92E8 3FFCB384 3FE6DDA8 > > GPR24: 3FFDA09C 3FFE0544 3FFF9A6C 3FFF9A6C 3FE6DD24 3FFF9A6C > > ** Illegal Instruction ** > > > > This patch fixes it: > > > > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/48103 > > > > I still get this crash with latest head > (u-boot 2009.08-00338-gcd77dd1). Thanks Ed, To clarify, you're saying that the patch linked above just needs to be applied, right? Was there a reason the patch wasn't applied back in 2008? The change looks good to me for what its worth. Wolfgang or Kumar, could one of you pick it up? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Environment variable command grouping?
For this task: http://www.denx.de/wiki/U-Boot/TaskSetEnvironmentDefaults was the end goal to group all environment commands under a new "environment" command, in addition to adding the new "clear" and "default" commands? eg: setenv becomes "env set" printenv becomes "env print" askenv becomes "env ask" add new "env clear" add new "env default" I'd personally welcome this change. Here's some discussion about the task for reference: http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg01414.html Also, is anybody working on this? Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Fri, 2009-10-09 at 09:02 +1100, Graeme Russ wrote: > On Fri, Oct 9, 2009 at 8:23 AM, Wolfgang Denk wrote: > > Dear Graeme Russ, > > > > In message > > you wrote: > >> > >> > >> Once the reloc branch has been merged, how many arches are left which do > >> not support relocation? > > > > All but PPC ? > > Hmm, so commit 0630535e2d062dd73c1ceca5c6125c86d1127a49 is all about > removing code that is not used because these arches do not do any > relocation at all? I sent that patch/RFC after noticing none of those architectures performed manual relocation fixups, thus they could save some code space by defining CONFIG_RELOC_FIXUP_WORKS. Similarly the gd->reloc_off field was no longer needed for them. I'm not familiar with if or how those architectures are relocating, just that they didn't need relocation fixups. So that was the logic... > So ultimately, what we are looking at is the complete and utter > removal of any code which references a relocation adjustment in lieu > of each arch either: > > a) Execute in Place from Flash, or; > b) Setting a fixed TEXT_BASE at a known RAM location and copying > the contents of Flash to RAM, or; > c) Implementing full Relocation d) Leaving those architectures the way they are now Could be added if a,b,c won't work for some reason too. I think it would be great to remove any manual relocation adjustments in the long run. This isn't strictly necessary though, as we can still have manual relocations littering the code - its just a bit dirty and prone to issues in the long run. So my vote would be to shoot for c) for all arches, but I have no idea what impact that would have on them:) Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
On Thu, 2009-10-08 at 20:23 +0200, Alessandro Rubini wrote: > >> That's true, but I think the most important case is lcd scrolling, > >> where it's usually a big power of two -- that's where we had the #ifdef, > >> so the problem was known, I suppose. > > > > I think the most important case for *you* is lcd scrolling, but for 99% > > of everyone else, it isn't at all:) > > Well, its a big memcpy, and it has direct effect on the user. Every > other copy is smaller, or has no interactive value. > > > memcpy() and memset() are used 100 times more often in non-lcd > > related code and most boards don't even have LCDs. > > That's true. But it's only a boot loader (I just looked at what Nicolas > Pitre did in the kernel for ARM strcpy and, well). > > So I made some measures (it's one of Pike's rules of programming: > > * Rule 2. Measure. Don't tune for speed until you've measured, and even >then don't unless one part of the code overwhelms the rest. > > ) > > I booted in u-boot, typed "setenv stdout serial" then "boot", which goes > over the ethernet. Stopped the system after u-boot gave over control to > the kernel. Result: 10412 memcopies so divided (number, length): > >3941 4 >1583 6 > 772 20 > 1 46 > 1 47 > 3 60 >1024 64 > 1 815 > 1 888 > 770 1148 >1543 1480 > 1 2283 > 1 3836 > 770 4096 > > So I dare say non-power-of-4 is a minority anyways: 1587 calls, 12689 bytes. > i.e. 15.2% of the calls and 0.2% of the data. The statistics are going to be very different for different scenarios. For example, network operations seem to be the majority of your large memcpys, this isn't the case for everyone. If/when U-Boot runs on 64-bit hardware, the stats will change too. In any case, my only suggestion would be that if we're improving memcpy()/memset(), do the extra 10% of effort required to make them a little better. That 10% of effort will improve 15.2% of all memcpy() calls for the foreseeable future:) I honestly don't care much what implementation you choose as I only currently use PPC, which has their own memcpy()/memset(). I'm only trying to be helpful, feel free to proceed however you see fit, I promise I won't comment on future patches:) Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
On Thu, 2009-10-08 at 18:00 +0200, Alessandro Rubini wrote: > > No interest in the suggestion to not require count to be an exact > > multiple of 4/8? > > Actually, I wrote about that in my patch 0/3. Sorry, I should have read more thoroughly. > > I don't think it would be that hard to update the logic accordingly > > and this would let your code be utilized much more often, especially > > if/when we run on a 64-bit machine. > > That's true, but I think the most important case is lcd scrolling, > where it's usually a big power of two -- that's where we had the #ifdef, > so the problem was known, I suppose. I think the most important case for *you* is lcd scrolling, but for 99% of everyone else, it isn't at all:) memcpy() and memset() are used 100 times more often in non-lcd related code and most boards don't even have LCDs. In my opinion, we shouldn't be fixing/bloating common code for 1 outlying scenario, we should be trying to improve it for common cases. > Currently, I don't even know if this is going to be picked up, so I > don't want to go too far -- and in that case I would like to measure > things and be able to test for stupid bugs, so it takes time. Sure, I understand where you're coming from. FWIW, if people don't want to pick this up as it affects lots of people, you could always add an architecture-specific memcpy/memset implementation. > If there's interest, there's memmov to fix; it's used pretty often and > it's the same idea as memcpy (well, scrolling should use memmove, > in theory). I'll quit pestering, just wanted to put my $.02 in:) Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Thu, 2009-10-08 at 08:53 -0700, J. William Campbell wrote: > Peter Tyser wrote: > > On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote: > > > >> Out of curiosity, I wanted to see just how much of a size penalty I am > >> incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are > >> the results (fixed width font will help - its space, not tab, formatted): > >> > >> Section non-reloc reloc > >> --- > >> .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger > >> .rodata 5bad 59d0 > >> .interp n/a 0013 > >> .dynstr n/a 0648 > >> .hashn/a 0428 > >> .eh_frame3268 34fc > >> .data0a6c 01dc > >> .data.reln/a 0098 > >> .data.rel.ro.local n/a 0178 > >> .data.rel.local n/a 07e4 > >> .got 01f0 > >> .got.plt n/a 000c > >> .rel.got n/a 03e0 > >> .rel.dyn n/a 1228 > >> .dynsym n/a 0850 > >> .dynamic n/a 0080 > >> .u_boot_cmd 03c0 03c0 > >> .bss 1a34 1a34 > >> .realmode0166 0166 > >> .bios053e 053e > >> === > >> Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger > >> > >> Its more than a 16% increase in size!!! > >> > >> .text accounts for a little under half of the total bloat, and of that, > >> the crude dynamic loader accounts for only 341 bytes > >> > >> Have any metrics been done for PPC? > >> > > > > Things actually improve a little bit when we use -mrelocatable and get > > rid of all the manual "+= gd->reloc_off" fixups: > > > > 1) Top of mainline on XPedite5370: > >textdata bss dec hex filename > > 308612 24488 33172 366272 596c0 u-boot > > > > 2) Top of "reloc" branch on XPedite5370 (ie -mrelocatable): > >textdata bss dec hex filename > > 303704 28644 33156 365504 593c0 u-boot > > > > > Hi Peter, > Just to be clear, the total text+data length of u-boot with the > "manual" relocations (#1) is LARGER than the text+data length of u-boot > with the "manual" relocations removed and the necessary centralized > relocation code added, along with any additional data sections required > by -mrelocateable (#2), by 768 (dec) bytes? Hi Bill, Doah, looks like I chose a bad board as an example. The XPedite5370 already had -mrelocatable defined in its own board/xes/xpedite5370/config.mk in mainline, so the above comparison should be ignored as both builds used -mrelocatable. Here's some *real* results from the MPC8548CDS: 1) Top of mainline: textdata bss dec hex filename 219968 17052 22992 260012 3f7ac u-boot 2) Top of "reloc" branch (ie -mrelocatable) textdata bss dec hex filename 219192 20640 22980 262812 4029c u-boot So the reloc branch is 2.7K bigger for the MPC8548CDS. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] memcpy: copy one word at a time if possible
On Thu, 2009-10-08 at 13:30 +0200, Alessandro Rubini wrote:
> From: Alessandro Rubini
>
> Signed-off-by: Alessandro Rubini
> Acked-by: Andrea Gallo
> ---
> lib_generic/string.c | 17 +
> 1 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/lib_generic/string.c b/lib_generic/string.c
> index 181eda6..9911941 100644
> --- a/lib_generic/string.c
> +++ b/lib_generic/string.c
> @@ -446,12 +446,21 @@ char * bcopy(const char * src, char * dest, int count)
> * You should not use this function to access IO space, use memcpy_toio()
> * or memcpy_fromio() instead.
> */
> -void * memcpy(void * dest,const void *src,size_t count)
> +void * memcpy(void *dest, const void *src, size_t count)
> {
> - char *tmp = (char *) dest, *s = (char *) src;
> + char *d8 = (char *)dest, *s8 = (char *)src;
> + unsigned long *dl = (unsigned long *)dest, *sl = (unsigned long *)src;
>
> + /* if all data is aligned (common case), copy a word at a time */
> + if ( (((int)dest | (int)src | count) & (sizeof(long) - 1)) == 0) {
> + count /= sizeof(unsigned long);
> + while (count--)
> + *dl++ = *sl++;
> + return dest;
> + }
> + /* else, use 1-byte copy */
> while (count--)
> - *tmp++ = *s++;
> + *d8++ = *s8++;
>
> return dest;
> }
Hi Alessandro,
No interest in the suggestion to not require count to be an exact
multiple of 4/8? I don't think it would be that hard to update the
logic accordingly and this would let your code be utilized much more
often, especially if/when we run on a 64-bit machine. Conceptually it
seems like a cleaner implementation too, but that's probably just my
preference:)
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Relocation size penalty calculation
On Thu, 2009-10-08 at 22:54 +1100, Graeme Russ wrote: > Out of curiosity, I wanted to see just how much of a size penalty I am > incurring by using gcc -fpic / ld -pic on my x86 u-boot build. Here are > the results (fixed width font will help - its space, not tab, formatted): > > Section non-reloc reloc > --- > .text000118c4 000137fc <- 0x1f38 bytes (~8kB) bigger > .rodata 5bad 59d0 > .interp n/a 0013 > .dynstr n/a 0648 > .hashn/a 0428 > .eh_frame3268 34fc > .data0a6c 01dc > .data.reln/a 0098 > .data.rel.ro.local n/a 0178 > .data.rel.local n/a 07e4 > .got 01f0 > .got.plt n/a 000c > .rel.got n/a 03e0 > .rel.dyn n/a 1228 > .dynsym n/a 0850 > .dynamic n/a 0080 > .u_boot_cmd 03c0 03c0 > .bss 1a34 1a34 > .realmode0166 0166 > .bios053e 053e > === > Total0001d5dd 00022287 <- 0x4caa bytes (~19kB) bigger > > Its more than a 16% increase in size!!! > > .text accounts for a little under half of the total bloat, and of that, > the crude dynamic loader accounts for only 341 bytes > > Have any metrics been done for PPC? Things actually improve a little bit when we use -mrelocatable and get rid of all the manual "+= gd->reloc_off" fixups: 1) Top of mainline on XPedite5370: textdata bss dec hex filename 308612 24488 33172 366272 596c0 u-boot 2) Top of "reloc" branch on XPedite5370 (ie -mrelocatable): textdata bss dec hex filename 303704 28644 33156 365504 593c0 u-boot For fun: 3) #2 but with s/-mrelocatable/-fpic/ (probably doesn't boot): textdata bss dec hex filename 303704 24472 33156 361332 58374 u-boot There may be some other changes that affect the size between mainline and "reloc", but their sizes are in the same general ballpark. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
> > Jocke, Peter: am I understanding correctly that we now have everything > > in the "reloc" branch that we want to include with this upcoming > > release, i. e. that we can do the "final" testing now before I merge > > that branch into master? > > Yes, I have nothing more ready and I believe everything is in place. Same here, should be good to go. Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
Hi Jocke, > v2: included ppc4xx too. Looks like cpu/74xx_7xx is missing too:( > cpu/mpc512x/start.S |6 -- > cpu/mpc5xx/start.S |6 -- > cpu/mpc5xxx/start.S |6 -- > cpu/mpc8220/start.S |6 -- > cpu/mpc824x/start.S |6 -- > cpu/mpc8260/start.S |6 -- > cpu/mpc83xx/start.S |6 -- > cpu/mpc85xx/start.S |6 -- > cpu/mpc86xx/start.S |6 -- > cpu/mpc8xx/start.S |6 -- > cpu/ppc4xx/start.S |6 -- > 11 files changed, 44 insertions(+), 22 deletions(-) Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] 85xx: Ensure BSS segment isn't linked at address 0
When U-Boot is relocated from flash to RAM pointers are modified
accordingly. However, pointers initialzed with NULL values should not
be modified so that they maintain their intended NULL value. If the
BSS segment is linked at address 0 its address will not be
updated as necessary during relocation.
This is a temporary workaround. The end goal is to add support to
U-Boot to dynamically locate the BSS at an arbitrary address at
runtime. When the ability to fixup the BSS inteligently is
added, this workaround can be removed and the 85xx link script
can put the BSS at a fixed address at link time.
Signed-off-by: Peter Tyser
---
Changes since v1:
- Updated commit title and description
- Cleaned up logic to determine if we need to fixup bss address
cpu/mpc85xx/u-boot.lds | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/cpu/mpc85xx/u-boot.lds b/cpu/mpc85xx/u-boot.lds
index a347cd1..183dce9 100644
--- a/cpu/mpc85xx/u-boot.lds
+++ b/cpu/mpc85xx/u-boot.lds
@@ -131,6 +131,17 @@ SECTIONS
. = RESET_VECTOR_ADDRESS + 0x4;
+ /*
+ * Make sure that the bss segment isn't linked at 0x0, otherwise its
+ * address won't be updated during relocation fixups. Note that
+ * this is a temporary fix. Code to dynamically the fixup the bss
+ * location will be added in the future. When the bss relocation
+ * fixup code is present this workaround should be removed.
+ */
+#if (RESET_VECTOR_ADDRESS == 0xfffc)
+ . |= 0x10;
+#endif
+
__bss_start = .;
.bss (NOLOAD) :
{
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] memcpy: use 32-bit copies if possible
Hi Alessandro,
> --- a/lib_generic/string.c
> +++ b/lib_generic/string.c
> @@ -449,7 +449,16 @@ char * bcopy(const char * src, char * dest, int count)
> void * memcpy(void * dest,const void *src,size_t count)
> {
> char *tmp = (char *) dest, *s = (char *) src;
> + u32 *d32 = (u32 *)dest, *s32 = (u32 *) src;
>
> + /* if both are aligned, use 32-bit copy */
> + if ( (((int)dest & 3) | ((int)src & 3) | (count & 3)) == 0 ) {
> + count /= 4;
> + while (count--)
> + *d32++ = *s32++;
> + return dest;
> + }
> + /* else, use 1-byte copy */
> while (count--)
> *tmp++ = *s++;
If we're adding this logic, what about adding it such that:
if (src/dest are 32-bit aligned and count > 3) {
perform 32-bit copies till count <= 3
}
perform remaining 8-bit copies till count == 0
You'd still get the performance boost but not have the requirement that
count is evenly divisible by 4. You could do byte copies before the
32-bit copies to align the src/dest in some cases, but that might be
overkill...
Same comment goes for the memset implementation.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
> > It seems like a clean solution. Adding a bss-aware fixup routine or > > putting the bss after the U-Boot image both seem good to me. The > > bss-aware fixup routine has a clearer readelf output and slightly more > > complicated code while the bss-after-uboot change has a misleading > > readelf output and simpler code. In any case I'd give a thumbs up to > > either of them. > > My vote is for the first, because otherwise we will run into > situations again and again where users and/or the linker get confused > about overlapping sections and/or sections wrapping around the > physical end of address space. Are you proposing adding this new bss fixup code to this release, or rolling it into the next release along with Jocke's addition of relocation code written in C-code? Logically it'd be much easier to add this new bss fixup logic to Jocke's 1 C-code function instead of 15 assembly files, but then we'd have to have a temporary 85xx workaround just for this release (which is fine by me). Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc8xxx: improve LAW error messages when setting up DDR
Hi Paul,
> diff --git a/cpu/mpc8xxx/ddr/util.c b/cpu/mpc8xxx/ddr/util.c
> index 4451989..d0f61a8 100644
> --- a/cpu/mpc8xxx/ddr/util.c
> +++ b/cpu/mpc8xxx/ddr/util.c
> @@ -89,16 +89,16 @@ __fsl_ddr_set_lawbar(const common_timing_params_t
> *memctl_common_params,
> ? LAW_TRGT_IF_DDR_INTRLV : LAW_TRGT_IF_DDR_1;
>
> if (set_ddr_laws(base, size, lawbar1_target_id) < 0) {
> - printf("ERROR\n");
> + printf("set_lawbar: ERROR (%d)\n", memctl_interleaved);
> return ;
> }
> } else if (ctrl_num == 1) {
> if (set_ddr_laws(base, size, LAW_TRGT_IF_DDR_2) < 0) {
> - printf("ERROR\n");
> + printf("set_lawbar: ERROR (ctrl #2)\n");
This error would print out #2 for the 2nd controller...
> return ;
> }
> } else {
> - printf("unexpected controller number %u in %s\n",
> + printf("set_lawbar: unexpected controller number %u in %s\n",
> ctrl_num, __FUNCTION__);
But this error would print out 2 for the 3rd controller. Either
convention is going to be confusing, but it'd be nice if they were at
least consistent.
__func__ is preferred over __FUNCTION__, maybe you could update it also?
Wouldn't this message look at bit funny with the title being
"set_lawbar:" but then also including the full "__fsl_ddr_set_lawbar" in
the same message? And neither of the other errors include the printing
of __func__? Hopefully I'll never see the errors, so proceed as you see
fit:)
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
On Tue, 2009-10-06 at 18:43 -0500, Peter Tyser wrote: > > > The values all changed and are dependent on RAM size, but their > > > relationship to one another didn't - they all just increased by > > > 0x7fff. So practically speaking, we do need to know where the bss > > > is at link time - its address is not dynamic like the malloc pool or > > > stack - its tied directly to the address of the other sections at link > > > time. (Unless we added some bss-specific fixups I imagine) > > > > Right, that's the current situation. > > > > My suggestion was NOT to put the bss at a fixed _offset_ to the > > U-Boot image, but to a fixed absolute address. My hope is that this > > might simplify the linker scripts at the cost of adding a little code > > to the relocation routine - for addresses in the bss we would have to > > add a different relocation offset. > > I think I see what you're getting at. If we have a bss-specific fixup > routine I don't give a hoot where the bss is located at link time. Its > just that that bss-aware fixup routine doesn't exist right now:) > > It seems like a clean solution. Adding a bss-aware fixup routine or > putting the bss after the U-Boot image both seem good to me. The > bss-aware fixup routine has a clearer readelf output and slightly more > complicated code while the bss-after-uboot change has a misleading > readelf output and simpler code. In any case I'd give a thumbs up to > either of them. Sorry, just to be clear, where did you want to put the fixed up bss? Still at a low memory address, ie the original address at link time? I had assumed if we were adding a bss-specific fixup we'd move it to the top of memory, near U-Boot, the malloc pool, etc. I'd be all for relocating it to higher in memory, but wouldn't be too excited about leaving at a low memory address... If we were to add bss fixups, we may as well move it to a location that lines up with the rest of U-Boot code, stack, and malloc, right? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
> > The values all changed and are dependent on RAM size, but their > > relationship to one another didn't - they all just increased by > > 0x7fff. So practically speaking, we do need to know where the bss > > is at link time - its address is not dynamic like the malloc pool or > > stack - its tied directly to the address of the other sections at link > > time. (Unless we added some bss-specific fixups I imagine) > > Right, that's the current situation. > > My suggestion was NOT to put the bss at a fixed _offset_ to the > U-Boot image, but to a fixed absolute address. My hope is that this > might simplify the linker scripts at the cost of adding a little code > to the relocation routine - for addresses in the bss we would have to > add a different relocation offset. I think I see what you're getting at. If we have a bss-specific fixup routine I don't give a hoot where the bss is located at link time. Its just that that bss-aware fixup routine doesn't exist right now:) It seems like a clean solution. Adding a bss-aware fixup routine or putting the bss after the U-Boot image both seem good to me. The bss-aware fixup routine has a clearer readelf output and slightly more complicated code while the bss-after-uboot change has a misleading readelf output and simpler code. In any case I'd give a thumbs up to either of them. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
On Wed, 2009-10-07 at 01:07 +0200, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <1254862383.24664.2742.ca...@localhost.localdomain> you wrote: > > > > What's the advantage of having the bss not be located next to U-Boot? > > One advantage is that we might chose the same address for all boards, > and eventually for all Power processor families. We could achieve this wherever we end up putting the bss. eg if people think putting the bss right after the u-boot image is best, we can update the 44x linker script, etc to do the same thing. I think this discussion is applicable to most any PPC board. > One disadvantage is that we need to relocate it separately, or we will > have a gap in the RAm memory map which is IMO not acceptable. What does "relocating the bss separately" entail? > > The big disadvantage of picking an arbitrary address for the bss is that > > there's now 1 more magical section of SDRAM that the user needs to know > > shouldn't be used. I already field enough question from people that > > Why should it not be used? You seem to be pretty fixed on that idea, > which is wrong. No code will ever be written to RAM at list location. When I say user, I'm refering to an end user, eg a customer. Not a developer. For arguments sake, lets say we developers put the bss at a "fixed (random, non-zero) address" of 0x8. A user tftps an image to 0x8 and suddenly their board starts acting up. > In the current setup, we don't write any code to RAM at 0x0 either. Right, and this limitation causes headaches. I personally get lots of questions from customers about why their board hangs when they tftp an image to 0x0. In a perfect world we'd only have 1 reserved section of memory which contained the interrupt vectors, text, bss, malloc, stack, etc. > > corrupt their exception vectors or stack/malloc pool/u-boot code, I > > don't want to add more bss questions:) Its crappy to have 2 sections of memory that a user has to know not to touch, I don't want to have 3:) Maybe I'm not understanding your suggestion "to chose a fixed (random, non-zero) address" for the bss. That implies to me we choose an address low memory (eg 0x1) and put the bss there. I think it'd be more plausible for someone to blow this away accidentally than high memory by U-Boot, and you also couldn't use any data stored in the bss after you blow it away, eg right before jumping to a linux kernel. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
On Tue, 2009-10-06 at 15:34 -0700, J. William Campbell wrote: > Peter Tyser wrote: > > On Tue, 2009-10-06 at 13:34 -0700, J. William Campbell wrote: > > > >> Peter Tyser wrote: > >> > >>> On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote: > >>> > >>> > >>>> Dear Peter Tyser, > >>>> > >>>> In message <1254843932.24664.2083.ca...@localhost.localdomain> you wrote: > >>>> > >>>> > >>>>> I personally like the current implementation of putting the bss after > >>>>> the entire U-Boot image. It keeps U-Boot's code, malloc pool, stack, > >>>>> bss, etc all in the same general area which is nice, and has the side > >>>>> benefit that the bootpg won't be overwritten. > >>>>> > >>>>> > >>>> OK, if you think so... > >>>> > >>>> > >>>> > >>>>> I know ORing in 0x10 is a bit ugly, but what's the real downside of > >>>>> doing it? > >>>>> > >>>>> > >>>> Nothing. I just hate to allocate the bss at 0x0, because this is > >>>> actually incorrect - it's the result of an address overflow / > >>>> truncation, and pretty much misleading to someone trying to read and > >>>> understand the code. For the linked image, it does not _look_ as if > >>>> the bss was located _after_ the U-Boot image, it looks detached and > >>>> allocated in low RAM. > >>>> > >>>> > >>> Do you have a preference Kumar? You're probably going to be the first > >>> in line to have to deal with any resulting confusion:) > >>> > >>> I personally would rank the options: > >>> 1. OR in an offset to the bss address and leave some good comments in > >>> the linker script and commit message > >>> > >>> 2. Make the bss the last section like other PPC boards which would > >>> result in the bootpg sometimes being overwritten > >>> > >>> 3. Put the bss at an arbitrary address > >>> > >>> > >> FWIW, I think an arbitrary address disjoint from the u-boot addresses is > >> best. While u-boot is in ROM, you can't use the bss anyway. The bss will > >> actually be located at an address selected by the u-boot code itself > >> after memory is sized. All references to the bss will be re-located by > >> subtracting the arbitrary start address and adding the run-time chosen > >> start address. So the linked start address is not important, except that > >> is cannot be NULL or it may confuse the relocation code that doesn't > >> want to re-locate NULL pointers. Some of the confusion in this > >> discussion probably stems from the fact that the linker scripts make the > >> bss look like "part of u-boot", when it is really not. It is just a > >> chunk of "zero'ed" ram, located anywhere the u-boot code decides to put > >> it. An arbitrary strange address would make this more apparent. > >> > > > > Hi Bill, > > What's the advantage of having the bss not be located next to U-Boot? > > The big disadvantage of picking an arbitrary address for the bss is that > > there's now 1 more magical section of SDRAM that the user needs to know > > shouldn't be used. I already field enough question from people that > > corrupt their exception vectors or stack/malloc pool/u-boot code, I > > don't want to add more bss questions:) > > > Hi Peter, > The point is that the address chosen for the ld step is NOT the > address in ram where the bss will reside anyway. This address can > overlap the exception vectors, stack, or even the u-boot code itself and > it wouldn't matter (other than possible confusion). The actual physical > address where the bss and u-boot itself resides is COMPUTED by u-boot > after it sizes memory. u-boot only needs to know how big the section is > in order to allow enough room. All references to the bss will then be > re-located correctly. Where the bss actually ends up is a function of > u-boot code. It may be on some processors that the computation of bss > start is done assuming the bss is adjacent to u-boot in the original > memory map, but if so, it is an un-necessary restriction. All that i
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
On Tue, 2009-10-06 at 15:46 -0500, Kumar Gala wrote: > On Oct 6, 2009, at 1:08 PM, Peter Tyser wrote: > > > On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote: > >> Dear Peter Tyser, > >> > >> In message <1254843932.24664.2083.ca...@localhost.localdomain> you > >> wrote: > >>> > >>> I personally like the current implementation of putting the bss > >>> after > >>> the entire U-Boot image. It keeps U-Boot's code, malloc pool, > >>> stack, > >>> bss, etc all in the same general area which is nice, and has the > >>> side > >>> benefit that the bootpg won't be overwritten. > >> > >> OK, if you think so... > >> > >>> I know ORing in 0x10 is a bit ugly, but what's the real downside of > >>> doing it? > >> > >> Nothing. I just hate to allocate the bss at 0x0, because this is > >> actually incorrect - it's the result of an address overflow / > >> truncation, and pretty much misleading to someone trying to read and > >> understand the code. For the linked image, it does not _look_ as if > >> the bss was located _after_ the U-Boot image, it looks detached and > >> allocated in low RAM. > > > > Do you have a preference Kumar? You're probably going to be the first > > in line to have to deal with any resulting confusion:) > > > > I personally would rank the options: > > 1. OR in an offset to the bss address and leave some good comments in > > the linker script and commit message > > > > 2. Make the bss the last section like other PPC boards which would > > result in the bootpg sometimes being overwritten > > > > 3. Put the bss at an arbitrary address > > I don't have a preference, but maybe I missed the answer to my > question about where does 44x put the BSS. The 44x boards put the bss after "the rest" of u-boot, but before the bootpg section. Sometimes the bss might overlap the bootpg which would mean the bootpg would get zeroed out on bootup and the bss would "wrap around to 0 (which is fine, just confusing). Eg: [ 0] NULL 00 00 00 0 0 0 [ 1] .resetvec PROGBITSfffc 03f2e4 04 00 AX 0 0 1 [ 2] .bootpg PROGBITSf000 03e2e8 000250 00 AX 0 0 1 [ 3] .text PROGBITSfff8 94 0303b0 00 AX 0 0 4 [ 4] .rodata PROGBITSfffb03b0 030444 00a14c 00 A 0 0 4 [ 5] .relocPROGBITSfffba500 03a594 002280 00 WA 0 0 4 [ 6] .data PROGBITSfffbc780 03c814 00088c 00 WA 0 0 4 [ 7] .data.rel.local PROGBITSfffbd00c 03d0a0 000a98 00 WA 0 0 4 [ 8] .data.rel.ro.loca PROGBITSfffbdaa4 03db38 b0 00 WA 0 0 4 [ 9] .data.rel PROGBITSfffbdb54 03dbe8 000100 00 WA 0 0 4 [10] .u_boot_cmd PROGBITSfffbdc54 03dce8 000600 00 WA 0 0 4 [11] .bss NOBITS fffbe300 03e2e8 011c44 00 WA 0 0 4 > Is it possible to put it before TEXTBASE? I looked into that originally but couldn't get it to work via the linker script alone. If we wanted to hardcode a bss size, we could pass "-Tbss " to ld to position it. We could allocate some relatively huge chunk of memory for it below TEXTBASE, but I'm not sure we could make it dynamically sized. Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
On Tue, 2009-10-06 at 13:34 -0700, J. William Campbell wrote: > Peter Tyser wrote: > > On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote: > > > >> Dear Peter Tyser, > >> > >> In message <1254843932.24664.2083.ca...@localhost.localdomain> you wrote: > >> > >>> I personally like the current implementation of putting the bss after > >>> the entire U-Boot image. It keeps U-Boot's code, malloc pool, stack, > >>> bss, etc all in the same general area which is nice, and has the side > >>> benefit that the bootpg won't be overwritten. > >>> > >> OK, if you think so... > >> > >> > >>> I know ORing in 0x10 is a bit ugly, but what's the real downside of > >>> doing it? > >>> > >> Nothing. I just hate to allocate the bss at 0x0, because this is > >> actually incorrect - it's the result of an address overflow / > >> truncation, and pretty much misleading to someone trying to read and > >> understand the code. For the linked image, it does not _look_ as if > >> the bss was located _after_ the U-Boot image, it looks detached and > >> allocated in low RAM. > >> > > > > Do you have a preference Kumar? You're probably going to be the first > > in line to have to deal with any resulting confusion:) > > > > I personally would rank the options: > > 1. OR in an offset to the bss address and leave some good comments in > > the linker script and commit message > > > > 2. Make the bss the last section like other PPC boards which would > > result in the bootpg sometimes being overwritten > > > > 3. Put the bss at an arbitrary address > > > FWIW, I think an arbitrary address disjoint from the u-boot addresses is > best. While u-boot is in ROM, you can't use the bss anyway. The bss will > actually be located at an address selected by the u-boot code itself > after memory is sized. All references to the bss will be re-located by > subtracting the arbitrary start address and adding the run-time chosen > start address. So the linked start address is not important, except that > is cannot be NULL or it may confuse the relocation code that doesn't > want to re-locate NULL pointers. Some of the confusion in this > discussion probably stems from the fact that the linker scripts make the > bss look like "part of u-boot", when it is really not. It is just a > chunk of "zero'ed" ram, located anywhere the u-boot code decides to put > it. An arbitrary strange address would make this more apparent. Hi Bill, What's the advantage of having the bss not be located next to U-Boot? The big disadvantage of picking an arbitrary address for the bss is that there's now 1 more magical section of SDRAM that the user needs to know shouldn't be used. I already field enough question from people that corrupt their exception vectors or stack/malloc pool/u-boot code, I don't want to add more bss questions:) Best, Peter PS. please keep the original email recipients on CC ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
On Tue, 2009-10-06 at 19:51 +0200, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <1254843932.24664.2083.ca...@localhost.localdomain> you wrote: > > > > I personally like the current implementation of putting the bss after > > the entire U-Boot image. It keeps U-Boot's code, malloc pool, stack, > > bss, etc all in the same general area which is nice, and has the side > > benefit that the bootpg won't be overwritten. > > OK, if you think so... > > > I know ORing in 0x10 is a bit ugly, but what's the real downside of > > doing it? > > Nothing. I just hate to allocate the bss at 0x0, because this is > actually incorrect - it's the result of an address overflow / > truncation, and pretty much misleading to someone trying to read and > understand the code. For the linked image, it does not _look_ as if > the bss was located _after_ the U-Boot image, it looks detached and > allocated in low RAM. Do you have a preference Kumar? You're probably going to be the first in line to have to deal with any resulting confusion:) I personally would rank the options: 1. OR in an offset to the bss address and leave some good comments in the linker script and commit message 2. Make the bss the last section like other PPC boards which would result in the bootpg sometimes being overwritten 3. Put the bss at an arbitrary address Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
Hi Wolfgang, > So far U-Boot is actually a 32 bit boot loader; address calculations > like this "just wrap around". So far this has not caused problems yet; > what has caused problems is that we can have overlapping sections on > 4xx. Also it's probably overkill that each board has it's own linker > script. I added some debug and came to the same conclusion about the wrapping math. Full ack on the linker script consolidation. > I would like to see this fixed in this process. Maybe Stefan finds > some spare cycles to address this. > > > > Where is BSS on 44x boards? I dont see any reason we shouldn't be > > > able to put it at the same location. > > > > >From the XPedite1000: > > > > [ 0] NULL 00 00 00 0 > > 0 0 > > [ 1] .resetvec PROGBITSfffc 03f2e4 04 00 AX 0 > > 0 1 > > [ 2] .bootpg PROGBITSf000 03e2e8 000250 00 AX 0 > > 0 1 > > [ 3] .text PROGBITSfff8 94 0303b0 00 AX 0 > > 0 4 > > [ 4] .rodata PROGBITSfffb03b0 030444 00a14c 00 A 0 > > 0 4 > > [ 5] .relocPROGBITSfffba500 03a594 002280 00 WA 0 > > 0 4 > > [ 6] .data PROGBITSfffbc780 03c814 00088c 00 WA 0 > > 0 4 > > [ 7] .data.rel.local PROGBITSfffbd00c 03d0a0 000a98 00 WA 0 > > 0 4 > > [ 8] .data.rel.ro.loca PROGBITSfffbdaa4 03db38 b0 00 WA 0 > > 0 4 > > [ 9] .data.rel PROGBITSfffbdb54 03dbe8 000100 00 WA 0 > > 0 4 > > [10] .u_boot_cmd PROGBITSfffbdc54 03dce8 000600 00 WA 0 > > 0 4 > > [11] .bss NOBITS fffbe300 03e2e8 011c44 00 WA 0 > > 0 4 > > > > I shied away from this for the 2 reasons above - the bootpg section will > > be wiped out when the bss is cleared for images near their maximum size > > I think it will not be needed any more by then. Its not currently used (at least on 85xx), but I know using it had been mentioned in the past. There's a >3K chunk that's sitting empty right now that could be used. All things being equal I think it would be ideal not to trash a section of U-Boot code - it could be useful and at some point someone's going to be banging their head on the wall trying to figure out why some chunk of assembly code isn't working. > > If everyone is OK with the limitation of #1 above I can make the 85xx > > act like the other PPC boards. The only downside I see is that we could > > never put any non-reset related code in the bootpg. > > What about my suggestion to chose a fixed (random, non-zero) address? I'd vote against this. It'd have to be some area in low memory and people would be bound to accidentally stomp on it and cause all sorts of odd errors- like overwriting the exception vectors, but harder to debug. I personally like the current implementation of putting the bss after the entire U-Boot image. It keeps U-Boot's code, malloc pool, stack, bss, etc all in the same general area which is nice, and has the side benefit that the bootpg won't be overwritten. I know ORing in 0x10 is a bit ugly, but what's the real downside of doing it? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
On Tue, 2009-10-06 at 17:04 +0200, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <1de23de0-b901-4e15-845c-43889ee0b...@kernel.crashing.org> you > wrote: > > > ... > > > But bss is NOLOAD, and the actual location in the flash is just a > > > fiction - we never use anything of this but the start address. > > > > Where is BSS on 44x boards? I dont see any reason we shouldn't be > > able to put it at the same location. > > Um... maybe Stefan should explain this. I don't want to have to ;-) The 44x boards look the same as 85xx used to be - the bss is the last section in the ELF, but it has the downside that the code in the bootpg will be zeroed out along with the bss if the U-Boot image is near its maximum size and the bss overlaps the bootpg. Kumar prevented this (whether he meant to or not:) by putting the bss after the entire U-Boot image. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
On Tue, 2009-10-06 at 09:07 -0500, Kumar Gala wrote: > >>> This whole "bss at 0x0" is a myth to me. > >> > >> Do a readelf on most MPC8548 boards, eg MPC8548CDS. __bss_start is > >> also > >> located at 0x0 for these boards, which is the issue this patch > >> attempted > >> to address. > > > > I know that this _is_ the case. My questions meant: _why_ is this the > > case? My speculkation is that it's just by accident, because the bss > > was located just after the instruction allocated for the reset > > vector; this being at 0xFFFC on most 8xxx systems, the address > > counter wrapped around on 32 bit tool chains, resulting in 0x0. > > > >> The current U-Boot code is already relocating this bss address > >> higher up > >> in SDRAM during relocation, all this patch does is add 0x10 bytes to > >> that address. I had assumed the current code was working, but > >> perhaps > >> there's a bigger issue... > > > > I don;t think it's an issue. The code seems to work. But I wonder if > > we could not simplify all this buy defining an arbitrary, non-zero > > address. > > > >> I shied away from this since as the text/data/bss grow at some > >> point the > >> bss is going to overlap with the boot page. I think ld would > >> intelligently wrap the bss around the boot page, but U-Boot won't > >> be so > >> intelligent when the bss is zeroed out:) The bss address range would > >> also wrap back around to 0x0. I didn't feel good about zeroing out > >> the > > > > But bss is NOLOAD, and the actual location in the flash is just a > > fiction - we never use anything of this but the start address. My concern was that we use __bss_start and _end to calculate the size of the bss to zero out. If the bss wraps, I'd be concerned about what gets cleared as _end would be truncated to a low memory address while __bss_start would be a high memory address. Or other similar problems - I didn't investigate what would really happen, I was just worried what could happen:) > Where is BSS on 44x boards? I dont see any reason we shouldn't be > able to put it at the same location. >From the XPedite1000: [ 0] NULL 00 00 00 0 0 0 [ 1] .resetvec PROGBITSfffc 03f2e4 04 00 AX 0 0 1 [ 2] .bootpg PROGBITSf000 03e2e8 000250 00 AX 0 0 1 [ 3] .text PROGBITSfff8 94 0303b0 00 AX 0 0 4 [ 4] .rodata PROGBITSfffb03b0 030444 00a14c 00 A 0 0 4 [ 5] .relocPROGBITSfffba500 03a594 002280 00 WA 0 0 4 [ 6] .data PROGBITSfffbc780 03c814 00088c 00 WA 0 0 4 [ 7] .data.rel.local PROGBITSfffbd00c 03d0a0 000a98 00 WA 0 0 4 [ 8] .data.rel.ro.loca PROGBITSfffbdaa4 03db38 b0 00 WA 0 0 4 [ 9] .data.rel PROGBITSfffbdb54 03dbe8 000100 00 WA 0 0 4 [10] .u_boot_cmd PROGBITSfffbdc54 03dce8 000600 00 WA 0 0 4 [11] .bss NOBITS fffbe300 03e2e8 011c44 00 WA 0 0 4 I shied away from this for the 2 reasons above - the bootpg section will be wiped out when the bss is cleared for images near their maximum size and I wasn't sure if there were any ramifications about the bss wrapping around to 0. Other arches must have a similar issue which would somewhat imply: 1. No one cares if their bootpg/reset vector is cleared 2. U-Boot works even if the bss wraps around to 0. If everyone is OK with the limitation of #1 above I can make the 85xx act like the other PPC boards. The only downside I see is that we could never put any non-reset related code in the bootpg. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] 85xx: Ensure BSS segment doesn't start at address 0x0
> > --- a/cpu/mpc85xx/u-boot.lds.S > > +++ b/cpu/mpc85xx/u-boot.lds.S > > @@ -131,6 +131,14 @@ SECTIONS > > > >. = RESET_VECTOR_ADDRESS + 0x4; > > > > + /* > > + * Make sure that the bss segment doesn't start at 0x0, otherwise its > > + * address won't be updated during relocation fixups > > + */ > > +#if !((RESET_VECTOR_ADDRESS + 0x4) & 0x) > > This seems to be a pretty complicated way of writing > > #if (RESET_VECTOR_ADDRESS == 0xFFFC) > > ? Good point. > > + . |= 0x10; > > I'm not sure if all this is always doing what we want, or if it's > always working the same way. When building on 32 bit machines, dot > will wrap around for "0xFFFC + 4" and result in 0; ". |= 0x10" > makes it 0x10 then. > > When built using a 64 bit host, 0xFFFC + 4 = 0x1, and the > OR makes it 0x10010. But here this OR was not needed. The 64-bit addresses will need to be truncated to 32-bits when the u-boot ELF is actually generated, so I think we'd get 0x10 when building on a 32 or 64 bit machine. I'll verify. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
On Tue, 2009-10-06 at 09:32 +0200, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <1254783670-21301-1-git-send-email-pty...@xes-inc.com> you wrote: > > It looks like the 85xx platform is the only one which has boards > > with the bss at 0x0. It uses a slightly different linker script > > format which puts the bss after the reset vector, which is > > 0xfffc + 4 for a number of boards. Other platforms don't put > > their bss in a similar location, so they don't have this issue. > > I verified this by running MAKEALL and printing the bss address > > as well. > > > > A few bytes of RAM are wasted for boards which used to have the > > bss at 0x0 FWIW. > > I never understood how this is supposed to work at all. > > We have two phases of operation: > > 1) before relocation to RAM. Here we actually do not have a working >bss segment at all, no mater what the linker may think. Agreed. > 2) after relocation to RAM. Here we reserve space for the BSS at the >end (well, more or less) of the RAM. Agreed. > This whole "bss at 0x0" is a myth to me. Do a readelf on most MPC8548 boards, eg MPC8548CDS. __bss_start is also located at 0x0 for these boards, which is the issue this patch attempted to address. The current U-Boot code is already relocating this bss address higher up in SDRAM during relocation, all this patch does is add 0x10 bytes to that address. I had assumed the current code was working, but perhaps there's a bigger issue... FWIW, it looked like non-85xx PPC boards seem to do something like: 0xfff0 text 0xfff5 data 0xfff6 bss 0x "boot page"/reset vectors I shied away from this since as the text/data/bss grow at some point the bss is going to overlap with the boot page. I think ld would intelligently wrap the bss around the boot page, but U-Boot won't be so intelligent when the bss is zeroed out:) The bss address range would also wrap back around to 0x0. I didn't feel good about zeroing out the bootpage and wasn't sure what the ramifications of having the bss address wrap back around to 0x0 were (or if the wrapping is even a concern) so didn't use this memory layout. Other arches seem to do this though... Anyway, this patch just adds 0x10 to boards that already have their bss at 0x0. But maybe those boards already have issues:) I'll investigate at bit and follow up. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] 85xx: Preprocess link scripts
On Tue, 2009-10-06 at 09:28 +0200, Wolfgang Denk wrote:
> Dear Peter Tyser,
>
> In message <1254783670-21301-2-git-send-email-pty...@xes-inc.com> you wrote:
> > This allows for fancy conditionals and inclusions
> >
> > Signed-off-by: Peter Tyser
> > ---
> > cpu/mpc85xx/config.mk |2 +-
> > cpu/mpc85xx/{u-boot-nand.lds => u-boot-nand.lds.S} |0
> > cpu/mpc85xx/{u-boot.lds => u-boot.lds.S} |0
> > 3 files changed, 1 insertions(+), 1 deletions(-)
> > rename cpu/mpc85xx/{u-boot-nand.lds => u-boot-nand.lds.S} (100%)
> > rename cpu/mpc85xx/{u-boot.lds => u-boot.lds.S} (100%)
> >
> > diff --git a/cpu/mpc85xx/config.mk b/cpu/mpc85xx/config.mk
> > index beb3514..03a34a9 100644
> > --- a/cpu/mpc85xx/config.mk
> > +++ b/cpu/mpc85xx/config.mk
> > @@ -27,4 +27,4 @@ PLATFORM_CPPFLAGS += -ffixed-r2 -Wa,-me500 -msoft-float
> > -mno-string
> > PLATFORM_CPPFLAGS +=$(call cc-option,-mno-spe)
> >
> > # Use default linker script. Board port can override in board/*/config.mk
> > -LDSCRIPT := $(SRCTREE)/cpu/mpc85xx/u-boot.lds
> > +LDSCRIPT := $(SRCTREE)/cpu/mpc85xx/u-boot.lds.S
> > diff --git a/cpu/mpc85xx/u-boot-nand.lds b/cpu/mpc85xx/u-boot-nand.lds.S
> > similarity index 100%
> > rename from cpu/mpc85xx/u-boot-nand.lds
> > rename to cpu/mpc85xx/u-boot-nand.lds.S
> > diff --git a/cpu/mpc85xx/u-boot.lds b/cpu/mpc85xx/u-boot.lds.S
> > similarity index 100%
> > rename from cpu/mpc85xx/u-boot.lds
> > rename to cpu/mpc85xx/u-boot.lds.S
>
> Why would such a rename be needed?
>
> The linker scripts aready get preprocessed, even without this rename.
> See the rule
>
> 369 $(obj)u-boot.lds: $(LDSCRIPT)
> 370 $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P
> - <$^ >$@
>
> in the top level Makefile.
Argh, I see. I was using the fancy lib_blackfin/u-boot.lds.S as a
reference and assumed the .S was needed. Ignore this patch.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
Hi Jocke,
> > > There are a few change which would further improve relocation that Jocke
> > > and I want to get merged. Whether these improvements occur in this
> > > release or the next is not a big deal to me.
> > > 1. Fix relocation of NULL pointers.
> > > eg the following code would print the relocation fixup offset instead of
> > > the expected NULL.
> > >void weak_fun(void) __attribute__((weak));
> > >printf("weak_fun:%p\n", weak_fun);
> > > This was already an issue, so we're not breaking anything in the "reloc"
> > > branch
> > >
> > > 2. Move relocation fixup code to C-code
> > >
> > > 3. Possibly get true relocation working so that U-Boot could be located
> > > anywhere and still execute.
> >
> > I tend to get all of this (as far as it's available and considered to
> > be ready) into this release, so we have it all in one big block.
>
> 3. isn't ready and won't be for a while more
>
> 1. is just a small fix the the existing asm reloc functions. Pretty much
>ready but needs some linker tweeks it seems. No idea if other
>boards than 85xx also needs a linker tweak or not.
It looks like 85xx is the only arch that needed linker script tweaks. I
just submitted some patches a bit ago.
> 2. is 1 in C and some common supporting asm for ppc. Any idea were
>to put common asm files for ppc? I was hoping I could get away with
>just 83xx and the rest could be done later by interested parties?
Assuming the 85xx link script changes are accepted, what's the gameplan
now? #1 is pretty trivial (the original patch that spawned this thread
with slight tweaks) and should be easy to get in this merge window.
That would get us to the point that relocation is fully functional,
including non-relocation of NULL pointers.
#2 looks more involved and prone to errors as it requires some shuffling
of registers in assembly for all architectures. Are we aiming for
getting #2 across all architectures in this window? I should be able to
implement and test it on 85xx, 86xx, and 44x, and Jocke's tested on
83xx. I don't think I could do the rest of the arches by the end of
this week though. Any other takers? Save it for the next merge window?
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
It looks like the 85xx platform is the only one which has boards
with the bss at 0x0. It uses a slightly different linker script
format which puts the bss after the reset vector, which is
0xfffc + 4 for a number of boards. Other platforms don't put
their bss in a similar location, so they don't have this issue.
I verified this by running MAKEALL and printing the bss address
as well.
A few bytes of RAM are wasted for boards which used to have the
bss at 0x0 FWIW.
These changes should be applied to the "reloc" branch.
Peter Tyser (2):
85xx: Preprocess link scripts
85xx: Ensure BSS segment doesn't start at address 0x0
cpu/mpc85xx/config.mk |2 +-
cpu/mpc85xx/{u-boot-nand.lds => u-boot-nand.lds.S} |0
cpu/mpc85xx/{u-boot.lds => u-boot.lds.S} |8
3 files changed, 9 insertions(+), 1 deletions(-)
rename cpu/mpc85xx/{u-boot-nand.lds => u-boot-nand.lds.S} (100%)
rename cpu/mpc85xx/{u-boot.lds => u-boot.lds.S} (94%)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] 85xx: Ensure BSS segment doesn't start at address 0x0
When U-Boot is relocated from flash to RAM pointers are modified
accordingly. However, pointers initialzed with NULL values should not
be modified so that they maintain their intended NULL value. The
address of the BSS segment must be modified during relocation which
means that it must not have a NULL value.
Signed-off-by: Peter Tyser
---
cpu/mpc85xx/u-boot.lds.S |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/cpu/mpc85xx/u-boot.lds.S b/cpu/mpc85xx/u-boot.lds.S
index a347cd1..ef3de66 100644
--- a/cpu/mpc85xx/u-boot.lds.S
+++ b/cpu/mpc85xx/u-boot.lds.S
@@ -131,6 +131,14 @@ SECTIONS
. = RESET_VECTOR_ADDRESS + 0x4;
+ /*
+ * Make sure that the bss segment doesn't start at 0x0, otherwise its
+ * address won't be updated during relocation fixups
+ */
+#if !((RESET_VECTOR_ADDRESS + 0x4) & 0x)
+ . |= 0x10;
+#endif
+
__bss_start = .;
.bss (NOLOAD) :
{
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] 85xx: Preprocess link scripts
This allows for fancy conditionals and inclusions
Signed-off-by: Peter Tyser
---
cpu/mpc85xx/config.mk |2 +-
cpu/mpc85xx/{u-boot-nand.lds => u-boot-nand.lds.S} |0
cpu/mpc85xx/{u-boot.lds => u-boot.lds.S} |0
3 files changed, 1 insertions(+), 1 deletions(-)
rename cpu/mpc85xx/{u-boot-nand.lds => u-boot-nand.lds.S} (100%)
rename cpu/mpc85xx/{u-boot.lds => u-boot.lds.S} (100%)
diff --git a/cpu/mpc85xx/config.mk b/cpu/mpc85xx/config.mk
index beb3514..03a34a9 100644
--- a/cpu/mpc85xx/config.mk
+++ b/cpu/mpc85xx/config.mk
@@ -27,4 +27,4 @@ PLATFORM_CPPFLAGS += -ffixed-r2 -Wa,-me500 -msoft-float
-mno-string
PLATFORM_CPPFLAGS +=$(call cc-option,-mno-spe)
# Use default linker script. Board port can override in board/*/config.mk
-LDSCRIPT := $(SRCTREE)/cpu/mpc85xx/u-boot.lds
+LDSCRIPT := $(SRCTREE)/cpu/mpc85xx/u-boot.lds.S
diff --git a/cpu/mpc85xx/u-boot-nand.lds b/cpu/mpc85xx/u-boot-nand.lds.S
similarity index 100%
rename from cpu/mpc85xx/u-boot-nand.lds
rename to cpu/mpc85xx/u-boot-nand.lds.S
diff --git a/cpu/mpc85xx/u-boot.lds b/cpu/mpc85xx/u-boot.lds.S
similarity index 100%
rename from cpu/mpc85xx/u-boot.lds
rename to cpu/mpc85xx/u-boot.lds.S
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
Hi Wolfgang, > > My "fix" to the linker script was to change: > > __bss_start = .; > > into: > > __bss_start = . | 4; > > > > ie, a big hack, but it did work:) I'll take a peek at a more proper > > link script workaround. > > 32 bit alignment of the BSS segment might not be sufficient. Be > careful! I've tried a few ways to ensure the BSS isn't at address 0x0, and they all seem to have their shortcomings. I'm currently leaning towards doing something along the lines of the above, ie ORing 0x10 into the BSS address. I had assumed 8 or 16 bit alignment of the BSS would be sufficient. Could you give a little background on your warning above about 32 bit alignment being insufficient? Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
On Sat, 2009-10-03 at 14:13 +0200, Wolfgang Denk wrote:
> Dear Joakim Tjernlund,
>
> In message
> you
> wrote:
> >
> > > It seems discussion stopped here. Is it correct forme to assume that
> > > there is no patch available yet that is considered ripe to be added
> > > (to the "reloc" branch) ?
> >
> > That is correct. Some boards(85xx) seem to have bss_start at 0 sometimes
> > and that won't play nice with this patch. Peter was looking into this but
> > seems like he isn't finished yet.
> >
> > Also, I have been looking at moving this relocation to C-code and it isn't
> > quite ready yet. What is left is to modify all ppc boards to use this new
> > C-code
>
> So how should we proceed? My plan was to merge the "reloc" branch by
> the end of next week. Is this still realistic?
That plan is realistic. The executive summary is:
The current "reloc" branch works, and is an improvement on U-Boot's
previous "semi-reolcation", so we should merge it for this release.
There are a few change which would further improve relocation that Jocke
and I want to get merged. Whether these improvements occur in this
release or the next is not a big deal to me.
1. Fix relocation of NULL pointers.
eg the following code would print the relocation fixup offset instead of
the expected NULL.
void weak_fun(void) __attribute__((weak));
printf("weak_fun:%p\n", weak_fun);
This was already an issue, so we're not breaking anything in the "reloc"
branch
2. Move relocation fixup code to C-code
3. Possibly get true relocation working so that U-Boot could be located
anywhere and still execute.
Jocke has 1 and 2 mostly figured out, I just need some time to play with
the linker scripts a bit more to ensure nothing breaks. (Sorry Jocke,
its been a busy week).
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] standalone: Increment XF_VERSION to 6
Signed-off-by: Peter Tyser
---
This should be squashed with the top-most commit in the
reloc branch.
Ideally we could fold
"[PATCH/RFC] arm/microblaze/nios/nios2/sh: Remove relocation fixups"
into the reloc branch too so we don't have to increment XF_VERSION
again in the next release. I have no way of testing these
arches though
include/exports.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/exports.h b/include/exports.h
index 16ea03a..2e8fd8b 100644
--- a/include/exports.h
+++ b/include/exports.h
@@ -47,7 +47,7 @@ enum {
XF_MAX
};
-#define XF_VERSION 5
+#define XF_VERSION 6
#if defined(CONFIG_I386)
extern gd_t *global_data;
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
On Mon, 2009-09-28 at 16:41 +0200, Joakim Tjernlund wrote:
> Peter Tyser wrote on 28/09/2009 14:45:46:
> >
> > On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
> > > Peter Tyser wrote on 28/09/2009 06:31:28:
> > > >
> > > > On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
> > > > > Wolfgang Denk wrote on 23/09/2009 20:23:14:
> > > > > >
> > > > > > Dear Peter Tyser,
> > > > > >
> > > > > > In message <1253710639.3968.19.ca...@ptyser-laptop> you wrote:
> > > > > > >
> > > > > > > My "fix" to the linker script was to change:
> > > > > > > __bss_start = .;
> > > > > > > into:
> > > > > > > __bss_start = . | 4;
> > > > > > >
> > > > > > > ie, a big hack, but it did work:) I'll take a peek at a more
> > > > > > > proper
> > > > > > > link script workaround.
> > > > > >
> > > > > > 32 bit alignment of the BSS segment might not be sufficient. Be
> > > > > > careful!
> > > > >
> > > > > Any progress on this ?
> > > >
> > > > I've been swamped the last few days, but think I have a workaround. I
> > > > hope to test it tomorrow or tues. I'll send an email when I have a more
> > > > definitive answer.
> > > >
> > > > > > > Nice! It'd be great to have the magical 20 lines of assembly put
> > > > > > > into
> > > > > > > some semi-understandable c.
> > > > > >
> > > > > > :-)
> > > > >
> > > > > I have worked some more on this but all boards need to be converted
> > > > > to use
> > > > > the new C-variants.
> > > >
> > > > Great!
> > > >
> > > > > Anyhow, I have also been thinking/working on making U-boot
> > > > > fully PIC and reached a important conclusion. The GOT holds absolute
> > > > > ptr values and there is not much one can do about it sans modifying
> > > > > gcc.
> > > > > So before u-boot is relocated to RAM one must manually add any offset
> > > > > to
> > > > > all global/static data and string literals. The majority of strings
> > > > > are passed directly to printf and friends so the offset can be added
> > > > > inside
> > > > > printf. The remaining few data accesses needs to be dealt with
> > > > > directly, example:
> > > > > - for (init_fnc_ptr = init_sequence; *init_fnc_ptr;
> > > > > ++init_fnc_ptr) {
> > > > > + for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; +
> > +init_fnc_ptr) {
> > > > >
> > > > > Only code called before relocation to RAM needs this, mostly the _f()
> > > > > functions.
> > > > > Would this be an acceptable change?
> > > >
> > > > Could you describe the advantages of generating a fully PIC U-Boot
> > > > image? I understand you could execute the image from different places
> > > > in flash, but on the boards I've worked with this isn't a huge concern.
> > > > For example, its possible to have a preliminary flash mapping that
> > > > U-Boot executes from, then after relocation to RAM that flash mapping
> > > > can be modified. So where U-Boot initially executes from isn't all that
> > > > important for me. Is there some killer feature that a fully PIC U-Boot
> > > > provides to make adding the got_off() workarounds you mention
> > > > worthwhile?
> > >
> > > For me, it is mainly to be to have two u-boot partitions and
> > > be able to select one to boot from. This makes it safer to
> > > update u-boot in the field.
>
> Peter, I just discovered that my gcc 3.4.6 allows me to use -mrelocatable
> with -fpie
> -fpie is about the same as -fpic and -fPIE is similar to -fPIC
> -fpie generates smaller code so one could consider using -fpie and
> -mrelocatable
> However -fpic/-fpie needs some fixes to the relocation code, but a quick hack
> by me works on my board.
>
> Does -fpie and -mrelocatable compile for you and do you have a non zero fixup
> section?
-fpie and -mrelocatable does compile for me (tested on the XPedite5370
with gcc 4.2.2) and has a non-zero fixup section. However, the -fpie
U-Boot image is slightly larger:
pty...@petert u-boot $ size u-boot.PIC
textdata bss dec hex filename
304300 28644 33156 366100 59614 u-boot.PIC
pty...@petert u-boot $ size u-boot.pie
textdata bss dec hex filename
304508 28624 33156 366288 596d0 u-boot.pie
Let me know if I can provide any additional detail.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
> > > >
> > > > > Anyhow, I have also been thinking/working on making U-boot
> > > > > fully PIC and reached a important conclusion. The GOT holds absolute
> > > > > ptr values and there is not much one can do about it sans modifying
> > > > > gcc.
> > > > > So before u-boot is relocated to RAM one must manually add any offset
> > > > > to
> > > > > all global/static data and string literals. The majority of strings
> > > > > are passed directly to printf and friends so the offset can be added
> > > > > inside
> > > > > printf. The remaining few data accesses needs to be dealt with
> > > > > directly, example:
> > > > > - for (init_fnc_ptr = init_sequence; *init_fnc_ptr;
> > > > > ++init_fnc_ptr) {
> > > > > + for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; +
> > +init_fnc_ptr) {
> > > > >
> > > > > Only code called before relocation to RAM needs this, mostly the _f()
> > > > > functions.
> > > > > Would this be an acceptable change?
> > > >
> > > > Could you describe the advantages of generating a fully PIC U-Boot
> > > > image? I understand you could execute the image from different places
> > > > in flash, but on the boards I've worked with this isn't a huge concern.
> > > > For example, its possible to have a preliminary flash mapping that
> > > > U-Boot executes from, then after relocation to RAM that flash mapping
> > > > can be modified. So where U-Boot initially executes from isn't all that
> > > > important for me. Is there some killer feature that a fully PIC U-Boot
> > > > provides to make adding the got_off() workarounds you mention
> > > > worthwhile?
> > >
> > > For me, it is mainly to be to have two u-boot partitions and
> > > be able to select one to boot from. This makes it safer to
> > > update u-boot in the field.
> >
> > X-ES requires this same functionality of dual booting. We generally
> > have a jumper on each card that swaps 2 chip select 0 and 1 so that
> > either can be booted from (assuming CS 0 is always used to load U-Boot).
> > The same U-Boot image can be programmed to both flashes. After U-Boot
> > relocates to RAM, we remap the flashes (in
> > board/xes/xpedite5370/xpedite5370.c: flash_cs_fixup()) to provide a
> > common flash layout regardless of which flash we booted from. Would it
> > be possible to do something similar in your hardware setup so that the
> > same U-Boot image could be loaded from either flash partition without
> > the got_off() fixups you mention above?
>
> Nope, we don't have that extra HW support and won't have in the future
> either. This type of extra HW logic should not be needed and even if you
> do have it, how do you flip a jumper remotely? Can be done I am sure, but
> all this extra HW logic should not be needed at all.
How do you provide true redundancy without some means of changing a chip
select, hardware strapping pin, etc? Without hardware support you only
have 1 code entry point, correct? If that fails, the board is toast,
regardless if you have redundant U-Boot images. The "jumper" I was
refering to could be a physical jumper, a non-volatile gpio device,
FPGA, IPMI controller, etc.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
On Mon, 2009-09-28 at 09:34 +0200, Joakim Tjernlund wrote:
> Peter Tyser wrote on 28/09/2009 06:31:28:
> >
> > On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
> > > Wolfgang Denk wrote on 23/09/2009 20:23:14:
> > > >
> > > > Dear Peter Tyser,
> > > >
> > > > In message <1253710639.3968.19.ca...@ptyser-laptop> you wrote:
> > > > >
> > > > > My "fix" to the linker script was to change:
> > > > > __bss_start = .;
> > > > > into:
> > > > > __bss_start = . | 4;
> > > > >
> > > > > ie, a big hack, but it did work:) I'll take a peek at a more proper
> > > > > link script workaround.
> > > >
> > > > 32 bit alignment of the BSS segment might not be sufficient. Be
> > > > careful!
> > >
> > > Any progress on this ?
> >
> > I've been swamped the last few days, but think I have a workaround. I
> > hope to test it tomorrow or tues. I'll send an email when I have a more
> > definitive answer.
> >
> > > > > Nice! It'd be great to have the magical 20 lines of assembly put into
> > > > > some semi-understandable c.
> > > >
> > > > :-)
> > >
> > > I have worked some more on this but all boards need to be converted to use
> > > the new C-variants.
> >
> > Great!
> >
> > > Anyhow, I have also been thinking/working on making U-boot
> > > fully PIC and reached a important conclusion. The GOT holds absolute
> > > ptr values and there is not much one can do about it sans modifying gcc.
> > > So before u-boot is relocated to RAM one must manually add any offset to
> > > all global/static data and string literals. The majority of strings
> > > are passed directly to printf and friends so the offset can be added
> > > inside
> > > printf. The remaining few data accesses needs to be dealt with directly,
> > > example:
> > > - for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr)
> > > {
> > > + for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr;
> > > ++init_fnc_ptr) {
> > >
> > > Only code called before relocation to RAM needs this, mostly the _f()
> > > functions.
> > > Would this be an acceptable change?
> >
> > Could you describe the advantages of generating a fully PIC U-Boot
> > image? I understand you could execute the image from different places
> > in flash, but on the boards I've worked with this isn't a huge concern.
> > For example, its possible to have a preliminary flash mapping that
> > U-Boot executes from, then after relocation to RAM that flash mapping
> > can be modified. So where U-Boot initially executes from isn't all that
> > important for me. Is there some killer feature that a fully PIC U-Boot
> > provides to make adding the got_off() workarounds you mention
> > worthwhile?
>
> For me, it is mainly to be to have two u-boot partitions and
> be able to select one to boot from. This makes it safer to
> update u-boot in the field.
X-ES requires this same functionality of dual booting. We generally
have a jumper on each card that swaps 2 chip select 0 and 1 so that
either can be booted from (assuming CS 0 is always used to load U-Boot).
The same U-Boot image can be programmed to both flashes. After U-Boot
relocates to RAM, we remap the flashes (in
board/xes/xpedite5370/xpedite5370.c: flash_cs_fixup()) to provide a
common flash layout regardless of which flash we booted from. Would it
be possible to do something similar in your hardware setup so that the
same U-Boot image could be loaded from either flash partition without
the got_off() fixups you mention above?
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
On Sun, 2009-09-27 at 15:15 +0200, Joakim Tjernlund wrote:
> Wolfgang Denk wrote on 23/09/2009 20:23:14:
> >
> > Dear Peter Tyser,
> >
> > In message <1253710639.3968.19.ca...@ptyser-laptop> you wrote:
> > >
> > > My "fix" to the linker script was to change:
> > > __bss_start = .;
> > > into:
> > > __bss_start = . | 4;
> > >
> > > ie, a big hack, but it did work:) I'll take a peek at a more proper
> > > link script workaround.
> >
> > 32 bit alignment of the BSS segment might not be sufficient. Be
> > careful!
>
> Any progress on this ?
I've been swamped the last few days, but think I have a workaround. I
hope to test it tomorrow or tues. I'll send an email when I have a more
definitive answer.
> > > Nice! It'd be great to have the magical 20 lines of assembly put into
> > > some semi-understandable c.
> >
> > :-)
>
> I have worked some more on this but all boards need to be converted to use
> the new C-variants.
Great!
> Anyhow, I have also been thinking/working on making U-boot
> fully PIC and reached a important conclusion. The GOT holds absolute
> ptr values and there is not much one can do about it sans modifying gcc.
> So before u-boot is relocated to RAM one must manually add any offset to
> all global/static data and string literals. The majority of strings
> are passed directly to printf and friends so the offset can be added inside
> printf. The remaining few data accesses needs to be dealt with directly,
> example:
> - for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> + for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr;
> ++init_fnc_ptr) {
>
> Only code called before relocation to RAM needs this, mostly the _f()
> functions.
> Would this be an acceptable change?
Could you describe the advantages of generating a fully PIC U-Boot
image? I understand you could execute the image from different places
in flash, but on the boards I've worked with this isn't a huge concern.
For example, its possible to have a preliminary flash mapping that
U-Boot executes from, then after relocation to RAM that flash mapping
can be modified. So where U-Boot initially executes from isn't all that
important for me. Is there some killer feature that a fully PIC U-Boot
provides to make adding the got_off() workarounds you mention
worthwhile?
Thanks,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] ppc: Fix relocation
On Thu, 2009-09-24 at 00:31 +0200, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <1253550038-16734-1-git-send-email-pty...@xes-inc.com> you wrote: > > This series attempts to fix relocation to RAM for ppc boards. > > > > I split the patches up pretty liberally, let me know if you'd like > > them organized differently. > > > > I tried to be thorough during the changes (especially #1), let me > > know if I missed anything, there's lots of linker scripts for ppc > > boards:) > > > > Peter Tyser (13): > > ppc: Enable full relocation to RAM > > ppc: Check for compilers that don't support relocation > > ppc: Remove board.c relocation fixups > > ppc: Remove pci config table pointer relocation fixups > > ppc: Remove extable relocation fixups > > ppc: Remove board-specific command table relocation fixups > > tsec: Remove PHY command relocation fixups > > fpga: Remove relocation fixups > > mpl: Remove memory test relocation fixups > > lwmon, lwmon5: Remove sysmon POST relocation fixups > > p3mx: Remove serial relocation fixups > > Conditionally perform common relocation fixups > > ppc: Remove reloc_off field from global_data structure > > All patches applied to "reloc" branch. Thanks for all this work. > > So far the only issue I've seen (I didn't do any actual testing yet, > though) is the missing increment to the XF_VERSION value to indicate > incompatibility with older standalone applications. If you agree, I > woul like to squash this into the topmost commit on the "reloc" > branch? Hi Wolfgang, Is the plan to apply these patches for the upcoming release, or the release after that one? I ask because some of X-ES's boards broke when the 85xx linker script was consolidated. These patches fix the breakage, but if these patches won't be included in the upcoming release I'll send a small fixup just for X-ES's boards. Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Add command 440epx_r
> > + switch (ppc440epx_reg[i].address) {
> > + case 0x00b0:
> > + value = mfdcr ( 0x00b0 );
>
> Please drop the spaces around the braces:
>
> value = mfdcr(0x00b0);
>
> Also in the other cases below.
> > + case 0x0026:
> > + value = mfdcr ( 0x0026 );
> > + break;
> > + default:
> > + printf ("\nERROR: unknown DCR address: 0x%x\n",
> > + ppc440epx_reg[i].address);
>
> I would prefer the style func(), without a space before the "(". Most of the
> code uses this code, so its more consistent.
I have the same preferences, as do most people I would guess. I
mentioned this preference to someone else who submitted a patch in the
past and they promptly pointed me to
http://www.denx.de/wiki/U-Boot/CodingStyle
Anyone care if I change the part about ""Lindent -pcs" (adding spaces
before parameters to function calls) is actually used." And adding a
reference to Linux's checkpatch.pl script would be nice too.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: HCU5 board: add register dump
On Thu, 2009-09-24 at 11:21 +0200, Stefan Roese wrote: > On Wednesday 23 September 2009 19:51:24 Niklaus Giger wrote: > > > > Adds a HCU5 board specific cmd reghcu5 to dump about 140 internal > > > > register which define the HW configuration. Needed for documentation > > > > purposes and to compare different settings. > > > > > > Apart from Peter's comments, I also have a more general comment. Please > > > correct me if I'm wring, but this register dump doesn't seem to be HCU5 > > > specific, but PPC440EPx specific. If this is the case, we (you) should > > > probably move this code into the cpu/ppc4xx directory. Perhaps something > > > like: > > > > > > cpu/ppc4xx/440epx_regdump.c > > > > > > What do you think? > > > > I feel honoured if you consider this patch useful for other boards, too. I > > will rename the cmd to "440epx_regdump" unless you have a better idea. > > Thinking a bit more about it, we should probably choose a more generic name, > so that other 4xx variants may use this command as well. How about just using > "regdump"? > > And please base you patch against the "4xx-register-cleanup" branch of my u- > boot-ppc4xx repo. What about adding a common 4xx_reginfo() function instead, then calling it from common/cmd_reginfo.c? Some of the 4xx dumping already in cmd_reginfo.c could also be moved to cpu/ppc4xx/[reginfo.c|cpu.c] to clean it up. Unless there's a good reason to have both "regdump" and "reginfo" commands... Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/13] ppc: Fix relocation
On Thu, 2009-09-24 at 00:31 +0200, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <1253550038-16734-1-git-send-email-pty...@xes-inc.com> you wrote: > > This series attempts to fix relocation to RAM for ppc boards. > > > > I split the patches up pretty liberally, let me know if you'd like > > them organized differently. > > > > I tried to be thorough during the changes (especially #1), let me > > know if I missed anything, there's lots of linker scripts for ppc > > boards:) > > > > Peter Tyser (13): > > ppc: Enable full relocation to RAM > > ppc: Check for compilers that don't support relocation > > ppc: Remove board.c relocation fixups > > ppc: Remove pci config table pointer relocation fixups > > ppc: Remove extable relocation fixups > > ppc: Remove board-specific command table relocation fixups > > tsec: Remove PHY command relocation fixups > > fpga: Remove relocation fixups > > mpl: Remove memory test relocation fixups > > lwmon, lwmon5: Remove sysmon POST relocation fixups > > p3mx: Remove serial relocation fixups > > Conditionally perform common relocation fixups > > ppc: Remove reloc_off field from global_data structure > > All patches applied to "reloc" branch. Thanks for all this work. > > So far the only issue I've seen (I didn't do any actual testing yet, > though) is the missing increment to the XF_VERSION value to indicate > incompatibility with older standalone applications. If you agree, I > woul like to squash this into the topmost commit on the "reloc" > branch? That sounds good to me. 2 additional comments: 1. Might be nice to move the jumptable to the beginning of the global_data struct when we increment XF_VERSION. 2. Depending on when you merge the reloc branch, it would be nice for people to give the patch in "[PATCH/RFC] arm/microblaze/nios/nios2/sh: Remove relocation fixups" a try. It should reduce the bloat on some other arches and will put pressure on other, non-relocatable arches to fix relocation:) Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] ppc: Remove reloc_off field from global_data structure
> In message <1253550038-16734-14-git-send-email-pty...@xes-inc.com> you wrote: > > Now that proper relocation is supported, the reloc_off field is no longer > > necessary. > > > > Note that the location of the standalone application jump table pointer > > in the global data structure is affected by this change, breaking > > execution of standalone applications compiled for previous versions of > > U-Boot. > > We must increment the XF_VERSION value, then. See > doc/README.standalone. Ah, will do. While we're at it, any interest in a follow-up patch which moves the jump table pointer to the 2nd field of global_data, right after the bd field? This would hopefully reduce the breakage of the jt pointer as the global_data structure inevitably changes down the road. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: HCU5 board: add register dump
Hi Niklaus,
> +enum REGISTER_TYPE {
> + DCR,/* Directly Accessed DCR's */
> + IDCR1, /* Indirectly Accessed DCR to SDRAM0_CFGADDR
> and SDRAM0_CFGDATA */
> + IDCR2, /* Indirectly Accessed DCR to EBC0_CFGADDR and
> EBC0_CFGDATA */
> + IDCR3, /* Indirectly Accessed DCR to EBM0_CFGADDR and
> EBM0_CFGDATA */
> + IDCR4, /* Indirectly Accessed DCR to PPM0_CFGADDR and
> PPM0_CFGDATA */
> + IDCR5, /* Indirectly Accessed DCR to CPR0_CFGADDR and
> CPR0_CFGDATA */
> + IDCR6, /* Indirectly Accessed DCR to SDR0_CFGADDR and
> SDR0_CFGDATA */
> + MM /* Directly Accessed MMIO Register */
> +};
The lines above are well over 80 lines.
> +struct cpu_register {
> + char *name;
> + enum REGISTER_TYPE type;
> + unsigned long address;
> +};
> +
> +/* PPC440EPx registers ordered for output
> + * name typeaddrsize
> + * ---
> + */
> +const struct cpu_register ppc440epx_reg[] = {
> + {"EBC0_B0CR ", IDCR2, PB0CR},
> + {"EBC0_B1CR ", IDCR2, PB1CR},
> + {"EBC0_B2CR ", IDCR2, PB2CR},
> + {"EBC0_B3CR ", IDCR2, PB3CR},
> + {"EBC0_B4CR ", IDCR2, PB4CR},
> + {"EBC0_B5CR ", IDCR2, PB5CR},
> + {"EBC0_B0AP ", IDCR2, PB0AP},
> + {"EBC0_B1AP ", IDCR2, PB1AP},
> + {"EBC0_B2AP ", IDCR2, PB2AP},
> + {"EBC0_B3AP ", IDCR2, PB3AP},
You should be able to remove all those empty spaces in the strings above
and use a fancy printf format to get your alignment right.
> +/*
> + * CPU Register dump of PPC440EPx
> + * Output in order of struct ppc440epx_reg
> + */
> +int do_reghcu5(cmd_tbl_t * cmdtp, int flag, int argc, char *argv[])
> +{
> + unsigned int i;
> + unsigned int n;
> + unsigned long value;
> + enum REGISTER_TYPE type;
> +
> + printf
> + ("\nRegister Dump PPC440EPx for comparison with document
> A0001492\n\n");
> + n = sizeof(ppc440epx_reg) / sizeof(ppc440epx_reg[0]);
> + for (i = 0; i < n; i++) {
> + value = 0;
> + type = ppc440epx_reg[i].type;
> + switch (type) {
> + case DCR: /* Directly Accessed DCR's */
> + switch (ppc440epx_reg[i].address) {
> + /* following list includes only registers
> included in struct */
> + case 0x0b0:
> + value = mfdcr(0x0b0);
> + break;
> + case 0x0f0:
> + value = mfdcr(0x0f0);
> + break;
> + case 0x0180:
> + value = mfdcr(0x0180);
> + break;
> + case 0x081:
> + value = mfdcr(0x081);
> + break;
> + case 0x089:
> + value = mfdcr(0x089);
> + break;
> + case 0x077:
> + value = mfdcr(0x077);
> + break;
> + case 0x350:
> + value = mfdcr(0x350);
> + break;
> + case 0x026:
> + value = mfdcr(0x026);
> + break;
Replace all the above "value = ...; break;" with 1 "value =
mfdcr(ppc440epx_reg[i].address); break;"?
> +
> +/* define do_reghcu5 as u-boot command */
> +U_BOOT_CMD(reghcu5, 2, 1, do_reghcu5,
> +"reghcu5 - print register information for HCU5\n",);
This command's help message won't be printed correctly.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
> > I made the same changes recently, but ran into an "issue" that prevented > > me from sending the change upstream. Some boards/arches have the bss at > > address 0 and later relocate it, unlike every other NULL pointer. If > > you don't fix up the bss address, the board will not function. If you > > run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be > > more clear what's going on. I was doing my testing on the XPedite5370 > > fwiw. > > Ouch, the horror continues :( Yeah... Its seemingly never ending:) > > In any case, the change as is would break some other arches. Seems like > > the proper workaround would be to "fix" the 85xx (and other arches) link > > script to locate the bss similar to the 83xx boards. > > Yes, something should be done. Does it work for you with a "fixed" linker > script? My "fix" to the linker script was to change: __bss_start = .; into: __bss_start = . | 4; ie, a big hack, but it did work:) I'll take a peek at a more proper link script workaround. > > It might be nice to consolidate all the ppc relocate code into 1 > > function while we were at it. > > Played around a little and this is what I got sofar, possibly > WS damged and fixups untested: Nice! It'd be great to have the magical 20 lines of assembly put into some semi-understandable c. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers.
On Wed, 2009-09-23 at 13:51 +0200, Joakim Tjernlund wrote:
> NULL is an absolute value and should not be relocated.
> After this correction code like:
> void weak_fun(void) __attribute__((weak));
> printf("weak_fun:%p\n", weak_fun);
> will still print null after relocation.
>
> Signed-off-by: Joakim Tjernlund
> ---
>
> I have only tested this on 83xx and on a somewhat older u-boot.
> The change is exactly the same on all PowerPC platforms though.
Hi Jocke,
I made the same changes recently, but ran into an "issue" that prevented
me from sending the change upstream. Some boards/arches have the bss at
address 0 and later relocate it, unlike every other NULL pointer. If
you don't fix up the bss address, the board will not function. If you
run readelf on an 83xx u-boot image vs a 85xx u-boot image it should be
more clear what's going on. I was doing my testing on the XPedite5370
fwiw.
In any case, the change as is would break some other arches. Seems like
the proper workaround would be to "fix" the 85xx (and other arches) link
script to locate the bss similar to the 83xx boards.
It might be nice to consolidate all the ppc relocate code into 1
function while we were at it.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4 v3] s5pc1xx: add support SMDKC100 board
> >>> > >> Please include a brief readme doc/README.s5pc1xx similar to README.omap > > > > Hi Tom, > > Others may disagree, but I'm personally opposed to creating > > Slugfest over documentation! Nothing gets me more worked up than a documentation discussion:) > I can see you point. If you have the board you likely have the user manual. > In no way do I want a user manual. > > Mostly what I am looking for brief product description and a list of the > configs. Maybe some hints if the setup is tricky. README.omap3 contains > writeups on 6 boards, each get about 10 lines. The README.omap3 looks decent, but even that I would personally have a few issues with the following: 1. The list of omap3 boards is going to get out of date quickly when people don't update README.omap3. Eg devkit8000 already isn't in the list:) 2. I still think the details of how to configure U-Boot for a board, use the ecc commands, and gpio interfaces would still be better placed in a User's Manual. New users will use the User's Manual and experienced users will know how to dig through the code - eg I'm not sure who will reference README.omap3:). Those command names and config names will probably change at some point in the future, and there's a decent chance README.omap3 won't be similarly updated. > The vendor readme is also good if you want to convey board family u-boot > interfaces to other developers. See my writeup of omap gpio in omap3. I see your point. If it were me, I'd throw that documentation in the omap3 gpio driver itself. Its much more likely to be kept in sync when code changes, and if someone is writing low-level U-Boot code, I'd hope they'd be smart enough to track down the gpio driver they need to use. > > board/vendor-specific doc/README. files in most cases. My logic > > is that the people that are compiling and using U-Boot on my company's > > boards will have bought the boards from us, and we should be the ones > > providing them documentation. eg I would guess the vast majority of > > board vendors don't say "for board information consult > > doc/README. in the U-Boot source code", they provide a PDF, text > > document, datasheet, etc about the board and how it can be used. Thus > > the doc/README. doesn't really provide any useful info. > > This is doc/README. OK, I missed that point. SOC documentation does seem more fitting. I personally think low-level details shouldn't be in the SOC doc however. For example, take a look at README.blackfin. There's nothing I could ever change about U-Boot which would require this file to be updated, which is perfect! > > I only care because I hate having to pick through 10 board-specific > > README files every time I make a change the renames a command, adds a > > new command, changes a CONFIG_XYZ name, etc:) > > > > This should be the task of the board/soc maintainer. I think this is debatable. I'd guess most board maintainers don't follow the list closely or care enough to monitor every change and determine if they need to update their board's README file. So if the person making a large change doesn't update relevant READMEs, no one will. Eg, no one added devkit8000 to README.omap3. > > I think README files are good in general, but board-specific details > > should be documented elsewhere such as a product manual. > > > > Anyway, that's my $.02. > > Taking it outside over documentation, Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4 v3] s5pc1xx: add support SMDKC100 board
On Tue, 2009-09-22 at 10:03 -0500, Tom wrote: > Minkyu Kang wrote: > > Adds new board SMDKC100 that uses s5pc100 SoC > > > > Signed-off-by: Minkyu Kang > > Signed-off-by: HeungJun, Kim > > --- > > Changes since v1: > > - arrange env values for more readable > > - make C struct instead of base+offset > > - use MACH_TYPE_SMDKC100 directly > > - fix the CONFIG_SYS_HZ to 1000 > > - enable LOADB, LOADS, BOOTD, XIMG, FPGA > > > > Changes since v2: > > - remove and SZ_XX defines > > - remove the define of machine type > > - remove the unnecessary comment > > > > MAINTAINERS|4 + > > MAKEALL|1 + > > Makefile |3 + > > board/samsung/smdkc100/Makefile| 55 +++ > > board/samsung/smdkc100/config.mk | 16 ++ > > board/samsung/smdkc100/lowlevel_init.S | 215 > > board/samsung/smdkc100/mem_setup.S | 197 ++ > > board/samsung/smdkc100/onenand.c | 83 +++ > > board/samsung/smdkc100/smdkc100.c | 51 +++ > > include/configs/smdkc100.h | 242 > > > > 10 files changed, 867 insertions(+), 0 deletions(-) > > create mode 100644 board/samsung/smdkc100/Makefile > > create mode 100644 board/samsung/smdkc100/config.mk > > create mode 100644 board/samsung/smdkc100/lowlevel_init.S > > create mode 100644 board/samsung/smdkc100/mem_setup.S > > create mode 100644 board/samsung/smdkc100/onenand.c > > create mode 100644 board/samsung/smdkc100/smdkc100.c > > create mode 100644 include/configs/smdkc100.h > > > > Please include a brief readme doc/README.s5pc1xx similar to README.omap Hi Tom, Others may disagree, but I'm personally opposed to creating board/vendor-specific doc/README. files in most cases. My logic is that the people that are compiling and using U-Boot on my company's boards will have bought the boards from us, and we should be the ones providing them documentation. eg I would guess the vast majority of board vendors don't say "for board information consult doc/README. in the U-Boot source code", they provide a PDF, text document, datasheet, etc about the board and how it can be used. Thus the doc/README. doesn't really provide any useful info. I think the doc/README. files have a tendency to get out of date, reference old commands, etc so are often not the best source of reference anyway. eg take a look at doc/README.m5373evb. I'd argue a lot of that info isn't necessary, and some of its duplicated in other places. I only care because I hate having to pick through 10 board-specific README files every time I make a change the renames a command, adds a new command, changes a CONFIG_XYZ name, etc:) I think README files are good in general, but board-specific details should be documented elsewhere such as a product manual. Anyway, that's my $.02. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH/RFC] arm/microblaze/nios/nios2/sh: Remove relocation fixups
These architectures don't need relocation fixups, so reduce their
codesize a bit by defining CONFIG_RELOC_FIXUP_WORKS.
Also remove the reloc_off field from their global data structures
as it is no longer needed.
Note that the location of the standalone application jump table pointer
in the global data structure is affected by this change, breaking
execution of standalone applications compiled for previous versions of
U-Boot.
Signed-off-by: Peter Tyser
---
I apparently forgot to send this yesterday with the rest of the
relocation patches.
If the ppc relocation series just sent gets accepted, this change
should cut out some unneeded code from other arches which
don't use relocation fixups. I haven't compiled any of these arches
though, so take the patch with a grain of salt.
common/stdio.c |4 ++--
include/asm-arm/config.h |3 +++
include/asm-arm/global_data.h|1 -
include/asm-microblaze/config.h |3 +++
include/asm-microblaze/global_data.h |1 -
include/asm-nios/config.h|3 +++
include/asm-nios/global_data.h |1 -
include/asm-nios2/config.h |3 +++
include/asm-nios2/global_data.h |1 -
include/asm-sh/config.h |3 +++
include/asm-sh/global_data.h |1 -
11 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/common/stdio.c b/common/stdio.c
index 5e58dbe..870ddfd 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -201,7 +201,7 @@ int stdio_deregister(char *devname)
int stdio_init (void)
{
-#if !defined(CONFIG_ARM) && !defined(CONFIG_RELOC_FIXUP_WORKS)
+#if !defined(CONFIG_RELOC_FIXUP_WORKS)
/* already relocated for current ARM implementation */
ulong relocation_offset = gd->reloc_off;
int i;
@@ -211,7 +211,7 @@ int stdio_init (void)
stdio_names[i] = (char *) (((ulong) stdio_names[i]) +
relocation_offset);
}
-#endif /* !ARM && !CONFIG_RELOC_FIXUP_WORKS */
+#endif /* !CONFIG_RELOC_FIXUP_WORKS */
/* Initialize the list */
INIT_LIST_HEAD(&(devs.list));
diff --git a/include/asm-arm/config.h b/include/asm-arm/config.h
index 049c44e..b76fd8e 100644
--- a/include/asm-arm/config.h
+++ b/include/asm-arm/config.h
@@ -21,4 +21,7 @@
#ifndef _ASM_CONFIG_H_
#define _ASM_CONFIG_H_
+/* Relocation to SDRAM works on all ARM boards */
+#define CONFIG_RELOC_FIXUP_WORKS
+
#endif
diff --git a/include/asm-arm/global_data.h b/include/asm-arm/global_data.h
index 5c56ce3..8115a24 100644
--- a/include/asm-arm/global_data.h
+++ b/include/asm-arm/global_data.h
@@ -38,7 +38,6 @@ typedef struct global_data {
unsigned long flags;
unsigned long baudrate;
unsigned long have_console; /* serial_init() was called */
- unsigned long reloc_off; /* Relocation Offset */
unsigned long env_addr; /* Address of Environment struct */
unsigned long env_valid; /* Checksum of Environment valid? */
unsigned long fb_base;/* base address of frame buffer */
diff --git a/include/asm-microblaze/config.h b/include/asm-microblaze/config.h
index 049c44e..8a9064b 100644
--- a/include/asm-microblaze/config.h
+++ b/include/asm-microblaze/config.h
@@ -21,4 +21,7 @@
#ifndef _ASM_CONFIG_H_
#define _ASM_CONFIG_H_
+/* Relocation to SDRAM works on all Microblaze boards */
+#define CONFIG_RELOC_FIXUP_WORKS
+
#endif
diff --git a/include/asm-microblaze/global_data.h
b/include/asm-microblaze/global_data.h
index 3f49c34..ec7837f 100644
--- a/include/asm-microblaze/global_data.h
+++ b/include/asm-microblaze/global_data.h
@@ -39,7 +39,6 @@ typedef struct global_data {
unsigned long flags;
unsigned long baudrate;
unsigned long have_console; /* serial_init() was called */
- unsigned long reloc_off; /* Relocation Offset */
unsigned long env_addr; /* Address of Environment struct */
unsigned long env_valid; /* Checksum of Environment valid? */
unsigned long fb_base;/* base address of frame buffer */
diff --git a/include/asm-nios/config.h b/include/asm-nios/config.h
index 049c44e..2efe898 100644
--- a/include/asm-nios/config.h
+++ b/include/asm-nios/config.h
@@ -21,4 +21,7 @@
#ifndef _ASM_CONFIG_H_
#define _ASM_CONFIG_H_
+/* Relocation to SDRAM works on all NIOS boards */
+#define CONFIG_RELOC_FIXUP_WORKS
+
#endif
diff --git a/include/asm-nios/global_data.h b/include/asm-nios/global_data.h
index 4929a5b..fa54ee4 100644
--- a/include/asm-nios/global_data.h
+++ b/include/asm-nios/global_data.h
@@ -31,7 +31,6 @@ typedef struct global_data {
unsigned long cpu_clk;/* CPU clock in Hz! */
unsigned long have_console; /* serial_init() was called */
phys_size_t ram_size; /* RAM size */
- unsigne
Re: [U-Boot] [PATCH 00/13] ppc: Fix relocation
Hi Detlev, > >> This series attempts to fix relocation to RAM for ppc boards. > >> > >> I split the patches up pretty liberally, let me know if you'd like > >> them organized differently. > >> > >> I tried to be thorough during the changes (especially #1), let me > >> know if I missed anything, there's lots of linker scripts for ppc > >> boards:) > >> > >> Peter Tyser (13): > >> ppc: Enable full relocation to RAM > >> ppc: Check for compilers that don't support relocation > >> ppc: Remove board.c relocation fixups > >> ppc: Remove pci config table pointer relocation fixups > >> ppc: Remove extable relocation fixups > >> ppc: Remove board-specific command table relocation fixups > >> tsec: Remove PHY command relocation fixups > >> fpga: Remove relocation fixups > >> mpl: Remove memory test relocation fixups > >> lwmon, lwmon5: Remove sysmon POST relocation fixups > >> p3mx: Remove serial relocation fixups > >> Conditionally perform common relocation fixups > >> ppc: Remove reloc_off field from global_data structure > > > > Wow, this is really good work. Didn't think there would be so much code > > that could be deleted due to working relocation :) > > I hope WD will pull this in and potentially broken boards will have to > > be fixed rather than backing stuff out. > > Seconded. That's what a merge window is for, isn't it? :) Thirded:) > One should do some further simple text searching to find more code that > can now be potentially be removed. For example, from what I wrote > board/inka4x0/inkadiag.c also has such reloacted code inside. I didn't see any relocation fixups in inkadiag.c that could be removed at a glance. Am I missing something? I attempted to clean up all relocation fixups that affect ppc (and other arches that support relocation), so let me know if I missed anything. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc8610hpcd: Use common 86xx fdt fixup code
Using the common 86xx fdt fixups removes some board-specific code and
should make the mpc8610hpcd easier to maintain in the long run.
Signed-off-by: Peter Tyser
---
board/freescale/mpc8610hpcd/mpc8610hpcd.c | 14 +-
2 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd.c
b/board/freescale/mpc8610hpcd/mpc8610hpcd.c
index 98111eb..358148f 100644
--- a/board/freescale/mpc8610hpcd/mpc8610hpcd.c
+++ b/board/freescale/mpc8610hpcd/mpc8610hpcd.c
@@ -387,19 +387,7 @@ void pci_init_board(void)
void
ft_board_setup(void *blob, bd_t *bd)
{
- do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
-"timebase-frequency", bd->bi_busfreq / 4, 1);
- do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
-"bus-frequency", bd->bi_busfreq, 1);
- do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
-"clock-frequency", bd->bi_intfreq, 1);
- do_fixup_by_prop_u32(blob, "device_type", "soc", 4,
-"bus-frequency", bd->bi_busfreq, 1);
-
- do_fixup_by_compat_u32(blob, "ns16550",
- "clock-frequency", bd->bi_busfreq, 1);
-
- fdt_fixup_memory(blob, bd->bi_memstart, bd->bi_memsize);
+ ft_cpu_setup(blob, bd);
#ifdef CONFIG_PCI1
ft_fsl_pci_setup(blob, "pci0", &pci1_hose);
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2 v5] MAKEALL: Use POSIX math
Signed-off-by: Peter Tyser --- MAKEALL |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAKEALL b/MAKEALL index fd06d8d..1e7ec20 100755 --- a/MAKEALL +++ b/MAKEALL @@ -9,7 +9,7 @@ trap print_stats 0 if [ "$BUILD_NCPUS" -gt 1 ] then - JOBS=-j`expr "$BUILD_NCPUS" + 1` + JOBS="-j $((BUILD_NCPUS + 1))" else JOBS="" fi -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v5] MAKEALL: Add summary information
This change adds some basic summary information to the MAKEALL script.
The summary information includes how many boards were compiled, how many
boards had compile warnings or errors, and which specific boards had
compile warnings or errors.
This information is useful when doing compile testing to quickly
determine which boards are broken.
As a side benefit, no empty $BOARD.ERR files are generated by MAKEALL.
Previously, each board had a corresponding $BOARD.ERR file, even if the
board compiled cleanly.
Signed-off-by: Peter Tyser
---
Changes since v1:
- Fix issue where summary was printed multiple times when a list
was composed of sublists
Changes since v2:
- Update script to only use POSIX arithmetic
Changes since v3:
- Remove unnecessary expansion of variables inside of $(( ... ))
Changes since v4:
- Catch additional termination signals
- Use signal 0 to trigger printing of stats
- Break POSIX math change into a separate patch
MAKEALL | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 1d50c34..fd06d8d 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -1,5 +1,9 @@
#!/bin/sh
+# Print statistics when we exit
+trap exit 1 2 3 15
+trap print_stats 0
+
# Determine number of CPU cores if no default was set
: ${BUILD_NCPUS:="`getconf _NPROCESSORS_ONLN`"}
@@ -31,6 +35,11 @@ fi
LIST=""
+# Keep track of the number of builds and errors
+ERR_CNT=0
+ERR_LIST=""
+TOTAL_CNT=0
+
#
## MPC5xx Systems
#
@@ -900,6 +909,14 @@ build_target() {
${MAKE} ${JOBS} all 2>&1 >${LOG_DIR}/$target.MAKELOG \
| tee ${LOG_DIR}/$target.ERR
+ if [ -s ${LOG_DIR}/$target.ERR ] ; then
+ ERR_CNT=$((ERR_CNT + 1))
+ ERR_LIST="${ERR_LIST} $target"
+ else
+ rm ${LOG_DIR}/$target.ERR
+ fi
+
+ TOTAL_CNT=$((TOTAL_CNT + 1))
${CROSS_COMPILE}size ${BUILD_DIR}/u-boot \
| tee -a ${LOG_DIR}/$target.MAKELOG
@@ -907,7 +924,17 @@ build_target() {
#---
+print_stats() {
+ echo ""
+ echo "- SUMMARY "
+ echo "Boards compiled: ${TOTAL_CNT}"
+ if [ ${ERR_CNT} -gt 0 ] ; then
+ echo "Boards with warnings or errors: ${ERR_CNT} (${ERR_LIST} )"
+ fi
+ echo "--"
+}
+#---
for arg in $@
do
case "$arg" in
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] ppc: Remove pci config table pointer relocation fixups
On Mon, 2009-09-21 at 12:49 -0400, Paul Gortmaker wrote:
> On Mon, Sep 21, 2009 at 12:20 PM, Peter Tyser wrote:
> > Signed-off-by: Peter Tyser
>
> It looks like something happened during the send of your patches;
> it seems the long log of what you are trying to fix and how the patch
> fixes it is missing here and from several of the other patches
> as well.
I didn't put long log messages in patches which I thought would be clear
what was changing. All the "Remove XYZ relocation fixups" are intended
to only remove no longer needed fixups. They shouldn't (hopefully) have
any functional change. I can add log messages, but they will all be the
same "don't fixup xyz as relocation now works".
> > ---
> > board/freescale/mpc8548cds/mpc8548cds.c |7 ---
> > board/mpl/common/pci.c | 18 --
> > board/sbc8548/sbc8548.c |6 --
> > 3 files changed, 0 insertions(+), 31 deletions(-)
> >
> > diff --git a/board/freescale/mpc8548cds/mpc8548cds.c
> > b/board/freescale/mpc8548cds/mpc8548cds.c
> > index 80de6f8..73e7c21 100644
> > --- a/board/freescale/mpc8548cds/mpc8548cds.c
> > +++ b/board/freescale/mpc8548cds/mpc8548cds.c
> > @@ -276,7 +276,6 @@ pci_init_board(void)
> > {
> >volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *)
> > CONFIG_SYS_PCI1_ADDR;
> >struct pci_controller *hose = &pci1_hose;
> > - struct pci_config_table *table;
> >struct pci_region *r = hose->regions;
> >
> >uint pci_32 = gur->pordevsr & MPC85xx_PORDEVSR_PCI1_PCI32; /*
> > PORDEVSR[15] */
> > @@ -312,12 +311,6 @@ pci_init_board(void)
> > PCI_REGION_IO);
> >hose->region_count = r - hose->regions;
> >
> > - /* relocate config table pointers */
> > - hose->config_table = \
> > - (struct pci_config_table
> > *)((uint)hose->config_table + gd->reloc_off);
> > - for (table = hose->config_table; table && table->vendor;
> > table++)
> > - table->config_device += gd->reloc_off;
>
> For the mpc8548cds, if this removal was somehow the right thing to do,
> it would still be incomplete; I am sure that there is a dummy function
> related to a PCI bridge quirk associated with the above change that
> would now be orphaned in the code.
I didn't intend to make any functional change as I know nothing about
this board:) I only intended to remove the references to gd->reloc_off.
I looked over this code quickly and came to the conclusion I wasn't
changing any functionality, let me know if I'm missing something.
> > -
> >hose->first_busno=first_free_busno;
> >
> >fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
>
> [...]
>
> > diff --git a/board/sbc8548/sbc8548.c b/board/sbc8548/sbc8548.c
> > index e5b21b5..5cdfef4 100644
> > --- a/board/sbc8548/sbc8548.c
> > +++ b/board/sbc8548/sbc8548.c
> > @@ -392,12 +392,6 @@ pci_init_board(void)
> > PCI_REGION_IO);
> >hose->region_count = r - hose->regions;
> >
> > - /* relocate config table pointers */
> > - hose->config_table = \
> > - (struct pci_config_table
> > *)((uint)hose->config_table + gd->reloc_off);
> > - for (table = hose->config_table; table && table->vendor;
> > table++)
> > - table->config_device += gd->reloc_off;
>
> This code is already gone from the sbc8548 in the 85xx branch;
> the sbc8548 didn't need the bridge quirk fixup.
Thanks for the heads up. Maybe git will gracefully handle this change?
If not, I'd prefer to wait till Wolfgang attempts to merge this patch as
other things may be merged between now and then and I'd rather just send
1 cleanup patch series.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/13] Conditionally perform common relocation fixups
Add #ifdefs where necessary to not perform relocation fixups. This
allows boards/architectures which support relocation to trim a decent
chunk of code.
Note that this patch doesn't add #ifdefs to architecture-specific code
which does not support relocation.
Signed-off-by: Peter Tyser
---
common/cmd_bootm.c |4 +++-
common/cmd_date.c |4
common/dlmalloc.c |2 ++
common/env_common.c |4
common/hush.c |4
common/image.c |6 +-
common/serial.c |2 ++
common/stdio.c |5 +++--
disk/part.c |5 -
drivers/mtd/nand/nand.c |2 ++
fs/ubifs/ubifs.c|4
include/post.h |2 ++
post/post.c |2 ++
13 files changed, 41 insertions(+), 5 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 365ceeb..8f83598 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -561,7 +561,6 @@ int do_bootm_subcommand (cmd_tbl_t *cmdtp, int flag, int
argc, char *argv[])
/***/
/* bootm - boot application image from image in memory */
/***/
-static int relocated = 0;
int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
@@ -569,6 +568,8 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
ulong load_end = 0;
int ret;
boot_os_fn *boot_fn;
+#ifndef CONFIG_RELOC_FIXUP_WORKS
+ static int relocated = 0;
/* relocate boot function table */
if (!relocated) {
@@ -578,6 +579,7 @@ int do_bootm (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
boot_os[i] += gd->reloc_off;
relocated = 1;
}
+#endif
/* determine if we have a sub command */
if (argc > 1) {
diff --git a/common/cmd_date.c b/common/cmd_date.c
index b69e935..9f50f89 100644
--- a/common/cmd_date.c
+++ b/common/cmd_date.c
@@ -35,7 +35,11 @@ const char *weekdays[] = {
"Sun", "Mon", "Tues", "Wednes", "Thurs", "Fri", "Satur",
};
+#ifdef CONFIG_RELOC_FIXUP_WORKS
+#define RELOC(a) a
+#else
#define RELOC(a) ((typeof(a))((unsigned long)(a) + gd->reloc_off))
+#endif
int mk_date (char *, struct rtc_time *);
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 241db8c..ca088a1 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1494,6 +1494,7 @@ static mbinptr av_[NAV * 2 + 2] = {
IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125), IAV(126), IAV(127)
};
+#ifndef CONFIG_RELOC_FIXUP_WORKS
void malloc_bin_reloc (void)
{
unsigned long *p = (unsigned long *)(&av_[2]);
@@ -1502,6 +1503,7 @@ void malloc_bin_reloc (void)
*p++ += gd->reloc_off;
}
}
+#endif
ulong mem_malloc_start = 0;
ulong mem_malloc_end = 0;
diff --git a/common/env_common.c b/common/env_common.c
index be64d13..439a4a9 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -224,8 +224,10 @@ void set_default_env(void)
void env_relocate (void)
{
+#ifndef CONFIG_RELOC_FIXUP_WORKS
DEBUGF ("%s[%d] offset = 0x%lx\n", __FUNCTION__,__LINE__,
gd->reloc_off);
+#endif
#ifdef CONFIG_AMIGAONEG3SE
enable_nvram();
@@ -236,7 +238,9 @@ void env_relocate (void)
* The environment buffer is embedded with the text segment,
* just relocate the environment pointer
*/
+#ifndef CONFIG_RELOC_FIXUP_WORKS
env_ptr = (env_t *)((ulong)env_ptr + gd->reloc_off);
+#endif
DEBUGF ("%s[%d] embedded ENV at %p\n", __FUNCTION__,__LINE__,env_ptr);
#else
/*
diff --git a/common/hush.c b/common/hush.c
index 528dd25..06c5ff8 100644
--- a/common/hush.c
+++ b/common/hush.c
@@ -3270,6 +3270,7 @@ int parse_file_outer(void)
}
#ifdef __U_BOOT__
+#ifndef CONFIG_RELOC_FIXUP_WORKS
static void u_boot_hush_reloc(void)
{
unsigned long addr;
@@ -3280,6 +3281,7 @@ static void u_boot_hush_reloc(void)
r->literal = (char *)addr;
}
}
+#endif
int u_boot_hush_start(void)
{
@@ -3290,7 +3292,9 @@ int u_boot_hush_start(void)
top_vars->next = 0;
top_vars->flg_export = 0;
top_vars->flg_read_only = 1;
+#ifndef CONFIG_RELOC_FIXUP_WORKS
u_boot_hush_reloc();
+#endif
}
return 0;
}
diff --git a/common/image.c b/common/image.c
index d0f169d..6eaf41e 100644
--- a/common/image.c
+++ b/common/image.c
@@ -513,7 +513,7 @@ char *get_table_entry_name (table_entry_t *table, char
*msg, int id)
{
for (; table->id >= 0; ++table) {
if (table->id == id)
-#ifdef USE_HOSTCC
+#if defined(USE_HOSTCC) || defined(CONFIG_RELOC_FIXUP_WORKS)
[U-Boot] [PATCH 13/13] ppc: Remove reloc_off field from global_data structure
Now that proper relocation is supported, the reloc_off field is no longer
necessary.
Note that the location of the standalone application jump table pointer
in the global data structure is affected by this change, breaking
execution of standalone applications compiled for previous versions of
U-Boot.
Signed-off-by: Peter Tyser
---
Would others prefer an empty ulong take reloc_off's place so old
standalone apps don't break? Or perhaps we should move the jump
table pointer to the first item in global_data to prevent breakage
every time global_data is modified in the future?
include/asm-ppc/global_data.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-ppc/global_data.h b/include/asm-ppc/global_data.h
index db4b1ea..55e7e20 100644
--- a/include/asm-ppc/global_data.h
+++ b/include/asm-ppc/global_data.h
@@ -24,6 +24,7 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+#include "config.h"
#include "asm/types.h"
/*
@@ -124,7 +125,6 @@ typedef struct global_data {
unsigned long flb_clk;
#endif
phys_size_t ram_size; /* RAM size */
- unsigned long reloc_off; /* Relocation Offset */
unsigned long reset_status; /* reset status register at boot
*/
#if defined(CONFIG_MPC83xx)
unsigned long arbiter_event_attributes;
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 11/13] p3mx: Remove serial relocation fixups
Signed-off-by: Peter Tyser
---
board/prodrive/p3mx/p3mx.c | 10 --
include/configs/p3mx.h |1 -
2 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/board/prodrive/p3mx/p3mx.c b/board/prodrive/p3mx/p3mx.c
index 0247bb8..05eca52 100644
--- a/board/prodrive/p3mx/p3mx.c
+++ b/board/prodrive/p3mx/p3mx.c
@@ -316,16 +316,6 @@ int misc_init_r ()
return 0;
}
-int board_early_init_r(void)
-{
- /* now relocate the debug serial driver */
- mpsc_putchar += gd->reloc_off;
- mpsc_getchar += gd->reloc_off;
- mpsc_test_char += gd->reloc_off;
-
- return 0;
-}
-
void after_reloc (ulong dest_addr, gd_t * gd)
{
memoryMapDeviceSpace (BOOT_DEVICE, CONFIG_SYS_BOOT_SPACE,
CONFIG_SYS_BOOT_SIZE);
diff --git a/include/configs/p3mx.h b/include/configs/p3mx.h
index 5e4d30b..0749037 100644
--- a/include/configs/p3mx.h
+++ b/include/configs/p3mx.h
@@ -59,7 +59,6 @@
/* which initialization functions to call for this board */
#define CONFIG_SYS_BOARD_ASM_INIT 1
#define CONFIG_BOARD_EARLY_INIT_F 1 /* Call board_early_init_f */
-#define CONFIG_BOARD_EARLY_INIT_R 1 /* Call board_early_init_f */
#define CONFIG_MISC_INIT_R 1 /* Call misc_init_r() */
/*---
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/13] mpl: Remove memory test relocation fixups
Signed-off-by: Peter Tyser
---
board/mpl/common/memtst.c | 26 --
board/mpl/mip405/mip405.c |3 +--
board/mpl/pati/pati.c |2 --
board/mpl/vcma9/vcma9.c |3 ---
4 files changed, 1 insertions(+), 33 deletions(-)
diff --git a/board/mpl/common/memtst.c b/board/mpl/common/memtst.c
index 1393ea1..92c33ba 100644
--- a/board/mpl/common/memtst.c
+++ b/board/mpl/common/memtst.c
@@ -468,32 +468,6 @@ static RAM_MEMTEST_FUNC test_stage[TEST_STAGES] = {
RAM_MemTest_CheckRandomPattern, NULL}
};
-void mem_test_reloc(void)
-{
- unsigned long addr;
- int i;
- for (i=0; i< TEST_STAGES; i++) {
- addr = (ulong) (test_stage[i].test_write) + gd->reloc_off;
- test_stage[i].test_write=
- (void (*) (unsigned long startaddr, unsigned long size,
- unsigned long *pat))addr;
- addr = (ulong) (test_stage[i].test_write_desc) + gd->reloc_off;
- test_stage[i].test_write_desc=(char *)addr;
- if(test_stage[i].test_check1) {
- addr = (ulong) (test_stage[i].test_check1) +
gd->reloc_off;
- test_stage[i].test_check1=
- (void *(*) (int mode, unsigned long startaddr,
-unsigned long size, unsigned long *pat))addr;
- }
- if(test_stage[i].test_check2) {
- addr = (ulong) (test_stage[i].test_check2) +
gd->reloc_off;
- test_stage[i].test_check2=
- (void *(*) (int mode, unsigned long startaddr,
-unsigned long size, unsigned long *pat))addr;
- }
- }
-}
-
int mem_test (unsigned long start, unsigned long ramsize, int quiet)
{
diff --git a/board/mpl/mip405/mip405.c b/board/mpl/mip405/mip405.c
index d8279e8..fdfa897 100644
--- a/board/mpl/mip405/mip405.c
+++ b/board/mpl/mip405/mip405.c
@@ -717,7 +717,6 @@ int post_hotkeys_pressed(void)
}
#endif
-extern void mem_test_reloc(void);
extern int mk_date (char *, struct rtc_time *);
int last_stage_init (void)
@@ -725,7 +724,7 @@ int last_stage_init (void)
unsigned long stop;
struct rtc_time newtm;
char *s;
- mem_test_reloc();
+
/* write correct LED configuration */
if (miiphy_write("ppc_4xx_eth0", 0x1, 0x14, 0x2402) != 0) {
printf ("Error writing to the PHY\n");
diff --git a/board/mpl/pati/pati.c b/board/mpl/pati/pati.c
index 1b3b698..e12bc42 100644
--- a/board/mpl/pati/pati.c
+++ b/board/mpl/pati/pati.c
@@ -144,7 +144,6 @@ const sdram_t sdram_table[] = {
extern int mem_test (unsigned long start, unsigned long ramsize, int quiet);
-extern void mem_test_reloc(void);
/*
* Get RAM size.
@@ -334,7 +333,6 @@ void user_led1(int led_on)
/
int last_stage_init (void)
{
- mem_test_reloc();
init_ios();
return 0;
}
diff --git a/board/mpl/vcma9/vcma9.c b/board/mpl/vcma9/vcma9.c
index 3216d63..2b64f44 100644
--- a/board/mpl/vcma9/vcma9.c
+++ b/board/mpl/vcma9/vcma9.c
@@ -312,11 +312,8 @@ int checkboard(void)
}
-extern void mem_test_reloc(void);
-
int last_stage_init(void)
{
- mem_test_reloc();
checkboard();
stdio_print_current_devices();
check_env();
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/13] fpga: Remove relocation fixups
PPC boards are the only users of the current FPGA code which is littered
with manual relocation fixups. Now that proper relocation is supported
for PPC boards, remove FPGA manual relocation.
Signed-off-by: Peter Tyser
---
board/esd/pmc440/fpga.c |6 +-
board/gen860t/fpga.c |5 +-
board/matrix_vision/mvbc_p/fpga.c |7 +-
board/matrix_vision/mvblm7/fpga.c |6 +-
board/prodrive/alpr/fpga.c|4 +-
drivers/fpga/ACEX1K.c | 96 ---
drivers/fpga/altera.c | 39
drivers/fpga/cyclon2.c| 91 --
drivers/fpga/fpga.c | 53 +--
drivers/fpga/spartan2.c | 187 -
drivers/fpga/spartan3.c | 185
drivers/fpga/stratixII.c | 24 -
drivers/fpga/virtex2.c| 118 ---
drivers/fpga/xilinx.c | 42
include/ACEX1K.h |4 -
include/altera.h |1 -
include/fpga.h|2 +-
include/spartan2.h|3 -
include/spartan3.h|3 -
include/stratixII.h |1 -
include/virtex2.h |3 -
include/xilinx.h |1 -
22 files changed, 18 insertions(+), 863 deletions(-)
diff --git a/board/esd/pmc440/fpga.c b/board/esd/pmc440/fpga.c
index a2eda32..f92bbff 100644
--- a/board/esd/pmc440/fpga.c
+++ b/board/esd/pmc440/fpga.c
@@ -442,9 +442,9 @@ int pmc440_init_fpga(void)
{
char *s;
- debug("%s:%d: Initialize FPGA interface (relocation offset =
0x%.8lx)\n",
- __FUNCTION__, __LINE__, gd->reloc_off);
- fpga_init(gd->reloc_off);
+ debug("%s:%d: Initialize FPGA interface\n",
+ __FUNCTION__, __LINE__);
+ fpga_init();
fpga_serialslave_init ();
debug("%s:%d: Adding fpga 0\n", __FUNCTION__, __LINE__);
diff --git a/board/gen860t/fpga.c b/board/gen860t/fpga.c
index 29cad2e..d42c500 100644
--- a/board/gen860t/fpga.c
+++ b/board/gen860t/fpga.c
@@ -193,8 +193,9 @@ int gen860t_init_fpga (void)
{
int i;
- PRINTF ("%s:%d: Initialize FPGA interface (relocation offset =
0x%.8lx)\n", __FUNCTION__, __LINE__, gd->reloc_off);
- fpga_init (gd->reloc_off);
+ PRINTF ("%s:%d: Initialize FPGA interface\n",
+ __FUNCTION__, __LINE__);
+ fpga_init ();
fpga_selectmap_init ();
for (i = 0; i < CONFIG_FPGA_COUNT; i++) {
diff --git a/board/matrix_vision/mvbc_p/fpga.c
b/board/matrix_vision/mvbc_p/fpga.c
index 356af1a..3ed46fe 100644
--- a/board/matrix_vision/mvbc_p/fpga.c
+++ b/board/matrix_vision/mvbc_p/fpga.c
@@ -46,7 +46,6 @@ Altera_CYC2_Passive_Serial_fns altera_fns = {
fpga_wr_fn,
fpga_null_fn,
fpga_null_fn,
- 0
};
Altera_desc cyclone2 = {
@@ -55,16 +54,14 @@ Altera_desc cyclone2 = {
Altera_EP2C8_SIZE,
(void *) &altera_fns,
NULL,
- 0
};
DECLARE_GLOBAL_DATA_PTR;
int mvbc_p_init_fpga(void)
{
- fpga_debug("Initialize FPGA interface (reloc 0x%.8lx)\n",
- gd->reloc_off);
- fpga_init(gd->reloc_off);
+ fpga_debug("Initialize FPGA interface\n");
+ fpga_init();
fpga_add(fpga_altera, &cyclone2);
fpga_config_fn(0, 1, 0);
udelay(60);
diff --git a/board/matrix_vision/mvblm7/fpga.c
b/board/matrix_vision/mvblm7/fpga.c
index 7527d16..7b03d6f 100644
--- a/board/matrix_vision/mvblm7/fpga.c
+++ b/board/matrix_vision/mvblm7/fpga.c
@@ -46,7 +46,6 @@ Altera_CYC2_Passive_Serial_fns altera_fns = {
fpga_wr_fn,
fpga_null_fn,
fpga_null_fn,
- 0
};
Altera_desc cyclone2 = {
@@ -62,9 +61,8 @@ DECLARE_GLOBAL_DATA_PTR;
int mvblm7_init_fpga(void)
{
- fpga_debug("Initialize FPGA interface (reloc 0x%.8lx)\n",
- gd->reloc_off);
- fpga_init(gd->reloc_off);
+ fpga_debug("Initialize FPGA interface\n");
+ fpga_init();
fpga_add(fpga_altera, &cyclone2);
fpga_config_fn(0, 1, 0);
udelay(60);
diff --git a/board/prodrive/alpr/fpga.c b/board/prodrive/alpr/fpga.c
index 0ecebc9..7571cd9 100644
--- a/board/prodrive/alpr/fpga.c
+++ b/board/prodrive/alpr/fpga.c
@@ -244,8 +244,8 @@ int alpr_fpga_init (void)
{
int i;
- PRINTF ("%s:%d: Initialize FPGA interface (relocation offset =
0x%.8lx)\n", __FUNCTION__, __LINE__, gd->reloc_off);
- fpga_init (gd->reloc_off);
+ PRINTF ("%s:%d: Initialize FPGA interface\n", __FUNCTION__, __LINE__);
+ fpga_init ();
for (i = 0; i < CONFIG_FPGA_COUNT; i++) {
PRINTF ("%s:%d: Adding fpga %d\n", __FUNCTION__, __LINE__, i);
diff --git a/drivers/
[U-Boot] [PATCH 10/13] lwmon, lwmon5: Remove sysmon POST relocation fixups
Signed-off-by: Peter Tyser
---
post/board/lwmon/sysmon.c | 17 +
post/board/lwmon5/sysmon.c | 17 +
2 files changed, 2 insertions(+), 32 deletions(-)
diff --git a/post/board/lwmon/sysmon.c b/post/board/lwmon/sysmon.c
index 79a5151..fc828b2 100644
--- a/post/board/lwmon/sysmon.c
+++ b/post/board/lwmon/sysmon.c
@@ -56,8 +56,6 @@ static int sysmon_temp_invalid = 0;
/* #define DEBUG */
-#defineRELOC(x) if (x != NULL) x = (void *) ((ulong) (x) +
gd->reloc_off)
-
typedef struct sysmon_s sysmon_t;
typedef struct sysmon_table_s sysmon_table_t;
@@ -159,20 +157,7 @@ int sysmon_init_f (void)
void sysmon_reloc (void)
{
- sysmon_t ** l;
- sysmon_table_t * t;
-
- for (l = sysmon_list; *l; l++) {
- RELOC(*l);
- RELOC((*l)->init);
- RELOC((*l)->read);
- }
-
- for (t = sysmon_table; t < sysmon_table + sysmon_table_size; t ++) {
- RELOC(t->exec_before);
- RELOC(t->exec_after);
- RELOC(t->sysmon);
- }
+ /* Do nothing for now, sysmon_reloc() is required by the sysmon post */
}
static char *sysmon_unit_value (sysmon_table_t *s, uint val)
diff --git a/post/board/lwmon5/sysmon.c b/post/board/lwmon5/sysmon.c
index aef5bd0..9c49d0e 100644
--- a/post/board/lwmon5/sysmon.c
+++ b/post/board/lwmon5/sysmon.c
@@ -58,8 +58,6 @@ DECLARE_GLOBAL_DATA_PTR;
/* from dspic.c */
extern int dspic_read(ushort reg);
-#defineRELOC(x) if (x != NULL) x = (void *) ((ulong) (x) +
gd->reloc_off)
-
#define REG_TEMPERATURE0x12BC
#define REG_VOLTAGE_5V 0x12CA
#define REG_VOLTAGE_5V_STANDBY 0x12C6
@@ -160,20 +158,7 @@ int sysmon_init_f (void)
void sysmon_reloc (void)
{
- sysmon_t ** l;
- sysmon_table_t * t;
-
- for (l = sysmon_list; *l; l++) {
- RELOC(*l);
- RELOC((*l)->init);
- RELOC((*l)->read);
- }
-
- for (t = sysmon_table; t < sysmon_table + sysmon_table_size; t ++) {
- RELOC(t->exec_before);
- RELOC(t->exec_after);
- RELOC(t->sysmon);
- }
+ /* Do nothing for now, sysmon_reloc() is required by the sysmon post */
}
static char *sysmon_unit_value (sysmon_table_t *s, uint val)
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/13] tsec: Remove PHY command relocation fixups
Signed-off-by: Peter Tyser
---
drivers/net/tsec.c | 49 -
1 files changed, 0 insertions(+), 49 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 5c3d261..3f74118 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -35,8 +35,6 @@ typedef volatile struct rtxbd {
#define MAXCONTROLLERS (8)
-static int relocated = 0;
-
static struct tsec_private *privlist[MAXCONTROLLERS];
static int num_tsecs = 0;
@@ -59,7 +57,6 @@ uint read_phy_reg(struct tsec_private *priv, uint regnum);
struct phy_info *get_phy_info(struct eth_device *dev);
void phy_run_commands(struct tsec_private *priv, struct phy_cmd *cmd);
static void adjust_link(struct eth_device *dev);
-static void relocate_cmds(void);
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) \
&& !defined(BITBANGMII)
static int tsec_miiphy_write(char *devname, unsigned char addr,
@@ -321,9 +318,6 @@ static int init_phy(struct eth_device *dev)
asm("sync");
while (priv->phyregs->miimind & MIIMIND_BUSY) ;
- if (0 == relocated)
- relocate_cmds();
-
/* Get the cmd structure corresponding to the attached
* PHY */
curphy = get_phy_info(dev);
@@ -1800,49 +1794,6 @@ void phy_run_commands(struct tsec_private *priv, struct
phy_cmd *cmd)
}
}
-/* Relocate the function pointers in the phy cmd lists */
-static void relocate_cmds(void)
-{
- struct phy_cmd **cmdlistptr;
- struct phy_cmd *cmd;
- int i, j, k;
-
- for (i = 0; phy_info[i]; i++) {
- /* First thing's first: relocate the pointers to the
-* PHY command structures (the structs were done) */
- phy_info[i] = (struct phy_info *)((uint) phy_info[i]
- + gd->reloc_off);
- phy_info[i]->name += gd->reloc_off;
- phy_info[i]->config =
- (struct phy_cmd *)((uint) phy_info[i]->config
- + gd->reloc_off);
- phy_info[i]->startup =
- (struct phy_cmd *)((uint) phy_info[i]->startup
- + gd->reloc_off);
- phy_info[i]->shutdown =
- (struct phy_cmd *)((uint) phy_info[i]->shutdown
- + gd->reloc_off);
-
- cmdlistptr = &phy_info[i]->config;
- j = 0;
- for (; cmdlistptr <= &phy_info[i]->shutdown; cmdlistptr++) {
- k = 0;
- for (cmd = *cmdlistptr;
-cmd->mii_reg != miim_end;
-cmd++) {
- /* Only relocate non-NULL pointers */
- if (cmd->funct)
- cmd->funct += gd->reloc_off;
-
- k++;
- }
- j++;
- }
- }
-
- relocated = 1;
-}
-
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) \
&& !defined(BITBANGMII)
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/13] ppc: Remove pci config table pointer relocation fixups
Signed-off-by: Peter Tyser
---
board/freescale/mpc8548cds/mpc8548cds.c |7 ---
board/mpl/common/pci.c | 18 --
board/sbc8548/sbc8548.c |6 --
3 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/board/freescale/mpc8548cds/mpc8548cds.c
b/board/freescale/mpc8548cds/mpc8548cds.c
index 80de6f8..73e7c21 100644
--- a/board/freescale/mpc8548cds/mpc8548cds.c
+++ b/board/freescale/mpc8548cds/mpc8548cds.c
@@ -276,7 +276,6 @@ pci_init_board(void)
{
volatile ccsr_fsl_pci_t *pci = (ccsr_fsl_pci_t *) CONFIG_SYS_PCI1_ADDR;
struct pci_controller *hose = &pci1_hose;
- struct pci_config_table *table;
struct pci_region *r = hose->regions;
uint pci_32 = gur->pordevsr & MPC85xx_PORDEVSR_PCI1_PCI32; /*
PORDEVSR[15] */
@@ -312,12 +311,6 @@ pci_init_board(void)
PCI_REGION_IO);
hose->region_count = r - hose->regions;
- /* relocate config table pointers */
- hose->config_table = \
- (struct pci_config_table *)((uint)hose->config_table +
gd->reloc_off);
- for (table = hose->config_table; table && table->vendor;
table++)
- table->config_device += gd->reloc_off;
-
hose->first_busno=first_free_busno;
fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
diff --git a/board/mpl/common/pci.c b/board/mpl/common/pci.c
index e0ba620..f9bb6ab 100644
--- a/board/mpl/common/pci.c
+++ b/board/mpl/common/pci.c
@@ -94,29 +94,11 @@ static struct pci_controller hose = {
};
-static void reloc_pci_cfg_table(struct pci_config_table *table)
-{
- unsigned long addr;
-
- for (; table && table->vendor; table++) {
- addr = (ulong) (table->config_device) + gd->reloc_off;
-#ifdef DEBUG
- printf ("device \"%d\": 0x%08lx => 0x%08lx\n",
- table->device, (ulong) (table->config_device),
addr);
-#endif
- table->config_device =
- (void (*)(struct pci_controller* hose, pci_dev_t dev,
- struct pci_config_table *))addr;
- table->priv[0]+=gd->reloc_off;
- }
-}
-
void pci_init_board(void)
{
/*we want the ptrs to RAM not flash (ie don't use init list)*/
hose.fixup_irq= pci_pip405_fixup_irq;
hose.config_table = pci_pip405_config_table;
- reloc_pci_cfg_table(hose.config_table);
#ifdef DEBUG
printf("Init PCI: fixup_irq=%p config_table=%p
hose=%p\n",pci_pip405_fixup_irq,pci_pip405_config_table,hose);
#endif
diff --git a/board/sbc8548/sbc8548.c b/board/sbc8548/sbc8548.c
index e5b21b5..5cdfef4 100644
--- a/board/sbc8548/sbc8548.c
+++ b/board/sbc8548/sbc8548.c
@@ -392,12 +392,6 @@ pci_init_board(void)
PCI_REGION_IO);
hose->region_count = r - hose->regions;
- /* relocate config table pointers */
- hose->config_table = \
- (struct pci_config_table *)((uint)hose->config_table +
gd->reloc_off);
- for (table = hose->config_table; table && table->vendor;
table++)
- table->config_device += gd->reloc_off;
-
hose->first_busno=first_free_busno;
fsl_pci_init(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/13] ppc: Remove board-specific command table relocation fixups
Signed-off-by: Peter Tyser
---
board/digsy_mtc/cmd_mtc.c | 30 --
board/digsy_mtc/digsy_mtc.c |2 --
board/inka4x0/inka4x0.c | 10 --
board/inka4x0/inkadiag.c| 28
include/configs/inka4x0.h |1 -
5 files changed, 0 insertions(+), 71 deletions(-)
diff --git a/board/digsy_mtc/cmd_mtc.c b/board/digsy_mtc/cmd_mtc.c
index aa39611..ecea5b3 100644
--- a/board/digsy_mtc/cmd_mtc.c
+++ b/board/digsy_mtc/cmd_mtc.c
@@ -320,36 +320,6 @@ static int do_mtc_help(cmd_tbl_t *cmdtp, int flag, int
argc, char *argv[])
ARRAY_SIZE(cmd_mtc_sub), cmdtp, flag, argc, argv);
}
-/* Relocate the command table function pointers when running in RAM */
-int mtc_cmd_init_r(void)
-{
- cmd_tbl_t *cmdtp;
-
- for (cmdtp = &cmd_mtc_sub[0]; cmdtp !=
-&cmd_mtc_sub[ARRAY_SIZE(cmd_mtc_sub)]; cmdtp++) {
- ulong addr;
-
- addr = (ulong)(cmdtp->cmd) + gd->reloc_off;
- cmdtp->cmd =
- (int (*)(struct cmd_tbl_s *, int, int, char *[]))addr;
-
- addr = (ulong)(cmdtp->name) + gd->reloc_off;
- cmdtp->name = (char *)addr;
-
- if (cmdtp->usage) {
- addr = (ulong)(cmdtp->usage) + gd->reloc_off;
- cmdtp->usage = (char *)addr;
- }
-#ifdef CONFIG_SYS_LONGHELP
- if (cmdtp->help) {
- addr = (ulong)(cmdtp->help) + gd->reloc_off;
- cmdtp->help = (char *)addr;
- }
-#endif
- }
- return 0;
-}
-
int cmd_mtc(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
cmd_tbl_t *c;
diff --git a/board/digsy_mtc/digsy_mtc.c b/board/digsy_mtc/digsy_mtc.c
index 9d77e54..cc6087b 100644
--- a/board/digsy_mtc/digsy_mtc.c
+++ b/board/digsy_mtc/digsy_mtc.c
@@ -240,7 +240,6 @@ void board_get_enetaddr (uchar * enet)
int misc_init_r(void)
{
- extern int mtc_cmd_init_r (void);
uchar enetaddr[6];
if (!eth_getenv_enetaddr("ethaddr", enetaddr)) {
@@ -248,7 +247,6 @@ int misc_init_r(void)
eth_setenv_enetaddr("ethaddr", enetaddr);
}
- mtc_cmd_init_r();
return 0;
}
diff --git a/board/inka4x0/inka4x0.c b/board/inka4x0/inka4x0.c
index c645b05..27b79ec 100644
--- a/board/inka4x0/inka4x0.c
+++ b/board/inka4x0/inka4x0.c
@@ -177,16 +177,6 @@ void flash_preinit(void)
clrbits_be32(&lpb->cs0_cfg, 0x1); /* clear RO */
}
-int misc_init_r (void) {
- extern int inkadiag_init_r (void);
-
- /*
-* The command table used for the subcommands of inkadiag
-* needs to be relocated manually.
-*/
- return inkadiag_init_r();
-}
-
int misc_init_f (void)
{
volatile struct mpc5xxx_gpio*gpio=
diff --git a/board/inka4x0/inkadiag.c b/board/inka4x0/inkadiag.c
index 3761ef6..0a75abd 100644
--- a/board/inka4x0/inkadiag.c
+++ b/board/inka4x0/inkadiag.c
@@ -484,31 +484,3 @@ U_BOOT_CMD(inkadiag, 6, 1, do_inkadiag,
"[inkadiag what ...]\n"
"- perform a diagnosis on inka hardware\n"
"'inkadiag' performs hardware tests.");
-
-/* Relocate the command table function pointers when running in RAM */
-int inkadiag_init_r (void) {
- cmd_tbl_t *cmdtp;
-
- for (cmdtp = &cmd_inkadiag_sub[0]; cmdtp !=
-&cmd_inkadiag_sub[ARRAY_SIZE(cmd_inkadiag_sub)]; cmdtp++) {
- ulong addr;
-
- addr = (ulong) (cmdtp->cmd) + gd->reloc_off;
- cmdtp->cmd = (int (*)(struct cmd_tbl_s *, int, int, char
*[]))addr;
-
- addr = (ulong)(cmdtp->name) + gd->reloc_off;
- cmdtp->name = (char *)addr;
-
- if (cmdtp->usage) {
- addr = (ulong)(cmdtp->usage) + gd->reloc_off;
- cmdtp->usage = (char *)addr;
- }
-#ifdef CONFIG_SYS_LONGHELP
- if (cmdtp->help) {
- addr = (ulong)(cmdtp->help) + gd->reloc_off;
- cmdtp->help = (char *)addr;
- }
-#endif
- }
- return 0;
-}
diff --git a/include/configs/inka4x0.h b/include/configs/inka4x0.h
index 46606ca..14f7826 100644
--- a/include/configs/inka4x0.h
+++ b/include/configs/inka4x0.h
@@ -42,7 +42,6 @@
#define BOOTFLAG_WARM 0x02/* Software reboot
*/
#define CONFIG_MISC_INIT_F 1 /* Use misc_init_f()
*/
-#define CONFIG_MISC_INIT_R 1 /* Use misc_init_r()
*/
#define CONFIG_HIGH_BATS 1 /* High BATs supported
*/
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/13] ppc: Remove extable relocation fixups
Signed-off-by: Peter Tyser
---
lib_ppc/extable.c | 26 ++
1 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/lib_ppc/extable.c b/lib_ppc/extable.c
index 91e2b3d..7408d5c 100644
--- a/lib_ppc/extable.c
+++ b/lib_ppc/extable.c
@@ -53,27 +53,13 @@ search_one_table(const struct exception_table_entry *first,
unsigned long value)
{
long diff;
- if ((ulong) first > CONFIG_SYS_MONITOR_BASE) {
- /* exception occurs in FLASH, before u-boot relocation.
-* No relocation offset is needed.
-*/
- while (first <= last) {
- diff = first->insn - value;
- if (diff == 0)
- return first->fixup;
- first++;
- }
- } else {
- /* exception occurs in RAM, after u-boot relocation.
-* A relocation offset should be added.
-*/
- while (first <= last) {
- diff = (first->insn + gd->reloc_off) - value;
- if (diff == 0)
- return (first->fixup + gd->reloc_off);
- first++;
- }
+ while (first <= last) {
+ diff = first->insn - value;
+ if (diff == 0)
+ return first->fixup;
+ first++;
}
+
return 0;
}
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/13] ppc: Check for compilers that don't support relocation
Certain ppc compilers are known not to generate the .fixup section properly. The .fixup section is necessary to create a relocatable U-Boot image. A basic check for the existence of the .fixup section should hopefully catch the majority of broken compilers which don't support relocation. Signed-off-by: Peter Tyser --- lib_ppc/Makefile |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/lib_ppc/Makefile b/lib_ppc/Makefile index 60ea0c9..399b41e 100644 --- a/lib_ppc/Makefile +++ b/lib_ppc/Makefile @@ -42,6 +42,12 @@ SRCS := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y)) $(LIB):$(obj).depend $(OBJS) + @if ! $(CROSS_COMPILE)readelf -S $(OBJS) | grep -q '\.fixup.*PROGBITS';\ + then \ + echo "ERROR: Your compiler doesn't generate .fixup sections!";\ + echo " Upgrade to a recent toolchain."; \ + exit 1; \ + fi; $(AR) $(ARFLAGS) $@ $(OBJS) # -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/13] ppc: Remove board.c relocation fixups
Signed-off-by: Peter Tyser
---
lib_ppc/board.c | 50 --
1 files changed, 0 insertions(+), 50 deletions(-)
diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index e8509ee..4123e73 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -627,13 +627,8 @@ void board_init_f (ulong bootflag)
*/
void board_init_r (gd_t *id, ulong dest_addr)
{
- cmd_tbl_t *cmdtp;
char *s;
bd_t *bd;
- extern void malloc_bin_reloc (void);
-#ifndef CONFIG_ENV_IS_NOWHERE
- extern char * env_name_spec;
-#endif
ulong malloc_start;
#ifndef CONFIG_SYS_NO_FLASH
@@ -646,18 +641,7 @@ void board_init_r (gd_t *id, ulong dest_addr)
gd->flags |= GD_FLG_RELOC; /* tell others: relocation done */
/* The Malloc area is immediately below the monitor copy in DRAM */
-#if defined(CONFIG_RELOC_FIXUP_WORKS)
- gd->reloc_off = 0;
malloc_start = dest_addr - TOTAL_MALLOC_LEN;
-#else
- gd->reloc_off = dest_addr - CONFIG_SYS_MONITOR_BASE;
- malloc_start = CONFIG_SYS_MONITOR_BASE + gd->reloc_off -
- TOTAL_MALLOC_LEN;
-#endif
-
-#if defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx)
- gd->cpu += gd->reloc_off;
-#endif
#ifdef CONFIG_SERIAL_MULTI
serial_initialize();
@@ -682,38 +666,6 @@ void board_init_r (gd_t *id, ulong dest_addr)
monitor_flash_len = (ulong)&__init_end - dest_addr;
- /*
-* We have to relocate the command table manually
-*/
- for (cmdtp = &__u_boot_cmd_start; cmdtp != &__u_boot_cmd_end; cmdtp++)
{
- ulong addr;
- addr = (ulong) (cmdtp->cmd) + gd->reloc_off;
-#if 0
- printf ("Command \"%s\": 0x%08lx => 0x%08lx\n",
- cmdtp->name, (ulong) (cmdtp->cmd), addr);
-#endif
- cmdtp->cmd =
- (int (*)(struct cmd_tbl_s *, int, int, char *[]))addr;
-
- addr = (ulong)(cmdtp->name) + gd->reloc_off;
- cmdtp->name = (char *)addr;
-
- if (cmdtp->usage) {
- addr = (ulong)(cmdtp->usage) + gd->reloc_off;
- cmdtp->usage = (char *)addr;
- }
-#ifdef CONFIG_SYS_LONGHELP
- if (cmdtp->help) {
- addr = (ulong)(cmdtp->help) + gd->reloc_off;
- cmdtp->help = (char *)addr;
- }
-#endif
- }
- /* there are some other pointer constants we must deal with */
-#ifndef CONFIG_ENV_IS_NOWHERE
- env_name_spec += gd->reloc_off;
-#endif
-
WATCHDOG_RESET ();
#ifdef CONFIG_LOGBUFFER
@@ -721,7 +673,6 @@ void board_init_r (gd_t *id, ulong dest_addr)
#endif
#ifdef CONFIG_POST
post_output_backlog ();
- post_reloc ();
#endif
WATCHDOG_RESET();
@@ -752,7 +703,6 @@ void board_init_r (gd_t *id, ulong dest_addr)
asm ("sync ; isync");
mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);
- malloc_bin_reloc ();
#if !defined(CONFIG_SYS_NO_FLASH)
puts ("FLASH: ");
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/13] ppc: Fix relocation
This series attempts to fix relocation to RAM for ppc boards. I split the patches up pretty liberally, let me know if you'd like them organized differently. I tried to be thorough during the changes (especially #1), let me know if I missed anything, there's lots of linker scripts for ppc boards:) Peter Tyser (13): ppc: Enable full relocation to RAM ppc: Check for compilers that don't support relocation ppc: Remove board.c relocation fixups ppc: Remove pci config table pointer relocation fixups ppc: Remove extable relocation fixups ppc: Remove board-specific command table relocation fixups tsec: Remove PHY command relocation fixups fpga: Remove relocation fixups mpl: Remove memory test relocation fixups lwmon, lwmon5: Remove sysmon POST relocation fixups p3mx: Remove serial relocation fixups Conditionally perform common relocation fixups ppc: Remove reloc_off field from global_data structure board/LEOX/elpt860/u-boot.lds |1 - board/LEOX/elpt860/u-boot.lds.debug|1 - board/MAI/AmigaOneG3SE/u-boot.lds |1 - board/Marvell/db64360/u-boot.lds |1 - board/Marvell/db64460/u-boot.lds |1 - board/RPXClassic/u-boot.lds|1 - board/RPXClassic/u-boot.lds.debug |1 - board/RPXlite/u-boot.lds |1 - board/RPXlite/u-boot.lds.debug |1 - board/RPXlite_dw/u-boot.lds|1 - board/RPXlite_dw/u-boot.lds.debug |1 - board/RRvision/u-boot.lds |1 - board/adder/u-boot.lds |1 - board/amcc/acadia/u-boot-nand.lds |1 - board/amcc/acadia/u-boot.lds |1 - board/amcc/bamboo/u-boot-nand.lds |1 - board/amcc/bamboo/u-boot.lds |1 - board/amcc/bubinga/u-boot.lds |1 - board/amcc/canyonlands/u-boot-nand.lds |1 - board/amcc/canyonlands/u-boot.lds |1 - board/amcc/ebony/u-boot.lds|1 - board/amcc/katmai/u-boot.lds |1 - board/amcc/kilauea/u-boot-nand.lds |1 - board/amcc/kilauea/u-boot.lds |1 - board/amcc/luan/u-boot.lds |1 - board/amcc/makalu/u-boot.lds |1 - board/amcc/ocotea/u-boot.lds |1 - board/amcc/redwood/u-boot.lds |1 - board/amcc/sequoia/u-boot-nand.lds |1 - board/amcc/sequoia/u-boot-ram.lds |1 - board/amcc/sequoia/u-boot.lds |1 - board/amcc/taihu/u-boot.lds|1 - board/amcc/taishan/u-boot.lds |1 - board/amcc/walnut/u-boot.lds |1 - board/amcc/yosemite/u-boot.lds |1 - board/amcc/yucca/u-boot.lds|1 - board/amirix/ap1000/u-boot.lds |1 - board/c2mon/u-boot.lds |1 - board/c2mon/u-boot.lds.debug |1 - board/cm5200/u-boot.lds|1 - board/cogent/u-boot.lds|1 - board/cogent/u-boot.lds.debug |1 - board/cray/L1/u-boot.lds |1 - board/cray/L1/u-boot.lds.debug |1 - board/csb272/u-boot.lds|1 - board/csb472/u-boot.lds|1 - board/dave/PPChameleonEVB/u-boot.lds |1 - board/digsy_mtc/cmd_mtc.c | 30 - board/digsy_mtc/digsy_mtc.c|2 - board/eltec/bab7xx/u-boot.lds |1 - board/eltec/elppc/u-boot.lds |1 - board/eltec/mhpc/u-boot.lds|1 - board/eltec/mhpc/u-boot.lds.debug |1 - board/emk/top860/u-boot.lds|1 - board/emk/top860/u-boot.lds.debug |1 - board/ep88x/u-boot.lds |1 - board/eric/u-boot.lds |1 - board/esd/adciop/u-boot.lds|1 - board/esd/apc405/u-boot.lds|1 - board/esd/ar405/u-boot.lds |1 - board/esd/ash405/u-boot.lds|1 - board/esd/canbt/u-boot.lds |1 - board/esd/cms700/u-boot.lds|1 - board/esd/cpci2dp/u-boot.lds |1 - board/esd/cpci405/u-boot.lds |1 - board/esd/cpci750/u-boot.lds |1 - board/esd/cpciiser4/u-boot.lds |1 - board/esd/dasa_sim/u-boot.lds |1 - board/esd/dp405/u-boot.lds |1 - board/esd/du405/u-boot.lds |1 - board/esd/du440/u-boot.lds |1 - board/esd/hh405/u-boot.lds |1 - board/esd/hub405/u-boot.lds|1 - board/esd/ocrtc/u-boot.lds |1 - board/esd/pci405/u-boot.lds|1 - board/esd/plu405/u-boot.lds|1 - board/esd/pm
Re: [U-Boot] [PATCH v2] MAKEALL: Add summary information
> > +# Print statistics when ctrl-c is pressed > > +trap "print_stats; exit " 2 > > Why only on signal 2? Usually we use "1 2 3 15" in such cases. 2's the only case I've ever used for MAKEALL, I'll add the other cases as you suggest. > Also, you might add "0" here and then... > > > @@ -932,3 +956,5 @@ do > > ;; > > esac > > done > > + > > +print_stats I didn't trap 0 because I wasn't aware of a quick way to only call print_stats once when ctrl-c was pressed (eg trapping 0 and 2 would result in 2 print_stats calls with the current code). Let me know if there's a standard way to workaround this. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] MAKEALL: Add summary information
On Mon, 2009-09-21 at 00:09 +0200, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <1253317683-2831-1-git-send-email-pty...@xes-inc.com> you wrote: > > > > if [ "$BUILD_NCPUS" -gt 1 ] > > then > > - JOBS=-j`expr "$BUILD_NCPUS" + 1` > > + JOBS="-j $(($BUILD_NCPUS + 1))" > > else > > JOBS="" > > fi > > This is an unrelated change. I would not include it with this patch. Mike mentioned using POSIX math in the new arithmetic functions I added, which makes sense. I reasoned it was better to convert the 1 other reference to 'expr + 1' to the same POSIX style for consistency's sake. Changing 1 'expr + 1' reference to $((+ 1)) doesn't seem worth its own commit, so I rolled it into this patch. How about I just add a sentence to the commit message stating that I also converted math operations to be POSIX compliant? Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] DLMALLOC:!X86: add av_ initialization
On Sat, 2009-09-19 at 10:37 -0500, Nishanth Menon wrote:
> Peter Tyser said the following on 09/19/2009 09:03 AM:
> > On Fri, 2009-09-18 at 21:21 -0500, Nishanth Menon wrote:
> >
> >> This is questionable if this is really required
> >> as the av_ static initalized values should have
> >> been loaded to sdram as part of the boot process
> >> and initialization should have been done.
> >>
> >
> > Is there a reason you need to do this fixup? Based on your commit
> > message its unclear if this patch is really needed...
> >
> >
> Essentially, the loaded memory from the NOR looks all corrupted.
> I am unable to convince myself why the SDRAM is not updated
> with the static default inits - SDRAM corruption would have
> cracked everything else and scope measurement looks good too.
> >> Signed-off-by: Nishanth Menon >> void mem_malloc_init(ulong start, ulong size)
> >> {
> >> + u8 i;
> >> + av_[0] = av_[1] = 0;
> >> + for (i = 0; i < 128; i++)
> >> + av_[2 + i * 2] = av_[2 + i * 2 + 1] = bin_at(i);
> >> +
> >>mem_malloc_start = start;
> >>mem_malloc_end = start + size;
> >>mem_malloc_brk = start;
> >>
> >
> > If you are going to do this fixup, av_ should not be initialized with
> > values (you're currently doing the same initialization 2 times). In
> > general, we could probably shave a bit off of U-Boot's size by leaving
> > av_ uninitialized and implementing your manual calculation of av_ above,
> >
> yep.. missed finishing that out.. :(
> > but I'm not sure why this change should be included in this patch
> > series.
> >
> This patch is need for booting SDP3430 from NOR flash.
Once the initialized values for av_ are removed, this patch would be
useful for everyone. It looks like it removes a few hundred bytes of
code size, so I'm all for it. I'd be a bit concerned about why your
board wasn't loading the initialized av_ table though. Seems like it
would be indicative of a larger problem...
So in any case, I like the patch because it reduces code size, but I
don't think the explanation or commit message of "for an unknown reason
it makes my board work" commit message is the best. Its affecting every
board, so at a minimum it should describe how it benefits them - eg
changing static initialization into dynamic initialization saves some
space.
That's my $.02, feel free to proceed as you see fit as I don't have any
real power here:)
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] MAKEALL: Add summary information
This change adds some basic summary information to the MAKEALL script.
The summary information includes how many boards were compiled, how many
boards had compile warnings or errors, and which specific boards had
compile warnings or errors.
This information is useful when doing compile testing to quickly
determine which boards are broken.
As a side benefit, no empty $BOARD.ERR files are generated by MAKEALL.
Previously, each board had a corresponding $BOARD.ERR file, even if the
board compiled cleanly.
Signed-off-by: Peter Tyser
---
Changes since v1:
- Fix issue where summary was printed multiple times when a list
was composed of sublists
Changes since v2:
- Update script to only use POSIX arithmetic
Changes since v3:
- Remove unnecessary expansion of variables inside of $(( ... ))
MAKEALL | 32 +---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 1d50c34..c8e7add 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -1,11 +1,14 @@
#!/bin/sh
+# Print statistics when ctrl-c is pressed
+trap "print_stats; exit " 2
+
# Determine number of CPU cores if no default was set
: ${BUILD_NCPUS:="`getconf _NPROCESSORS_ONLN`"}
if [ "$BUILD_NCPUS" -gt 1 ]
then
- JOBS=-j`expr "$BUILD_NCPUS" + 1`
+ JOBS="-j $((BUILD_NCPUS + 1))"
else
JOBS=""
fi
@@ -31,6 +34,11 @@ fi
LIST=""
+# Keep track of the number of builds and errors
+ERR_CNT=0
+ERR_LIST=""
+TOTAL_CNT=0
+
#
## MPC5xx Systems
#
@@ -898,8 +906,14 @@ build_target() {
${MAKE} distclean >/dev/null
${MAKE} ${target}_config
- ${MAKE} ${JOBS} all 2>&1 >${LOG_DIR}/$target.MAKELOG \
- | tee ${LOG_DIR}/$target.ERR
+ ERR=$(${MAKE} ${JOBS} all 2>&1 > ${LOG_DIR}/$target.MAKELOG)
+ if [ "${ERR}" ] ; then
+ echo "$ERR" | tee ${LOG_DIR}/$target.ERR
+ ERR_CNT=$((ERR_CNT + 1))
+ ERR_LIST="${ERR_LIST} $target"
+ fi
+
+ TOTAL_CNT=$((TOTAL_CNT + 1))
${CROSS_COMPILE}size ${BUILD_DIR}/u-boot \
| tee -a ${LOG_DIR}/$target.MAKELOG
@@ -907,7 +921,17 @@ build_target() {
#---
+print_stats() {
+ echo ""
+ echo "- SUMMARY "
+ echo "Boards compiled: ${TOTAL_CNT}"
+ if [ ${ERR_CNT} -gt 0 ] ; then
+ echo "Boards with warnings or errors: ${ERR_CNT} (${ERR_LIST} )"
+ fi
+ echo "--"
+}
+#---
for arg in $@
do
case "$arg" in
@@ -932,3 +956,5 @@ do
;;
esac
done
+
+print_stats
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM:OMAP3:SDP3430: initial support
Hi Nishanth,
On Fri, 2009-09-18 at 21:21 -0500, Nishanth Menon wrote:
> From: David Brownell
>
> Start of SDP3430 support in "mainline"
> u-boot mainline code
>
> Original Patch written by David Brownell
I don't think the above comments are necessary. David will be credited
with authorship already, and the subject line and text below make it
clear what this patch does.
> Support default jumpering and:
> - UART1/ttyS0 console(legacy sdp3430 u-boot)
> - UART3/ttyS2 console (matching other boards,
>and SDP HW docs)
> - Ethernet
> - mmc0
> - NOR boot
>
> TODO:
> - mmc1
> - NAND (boot or 128M storage)
> - OneNAND (boot or 256M storage)
> - Fix NOR env variable load
> - Review SDRC timing configuration/DPLL
> configuration
> - Dynamically read FPGA dip switch settings and
> map NOR/NAND/ONENAND devices to right
> chipselects
>
> Currently the UART1 is enabled by default. for
> compatibility with other OMAP3 u-boot platforms,
> enable the #define of CONSOLE_J9.
>
> Ref: SDP3430:
> http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12013&contentId=28741
>
> Signed-off-by: David Brownell
> Signed-off-by: Nishanth Menon
> ---
> MAINTAINERS |1 +
> MAKEALL |1 +
> Makefile|3 +
> board/ti/sdp3430/Makefile | 49 ++
> board/ti/sdp3430/config.mk | 33
> board/ti/sdp3430/sdp.c | 194 ++
> board/ti/sdp3430/sdp.h | 376
> +++
> board/ti/sdp3430/u-boot.lds | 63 +++
> include/configs/omap3_sdp.h | 367 +
> 9 files changed, 1087 insertions(+), 0 deletions(-)
> create mode 100644 board/ti/sdp3430/Makefile
> create mode 100644 board/ti/sdp3430/config.mk
> create mode 100644 board/ti/sdp3430/sdp.c
> create mode 100644 board/ti/sdp3430/sdp.h
> create mode 100644 board/ti/sdp3430/u-boot.lds
> create mode 100644 include/configs/omap3_sdp.h
The board config header file should be renamed to sdp.h from
omap3_sdp.h. There was a recent thread discussing this convention "ARM
Pull Request" around Sept 6.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e9db278..adc8a63 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -619,6 +619,7 @@ Guennadi Liakhovetski
> Nishanth Menon
>
> omap3_zoom1 ARM CORTEX-A8 (OMAP3xx SoC)
> + omap3_sdp ARM CORTEX-A8 (OMAP3xx SoC)
You may as well keep the boards ordered alphabetically (and remove the
omap_ prefix from sdp).
> David Mller
>
> diff --git a/MAKEALL b/MAKEALL
> index f0ed8ea..53620eb 100755
> --- a/MAKEALL
> +++ b/MAKEALL
> @@ -588,6 +588,7 @@ LIST_ARM_CORTEX_A8=" \
> omap3_pandora \
> omap3_zoom1 \
> omap3_zoom2 \
> + omap3_sdp \
> "
Ditto.
> #
> diff --git a/Makefile b/Makefile
> index 5a4a109..2626147 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -3172,6 +3172,9 @@ omap3_zoom1_config :unconfig
> omap3_zoom2_config : unconfig
> @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 logicpd omap3
>
> +omap3_sdp_config : unconfig
> + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 sdp3430 ti omap3
> +
Ditto.
> +/**
> + * Routine: board_init
> + * Description: Early hardware init.
> +
> */
> +int board_init(void)
> +{
> + DECLARE_GLOBAL_DATA_PTR;
> +
I'd use the preferred multi-line comment style:
/*
*
*/
There are lots of other non-preferred multi-line comments throughout the
patch as well.
I personally don't think its necessary to put "Routine: " stuff
for each function either. It doesn't add any benefit, adds cruft to
grep output, and might get out of sync with the real function name at
some point. If it were me, I would get rid of "Description: " text too.
Its pretty obvious that the text "Early hardware init" is a description
of the function.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] DLMALLOC:!X86: add av_ initialization
On Fri, 2009-09-18 at 21:21 -0500, Nishanth Menon wrote:
> This is questionable if this is really required
> as the av_ static initalized values should have
> been loaded to sdram as part of the boot process
> and initialization should have been done.
Is there a reason you need to do this fixup? Based on your commit
message its unclear if this patch is really needed...
> Signed-off-by: Nishanth Menon void mem_malloc_init(ulong start, ulong size)
> {
> + u8 i;
> + av_[0] = av_[1] = 0;
> + for (i = 0; i < 128; i++)
> + av_[2 + i * 2] = av_[2 + i * 2 + 1] = bin_at(i);
> +
> mem_malloc_start = start;
> mem_malloc_end = start + size;
> mem_malloc_brk = start;
If you are going to do this fixup, av_ should not be initialized with
values (you're currently doing the same initialization 2 times). In
general, we could probably shave a bit off of U-Boot's size by leaving
av_ uninitialized and implementing your manual calculation of av_ above,
but I'm not sure why this change should be included in this patch
series.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] MAKEALL: Add summary information
This change adds some basic summary information to the MAKEALL script.
The summary information includes how many boards were compiled, how many
boards had compile warnings or errors, and which specific boards had
compile warnings or errors.
This information is useful when doing compile testing to quickly
determine which boards are broken.
As a side benefit, no empty $BOARD.ERR files are generated by MAKEALL.
Previously, each board had a corresponding $BOARD.ERR file, even if the
board compiled cleanly.
Signed-off-by: Peter Tyser
---
Changes since v1:
- Fix issue where summary was printed multiple times when a list
was composed of sublists
Changes since v2:
- Update script to only use POSIX arithmetic
MAKEALL | 32 +---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 1d50c34..e7bdbc4 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -1,11 +1,14 @@
#!/bin/sh
+# Print statistics when ctrl-c is pressed
+trap "print_stats; exit " 2
+
# Determine number of CPU cores if no default was set
: ${BUILD_NCPUS:="`getconf _NPROCESSORS_ONLN`"}
if [ "$BUILD_NCPUS" -gt 1 ]
then
- JOBS=-j`expr "$BUILD_NCPUS" + 1`
+ JOBS="-j $(($BUILD_NCPUS + 1))"
else
JOBS=""
fi
@@ -31,6 +34,11 @@ fi
LIST=""
+# Keep track of the number of builds and errors
+ERR_CNT=0
+ERR_LIST=""
+TOTAL_CNT=0
+
#
## MPC5xx Systems
#
@@ -898,8 +906,14 @@ build_target() {
${MAKE} distclean >/dev/null
${MAKE} ${target}_config
- ${MAKE} ${JOBS} all 2>&1 >${LOG_DIR}/$target.MAKELOG \
- | tee ${LOG_DIR}/$target.ERR
+ ERR=$(${MAKE} ${JOBS} all 2>&1 > ${LOG_DIR}/$target.MAKELOG)
+ if [ "${ERR}" ] ; then
+ echo "$ERR" | tee ${LOG_DIR}/$target.ERR
+ ERR_CNT=$(($ERR_CNT + 1))
+ ERR_LIST="${ERR_LIST} $target"
+ fi
+
+ TOTAL_CNT=$(($TOTAL_CNT + 1))
${CROSS_COMPILE}size ${BUILD_DIR}/u-boot \
| tee -a ${LOG_DIR}/$target.MAKELOG
@@ -907,7 +921,17 @@ build_target() {
#---
+print_stats() {
+ echo ""
+ echo "- SUMMARY "
+ echo "Boards compiled: ${TOTAL_CNT}"
+ if [ ${ERR_CNT} -gt 0 ] ; then
+ echo "Boards with warnings or errors: ${ERR_CNT} (${ERR_LIST} )"
+ fi
+ echo "--"
+}
+#---
for arg in $@
do
case "$arg" in
@@ -932,3 +956,5 @@ do
;;
esac
done
+
+print_stats
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] MAKEALL: Add summary information
This change adds some basic summary information to the MAKEALL script.
The summary information includes how many boards were compiled, how many
boards had compile warnings or errors, and which specific boards had
compile warnings or errors.
This information is useful when doing compile testing to quickly
determine which boards are broken.
As a side benefit, no empty $BOARD.ERR files are generated by MAKEALL.
Previously, each board had a corresponding $BOARD.ERR file, even if the
board compiled cleanly.
Signed-off-by: Peter Tyser
---
Changes since v1:
- Fix issue where summary was printed multiple times when a list
was composed of sublists
MAKEALL | 30 --
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 1d50c34..a63d028 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -1,5 +1,8 @@
#!/bin/sh
+# Print statistics when ctrl-c is pressed
+trap "print_stats; exit " 2
+
# Determine number of CPU cores if no default was set
: ${BUILD_NCPUS:="`getconf _NPROCESSORS_ONLN`"}
@@ -31,6 +34,11 @@ fi
LIST=""
+# Keep track of the number of builds and errors
+ERR_CNT=0
+ERR_LIST=""
+TOTAL_CNT=0
+
#
## MPC5xx Systems
#
@@ -898,8 +906,14 @@ build_target() {
${MAKE} distclean >/dev/null
${MAKE} ${target}_config
- ${MAKE} ${JOBS} all 2>&1 >${LOG_DIR}/$target.MAKELOG \
- | tee ${LOG_DIR}/$target.ERR
+ ERR=$(${MAKE} ${JOBS} all 2>&1 > ${LOG_DIR}/$target.MAKELOG)
+ if [ "${ERR}" ] ; then
+ echo "$ERR" | tee ${LOG_DIR}/$target.ERR
+ ERR_CNT=`expr ${ERR_CNT} + 1`
+ ERR_LIST="${ERR_LIST} $target"
+ fi
+
+ TOTAL_CNT=`expr ${TOTAL_CNT} + 1`
${CROSS_COMPILE}size ${BUILD_DIR}/u-boot \
| tee -a ${LOG_DIR}/$target.MAKELOG
@@ -907,7 +921,17 @@ build_target() {
#---
+print_stats() {
+ echo ""
+ echo "- SUMMARY "
+ echo "Boards compiled: ${TOTAL_CNT}"
+ if [ ${ERR_CNT} -gt 0 ] ; then
+ echo "Boards with warnings or errors: ${ERR_CNT} (${ERR_LIST} )"
+ fi
+ echo "--"
+}
+#---
for arg in $@
do
case "$arg" in
@@ -932,3 +956,5 @@ do
;;
esac
done
+
+print_stats
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MAKEALL: Add summary information
This change adds some basic summary information to the MAKEALL script.
The summary information includes how many boards were compiled, how many
boards had compile warnings or errors, and which specific boards had
compile warnings or errors.
This information is useful when doing compile testing to quickly
determine which boards are broken.
As a side benefit, no empty $BOARD.ERR files are generated by MAKEALL.
Previously, each board had a corresponding $BOARD.ERR file, even if the
board compiled cleanly.
Signed-off-by: Peter Tyser
---
MAKEALL | 30 --
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index 1d50c34..d7c90ec 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -1,5 +1,8 @@
#!/bin/sh
+# Print statistics when ctrl-c is pressed
+trap "print_stats; exit " 2
+
# Determine number of CPU cores if no default was set
: ${BUILD_NCPUS:="`getconf _NPROCESSORS_ONLN`"}
@@ -31,6 +34,11 @@ fi
LIST=""
+# Keep track of the number of builds and errors
+ERR_CNT=0
+ERR_LIST=""
+TOTAL_CNT=0
+
#
## MPC5xx Systems
#
@@ -898,8 +906,14 @@ build_target() {
${MAKE} distclean >/dev/null
${MAKE} ${target}_config
- ${MAKE} ${JOBS} all 2>&1 >${LOG_DIR}/$target.MAKELOG \
- | tee ${LOG_DIR}/$target.ERR
+ ERR=$(${MAKE} ${JOBS} all 2>&1 > ${LOG_DIR}/$target.MAKELOG)
+ if [ "${ERR}" ] ; then
+ echo "$ERR" | tee ${LOG_DIR}/$target.ERR
+ ERR_CNT=`expr ${ERR_CNT} + 1`
+ ERR_LIST="${ERR_LIST} $target"
+ fi
+
+ TOTAL_CNT=`expr ${TOTAL_CNT} + 1`
${CROSS_COMPILE}size ${BUILD_DIR}/u-boot \
| tee -a ${LOG_DIR}/$target.MAKELOG
@@ -907,7 +921,17 @@ build_target() {
#---
+print_stats() {
+ echo ""
+ echo "- SUMMARY "
+ echo "Boards compiled: ${TOTAL_CNT}"
+ if [ ${ERR_CNT} -gt 0 ] ; then
+ echo "Boards with warnings or errors: ${ERR_CNT} (${ERR_LIST} )"
+ fi
+ echo "--"
+}
+#---
for arg in $@
do
case "$arg" in
@@ -931,4 +955,6 @@ do
*) build_target ${arg}
;;
esac
+
+ print_stats
done
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch
> > > Sorry, I don't have an example. Just a guess, weak function references:
> > >
> > > void weak_fun(void) __attribute__ ((weak));
> > > if (weak_fun)
> > >weak_fun();
> >
> > Using default weak functions as well as overridden weak functions both
> > definitely work. So the pointers must be being updated correctly. I
> > guess I'm not sure where specifically a problem could arise. Let me
> > know if you have any additional details. I'm hoping to send the patches
> > out later today, maybe some review/testing will make things clearer.
>
> This does not work:
>
> void weak_fun(void) __attribute__ ((weak));
> printf("weak_fun:%p\n", weak_fun);
>
> prints "weak 17f9c000" after relocation
> for me, should be NULL when weak_fun is undefined.
Ahh, I see. I see the same thing. In general U-Boot declares weak
functions by either using the 'alias' attribute:
static int __def_eth_init(bd_t *bis)
{
return -1;
}
int cpu_eth_init(bd_t *bis) __attribute__((weak, alias("__def_eth_init")));
or by declaring a function as weak:
void __attribute__((weak)) _machine_restart(void)
{
}
Both these scenarios work with the current relocation fixup scheme.
What is a real world scenario (such as your example) when someone would
declare a weak function, but not actually implement a default. Doesn't
that defeat the purpose of having a weak function in the first place?
Eg why would someone use your example of:
void weak_fun(void) __attribute__ ((weak));
...
if (weak_fun)
weak_fun();
...
over:
void weak_fun(void) __attribute__ ((weak))
{
};
...
weak_fun();
...
(or the alias implementation)
I'm trying to grasp the limitations of the current relocation mechanism
as I'm afraid I don't have time to dig through all PPC architectures'
start.S files to fix their relocation code right now:)
Thanks,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch
On Fri, 2009-09-18 at 16:52 +0200, Joakim Tjernlund wrote: > Peter Tyser wrote on 18/09/2009 16:28:35: > > > > > > > > On Thu, 2009-09-17 at 09:06 +0200, Joakim Tjernlund wrote: > > > > > > > > > > > > When preparing the ppc relocation patches I noticed that the gcc > > > > > > -mrelocatable compiler flag increases the .reloc section by 3 or 4 > > > > > > Kbytes. I did a compile test, and this increase pushes the ALPR > > > > > > board > > > > > > back over 256K (it recently had the same size issue, see "ppc4xx: > > > > > > Remove > > > > > > some features from ALPR to fit into 256k again"). No other boards > > > > > > appear to break size-wise. > > > > > > > > > > > > So I guess I had 2 questions: > > > > > > 1. Is enabling proper relocation worth the 3/4KB that will be added > > > > > > to > > > > > > every ppc binary? I personally think so as the manual relocation > > > > > > fixups > > > > > > that currently litter the code can be removed and true relocation is > > > > > > much less hokey in the long run. X-ES's U-Boot binaries also are > > > > > > generally much smaller than their allocated 512KB, so this increase > > > > > > doesn't affect me much:) > > > > > > > > > > You can get some of this space back by just #ifdef:ing out the manual > > > > > relocation > > > > > code. Removing it completely is OK by me though. > > > > > > > > The original patchset I had planned on submitting completely removed all > > > > PPC-specific manual relocation fixups, but didn't do anything with the > > > > references to gd->reloc_off in common files. The thought was that we > > > > could get other architectures to properly relocate, then get rid of > > > > gd->reloc_off globally. Otherwise there's going to be a fair number of > > > > #ifdef CONFIG_RELOC_FIXUP_WORKS littering the code until all arches > > > > support proper relocation which is a bit ugly. > > > > > > > > With all PPC-specific relocation manual fixups removed, the ALPR still > > > > didn't fit. However, I just removed all relocation fixups in the common > > > > fpga code as well as added some #ifdef CONFIG_RELOC_FIXUP_WORKS in > > > > common code, and now the ALPR fits in its designated 256KB. It looks to > > > > be 1.8KB larger than the original, non-relocatable code. > > > > > > > > I'll submit this patch for review shortly. I'm assuming people are OK > > > > with the 1.8KB image size increase? Perhaps some of Jocke's suggestions > > > > below can decrease the size as well. > > > > > > I remembered one thing, the reloc asm has a bug, one should not > > > relocate NULL values, pasting in an email from me sent to the list > > > some time ago about this: > > > > Hi Jocke, > > Do you have a C snippet that would bring this issue out? I would assume > > gcc would not emit relocation fixup information for NULL values. > > Variables initialized to NULL should be put in the bss segment, which > > just get zeroed out, not relocated. > > Sorry, I don't have an example. Just a guess, weak function references: > > void weak_fun(void) __attribute__ ((weak)); > if (weak_fun) > weak_fun(); Using default weak functions as well as overridden weak functions both definitely work. So the pointers must be being updated correctly. I guess I'm not sure where specifically a problem could arise. Let me know if you have any additional details. I'm hoping to send the patches out later today, maybe some review/testing will make things clearer. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch
> > On Thu, 2009-09-17 at 09:06 +0200, Joakim Tjernlund wrote:
> > > >
> > > > When preparing the ppc relocation patches I noticed that the gcc
> > > > -mrelocatable compiler flag increases the .reloc section by 3 or 4
> > > > Kbytes. I did a compile test, and this increase pushes the ALPR board
> > > > back over 256K (it recently had the same size issue, see "ppc4xx: Remove
> > > > some features from ALPR to fit into 256k again"). No other boards
> > > > appear to break size-wise.
> > > >
> > > > So I guess I had 2 questions:
> > > > 1. Is enabling proper relocation worth the 3/4KB that will be added to
> > > > every ppc binary? I personally think so as the manual relocation fixups
> > > > that currently litter the code can be removed and true relocation is
> > > > much less hokey in the long run. X-ES's U-Boot binaries also are
> > > > generally much smaller than their allocated 512KB, so this increase
> > > > doesn't affect me much:)
> > >
> > > You can get some of this space back by just #ifdef:ing out the manual
> > > relocation
> > > code. Removing it completely is OK by me though.
> >
> > The original patchset I had planned on submitting completely removed all
> > PPC-specific manual relocation fixups, but didn't do anything with the
> > references to gd->reloc_off in common files. The thought was that we
> > could get other architectures to properly relocate, then get rid of
> > gd->reloc_off globally. Otherwise there's going to be a fair number of
> > #ifdef CONFIG_RELOC_FIXUP_WORKS littering the code until all arches
> > support proper relocation which is a bit ugly.
> >
> > With all PPC-specific relocation manual fixups removed, the ALPR still
> > didn't fit. However, I just removed all relocation fixups in the common
> > fpga code as well as added some #ifdef CONFIG_RELOC_FIXUP_WORKS in
> > common code, and now the ALPR fits in its designated 256KB. It looks to
> > be 1.8KB larger than the original, non-relocatable code.
> >
> > I'll submit this patch for review shortly. I'm assuming people are OK
> > with the 1.8KB image size increase? Perhaps some of Jocke's suggestions
> > below can decrease the size as well.
>
> I remembered one thing, the reloc asm has a bug, one should not
> relocate NULL values, pasting in an email from me sent to the list
> some time ago about this:
Hi Jocke,
Do you have a C snippet that would bring this issue out? I would assume
gcc would not emit relocation fixup information for NULL values.
Variables initialized to NULL should be put in the bss segment, which
just get zeroed out, not relocated. For example, I just tested:
char *reloc_test = NULL;
/* After relocation to RAM */
printf("RAM test_reloc @ %p\n", test_reloc);
Which prints out the correct address:
RAM test_reloc @ (null)
Let me know if I'm missing something.
Best,
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch
On Thu, 2009-09-17 at 09:06 +0200, Joakim Tjernlund wrote: > > > > When preparing the ppc relocation patches I noticed that the gcc > > -mrelocatable compiler flag increases the .reloc section by 3 or 4 > > Kbytes. I did a compile test, and this increase pushes the ALPR board > > back over 256K (it recently had the same size issue, see "ppc4xx: Remove > > some features from ALPR to fit into 256k again"). No other boards > > appear to break size-wise. > > > > So I guess I had 2 questions: > > 1. Is enabling proper relocation worth the 3/4KB that will be added to > > every ppc binary? I personally think so as the manual relocation fixups > > that currently litter the code can be removed and true relocation is > > much less hokey in the long run. X-ES's U-Boot binaries also are > > generally much smaller than their allocated 512KB, so this increase > > doesn't affect me much:) > > You can get some of this space back by just #ifdef:ing out the manual > relocation > code. Removing it completely is OK by me though. The original patchset I had planned on submitting completely removed all PPC-specific manual relocation fixups, but didn't do anything with the references to gd->reloc_off in common files. The thought was that we could get other architectures to properly relocate, then get rid of gd->reloc_off globally. Otherwise there's going to be a fair number of #ifdef CONFIG_RELOC_FIXUP_WORKS littering the code until all arches support proper relocation which is a bit ugly. With all PPC-specific relocation manual fixups removed, the ALPR still didn't fit. However, I just removed all relocation fixups in the common fpga code as well as added some #ifdef CONFIG_RELOC_FIXUP_WORKS in common code, and now the ALPR fits in its designated 256KB. It looks to be 1.8KB larger than the original, non-relocatable code. I'll submit this patch for review shortly. I'm assuming people are OK with the 1.8KB image size increase? Perhaps some of Jocke's suggestions below can decrease the size as well. Best, Peter > The size can be further decreased by looking over the use of global data: > - Some tables can be replaced by code. > - Combine several global variables into one struct variable. > - reducing string literals > > One day we can fit the whole relocation table into built-in CPU memory, > hopefully > that will make it possible to make u-boot a true PIC exe > > Jocke > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ppc: Clean up calling of phy_reset() during init
Remove board-specific #ifdefs for calling phy_reset() during initializtion Signed-off-by: Peter Tyser --- include/configs/CCM.h|1 + include/configs/ELPT860.h|1 + include/configs/IP860.h |1 + include/configs/IVML24.h |2 ++ include/configs/IVMS8.h |2 ++ include/configs/MPC8260ADS.h |1 + include/configs/MPC8266ADS.h |1 + include/configs/MPC8560ADS.h |1 + include/configs/RPXsuper.h |1 + include/configs/SBC8540.h|1 + include/configs/SPD823TS.h |2 ++ include/configs/pcu_e.h |1 + include/configs/sbc8560.h|1 + include/configs/stxgp3.h |1 + lib_ppc/board.c | 17 + 15 files changed, 18 insertions(+), 16 deletions(-) diff --git a/include/configs/CCM.h b/include/configs/CCM.h index 8a94420..3f4a2c1 100644 --- a/include/configs/CCM.h +++ b/include/configs/CCM.h @@ -38,6 +38,7 @@ #define CONFIG_MPC860 1 /* This is a MPC860 CPU ... */ #define CONFIG_CCM 1 /* on a Card Controller Module */ #define CONFIG_MISC_INIT_R /* Call misc_init_r() */ +#define CONFIG_RESET_PHY_R 1 /* Call reset_phy() */ #define CONFIG_8xx_CONS_SMC11 /* Console is on SMC1 */ #undef CONFIG_8xx_CONS_SMC2 diff --git a/include/configs/ELPT860.h b/include/configs/ELPT860.h index ff58ea9..0f56302 100644 --- a/include/configs/ELPT860.h +++ b/include/configs/ELPT860.h @@ -57,6 +57,7 @@ #define CONFIG_BOOTDELAY 5 /* autoboot after 5 seconds */ #define CONFIG_BOARD_EARLY_INIT_F 1/* Call board_early_init_f */ +#define CONFIG_RESET_PHY_R 1 /* Call reset_phy() */ /* BOOT arguments */ #define CONFIG_PREBOOT\ diff --git a/include/configs/IP860.h b/include/configs/IP860.h index 125aa6c..be63ea5 100644 --- a/include/configs/IP860.h +++ b/include/configs/IP860.h @@ -36,6 +36,7 @@ #define CONFIG_MPC860 1 /* This is a MPC860 CPU */ #define CONFIG_IP860 1 /* ...on a IP860 board */ #define CONFIG_BOARD_EARLY_INIT_F 1/* Call board_early_init_f */ +#define CONFIG_RESET_PHY_R 1 /* Call reset_phy() */ #defineCONFIG_8xx_CONS_SMC11 /* Console is on SMC1 */ #define CONFIG_BAUDRATE9600 diff --git a/include/configs/IVML24.h b/include/configs/IVML24.h index cd100df..1a4924e 100644 --- a/include/configs/IVML24.h +++ b/include/configs/IVML24.h @@ -52,6 +52,8 @@ #defineCONFIG_CLOCKS_IN_MHZ1 /* clocks passsed to Linux in MHz */ #define CONFIG_8xx_GCLK_FREQ50331648 +#define CONFIG_RESET_PHY_R 1 /* Call reset_phy() */ + #defineCONFIG_SHOW_BOOT_PROGRESS 1 /* Show boot progress on LEDs */ #if 0 diff --git a/include/configs/IVMS8.h b/include/configs/IVMS8.h index 125cb4b..256cabd 100644 --- a/include/configs/IVMS8.h +++ b/include/configs/IVMS8.h @@ -49,6 +49,8 @@ #undef CONFIG_8xx_CONS_NONE #define CONFIG_BAUDRATE115200 +#define CONFIG_RESET_PHY_R 1 /* Call reset_phy() */ + #defineCONFIG_CLOCKS_IN_MHZ1 /* clocks passsed to Linux in MHz */ #define CONFIG_8xx_GCLK_FREQ50331648 diff --git a/include/configs/MPC8260ADS.h b/include/configs/MPC8260ADS.h index 942a4cc..52dd4e7 100644 --- a/include/configs/MPC8260ADS.h +++ b/include/configs/MPC8260ADS.h @@ -81,6 +81,7 @@ #endif /* CONFIG_ADSTYPE == CONFIG_SYS_8272ADS */ #define CONFIG_BOARD_EARLY_INIT_F 1/* Call board_early_init_f */ +#define CONFIG_RESET_PHY_R 1 /* Call reset_phy() */ /* allow serial and ethaddr to be overwritten */ #define CONFIG_ENV_OVERWRITE diff --git a/include/configs/MPC8266ADS.h b/include/configs/MPC8266ADS.h index 4fd86d3..b0162c3 100644 --- a/include/configs/MPC8266ADS.h +++ b/include/configs/MPC8266ADS.h @@ -54,6 +54,7 @@ #define CONFIG_CPM21 /* Has a CPM2 */ #define CONFIG_BOARD_EARLY_INIT_F 1/* Call board_early_init_f */ +#define CONFIG_RESET_PHY_R 1 /* Call reset_phy() */ /* allow serial and ethaddr to be overwritten */ #define CONFIG_ENV_OVERWRITE diff --git a/include/configs/MPC8560ADS.h b/include/configs/MPC8560ADS.h index c1a1a6d..8ddce5c 100644 --- a/include/configs/MPC8560ADS.h +++ b/include/configs/MPC8560ADS.h @@ -48,6 +48,7 @@ #undef CONFIG_ETHER_ON_FCC /* cpm FCC ethernet support */ #define CONFIG_ENV_OVERWRITE #define CONFIG_FSL_LAW 1 /* Use common FSL init code */ +#define CONFIG_RESET_PHY_R 1 /* Call reset_phy() */ /* * sysclk for MPC85xx diff --git a/include/configs/RPXsuper.h b/include/configs/RPXsuper.h index e97ef95..da962f3 100644 --- a/include/configs/RPXsuper.h +++ b/include/configs/RPXsuper.h @@ -189,6 +189,7 @@ #define CONFIG_CPM21 /* Has a CPM2 */ #define
[U-Boot] [PATCH 1/2] ppc: Clean up calling of misc_init_r() during init
Remove board-specific #ifdefs for calling misc_init_r() during initializtion Signed-off-by: Peter Tyser --- include/configs/CCM.h|1 + include/configs/CPCI405.h|1 + include/configs/CPCI4052.h |1 + include/configs/CPCI405AB.h |1 + include/configs/CPCI405DT.h |1 + include/configs/W7OLMC.h |1 + include/configs/W7OLMG.h |1 + include/configs/cogent_mpc8260.h |1 + include/configs/cogent_mpc8xx.h |1 + include/configs/lwmon.h |5 +++-- include/configs/pcu_e.h |2 ++ include/configs/sc3.h|1 + lib_ppc/board.c | 12 +--- 13 files changed, 16 insertions(+), 13 deletions(-) diff --git a/include/configs/CCM.h b/include/configs/CCM.h index d1c293f..8a94420 100644 --- a/include/configs/CCM.h +++ b/include/configs/CCM.h @@ -37,6 +37,7 @@ #define CONFIG_MPC860 1 /* This is a MPC860 CPU ... */ #define CONFIG_CCM 1 /* on a Card Controller Module */ +#define CONFIG_MISC_INIT_R /* Call misc_init_r() */ #define CONFIG_8xx_CONS_SMC11 /* Console is on SMC1 */ #undef CONFIG_8xx_CONS_SMC2 diff --git a/include/configs/CPCI405.h b/include/configs/CPCI405.h index fca6de0..d131aea 100644 --- a/include/configs/CPCI405.h +++ b/include/configs/CPCI405.h @@ -38,6 +38,7 @@ #define CONFIG_CPCI405 1 /* ...on a CPCI405 board*/ #define CONFIG_BOARD_EARLY_INIT_F 1/* call board_early_init_f()*/ +#define CONFIG_MISC_INIT_R 1 /* call misc_init_r() */ #define CONFIG_SYS_CLK_FREQ3300 /* external frequency to pll */ diff --git a/include/configs/CPCI4052.h b/include/configs/CPCI4052.h index fd04566..07c4e35 100644 --- a/include/configs/CPCI4052.h +++ b/include/configs/CPCI4052.h @@ -40,6 +40,7 @@ #undef CONFIG_CPCI405_6U /* enable this for 6U boards*/ #define CONFIG_BOARD_EARLY_INIT_F 1/* call board_early_init_f()*/ +#define CONFIG_MISC_INIT_R 1 /* call misc_init_r() */ #define CONFIG_SYS_CLK_FREQ /* external frequency to pll */ diff --git a/include/configs/CPCI405AB.h b/include/configs/CPCI405AB.h index d718ed4..c78552b 100644 --- a/include/configs/CPCI405AB.h +++ b/include/configs/CPCI405AB.h @@ -40,6 +40,7 @@ #define CONFIG_CPCI405AB 1 /* ...and special AB version*/ #define CONFIG_BOARD_EARLY_INIT_F 1/* call board_early_init_f()*/ +#define CONFIG_MISC_INIT_R 1 /* call misc_init_r() */ #define CONFIG_SYS_CLK_FREQ /* external frequency to pll */ diff --git a/include/configs/CPCI405DT.h b/include/configs/CPCI405DT.h index 09df470..59e0778 100644 --- a/include/configs/CPCI405DT.h +++ b/include/configs/CPCI405DT.h @@ -39,6 +39,7 @@ #define CONFIG_CPCI405_VER21 /* ...version 2 */ #define CONFIG_BOARD_EARLY_INIT_F 1/* call board_early_init_f()*/ +#define CONFIG_MISC_INIT_R 1 /* call misc_init_r() */ #define CONFIG_SYS_CLK_FREQ /* external frequency to pll */ diff --git a/include/configs/W7OLMC.h b/include/configs/W7OLMC.h index 40e4735..c017915 100644 --- a/include/configs/W7OLMC.h +++ b/include/configs/W7OLMC.h @@ -40,6 +40,7 @@ #define CONFIG_BOARD_EARLY_INIT_F 1/* Call board_early_init_f */ #defineCONFIG_MISC_INIT_F 1 /* and misc_init_f() */ +#defineCONFIG_MISC_INIT_R 1 /* and misc_init_r() */ #define CONFIG_SYS_CLK_FREQ/* external frequency to pll */ diff --git a/include/configs/W7OLMG.h b/include/configs/W7OLMG.h index a62f1b4..1d4ad13 100644 --- a/include/configs/W7OLMG.h +++ b/include/configs/W7OLMG.h @@ -40,6 +40,7 @@ #define CONFIG_BOARD_EARLY_INIT_F 1/* Call board_early_init_f */ #defineCONFIG_MISC_INIT_F 1 /* and misc_init_f() */ +#defineCONFIG_MISC_INIT_R 1 /* and misc_init_r() */ #define CONFIG_SYS_CLK_FREQ/* external frequency to pll */ diff --git a/include/configs/cogent_mpc8260.h b/include/configs/cogent_mpc8260.h index c580230..566565a 100644 --- a/include/configs/cogent_mpc8260.h +++ b/include/configs/cogent_mpc8260.h @@ -38,6 +38,7 @@ #define CONFIG_CPM21 /* Has a CPM2 */ #defineCONFIG_MISC_INIT_F 1 /* Use misc_init_f() */ +#defineCONFIG_MISC_INIT_R /* Use misc_init_r() */ /* Cogent Modular Architecture options */ #define CONFIG_CMA282 1 /* ...on a CMA282 CPU module*/ diff --git a/include/configs/cogent_mpc8xx.h b/include/configs/cogent_mpc8xx.h index 17bd9a0..750c0df 100644 --- a/include/configs/cogent_mpc8xx.h +++ b/include/configs/cogent_mpc8xx.h @@ -37,6 +37,7 @@ #define
[U-Boot] [PATCH v2] Remove deprecated 'autoscr' command/variables
The more standard 'source' command provides identical functionality to
the autoscr command.
Environment variable names/values on the MVBC_P, MVBML7, kmeter1,
mgcoge, and km8xx boards are updated to no longer refernce 'autoscr'.
The 'autoscript' and 'autoscript_uname' environment variables are
also removed.
Signed-off-by: Peter Tyser
---
Changes since v1:
- Removed all references to autoscript and autoscript_uname, previously
just the autoscr command was removed.
README |8
board/LEOX/elpt860/README.LEOX |2 +-
board/matrix_vision/mvbc_p/mvbc_p_autoscript |4 ++--
board/matrix_vision/mvblm7/mvblm7_autoscript |4 ++--
board/musenki/README |2 +-
board/pn62/cmd_pn62.c| 18 --
common/cmd_load.c| 18 --
common/cmd_net.c | 15 ---
common/cmd_source.c | 18 --
doc/README.IPHASE4539|2 +-
doc/README.m52277evb |2 +-
doc/README.m5373evb |2 +-
doc/README.m54455evb |2 +-
doc/README.m5475evb |2 +-
doc/feature-removal-schedule.txt | 19 ---
include/configs/MVBC_P.h | 14 +++---
include/configs/MVBLM7.h | 14 +++---
include/configs/keymile-common.h |6 +++---
18 files changed, 28 insertions(+), 124 deletions(-)
diff --git a/README b/README
index ff4ed8b..67b8eb0 100644
--- a/README
+++ b/README
@@ -3008,14 +3008,6 @@ Some configuration options can be set using Environment
Variables:
configuration from the BOOTP server, but not try to
load any image using TFTP
- autoscript - if set to "yes" commands like "loadb", "loady",
- "bootp", "tftpb", "rarpboot" and "nfs" will attempt
- to automatically run script images (by internally
- calling "source").
-
- autoscript_uname - if script image is in a format (FIT) this
-variable is used to get script subimage unit name.
-
autostart- if set to "yes", an image loaded using the "bootp",
"rarpboot", "tftpboot" or "diskboot" commands will
be automatically started (by internally calling
diff --git a/board/LEOX/elpt860/README.LEOX b/board/LEOX/elpt860/README.LEOX
index 25524af..e8ab867 100644
--- a/board/LEOX/elpt860/README.LEOX
+++ b/board/LEOX/elpt860/README.LEOX
@@ -68,7 +68,6 @@ Type "run nfsboot" to mount root filesystem over NFS
Hit any key to stop autoboot: 0
LEOX_elpt860: help
askenv - get environment variables from stdin
-autoscr - run script from memory
base- print or set address offset
bdinfo - print Board Info structure
bootm - boot application image from memory
@@ -100,6 +99,7 @@ run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
sleep - delay execution for some time
+source - run script from memory
tftpboot- boot image via network using TFTP protocol
and env variables ipaddr and serverip
version - print monitor version
diff --git a/board/matrix_vision/mvbc_p/mvbc_p_autoscript
b/board/matrix_vision/mvbc_p/mvbc_p_autoscript
index 1102354..9b21f30 100644
--- a/board/matrix_vision/mvbc_p/mvbc_p_autoscript
+++ b/board/matrix_vision/mvbc_p/mvbc_p_autoscript
@@ -26,7 +26,7 @@ if test ${oprofile} = yes;
then
setenv addprofile setenv bootargs \${bootargs} profile=\${profile}
fi
-if test ${autoscr_boot} != no;
+if test ${autoscript_boot} != no;
then
if test ${netboot} = yes;
then
@@ -44,5 +44,5 @@ then
echo "=== bootfromflash ==="
run cpdtb rundtb bootfromflash
else
- echo "=== boot stopped with autoscr_boot no ==="
+ echo "=== boot stopped with autoscript_boot no ==="
fi
diff --git a/board/matrix_vision/mvblm7/mvblm7_autoscript
b/board/matrix_vision/mvblm7/mvblm7_autoscript
index 6f9357f..dc385fd 100644
--- a/board/matrix_vision/mvblm7/mvblm7_autoscript
+++ b/board/matrix_vision/mvblm7/mvblm7_autoscript
@@ -21,7 +21,7 @@ setenv set_static_nm setenv netmask \${static_netmask}
setenv set_static_gw setenv gatewayip \${static_gateway}
setenv set_ip setenv ip \${ipaddr}::\${gatewayip}:\${netmask}
setenv ramparam setenv bootargs root=/dev/ram0 ro rootfstype=squashfs
-if test ${autoscr_boot} != no;
+if test ${autoscript_boot} != no;
then
if test ${netboot} = yes;
then
@@ -39,5 +39,5 @@ then
echo "=== bootfromflash ==="
run cpd
Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch
On Mon, 2009-09-14 at 23:26 +0200, Wolfgang Denk wrote: > Dear Peter Tyser, > > In message <1252709159-22326-1-git-send-email-pty...@xes-inc.com> you wrote: > > ** This patch is only meant to allow others to test relocation, it > > should not be applied!! ** > > > > This patch is a quick hack to enable proper relocation on powerpc > > boards. I tested on some mpc85xx-based boards. > > > > I updated the common ppc config.mk and u-boot.lds in cpu/ as needed, but > > didn't bother to update board-specific ones. CONFIG_RELOC_FIXUP_WORKS > > has also been hacked into common.h unconditionally. > > > > So if you want to try out this patch, make sure that you > > 1. Remove the *(.fixup) entry from the text section in your board's > > linker script. > > > > 2. Make sure your board's config.mk file includes: > > PLATFORM_RELFLAGS += -mrelocatable > > > > I'm hoping that relocation will work for all powerpc boards assuming you > > use a semi-recent version. I think at least gcc >= 3.4.6 (or maybe even > > 3.4.5) should work. > > > > It'd be great if people could give feedback if this patch works for > > them, and if not, how their board breaks. > > I have tested this patch on the following boards / tool chains: > > > Tool Chain: ELDK 3.1.1 ELDK 4.0ELDK 4.2 > gcc-3.3.3 gcc-4.0.0 gcc-4.2.2 > Board:binutils-2.14 binutils-2.16.1 binutils-2.17.50.0 > TQM834x OK OK OK > Canyonlands NOK1OK OK > MPC5121ADSOK OK OK > Haleakala OK OK OK > OcoteaNOK1OK OK > > NOK1: build error because old compiler does not accept "-m440" option When preparing the ppc relocation patches I noticed that the gcc -mrelocatable compiler flag increases the .reloc section by 3 or 4 Kbytes. I did a compile test, and this increase pushes the ALPR board back over 256K (it recently had the same size issue, see "ppc4xx: Remove some features from ALPR to fit into 256k again"). No other boards appear to break size-wise. So I guess I had 2 questions: 1. Is enabling proper relocation worth the 3/4KB that will be added to every ppc binary? I personally think so as the manual relocation fixups that currently litter the code can be removed and true relocation is much less hokey in the long run. X-ES's U-Boot binaries also are generally much smaller than their allocated 512KB, so this increase doesn't affect me much:) 2. Assuming we do want proper relocation, what should be done to decrease the size of the ALPR binary? Pieter had mentioned getting rid of CONFIG_CMD_PCI was OK in a previous email thread. Making this change puts the ALPR binary at around 253KB. I can roll this change in the relocation fixup changeset if he is OK with it. Thanks, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] RFC: stretch merge window?
> On Wednesday 16 September 2009 15:32:26 Wolfgang Denk wrote: > > The reorganization of the ARM custodian setup has caused some changes > > to the workflow, and I wonder if we should allow for a longer merge > > window? > > > > What do you think about stretching the MW by another week (with or > > without also shifting the release date) ? > > I would welcome a longer MW. I see no need for a release shift though. Just > my > 0.02$. +1 from me. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
