[U-Boot] 83xx: add missing CSCONFIG_ODT_WR_CFG for 832x CPUs
Signed-off-by: Heiko Schocher h...@denx.de --- include/mpc83xx.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/mpc83xx.h b/include/mpc83xx.h index fd742c7..44115c9 100644 --- a/include/mpc83xx.h +++ b/include/mpc83xx.h @@ -837,6 +837,9 @@ #define CSCONFIG_EN0x8000 #define CSCONFIG_AP0x0080 #define CSCONFIG_ODT_WR_ACS0x0001 +#if defined(CONFIG_MPC832x) +#define CSCONFIG_ODT_WR_CFG0x0004 +#endif #define CSCONFIG_BANK_BIT_30x4000 #define CSCONFIG_ROW_BIT 0x0700 #define CSCONFIG_ROW_BIT_120x -- 1.6.0.6 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] License Problems for standalone application at u-boot
Dear Peter Chen, In message 1250474437.13885.23.ca...@nchen-desktop you wrote: 1. Does jump table means the function lists which the standalone applications uses? The jump table provided by U-Boot exactly for this purpose is the list of functions exported through the include/_exports.h header file. At my situation, the standalone program is hardware independent. And the u-boot supplies hardware interfaces according to different platforms. Like at u-boot/board/myboard/myboard.c, there are a function lists struct, and the address of this struct will transfer to standalone program. If you set up your own list of function pointers (in addition or instead of the jump table provided by the include/_exports.h header), then this is a form of linking against the U-Boot code, and your application must be released under GPL. Is it free to license at below situation: The function list which is defined at u-boot/board/myboard/myboard.c, and all functions in this list only uses functions at include/_exports.h and some of user-defined functions. Your description is really vague; it would be easier if you could give specific code examples or such. If some of user-defined functions refers to code that is covered by the GPL, then your application must be released under GPL, too. Or Need I to export my functions at include/_exports.h? At my standalone application only uses address of functions at function list, not the name of function, so It doesn't need to include include_exports.h. What you implement is some form of static linking. ... which technically is a stupid thing to do, as your application will only be able to run with a very specific binary image of U-Boot. Even rebuilding the same version of U-Boot (jut using a different tool chain, for example) will most likely result in a U-Boot image that cannot run your application code any more. Even worse, ther ewill be not even a clear failure mode, instead you will execute random code. We would like to release our u-boot under GPL, but standalone Actually you have no choice; U-Boot is already covered by the GPL - as soon as you distribute the code, you also have to fufil the resulting requirements of the GPL. application includes some IP properties code, so we want to close it. This is no problem, as long as you strictly follow the rules. I think the exception from the GPL is pretty well defined and leaves not much room for interpretation. What you describe sounds fishy to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If a group of N persons implements a COBOL compiler, there will be N-1 passes. Someone in the group has to be the manager. - T. Cheatham ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Regarding the PORTING of U-boot to ARM7 based board.
Hi, I am Uday new to U-boot. Can any one tell me how to load U-boot in to ARM7(phillips LPC2129) based board. regards, Uday udybs...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding the PORTING of U-boot to ARM7 based board.
Dear uday bhaskar, In message 75bad7120908170135j1e3fcd49h6f3ebdc8ff591...@mail.gmail.com you wrote: I am Uday new to U-boot. Can any one tell me how to load U-boot in to ARM7(phillips LPC2129) based board. I'm not sure what exactly your question is. The process of porting U-Boot to your hardware is described in the Porting Guide section of the README. To actually load the resulting U-Boot image into the boot device (flash memory) on your board you will usually use a JTAG debugger. We use and recommend the BDI3000 by Abatron for this purpose. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I perceive a possibility of an immediate chronological sequence of events which includes a violence. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Adding support for DevKit8000
This patch adds support for the DevKit8000 board. Signed-off-by: Frederik Kriewitz frede...@kriewitz.eu --- Makefile|3 + board/omap3/devkit8000/Makefile | 51 + board/omap3/devkit8000/config.mk| 34 +++ board/omap3/devkit8000/devkit8000.c | 117 +++ board/omap3/devkit8000/devkit8000.h | 376 +++ doc/README.omap3| 11 + include/asm-arm/mach-types.h| 13 ++ include/configs/omap3_devkit8000.h | 365 ++ 8 files changed, 970 insertions(+), 0 deletions(-) create mode 100644 board/omap3/devkit8000/Makefile create mode 100644 board/omap3/devkit8000/config.mk create mode 100644 board/omap3/devkit8000/devkit8000.c create mode 100644 board/omap3/devkit8000/devkit8000.h create mode 100644 include/configs/omap3_devkit8000.h diff --git a/Makefile b/Makefile index 329e0f5..a040249 100644 --- a/Makefile +++ b/Makefile @@ -3084,6 +3084,9 @@ omap3_zoom1_config : unconfig omap3_zoom2_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 omap3 omap3 +omap3_devkit8000_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 devkit8000 omap3 omap3 + # ## XScale Systems # diff --git a/board/omap3/devkit8000/Makefile b/board/omap3/devkit8000/Makefile new file mode 100644 index 000..63e16b0 --- /dev/null +++ b/board/omap3/devkit8000/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# Modified by Frederik Kriewitz frede...@kriewitz.eu +# +# 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 $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := devkit8000.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/omap3/devkit8000/config.mk b/board/omap3/devkit8000/config.mk new file mode 100644 index 000..de973a5 --- /dev/null +++ b/board/omap3/devkit8000/config.mk @@ -0,0 +1,34 @@ +# +# (C) Copyright 2006 +# Texas Instruments, www.ti.com +# +# Modified by Frederik Kriewitz frede...@kriewitz.eu +# +# DevKit8000 uses OMAP3 (ARM-CortexA8) cpu +# see http://www.ti.com/ for more information on Texas Instruments +# +# 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 +# +# Physical Address: +# 8000' (bank0) +# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000 +# (mem base + reserved) + +# For use with external or internal boots. +TEXT_BASE = 0x80e8 diff --git a/board/omap3/devkit8000/devkit8000.c b/board/omap3/devkit8000/devkit8000.c new file mode 100644 index 000..2f30a2f --- /dev/null +++ b/board/omap3/devkit8000/devkit8000.c @@ -0,0 +1,117 @@ +/* + * (C) Copyright 2004-2008 + * Texas Instruments, www.ti.com + * + * Modified by Frederik Kriewitz frede...@kriewitz.eu + * + * Author : + * Sunil Kumar sunilsain...@gmail.com + * Shashi Ranjan
Re: [U-Boot] BMP display.
Dear Tuma, please keep the mailing list on Cc: - thanks. In message 200908171305.55605.chernigovs...@spb.gs.ru you wrote: In message 200908131326.20857.chernigovs...@spb.gs.ru you wrote: I have LCD drivers from TI for OMAP3 evm board. I need to include this files to my current u-boot. I have .h and .c files with some functional I need. I want to call some functions implemented in this files from main_loop (). I You definitely do NOT want to do that. the main_loop is the command interpreter. Don't mess with that code. Okay. We'll talk about it a little bit later. put .h files in the include directory, adn .c files to the drivers directory. Then I include appropriate .h file in main.c, compile and get error: /root/GS/Taimen/U-Boot-Upgrader/common/main.c:343: undefined reference to `enable_lcd_power'. What do I do wrong? How new files should be added to the project? You also have to make sure these files get linked, so check the parts of the Makefiles that include objects into the respective libraries. I understand what you've written but what file should I check? Maybe we should start from question - where (in what directories) I should put my new files? I have some .h files and few .c. I cannot answer this question without knowing that these files contain. Is this board specific code? Then it should go into your own board directory. Is it OMAP3 specific, generic stuff? Then it should probably go into the cpu/arm_cortexa8/omap3 directory. Is it driver code? Then it should go into some directory below drivers/ - maybe into drivers/video/ ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The high cost of living hasn't affected its popularity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BMP display.
On Monday 17 August 2009 13:33:50 you wrote: Dear Tuma, please keep the mailing list on Cc: - thanks. In message 200908171305.55605.chernigovs...@spb.gs.ru you wrote: In message 200908131326.20857.chernigovs...@spb.gs.ru you wrote: I have LCD drivers from TI for OMAP3 evm board. I need to include this files to my current u-boot. I have .h and .c files with some functional I need. I want to call some functions implemented in this files from main_loop (). I You definitely do NOT want to do that. the main_loop is the command interpreter. Don't mess with that code. Okay. We'll talk about it a little bit later. put .h files in the include directory, adn .c files to the drivers directory. Then I include appropriate .h file in main.c, compile and get error: /root/GS/Taimen/U-Boot-Upgrader/common/main.c:343: undefined reference to `enable_lcd_power'. What do I do wrong? How new files should be added to the project? You also have to make sure these files get linked, so check the parts of the Makefiles that include objects into the respective libraries. I understand what you've written but what file should I check? Maybe we should start from question - where (in what directories) I should put my new files? I have some .h files and few .c. I cannot answer this question without knowing that these files contain. Is this board specific code? Then it should go into your own board directory. Is it OMAP3 specific, generic stuff? Then it should probably go into the cpu/arm_cortexa8/omap3 directory. Is it driver code? Then it should go into some directory below drivers/ - maybe into drivers/video/ ? Yes, you're right - this is LCD driver (as I see it is based on some specific i2c driver, so it should be included too). And not specific for the OMAP3 evm board - OMAP3's display is only experimental for me now, final H/W will use another LCD. But I cannt find subdirectory video int drivers. Do you mean drivers in the root of U-Boot directory tree? Thank you. -- Software Developer General Satellite Corp. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for DevKit8000
Dear Frederik Kriewitz, In message 1250500736-20034-1-git-send-email-frede...@kriewitz.eu you wrote: This patch adds support for the DevKit8000 board. Signed-off-by: Frederik Kriewitz frede...@kriewitz.eu --- Makefile|3 + board/omap3/devkit8000/Makefile | 51 + board/omap3/devkit8000/config.mk| 34 +++ board/omap3/devkit8000/devkit8000.c | 117 +++ board/omap3/devkit8000/devkit8000.h | 376 +++ doc/README.omap3| 11 + include/asm-arm/mach-types.h| 13 ++ include/configs/omap3_devkit8000.h | 365 ++ 8 files changed, 970 insertions(+), 0 deletions(-) create mode 100644 board/omap3/devkit8000/Makefile create mode 100644 board/omap3/devkit8000/config.mk create mode 100644 board/omap3/devkit8000/devkit8000.c create mode 100644 board/omap3/devkit8000/devkit8000.h create mode 100644 include/configs/omap3_devkit8000.h There are some Coding Style issues like trailing white space, vertical alignment by spaces instead of TAB as required, C++ comments etc. Entry to MAINTAINERS missing. diff --git a/Makefile b/Makefile index 329e0f5..a040249 100644 --- a/Makefile +++ b/Makefile @@ -3084,6 +3084,9 @@ omap3_zoom1_config :unconfig omap3_zoom2_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 zoom2 omap3 omap3 +omap3_devkit8000_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 devkit8000 omap3 omap3 Please keep list sorted. diff --git a/board/omap3/devkit8000/Makefile b/board/omap3/devkit8000/Makefile new file mode 100644 index 000..63e16b0 --- /dev/null +++ b/board/omap3/devkit8000/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# Modified by Frederik Kriewitz frede...@kriewitz.eu Please add Copyright and year, then (applies globally). diff --git a/doc/README.omap3 b/doc/README.omap3 index 6227151..e24531c 100644 --- a/doc/README.omap3 +++ b/doc/README.omap3 @@ -21,6 +21,8 @@ Currently the following boards are supported: * TI/Logic PD Zoom 2 [7] +* DevKit8000 [9] + Toolchain = @@ -61,6 +63,11 @@ make make omap3_zoom2_config make +* DevKit8000: + +make omap3_devkit8000_config +make Please keep list sorted. diff --git a/include/asm-arm/mach-types.h b/include/asm-arm/mach-types.h index 5293d67..adacc90 100644 --- a/include/asm-arm/mach-types.h +++ b/include/asm-arm/mach-types.h @@ -2241,6 +2241,7 @@ extern unsigned int __machine_arch_type; #define MACH_TYPE_OMAP3_WL_FF 2258 #define MACH_TYPE_SIMCOM 2259 #define MACH_TYPE_MCWEBIO 2260 +#define MACH_TYPE_OMAP3_DEVKIT8000 2330 Please don't do this. Instead, send a request for an update of the mach-types.h file to the ARM custodian, please. diff --git a/include/configs/omap3_devkit8000.h b/include/configs/omap3_devkit8000.h new file mode 100644 index 000..b2871c8 --- /dev/null +++ b/include/configs/omap3_devkit8000.h ... +#define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + SZ_128K) +#define CONFIG_SYS_GBL_DATA_SIZE 128 /* bytes reserved for */ + /* initial data */ + One blank line is enough. +/* commands to include */ +#include config_cmd_default.h + +#define CONFIG_CMD_EXT2 /* EXT2 Support */ +#define CONFIG_CMD_FAT /* FAT support */ +#define CONFIG_CMD_JFFS2 /* JFFS2 Support*/ +#define CONFIG_CMD_MTDPARTS /* Enable MTD parts commands*/ +#define CONFIG_MTD_DEVICE/* needed for mtdparts commands */ +#define MTDIDS_DEFAULT nand0=nand +#define MTDPARTS_DEFAULT mtdparts=nand:512k(x-loader),\ + 1920k(u-boot),128k(u-boot-env),\ + 4m(kernel),-(fs) I recommend not to mix the list of command definitions with other defines. +#define CONFIG_CMD_I2C /* I2C serial bus support */ +#define CONFIG_CMD_MMC /* MMC support */ +#define CONFIG_CMD_NAND /* NAND support */ +#define CONFIG_CMD_NAND_LOCK_UNLOCK /* nand (un)lock commands */ Also, it may make sense to kepp such lists sorted, too. +#define CONFIG_BOOTCOMMAND \ + if mmc init 0; then \ + if run loadbootscript; then \ + run bootscript; \ + else \ + if run loaduimage; then \ + run mmcboot; \ + else run nandboot; \ + fi; \ + fi; \ + else run nandboot; fi In my opinion it makes little sense to define
Re: [U-Boot] BMP display.
Dear Tuma, In message 200908171338.23342.chernigovs...@spb.gs.ru you wrote: ... I cannot answer this question without knowing that these files contain. Is this board specific code? Then it should go into your own board directory. Is it OMAP3 specific, generic stuff? Then it should probably go into the cpu/arm_cortexa8/omap3 directory. Is it driver code? Then it should go into some directory below drivers/ - maybe into drivers/video/ ? Yes, you're right - this is LCD driver (as I see it is based on some specific i2c driver, so it should be included too). And not specific for the OMAP3 evm board - OMAP3's display is only experimental for me now, final H/W will use another LCD. The LCD type is probably the least concern here. But I cannt find subdirectory video int drivers. Do you mean drivers in the root of U-Boot directory tree? Yes, I do: - ls drivers/video/ Makefile ati_radeon_fb.h cfb_console.c mx3fb.c sed156x.c videomodes.c ati_ids.hatmel_lcdfb.cct69000.c s6e63d6.c sm501.c videomodes.h ati_radeon_fb.c bus_vcxk.c mb862xx.c sed13806.c smiLynxEM.c Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de e-credibility: the non-guaranteeable likelihood that the electronic data you're seeing is genuine rather than somebody's made-up crap. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] tools: mkimage: Making table_entry code global
1. get_table_entry_id API made global
2. get_table_entry_name API made global
3. struct table_entry moved to image.h
Currently it is used by image.c only
These APIs are very usefull and can be used by other part of code
This patch makes these APIs and struct global
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log:
v2: updated as per review feedback for v1
APIs and struct declared in same context with some documentation
The actual use case apart from image.c will come in kwbimage support patch
common/image.c | 10 ++
include/image.h | 25 +
2 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/common/image.c b/common/image.c
index 1d15148..2e16347 100644
--- a/common/image.c
+++ b/common/image.c
@@ -74,12 +74,6 @@ static image_header_t* image_get_ramdisk (ulong rd_addr,
uint8_t arch,
#include image.h
#endif /* !USE_HOSTCC*/
-typedef struct table_entry {
- int id; /* as defined in image.h*/
- char*sname; /* short (input) name */
- char*lname; /* long (output) name */
-} table_entry_t;
-
static table_entry_t uimage_arch[] = {
{ IH_ARCH_INVALID,NULL, Invalid ARCH, },
{ IH_ARCH_ALPHA, alpha,Alpha,},
@@ -514,7 +508,7 @@ static void genimg_print_time (time_t timestamp)
* long entry name if translation succeeds
* msg otherwise
*/
-static char *get_table_entry_name (table_entry_t *table, char *msg, int id)
+char *get_table_entry_name (table_entry_t *table, char *msg, int id)
{
for (; table-id = 0; ++table) {
if (table-id == id)
@@ -561,7 +555,7 @@ const char *genimg_get_comp_name (uint8_t comp)
* entry id if translation succeeds
* -1 otherwise
*/
-static int get_table_entry_id (table_entry_t *table,
+int get_table_entry_id (table_entry_t *table,
const char *table_name, const char *name)
{
table_entry_t *t;
diff --git a/include/image.h b/include/image.h
index 7c6eb04..7fe87f3 100644
--- a/include/image.h
+++ b/include/image.h
@@ -299,6 +299,31 @@ int genimg_get_comp_id (const char *name);
#define IMAGE_FORMAT_LEGACY0x01/* legacy image_header based format */
#define IMAGE_FORMAT_FIT 0x02/* new, libfdt based format */
+/*
+ * Translation table for entries of a specific type
+ * This structue is used by the global functions get_table_entry_id,
+ * get_table_entry_name and these functions and this structure can also be
+ * referred by other part of code
+ */
+typedef struct table_entry {
+ int id;
+ char*sname; /* name used to find table entry */
+ char*lname; /* name used to print for messages */
+} table_entry_t;
+
+/*
+ * get_table_entry_id() will go over translation table trying to find
+ * entry that matches given short name. If matching entry is found,
+ * its id returned to the caller.
+ */
+int get_table_entry_id (table_entry_t *table,
+ const char *table_name, const char *name);
+/*
+ * get_table_entry_name() will go over translation table trying to find
+ * entry that matches given id. If matching entry is found, its long
+ * name is returned to the caller.
+ */
+char *get_table_entry_name (table_entry_t *table, char *msg, int id);
void genimg_print_size (uint32_t size);
int genimg_get_format (void *img_addr);
int genimg_has_config (bootm_headers_t *images);
--
1.5.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BMP display.
On Monday 17 August 2009 13:52:46 you wrote: Dear Tuma, In message 200908171338.23342.chernigovs...@spb.gs.ru you wrote: ... I cannot answer this question without knowing that these files contain. Is this board specific code? Then it should go into your own board directory. Is it OMAP3 specific, generic stuff? Then it should probably go into the cpu/arm_cortexa8/omap3 directory. Is it driver code? Then it should go into some directory below drivers/ - maybe into drivers/video/ ? Yes, you're right - this is LCD driver (as I see it is based on some specific i2c driver, so it should be included too). And not specific for the OMAP3 evm board - OMAP3's display is only experimental for me now, final H/W will use another LCD. The LCD type is probably the least concern here. But I cannt find subdirectory video int drivers. Do you mean drivers in the root of U-Boot directory tree? Yes, I do: - ls drivers/video/ Makefile ati_radeon_fb.h cfb_console.c mx3fb.c sed156x.c videomodes.c ati_ids.hatmel_lcdfb.cct69000.c s6e63d6.c sm501.c videomodes.h ati_radeon_fb.c bus_vcxk.c mb862xx.c sed13806.c smiLynxEM.c Here are all my subdirectoryes in drivers: ls ./drivers -l | grep -i drwx drwxr-xr-x 3 root root552 2009-08-12 16:42 nand drwxr-xr-x 3 root root216 2009-08-12 16:42 nand_legacy drwxr-xr-x 3 root root280 2009-08-12 16:42 onenand drwxr-xr-x 4 root root 1176 2009-08-12 16:42 sk98lin I see videomodes.* in your video, so what is about videomodes.* in my U-Boot: ls ./drivers/videomodes.* -l -rw-r--r-- 1 root root 7137 2009-07-14 16:31 ./drivers/videomodes.c -rw-r--r-- 1 root root 3204 2009-07-14 16:31 ./drivers/videomodes.h -rw-r--r-- 1 root root 7396 2009-08-12 16:42 ./drivers/videomodes.o It seems I have no video subdirectory. So should I put all my drivers files to drivers? Sorry, but I _have to_ use this (not latest) version of U-Boot now. Best regards, Wolfgang Denk -- Software Developer General Satellite Corp. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier: - Even though all ARM systems basicy used the same compiler options to select a specific ABI from the tool chain, the code for this was distributed over all cpu/*/config.mk files. We move this one level up into lib_arm/config.mk instead. - So far, we only checked if -mapcs-32 was supported by the tool chain; if yes, this was used, if not, -mabi=apcs-gnu was selected, no matter if the tool chain actually understood this option. There was no support for EABI conformant tool chains. This patch implements the following logic: 1) If the tool chain supports -mabi=aapcs-linux -mno-thumb-interwork we use these options (EABI conformant tool chain). 2) Otherwise, we check first if -mapcs-32 is supported, and then check for -mabi=apcs-gnu If one test succeeds, we use the first found option. 3) In case 2), we also test if -mno-thumb-interwork, and use this if the test succeeds. [For -mabi=aapcs-linux we set -mno-thumb-interwork mandatorily.] This way we use a similar logic for the compile options as the Linux kenrel does. - Some EABI conformant tool chains cause external references to utility functions like raise(); such functions are provided in the new file lib_arm/eabi_compat.c Note that lib_arm/config.mk gets parsed several times, so we must make sure to add eabi_compat.o only once to the linker list. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Dirk Behme dirk.be...@googlemail.com Cc: Magnus Lilja lilja.mag...@gmail.com Cc: Tom Rix tom@windriver.com Cc: Prafulla Wadaskar prafu...@marvell.com --- I have run a full MAKEALL arm for ELDK releases 3.1 (gcc 3.3.3), 3.1.1 (gcc 3.3.3), 4.1 (gcc 4.0.0) and 4.2 (gcc 4.2.2, both as arm [softfloat] and armVFP [VFP hardfloat]), and all of these both with USE_PRIVATE_LIBGCC=yes (i. e. using U-Boot internal libgcc replacement code) and without (i. e. using the tool chain provided standard libgcc instead). The ELDK fails to build the big-endian IXP boards, but this is a restriction of the ELDK, not a new issue introcued by this patch. Except of this, all build were succesful. Note 1: Please note that older tool chains (based on binutils versions older than 2.16) will have problems with the SORT_BY_ALIGNMENT() and SORT_BY_NAME() functions introduced to the linker scripts with commit f62fb99941c6. I'll soon submit a patch to fix this issue. Final tests are running right now. Note 2: Even though this is a bigger change, I consider it a bug fix and therefor tend to have it included into the upcoming release. Of course this requires sufficient test coverage and feedback. Please help!! Note 3: Most ARM systems also define this: PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) I guess this can be unified and moved to lib_arm/config.mk, too, but I would like to handle this in a separate, later patch. This makes testing (and bisecting) easier, and it is a non-critical problem. config.mk |2 +- cpu/arm1136/config.mk |2 -- cpu/arm1176/config.mk |2 -- cpu/arm1176/s3c64xx/config.mk |1 - cpu/arm720t/config.mk |2 -- cpu/arm920t/config.mk |2 -- cpu/arm925t/config.mk |2 -- cpu/arm926ejs/config.mk |2 -- cpu/arm926ejs/davinci/config.mk |2 -- cpu/arm946es/config.mk |2 -- cpu/arm_cortexa8/config.mk |1 - cpu/arm_cortexa8/omap3/board.c |7 --- cpu/arm_intcm/config.mk |2 -- cpu/ixp/config.mk |1 - cpu/lh7a40x/config.mk |2 -- cpu/pxa/config.mk |2 -- cpu/s3c44b0/config.mk |2 -- cpu/sa1100/config.mk|2 -- lib_arm/Makefile| 15 --- lib_arm/config.mk | 28 lib_arm/eabi_compat.c | 18 ++ 21 files changed, 59 insertions(+), 40 deletions(-) create mode 100644 lib_arm/eabi_compat.c diff --git a/config.mk b/config.mk index fd56621..0c6d1d1 100644 --- a/config.mk +++ b/config.mk @@ -86,7 +86,7 @@ ifdef ARCH sinclude $(TOPDIR)/lib_$(ARCH)/config.mk # include architecture dependend rules endif ifdef CPU -sinclude $(TOPDIR)/cpu/$(CPU)/config.mk# include CPU specific rules +sinclude $(TOPDIR)/cpu/$(CPU)/config.mk#
Re: [U-Boot] BMP display.
Dear Tuma, In message 200908171512.57938.chernigovs...@spb.gs.ru you wrote: It seems I have no video subdirectory. So should I put all my drivers files to drivers? No. Sorry, but I _have to_ use this (not latest) version of U-Boot now. This will not work. Please use recent code. You must have a really, really (I mean: awfully) old version. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Is the glass half empty, half full, or twice as large as it needs to ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix all linker scripts for older binutils versions (pre-2.16)
Commit f62fb99941c6 fixed handling of all rodata sections by using a
wildcard combined with calls to ld's builtin functions SORT_BY_ALIGNMENT()
and SORT_BY_NAME(). Unfortunately these functions were only
introduced with biunutils version 2.16, so the modification broke
building with all tool chains using older binutils.
This patch makes it work again. This is done by omitting the use of
these functions for such old tool chains. This will result in
slightly larger target binaries, as the rodata sections are no longer
in optimal order alignment-wise which reauls in unused gaps, but the
effect was found to be insignificant - especially compared to the fact
that you cannot build U-Boot at all in the current state.
As ld seems to have no support for conditionals we run the linker
script through the C preprocessor which can be easily used to remove
the unwanted function calls.
Note that the C preprocessor must be run with the -ansi (or a
-std=) option to make sure all the system-specific predefined
macros outside the reserved namespace are suppressed. Otherise, cpp
might for example substitute powerpc to 1, thus corrupting for
example OUTPUT_ARCH(powerpc) etc.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Mike Frysinger vap...@gentoo.org
---
Compile tested on ARM and PPC, with ELDK 3.1, 3.1.1, 4.1 and 4.2,
on ARM both with and without USE_PRIVATE_LIBGCC=yes.
I'm not sure if this is to be considered a bug fix (if you have to
use an older tool chain, it certainly solves a serious problem of the
current code) and should go into the current release, or if we should
rather wait with this for the next version. Comments welcome.
Mike, I am aware that Blackfin is already using the C preprocessor to
generate it's linker scripts. I guess this step can now be folded into
this general mechanism. Do you want to provide such a patch, or shall
I do it?
Makefile | 15 +++
board/netstar/Makefile|9 ++---
board/voiceblue/Makefile | 11 +++
config.mk | 12 +++-
nand_spl/board/amcc/acadia/Makefile |7 +--
nand_spl/board/amcc/bamboo/Makefile |7 +--
nand_spl/board/amcc/canyonlands/Makefile |7 +--
nand_spl/board/amcc/kilauea/Makefile |7 +--
nand_spl/board/amcc/sequoia/Makefile |7 +--
nand_spl/board/freescale/mpc8313erdb/Makefile |7 +--
nand_spl/board/freescale/mx31pdk/Makefile |7 +--
nand_spl/board/samsung/smdk6400/Makefile |7 +--
nand_spl/board/sheldon/simpc8313/Makefile |7 +--
onenand_ipl/board/apollon/Makefile|7 +--
15 files changed, 86 insertions(+), 33 deletions(-)
diff --git a/Makefile b/Makefile
index 329e0f5..2636ac0 100644
--- a/Makefile
+++ b/Makefile
@@ -326,11 +326,13 @@ GEN_UBOOT = \
cd $(LNDIR) $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-Map u-boot.map -o u-boot
-$(obj)u-boot: depend $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS)
$(LDSCRIPT)
+$(obj)u-boot: depend $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT)
$(obj)u-boot.lds
$(GEN_UBOOT)
ifeq ($(CONFIG_KALLSYMS),y)
- smap=`$(call SYSTEM_MAP,u-boot) | awk '$$2 ~ /[tTwW]/ {printf
$$1 $$3 000}'` ; \
- $(CC) $(CFLAGS) -DSYSTEM_MAP=\$${smap}\ -c
common/system_map.c -o $(obj)common/system_map.o
+ smap=`$(call SYSTEM_MAP,u-boot) | \
+ awk '$$2 ~ /[tTwW]/ {printf $$1 $$3 000}'` ; \
+ $(CC) $(CFLAGS) -DSYSTEM_MAP=\$${smap}\ \
+ -c common/system_map.c -o $(obj)common/system_map.o
$(GEN_UBOOT) $(obj)common/system_map.o
endif
@@ -349,6 +351,9 @@ $(SUBDIRS): depend
$(LDSCRIPT): depend
$(MAKE) -C $(dir $@) $(notdir $@)
+$(obj)u-boot.lds: $(LDSCRIPT)
+ $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $^
$@
+
$(NAND_SPL): $(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
$(MAKE) -C nand_spl/board/$(BOARDDIR) all
@@ -3653,10 +3658,12 @@ clean:
$(obj)board/trab/trab_fkt $(obj)board/voiceblue/eeprom \
$(obj)board/armltd/{integratorap,integratorcp}/u-boot.lds \
$(obj)lib_blackfin/u-boot.lds \
+ $(obj)u-boot.lds \
$(obj)cpu/blackfin/bootrom-asm-offsets.[chs]
@rm -f $(obj)include/bmp_logo.h
- @rm -f $(obj)nand_spl/{u-boot-spl,u-boot-spl.map,System.map}
+ @rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
@rm -f
$(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl-2k.bin,ipl-4k.bin,ipl.map}
+ @rm -f $(obj)onenand_ipl/u-boot.lds
[U-Boot] [PATCH 1/4] tools: mkimage: Making genimg_print_size API global
Currently it is used by image.c only
This API can be used by additional mkimage types supports
for ex. kwbimage, to use it the API is made global
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
common/image.c |3 +--
include/image.h |1 +
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/image.c b/common/image.c
index 63939b8..1d15148 100644
--- a/common/image.c
+++ b/common/image.c
@@ -158,7 +158,6 @@ static table_entry_t uimage_comp[] = {
uint32_t crc32 (uint32_t, const unsigned char *, uint);
uint32_t crc32_wd (uint32_t, const unsigned char *, uint, uint);
-static void genimg_print_size (uint32_t size);
#if defined(CONFIG_TIMESTAMP) || defined(CONFIG_CMD_DATE) ||
defined(USE_HOSTCC)
static void genimg_print_time (time_t timestamp);
#endif
@@ -473,7 +472,7 @@ void memmove_wd (void *to, void *from, size_t len, ulong
chunksz)
}
#endif /* !USE_HOSTCC */
-static void genimg_print_size (uint32_t size)
+void genimg_print_size (uint32_t size)
{
#ifndef USE_HOSTCC
printf (%d Bytes = , size);
diff --git a/include/image.h b/include/image.h
index 02af3df..95f4b14 100644
--- a/include/image.h
+++ b/include/image.h
@@ -292,6 +292,7 @@ int genimg_get_os_id (const char *name);
int genimg_get_arch_id (const char *name);
int genimg_get_type_id (const char *name);
int genimg_get_comp_id (const char *name);
+void genimg_print_size (uint32_t size);
#ifndef USE_HOSTCC
/* Image format types, returned by _get_format() routine */
--
1.5.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/4] tools: mkimage: Making table_entry code global
1. get_table_entry_id API made global
2. get_table_entry_name API made global
3. struct table_entry moved to image.h
Currently it is used by image.c only
These APIs are very usefull and can be used by other part of code
This patch makes these APIs and struct global
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
change log:
updated as per review comments for v1
added some comments
common/image.c | 10 ++
include/image.h | 26 ++
2 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/common/image.c b/common/image.c
index 1d15148..2e16347 100644
--- a/common/image.c
+++ b/common/image.c
@@ -74,12 +74,6 @@ static image_header_t* image_get_ramdisk (ulong rd_addr,
uint8_t arch,
#include image.h
#endif /* !USE_HOSTCC*/
-typedef struct table_entry {
- int id; /* as defined in image.h*/
- char*sname; /* short (input) name */
- char*lname; /* long (output) name */
-} table_entry_t;
-
static table_entry_t uimage_arch[] = {
{ IH_ARCH_INVALID,NULL, Invalid ARCH, },
{ IH_ARCH_ALPHA, alpha,Alpha,},
@@ -514,7 +508,7 @@ static void genimg_print_time (time_t timestamp)
* long entry name if translation succeeds
* msg otherwise
*/
-static char *get_table_entry_name (table_entry_t *table, char *msg, int id)
+char *get_table_entry_name (table_entry_t *table, char *msg, int id)
{
for (; table-id = 0; ++table) {
if (table-id == id)
@@ -561,7 +555,7 @@ const char *genimg_get_comp_name (uint8_t comp)
* entry id if translation succeeds
* -1 otherwise
*/
-static int get_table_entry_id (table_entry_t *table,
+int get_table_entry_id (table_entry_t *table,
const char *table_name, const char *name)
{
table_entry_t *t;
diff --git a/include/image.h b/include/image.h
index 95f4b14..4651b4f 100644
--- a/include/image.h
+++ b/include/image.h
@@ -284,6 +284,32 @@ typedef struct bootm_headers {
#define uimage_to_cpu(x) be32_to_cpu(x)
#define cpu_to_uimage(x) cpu_to_be32(x)
+/*
+ * Translation table for entries of a specific type
+ * This structue is used by the global functions get_table_entry_id,
+ * get_table_entry_name and these functions and this structure can also be
+ * referred by other part of code
+ */
+typedef struct table_entry {
+ int id;
+ char*sname; /* name used to find table entry */
+ char*lname; /* name used to print for messages */
+} table_entry_t;
+
+/*
+ * get_table_entry_id() will go over translation table trying to find
+ * entry that matches given short name. If matching entry is found,
+ * its id returned to the caller.
+ */
+int get_table_entry_id (table_entry_t *table,
+ const char *table_name, const char *name);
+/*
+ * get_table_entry_name() will go over translation table trying to find
+ * entry that matches given id. If matching entry is found, its long
+ * name is returned to the caller.
+ */
+char *get_table_entry_name (table_entry_t *table, char *msg, int id);
+
const char *genimg_get_os_name (uint8_t os);
const char *genimg_get_arch_name (uint8_t arch);
const char *genimg_get_type_name (uint8_t type);
--
1.5.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] Kirkwood: Sheevaplug: kwimage configuration
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- board/Marvell/sheevaplug/config.mk|3 + board/Marvell/sheevaplug/kwbimage.cfg | 162 + 2 files changed, 165 insertions(+), 0 deletions(-) create mode 100644 board/Marvell/sheevaplug/kwbimage.cfg diff --git a/board/Marvell/sheevaplug/config.mk b/board/Marvell/sheevaplug/config.mk index a4ea769..2bd9f79 100644 --- a/board/Marvell/sheevaplug/config.mk +++ b/board/Marvell/sheevaplug/config.mk @@ -23,3 +23,6 @@ # TEXT_BASE = 0x0060 + +# Kirkwood Boot Image configuration file +KWD_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/kwbimage.cfg diff --git a/board/Marvell/sheevaplug/kwbimage.cfg b/board/Marvell/sheevaplug/kwbimage.cfg new file mode 100644 index 000..6c47d62 --- /dev/null +++ b/board/Marvell/sheevaplug/kwbimage.cfg @@ -0,0 +1,162 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com +# Written-by: Prafulla Wadaskar prafu...@marvell.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301 USA +# +# Refer docs/README.kwimage for more details about how-to configure +# and create kirkwood boot image +# + +# Boot Media configurations +BOOT_FROM nand +NAND_ECC_MODE default +NAND_PAGE_SIZE 0x0800 + +# SOC registers configuration using bootrom header extension +# Maximum KWBIMAGE_MAX_CONFIG configurations allowed + +# Configure RGMII-0 interface pad voltage to 1.8V +DATA 0xFFD100e0 0x1b1b1b9b + +#Dram initalization for SINGLE x16 CL=5 @ 400MHz +DATA 0xFFD01400 0x43000c30 # DDR Configuration register +# bit13-0: 0xc30 (3120 DDR2 clks refresh rate) +# bit23-14: zero +# bit24: 1= enable exit self refresh mode on DDR access +# bit25: 1 required +# bit29-26: zero +# bit31-30: 01 + +DATA 0xFFD01404 0x37543000 # DDR Controller Control Low +# bit 4:0=addr/cmd in smame cycle +# bit 5:0=clk is driven during self refresh, we don't care for APX +# bit 6:0=use recommended falling edge of clk for addr/cmd +# bit14:0=input buffer always powered up +# bit18:1=cpu lock transaction enabled +# bit23-20: 5=recommended value for CL=5 and STARTBURST_DEL disabled bit31=0 +# bit27-24: 7= CL+2, STARTBURST sample stages, for freqs 400MHz, unbuffered DIMM +# bit30-28: 3 required +# bit31:0=no additional STARTBURST delay + +DATA 0xFFD01408 0x22125451 # DDR Timing (Low) (active cycles value +1) +# bit3-0: TRAS lsbs +# bit7-4: TRCD +# bit11- 8: TRP +# bit15-12: TWR +# bit19-16: TWTR +# bit20:TRAS msb +# bit23-21: 0x0 +# bit27-24: TRRD +# bit31-28: TRTP + +DATA 0xFFD0140C 0x0a33 # DDR Timing (High) +# bit6-0: TRFC +# bit8-7: TR2R +# bit10-9: TR2W +# bit12-11: TW2W +# bit31-13: zero required + +DATA 0xFFD01410 0x0099 # DDR Address Control +# bit1-0: 01, Cs0width=x16 +# bit3-2: 10, Cs0size=512Mb +# bit5-4: 01, Cs1width=x16 +# bit7-6: 10, Cs1size=512Mb +# bit9-8: 00, Cs2width=nonexistent +# bit11-10: 00, Cs2size =nonexistent +# bit13-12: 00, Cs3width=nonexistent +# bit15-14: 00, Cs3size =nonexistent +# bit16:0, Cs0AddrSel +# bit17:0, Cs1AddrSel +# bit18:0, Cs2AddrSel +# bit19:0, Cs3AddrSel +# bit31-20: 0 required + +DATA 0xFFD01414 0x # DDR Open Pages Control +# bit0:0, OpenPage enabled +# bit31-1: 0 required + +DATA 0xFFD01418 0x # DDR Operation +# bit3-0: 0x0, DDR cmd +# bit31-4: 0 required + +DATA 0xFFD0141C 0x0C52 # DDR Mode +# bit2-0: 2, BurstLen=2 required +# bit3: 0, BurstType=0 required +# bit6-4: 4, CL=5 +# bit7: 0, TestMode=0 normal +# bit8: 0, DLL reset=0 normal +# bit11-9: 6, auto-precharge write recovery +# bit12:0, PD must be zero +# bit31-13: 0 required + +DATA 0xFFD01420 0x0040 # DDR Extended Mode +# bit0:0, DDR DLL enabled +# bit1:0, DDR drive strenght normal +# bit2:0, DDR ODT control lsd (disabled) +# bit5-3: 000, required +# bit6:1, DDR ODT control msb, (disabled) +# bit9-7: 000, required +# bit10: 0, differential DQS enabled +# bit11: 0, required +# bit12: 0, DDR output buffer enabled +# bit31-13: 0 required + +DATA 0xFFD01424 0xF17F # DDR Controller Control High +# bit2-0: 111, required +# bit3 : 1 , MBUS Burst Chop disabled +# bit6-4: 111,
[U-Boot] [PATCH v2 4/4] tools: mkimage: Add: Kirkwood Boot Image support (kwbimage)
This patch adds type kwbimabe support for new mkimage core
For more details refer docs/README.kwbimage
This patch is tested with Sheevaplug board
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log:
v2: updated as per review comments for v1
added len checks in checksum functions
added printable strings for each valid table entry
Makefile|5 +
common/image.c |1 +
doc/README.kwbimage | 93
include/image.h |1 +
tools/Makefile |5 +-
tools/kwbimage.c| 401 +++
tools/kwbimage.h| 106 ++
tools/mkimage.c |2 +
8 files changed, 613 insertions(+), 1 deletions(-)
create mode 100644 doc/README.kwbimage
create mode 100644 tools/kwbimage.c
create mode 100644 tools/kwbimage.h
diff --git a/Makefile b/Makefile
index 54c0b67..8a19d8f 100644
--- a/Makefile
+++ b/Makefile
@@ -314,6 +314,10 @@ $(obj)u-boot.img: $(obj)u-boot.bin
sed -e 's/[ ]*$$/ for $(BOARD) board/') \
-d $ $@
+$(obj)u-boot.kwb: $(obj)u-boot.bin
+ $(obj)tools/mkimage -n $(KWD_CONFIG) -T kwbimage \
+ -a $(TEXT_BASE) -e $(TEXT_BASE) -d $ $@
+
$(obj)u-boot.sha1: $(obj)u-boot.bin
$(obj)tools/ubsha1 $(obj)u-boot.bin
@@ -3671,6 +3675,7 @@ clobber: clean
@rm -f $(OBJS) $(obj)*.bak $(obj)ctags $(obj)etags $(obj)TAGS \
$(obj)cscope.* $(obj)*.*~
@rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL)
+ @rm -f $(obj)u-boot.kwb
@rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
@rm -f $(obj)cpu/mpc824x/bedbug_603e.c
@rm -f $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm
diff --git a/common/image.c b/common/image.c
index 2e16347..0be4ea6 100644
--- a/common/image.c
+++ b/common/image.c
@@ -139,6 +139,7 @@ static table_entry_t uimage_type[] = {
{ IH_TYPE_SCRIPT, script, Script, },
{ IH_TYPE_STANDALONE, standalone, Standalone Program, },
{ IH_TYPE_FLATDT, flat_dt,Flat Device Tree, },
+ { IH_TYPE_KWBIMAGE, kwbimage, Kirkwood Boot Image,},
{ -1, , , },
};
diff --git a/doc/README.kwbimage b/doc/README.kwbimage
new file mode 100644
index 000..2a5b3b3
--- /dev/null
+++ b/doc/README.kwbimage
@@ -0,0 +1,93 @@
+-
+Kirkwood Boot Image generation using mkimage
+-
+
+This document describes the U-Boot feature as it
+is implemented for the Kirkwood family of SoCs.
+
+The Kirkwood SoC's can boot directly from NAND FLASH,
+SPI FLASH, SATA etc. using its internal bootRom support.
+
+for more details refer section 24.2 of Kirkwood functional specifications.
+ref: www.marvell.com/products/embedded.../kirkwood/index.jsp
+
+Command syntax:
+--
+./tools/mkimage -l kwboot_file
+ to list the kwb image file details
+
+./tools/mkimage -n board specific configuration file \
+-T kwbimage -a start address -e execution address \
+ -d input_raw_binary output_kwboot_file
+
+for ex.
+./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \
+-T kwbimage -a 0x0060 -e 0x0060 \
+ -d u-boot.bin u-boot.kwb
+
+kwimage support available with mkimage utility will generate kirkwood boot
+image that can be flashed on the board NAND/SPI flash
+
+Board specific configuration file specifications:
+
+1. This file must present in the $(BOARDDIR) and the name should be
+ kwbimage.cfg (since this is used in Makefile)
+2. This file can have empty lines and lines starting with # as first
+ character to put comments
+3. This file can have configuration command lines as mentioned below,
+ any other information in this file is treated as invalid.
+
+Configuration command line syntax:
+-
+1. Each command line is must have two strings, first one command or address
+ and second one data string
+2. Following are the valid command strings and associated data strings:-
+ Command string data string
+ -- ---
+ BOOT_FROM nand/spi/sata
+ NAND_ECC_MODE default/rs/hamming/disabled
+ NAND_PAGE_SIZE any uint16_t hex value
+ SATA_PIO_MODE any uint32_t hex value
+ DDR_INIT_DELAY any uint32_t hex value
+ DATAregaddr and regdara hex value
+ you can have maximum 55 such register programming commands
+
+3. All commands are optional to program
+
+Typical example of kwimage.cfg file:
+---
+
+# Boot Media configurations
+BOOT_FROM nand
+NAND_ECC_MODE default
+NAND_PAGE_SIZE
[U-Boot] u-boot - Flash copie in RAM
Hello, to which RAM address does the u-boot copy the flash data? (I think uboot copies the flash data to the RAM memory. Where can I define to which address of RAM memory the flash data is written?) Thank you Johann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BMP display.
Dear Tuma, again: please keep the mailing list on Cc: !!! In message 200908171631.17975.chernigovs...@spb.gs.ru you wrote: Okay. Is new version configurable for OMAP3evm out of the box? Yes. And is the v2009.08-rc2 stable enought? Yes. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The price of curiosity is a terminal experience. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot - Flash copie in RAM
Dear Johann Steinbrecher, In message 9db06a550908170538l25649f45u74c92aa0d8fd6...@mail.gmail.com you wrote: to which RAM address does the u-boot copy the flash data? (I think uboot copies the flash data to the RAM memory. Where can I define to which address of RAM memory the flash data is written?) thsi depends on the architecture. For some architectures like ARM this is currently defined by the TEXT_BASE setting in your board's config.mk file (which we consider a bug that is to be fixed), while for other architectures like PowerPC it gets auto-computed to be at the end of available RAM, no matter how big that actually is (this is considered correct behaviour). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Our business is run on trust. We trust you will pay in advance. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Wolfgang Denk wrote: For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier: I am testing this on the toolchain I usually use. The Code Sourcery arm-2008q3 http://www.codesourcery.com/sgpp/lite/arm I see they have a 2009 version. I will download that and test that as well. Be aware that MAKEALL arm takes a couple of hours. Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Tom, In message 4a895462.1020...@windriver.com you wrote: I am testing this on the toolchain I usually use. The Code Sourcery arm-2008q3 http://www.codesourcery.com/sgpp/lite/arm I see they have a 2009 version. I will download that and test that as well. Thanks. Be aware that MAKEALL arm takes a couple of hours. Seems you need a faster machine... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The human race is a race of cowards; and I am not only marching in that procession but carrying a banner. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for DevKit8000
Thank you for reviewing my patch. I've fixed the issues and will submit it again once Jean-Christophe updated the mach-types.h. On Mon, Aug 17, 2009 at 11:50 AM, Wolfgang Denkw...@denx.de wrote: +#define CONFIG_SYS_MAX_FLASH_SECT 520 /* max number of sectors on */ + /* one chip */ +#define CONFIG_SYS_MAX_FLASH_BANKS 2 /* max number of flash banks */ +#define CONFIG_SYS_MONITOR_LEN SZ_256K /* Reserve 2 sectors */ + +#define CONFIG_SYS_FLASH_BASE boot_flash_base + +/* Monitor at start of flash */ +#define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE You seem to have NOR flash, but define NO_FLSH eralier. Is this intentional? What is the rationale behind that? I don't have NOR flash, just NAND. So NO_FLASH is fine. I'm was confused about the FLASH stuff too. Other OMAP3 Boards have them too and AFAIK none of them has NOR flash. e.g. CONFIG_SYS_ENV_SECT_SIZE is defined in several configs but never used. I removed them and everything works fine. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3]: arm: Kirkwood: See to it that sent data is 8-byte aligned
On Wed, 05 Aug 2009 23:08:16 +0200 Wolfgang Denk w...@denx.de wrote: In message 20090702150401.06ded...@marrow.netinsight.se Simon Kagstrom wrote: See to it that sent data is 8-byte aligned U-boot might use non-8-byte-aligned addresses for sending data, which the kwgbe_send doesn't accept (bootp does this for me). This patch copies the data to be sent to a temporary buffer if it is non-aligned. Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net --- drivers/net/kirkwood_egiga.c | 26 -- 1 files changed, 20 insertions(+), 6 deletions(-) Ping? Ack! I've been on vacation but I'm back now. I'll start reworking the non-accepted patches from this series according to the comments I got. The series consisted of (not accepted) [PATCH 1/4]: arm: Kirkwood: Set MAC address during registration for kirkwood egiga (accepted, applied) [PATCH 2/4]: arm: Kirkwood: Fix compiler optimization bug for kwgbe_send (accepted, applied) [PATCH 3/4]: arm: Kirkwood: Check the error summary bit for error detection (not accepted) [PATCH 4/4]: arm: Kirkwood: See to it that sent data is 8-byte aligned // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BMP display.
On Monday 17 August 2009 16:38:31 you wrote: Dear Tuma, again: please keep the mailing list on Cc: !!! In message 200908171631.17975.chernigovs...@spb.gs.ru you wrote: Okay. Is new version configurable for OMAP3evm out of the box? Yes. And is the v2009.08-rc2 stable enought? Yes. Thank you. I've downloaded new U-Boot 2009.08.rc2. I have some error while making it. I do: make distclean (Okay) make omap3_evm_config (Okay) make And get: make[1]: arm-linux-gcc: Command not found My old U-Boot used arm-none-linux-gnueabi-gcc which make system could easyly find on my system. Should I install some new software to build new U-Boot? Or configure existing Makefile? Best regards, Wolfgang Denk -- Software Developer General Satellite Corp. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BMP display.
On Monday 17 August 2009 17:55:31 Tuma wrote: On Monday 17 August 2009 16:38:31 you wrote: Dear Tuma, again: please keep the mailing list on Cc: !!! In message 200908171631.17975.chernigovs...@spb.gs.ru you wrote: Okay. Is new version configurable for OMAP3evm out of the box? Yes. And is the v2009.08-rc2 stable enought? Yes. Thank you. I've downloaded new U-Boot 2009.08.rc2. I have some error while making it. I do: make distclean (Okay) Sorry, make clean, and make distclean give the same error as make. make omap3_evm_config (Okay) make And get: make[1]: arm-linux-gcc: Command not found My old U-Boot used arm-none-linux-gnueabi-gcc which make system could easyly find on my system. Should I install some new software to build new U-Boot? Or configure existing Makefile? Best regards, Wolfgang Denk -- Software Developer General Satellite Corp. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8]: Define test_and_set/clear_bit for ARM
On Sun, 19 Jul 2009 11:47:13 +0200 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 15:58 Tue 07 Jul , Simon Kagstrom wrote: Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net --- include/asm-arm/bitops.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) NACK the test_and_set_bit and co must be endianless specific which is not the case here OK. Anyway, the bitops implementation is a bit messy (which I noted when trying to get ubifs working on arm - hence these patches). Maybe an idea could be to bring in the Linux asm-generic/bitops/* instead and remove the architecture-specific versions? // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Network based logging with U-Boot
Hello all, Is U-Boot able to log its actives etc to a machine accessible via the network? Desirable - U-Boot being able to log all its boot up info and details regarding booting it's OS image etc (ie everything sent to stdout) to a file on a remote machine. Scenario - multiple deployments all housed in sealed units on a LAN. Network based monitoring is the only option. It would be extremely useful if each platform could provide its status over the network so that any problems regarding boot up could be easily seen. I'm sure I read somewhere that UDP logging is available in U-Boot but information on this doesn't seem to be hugely available. I've got netconsole running via netcat on a host pc but this is console only and is not ideal for a multi-platform deployment model. Although, saying that, I suppose that doing 'set ncip server ip' and 'set stdout nc' and running netcat on a host pc would provide some level of diagnostics. Is anybody able to offer any advice or strategy here for similar requirements? Much appreciated. -- Matt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Fix chip_config command for AMCC Arches
This patch fixes the chip_config command for I2C bootstrap EEPROM
configuration. First it changes the I2C bootstrap EEPROM address to
0x54 as this is used on Arches (instead of 0x52 on Canyonlands/
Glacier). Additionally, the NAND bootstrap settings are removed
for Arches since Arches doesn't support NAND-booting.
Signed-off-by: Stefan Roese s...@denx.de
---
board/amcc/canyonlands/chip_config.c | 34 ++
include/configs/canyonlands.h|4
2 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/board/amcc/canyonlands/chip_config.c
b/board/amcc/canyonlands/chip_config.c
index e46f4d8..5ad78b8 100644
--- a/board/amcc/canyonlands/chip_config.c
+++ b/board/amcc/canyonlands/chip_config.c
@@ -34,45 +34,46 @@ struct ppc4xx_config ppc4xx_config_val[] = {
}
},
{
- 600-nand, NAND CPU: 600 PLB: 200 OPB: 100 EBC: 100,
+ 800-nor, NOR CPU: 800 PLB: 200 OPB: 100 EBC: 100,
{
- 0x86, 0x80, 0xce, 0x1f, 0x79, 0x90, 0x01, 0xa0,
- 0xa0, 0xe8, 0x23, 0x58, 0x0d, 0x05, 0x00, 0x00
+ 0x86, 0x80, 0xba, 0x14, 0x99, 0x80, 0x00, 0xa0,
+ 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
}
},
{
- 800-nor, NOR CPU: 800 PLB: 200 OPB: 100 EBC: 100,
+ 1000-nor, NOR CPU:1000 PLB: 200 OPB: 100 EBC: 100,
{
- 0x86, 0x80, 0xba, 0x14, 0x99, 0x80, 0x00, 0xa0,
+ 0x86, 0x82, 0x96, 0x19, 0xb9, 0x80, 0x00, 0xa0,
0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
}
},
{
- 800-nand, NAND CPU: 800 PLB: 200 OPB: 100 EBC: 100,
+ 1066-nor, NOR CPU:1066 PLB: 266 OPB: 88 EBC: 88,
{
- 0x86, 0x80, 0xba, 0x14, 0x99, 0x90, 0x01, 0xa0,
- 0xa0, 0xe8, 0x23, 0x58, 0x0d, 0x05, 0x00, 0x00
+ 0x86, 0x80, 0xb3, 0x01, 0x9d, 0x80, 0x00, 0xa0,
+ 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
}
},
+#if !defined(CONFIG_ARCHES)
{
- 1000-nor, NOR CPU:1000 PLB: 200 OPB: 100 EBC: 100,
+ 600-nand, NAND CPU: 600 PLB: 200 OPB: 100 EBC: 100,
{
- 0x86, 0x82, 0x96, 0x19, 0xb9, 0x80, 0x00, 0xa0,
- 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ 0x86, 0x80, 0xce, 0x1f, 0x79, 0x90, 0x01, 0xa0,
+ 0xa0, 0xe8, 0x23, 0x58, 0x0d, 0x05, 0x00, 0x00
}
},
{
- 1000-nand, NAND CPU:1000 PLB: 200 OPB: 100 EBC: 100,
+ 800-nand, NAND CPU: 800 PLB: 200 OPB: 100 EBC: 100,
{
- 0x86, 0x82, 0x96, 0x19, 0xb9, 0x90, 0x01, 0xa0,
+ 0x86, 0x80, 0xba, 0x14, 0x99, 0x90, 0x01, 0xa0,
0xa0, 0xe8, 0x23, 0x58, 0x0d, 0x05, 0x00, 0x00
}
},
{
- 1066-nor, NOR CPU:1066 PLB: 266 OPB: 88 EBC: 88,
+ 1000-nand, NAND CPU:1000 PLB: 200 OPB: 100 EBC: 100,
{
- 0x86, 0x80, 0xb3, 0x01, 0x9d, 0x80, 0x00, 0xa0,
- 0x40, 0x08, 0x23, 0x50, 0x0d, 0x05, 0x00, 0x00
+ 0x86, 0x82, 0x96, 0x19, 0xb9, 0x90, 0x01, 0xa0,
+ 0xa0, 0xe8, 0x23, 0x58, 0x0d, 0x05, 0x00, 0x00
}
},
{
@@ -82,6 +83,7 @@ struct ppc4xx_config ppc4xx_config_val[] = {
0xa0, 0xe8, 0x23, 0x58, 0x0d, 0x05, 0x00, 0x00
}
},
+#endif
};
int ppc4xx_config_count = ARRAY_SIZE(ppc4xx_config_val);
diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
index 217a8ee..3dddccf 100644
--- a/include/configs/canyonlands.h
+++ b/include/configs/canyonlands.h
@@ -331,7 +331,11 @@
#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 10
/* I2C bootstrap EEPROM */
+#if defined(CONFIG_ARCHES)
+#define CONFIG_4xx_CONFIG_I2C_EEPROM_ADDR 0x54
+#else
#define CONFIG_4xx_CONFIG_I2C_EEPROM_ADDR 0x52
+#endif
#define CONFIG_4xx_CONFIG_I2C_EEPROM_OFFSET0
#define CONFIG_4xx_CONFIG_BLOCKSIZE16
--
1.6.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for DevKit8000
Frederik Kriewitz wrote: Thank you for reviewing my patch. I've fixed the issues and will submit it again once Jean-Christophe updated the mach-types.h. Please send an official request for this. See http://lists.denx.de/pipermail/u-boot/2008-September/040553.html Best regards Dirk On Mon, Aug 17, 2009 at 11:50 AM, Wolfgang Denkw...@denx.de wrote: +#define CONFIG_SYS_MAX_FLASH_SECT520 /* max number of sectors on */ + /* one chip */ +#define CONFIG_SYS_MAX_FLASH_BANKS 2 /* max number of flash banks */ +#define CONFIG_SYS_MONITOR_LEN SZ_256K /* Reserve 2 sectors */ + +#define CONFIG_SYS_FLASH_BASEboot_flash_base + +/* Monitor at start of flash */ +#define CONFIG_SYS_MONITOR_BASE CONFIG_SYS_FLASH_BASE You seem to have NOR flash, but define NO_FLSH eralier. Is this intentional? What is the rationale behind that? I don't have NOR flash, just NAND. So NO_FLASH is fine. I'm was confused about the FLASH stuff too. Other OMAP3 Boards have them too and AFAIK none of them has NOR flash. e.g. CONFIG_SYS_ENV_SECT_SIZE is defined in several configs but never used. I removed them and everything works fine. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for DevKit8000
Frederik Kriewitz wrote:
This patch adds support for the DevKit8000 board.
Wolfgang commented already most of the topics.
So, only one comment left for me:
...
+++ b/board/omap3/devkit8000/devkit8000.c
...
+/*
+ * Routine: misc_init_r
+ * Description: Configure board specific parts
+ */
+int misc_init_r(void)
+{
...
+ /* Use OMAP DIE_ID as MAC address */
+ if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
+ enetaddr[0] = 0x02; /* locally administered */
+ enetaddr[1] = readl(id_base-die_id_1) 0xff;
+ *(u32*)enetaddr[2] = readl(id_base-die_id_0);
+ eth_setenv_enetaddr(ethaddr, enetaddr);
+ }
With the OMAP DIE_ID thread we know what you are doing here. But do we
want to have this really in mainline? It looks to me like a workaround
for broken hardware (that is, having no proper MAC address
configured)? Or do I miss anything?
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Tom wrote: I am testing this on the toolchain I usually use. The Code Sourcery arm-2008q3 http://www.codesourcery.com/sgpp/lite/arm I see they have a 2009 version. I will download that and test that as well. Yes, using recent 2009q1-203 is the recommended one. 2008q3 is known to have some (minor?) issues: http://elinux.org/ARMCompilers#Limitations Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MIMC200: set default fbmem value
This patch adds a default bootargs fbmem value to the CONFIG_BOOTARGS string for the MIMC200 board. Signed-off-by: Mark Jackson m...@mimc.co.uk --- include/configs/mimc200.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/mimc200.h b/include/configs/mimc200.h index 8f71664..36488b3 100644 --- a/include/configs/mimc200.h +++ b/include/configs/mimc200.h @@ -74,7 +74,7 @@ #define CONFIG_BAUDRATE115200 #define CONFIG_BOOTARGS \ - root=/dev/mtdblock1 rootfstype=jffs2 console=ttyS1 + root=/dev/mtdblock1 rootfstype=jffs2 fbmem=512k console=ttyS1 #define CONFIG_BOOTCOMMAND \ fsload boot/uImage; bootm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BMP display.
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Tuma Sent: Monday, August 17, 2009 7:26 PM To: Wolfgang Denk; U-Boot Mailing List Subject: Re: [U-Boot] BMP display. On Monday 17 August 2009 16:38:31 you wrote: Dear Tuma, again: please keep the mailing list on Cc: !!! In message 200908171631.17975.chernigovs...@spb.gs.ru you wrote: Okay. Is new version configurable for OMAP3evm out of the box? Yes. And is the v2009.08-rc2 stable enought? Yes. Thank you. I've downloaded new U-Boot 2009.08.rc2. I have some error while making it. I do: make distclean (Okay) make omap3_evm_config (Okay) make And get: make[1]: arm-linux-gcc: Command not found My old U-Boot used arm-none-linux-gnueabi-gcc which make system could easyly find on my system. Should I install some new software to build new U-Boot? Or configure existing Makefile? Can you try: make CROSS_COMPILE=arm-none-linux-gnueabi- Best regards, Wolfgang Denk -- Software Developer General Satellite Corp. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for DevKit8000
On Mon, Aug 17, 2009 at 5:21 PM, Dirk Behmedirk.be...@googlemail.com wrote: With the OMAP DIE_ID thread we know what you are doing here. But do we want to have this really in mainline? It looks to me like a workaround for broken hardware (that is, having no proper MAC address configured)? Or do I miss anything? I'll ask Embest (manufacturer of the board) to get some real MAC addresses. Some boards/devices already use random MAC addresses: drivers/net/kirkwood_egiga.c board/bf518f-ezbrd/bf518f-ezbrd.c board/bf526-ezbrd/bf526-ezbrd.c board/bf527-ezkit/bf527-ezkit.c board/bf537-minotaur/bf537-minotaur.c board/bf537-pnav/bf537-pnav.c board/bf537-srv1/bf537-srv1.c board/bf537-stamp/bf537-stamp.c board/cm-bf527/cm-bf527.c board/cm-bf537e/cm-bf537e.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Thu 13 Aug 2009 18:01, Wolfgang Denk pondered:
Dear Robin Getz,
In message 200908131747.20194.rg...@blackfin.uclinux.org you wrote:
The better thing to do (IMHO) - would be to print out the proper number of
hashes, depending on the size of the file (and implement RFC 2349 at the
same
time) - not the number of packets (which is what happens today)...
Agreed. Patches welcome!
Something like this?
- If turned on (CONFIG_TFTP_TSIZE), asks for the size of the file.
- if receives the file size, prints out the percentage of the file
downloaded.
- when done, prints 100%
- if it doesn't receive the file size (the server doesn't support RFC
2349, prints standard hash marks.
Comments welcome...
diff --git a/net/tftp.c b/net/tftp.c
index 9544691..56db247 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -66,6 +66,9 @@ static ulong TftpLastBlock; /* last packet sequence
number received */
static ulong TftpBlockWrap; /* count of sequence number wraparounds
*/
static ulong TftpBlockWrapOffset;/* memory offset due to wrapping
*/
static int TftpState;
+#ifdef CONFIG_TFTP_TSIZE
+static int TftpTsize; /* Tsize */
+#endif
#define STATE_RRQ 1
#define STATE_DATA 2
@@ -212,6 +215,10 @@ TftpSend (void)
sprintf((char *)pkt, %lu, TIMEOUT / 1000);
debug(send option \timeout %s\\n, (char *)pkt);
pkt += strlen((char *)pkt) + 1;
+#ifdef CONFIG_TFTP_TSIZE
+ pkt += sprintf((char *)pkt,tsize%c%d, 0,0);
+ pkt += strlen((char *)pkt) + 1;
+#endif
/* try for more effic. blk size */
pkt += sprintf((char *)pkt,blksize%c%d%c,
0,TftpBlkSizeOption,0);
@@ -321,8 +328,14 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
simple_strtoul((char*)pkt+i+8,NULL,10);
debug(Blocksize ack: %s, %d\n,
(char*)pkt+i+8,TftpBlkSize);
- break;
}
+#ifdef CONFIG_TFTP_TSIZE
+ if (strcmp ((char*)pkt+i,tsize) == 0) {
+ TftpTsize =
simple_strtoul((char*)pkt+i+6,NULL,10);
+ debug(size = %s, %d\n,
+(char*)pkt+i+6, TftpTsize);
+ }
+#endif
}
#ifdef CONFIG_MCAST_TFTP
parse_multicast_oack((char *)pkt,len-1);
@@ -348,7 +361,14 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
TftpBlockWrap++;
TftpBlockWrapOffset += TftpBlkSize * TFTP_SEQUENCE_SIZE;
printf (\n\t %lu MB received\n\t ,
TftpBlockWrapOffset20);
- } else {
+ }
+#ifdef CONFIG_TFTP_TSIZE
+ else if (TftpTsize) {
+
+ printf(%2d\b\b, NetBootFileXferSize * 100 /
TftpTsize);
+ }
+#endif
+ else {
if (((TftpBlock - 1) % 10) == 0) {
puts_quiet(#);
} else if ((TftpBlock % (10 * HASHES_PER_LINE)) == 0) {
@@ -442,6 +462,11 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
* We received the whole thing. Try to
* run it.
*/
+#ifdef CONFIG_TFTP_TSIZE
+ if (TftpTsize)
+ puts(100%);
+#endif
+
puts_quiet(\ndone\n);
#ifdef CONFIG_TFTP_TIME
end_time = get_timer(0);
@@ -550,6 +579,9 @@ TftpStart (void)
#ifdef CONFIG_TFTP_TIME
start_time = get_timer(0);
#endif
+#ifdef CONFIG_TFTP_TSIZE
+ TftpTsize = 0;
+#endif
TftpTimeoutMSecs = TftpRRQTimeoutMSecs;
TftpTimeoutCountMax = TftpRRQTimeoutCountMax;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Sat 8 Aug 2009 05:50, Ben Warren pondered: Allesandro, Alessandro Rubini wrote: I finally fixed the defrag code, testing with NFS as well. Didn't take performance figures, tough, for lack of time. I wanted to do config + environment for the NFS case, like tftp, but didnt' do the second step out of laziness (also, the source file has long lines while I have 80 columns). For the record, I added the check on ip_src and ip_dst, but everything stopped working. So I reverted that instead of entering a long debugging session. The CONFIG_NET_MAXDEFRAG argument is the actual payload, so I add NFS overhead to that figure, which is expected to a beautiful 4096 or 8192. I feel this is better than other options, as the person writing the config is not expected to know how much protocol overhead is there. Alessandro Rubini (4): net: defragment IP packets tftp: get the tftp block size from config file and from the environment I noticed that while playing with this, that if you set the tftpblocksize environment, do a transfer, and then clear it, it does not go back to the default setting. I was not sure if this was the intended or not, but this fixes it (and provides a small code size reduction when this option is not activated). Also wondering -- if the user sets the tftpblocksize to a number larger than IP_MAXUDP, the transfer will never finish. Should this be restricted here? diff --git a/net/tftp.c b/net/tftp.c index 9544691..56db247 100644 --- a/net/tftp.c +++ b/net/tftp.c +#ifdef CONFIG_TFTP_BLOCKSIZE /* Allow the user to choose tftpblocksize */ if ((ep = getenv(tftpblocksize)) != NULL) TftpBlkSizeOption = simple_strtol(ep, NULL, 10); + else + TftpBlkSizeOption = TFTP_MTU_BLOCKSIZE; debug(tftp block size is %i\n, TftpBlkSizeOption); +#endif ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for DevKit8000
Frederik Kriewitz wrote: On Mon, Aug 17, 2009 at 5:21 PM, Dirk Behmedirk.be...@googlemail.com wrote: With the OMAP DIE_ID thread we know what you are doing here. But do we want to have this really in mainline? It looks to me like a workaround for broken hardware (that is, having no proper MAC address configured)? Or do I miss anything? I'll ask Embest (manufacturer of the board) to get some real MAC addresses. Some boards/devices already use random MAC addresses: drivers/net/kirkwood_egiga.c board/bf518f-ezbrd/bf518f-ezbrd.c board/bf526-ezbrd/bf526-ezbrd.c board/bf527-ezkit/bf527-ezkit.c board/bf537-minotaur/bf537-minotaur.c board/bf537-pnav/bf537-pnav.c board/bf537-srv1/bf537-srv1.c board/bf537-stamp/bf537-stamp.c board/cm-bf527/cm-bf527.c board/cm-bf537e/cm-bf537e.c Thanks. If everybody is fine with this, I will not object, too ;) Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OT-ish: NOR flash write speed degradation?
Hi all, As I feel this list is a good resource for embedded design minds, please forgive this elementary question. As NOR flash ages, does write speed degrade? Or do writes take place at roughly the same rate over time until the part reaches the write limit (100k-1000k writes)? Any pointers in the right direction would be great. Thanks for your time. -- -jp Even though he was an enemy of mine, I had to admit that what he had accomplished was a brilliant piece of strategy. First, he punched me, then he kicked me, then he punched me again. deepthoughtsbyjackhandey.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] davinci_emac.c:*: warning: duplicate `volatile'
On Sun, 16 Aug 2009, Wolfgang Denk wrote: Dear Sergey, in include/asm-arm/arch-davinci/emac_defs.h you declare emac_desc with the volatile attribute, but when using it, volatile is frequently added again, resulting in complier warnings like these: Configuring for davinci_sffsdr board... davinci_emac.c:82: warning: duplicate `volatile' davinci_emac.c:83: warning: duplicate `volatile' davinci_emac.c:84: warning: duplicate `volatile' davinci_emac.c:85: warning: duplicate `volatile' davinci_emac.c: In function `davinci_eth_open': davinci_emac.c:257: warning: duplicate `volatile' davinci_emac.c: In function `davinci_eth_rcv_packet': davinci_emac.c:475: warning: duplicate `volatile' davinci_emac.c:476: warning: duplicate `volatile' davinci_emac.c:477: warning: duplicate `volatile' davinci_emac.c:496: warning: duplicate `volatile' Can you please provide a fix? Thanks in advance. Hey, what compiler do you use? I just compiled all the davinci boards with GNUEABI GCC 4.4.1 (binutils ver.2.19.1) and I didn't get a single compiler warning. There are 2 separate issues but they are not related to the above description. First is that it fails to compile with GNUEABI GCC but that is addressed in your recent arm build patch that works OK. The second one is that GCC 4.4.1 (don't know about the older ones, don't have those on my machine now) generates an error for inline weak functions in lib_arm/board.c (and I think it is totally correct -- what is an inline weak function?) Here is the failed build log excertpt: === Cut === board.c:127: error: inline function 'coloured_LED_init' cannot be declared weak board.c:129: error: inline function 'red_LED_on' cannot be declared weak board.c:131: error: inline function 'red_LED_off' cannot be declared weak board.c:133: error: inline function 'green_LED_on' cannot be declared weak board.c:135: error: inline function 'green_LED_off' cannot be declared weak board.c:137: error: inline function 'yellow_LED_on' cannot be declared weak board.c:139: error: inline function 'yellow_LED_off' cannot be declared weak board.c:141: error: inline function 'blue_LED_on' cannot be declared weak board.c:143: error: inline function 'blue_LED_off' cannot be declared weak make[1]: *** [board.o] Error 1 make[1]: Leaving directory /usr/src/U-Boot/Davinci/u-boot/lib_arm' make: *** [lib_arm/libarm.a] Error 2 === Cut === Do you want me to send a fix for those? It hardly makes sense, you can do it yourself by removing inline qualifier at those 9 lines but I can send a patch if you want me to. As for those duplicate `volatile' warnings I don't see them (and have never seen them before) so I don't know what to fix. I can send you my build logs off the list if you want. --- ** * k...@homeKOI8 Net The impossible we do immediately. * * Las Vegas NV, USA Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for DevKit8000
Dirk Behme wrote: Frederik Kriewitz wrote: Thank you for reviewing my patch. I've fixed the issues and will submit it again once Jean-Christophe updated the mach-types.h. Please send an official request for this. See http://lists.denx.de/pipermail/u-boot/2008-September/040553.html While we are talking about DevKit8000 mach-type.h, fyi: http://marc.info/?l=linux-omapm=125053205123728w=2 Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OT-ish: NOR flash write speed degradation?
On Mon, Aug 17, 2009 at 12:58 PM, Jake Peavydjstu...@gmail.com wrote: Hi all, As I feel this list is a good resource for embedded design minds, please forgive this elementary question. As NOR flash ages, does write speed degrade? Or do writes take place at roughly the same rate over time until the part reaches the write limit (100k-1000k writes)? Any pointers in the right direction would be great. Thanks for your time. I believe it's the erase time that grows - it takes longer to tunnel the charge off of the floating gate as it ages (which is a separate mechanism from the write). With some of the original flash parts (Intel 28F008 friends, IIRC), you had to time the erase operations yourself, and you could get some extended lifetime from the parts by just allowing more time for the erase to complete. These days that's all handled by embedded state machines in the parts. Also the old parts didn't have an internal charge pump, you had to feed them +12V for programming and erase ops. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Network based logging with U-Boot
Dear Matthew Lear, In message 4a896ed5.3010...@bubblegen.co.uk you wrote: Is U-Boot able to log its actives etc to a machine accessible via the network? U-Boot has support for netconsole, if that is what you are looking for. Desirable - U-Boot being able to log all its boot up info and details regarding booting it's OS image etc (ie everything sent to stdout) to a file on a remote machine. Note that netconsole does not output _all_ of U-Boot boot messages; it takes a lot of initialization until the network interface becomes operational, but this is usually only an issue during the port of U-Boot to new hardware. For normal deployment of a known-to-be-working image it's OK. Scenario - multiple deployments all housed in sealed units on a LAN. Network based monitoring is the only option. No problem. Use netconsole. I'm sure I read somewhere that UDP logging is available in U-Boot but information on this doesn't seem to be hugely available. Well, it's documented. Just read doc/README.NetConsole I've got netconsole running via netcat on a host pc but this is console only and is not ideal for a multi-platform deployment model. Although, not ideal? What exactly are you missing? saying that, I suppose that doing 'set ncip server ip' and 'set stdout nc' and running netcat on a host pc would provide some level of diagnostics. Is anybody able to offer any advice or strategy here for similar requirements? Try to explain what your exact problems with netconsole are. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de That was the thing about deserts. They had their own gravity. They sucked you into the centre. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
Dear Robin Getz,
In message 200908171315.40365.rg...@blackfin.uclinux.org you wrote:
Comments welcome...
I guess the code is largely untested?
diff --git a/net/tftp.c b/net/tftp.c
index 9544691..56db247 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -66,6 +66,9 @@ static ulongTftpLastBlock; /* last packet
sequence number received */
static ulong TftpBlockWrap; /* count of sequence number wraparounds
*/
static ulong TftpBlockWrapOffset;/* memory offset due to wrapping
*/
static int TftpState;
+#ifdef CONFIG_TFTP_TSIZE
+static int TftpTsize; /* Tsize */
+#endif
Why static int? This gives a random init value for the second and each
following TFTP transfers.
@@ -212,6 +215,10 @@ TftpSend (void)
sprintf((char *)pkt, %lu, TIMEOUT / 1000);
debug(send option \timeout %s\\n, (char *)pkt);
pkt += strlen((char *)pkt) + 1;
+#ifdef CONFIG_TFTP_TSIZE
+ pkt += sprintf((char *)pkt,tsize%c%d, 0,0);
+ pkt += strlen((char *)pkt) + 1;
Looks to me as if you were adding the length twice?
+#endif
/* try for more effic. blk size */
pkt += sprintf((char *)pkt,blksize%c%d%c,
0,TftpBlkSizeOption,0);
@@ -321,8 +328,14 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
simple_strtoul((char*)pkt+i+8,NULL,10);
debug(Blocksize ack: %s, %d\n,
(char*)pkt+i+8,TftpBlkSize);
- break;
}
+#ifdef CONFIG_TFTP_TSIZE
+ if (strcmp ((char*)pkt+i,tsize) == 0) {
+ TftpTsize =
simple_strtoul((char*)pkt+i+6,NULL,10);
+ debug(size = %s, %d\n,
+ (char*)pkt+i+6, TftpTsize);
+ }
It seems you rely on TftpTsize to be zero otherwise. The current code
(with a static int) does not guarantee that, though.
- } else {
+ }
+#ifdef CONFIG_TFTP_TSIZE
+ else if (TftpTsize) {
+
+ printf(%2d\b\b, NetBootFileXferSize * 100 /
TftpTsize);
+ }
+#endif
Hm... maybe we should rather print hashes (say one '#' for each 2%,
resulting in a maximum of 50 characters output.
Otherwise we actually increase the amount of characters sent over the
serial line (and the intention was to reduce it, right?)
+#ifdef CONFIG_TFTP_TSIZE
+ if (TftpTsize)
+ puts(100%);
+#endif
+
puts_quiet(\ndone\n);
Here we see the bad consequences of this puts_quiet() stuff (which I
really dislike. The longer I see it, the more I tend to reject it.
Here, the (necessary!) newline terminating the 100% output, is not
always sent, only when puts_quiet() is active.
@@ -550,6 +579,9 @@ TftpStart (void)
#ifdef CONFIG_TFTP_TIME
start_time = get_timer(0);
#endif
+#ifdef CONFIG_TFTP_TSIZE
+ TftpTsize = 0;
+#endif
Ah. I see :-)
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Question: How does one get fresh air into a Russian church?
Answer: One clicks on an icon, and a window opens!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
Dear Robin Getz, In message 200908171321.44317.rg...@blackfin.uclinux.org you wrote: Also wondering -- if the user sets the tftpblocksize to a number larger than IP_MAXUDP, the transfer will never finish. Should this be restricted here? Sounds like a good idea to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Plan to throw one away. You will anyway. - Fred Brooks, The Mythical Man Month ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OT-ish: NOR flash write speed degradation?
Dear Jake Peavy, In message c5221b990908171058s5e3b5f76j1aa6c6e0abc26...@mail.gmail.com you wrote: As I feel this list is a good resource for embedded design minds, please forgive this elementary question. You are welcome. As NOR flash ages, does write speed degrade? Or do writes take place at Yes, it does. Both erase and write times grow, sometimes significantly compared to virgin values when the flash was new. roughly the same rate over time until the part reaches the write limit (100k-1000k writes)? Any pointers in the right direction would be great. We've seen doubling of erase and write times much earlier, say after some 10...100 erase/write cycles. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de This isn't brain surgery; it's just television. - David Letterman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] davinci_emac.c:*: warning: duplicate `volatile'
Dear k...@koi8.net, In message pine.lnx.4.64ksi.0908171053160.9...@home-gw.koi8.net you wrote: what compiler do you use? I just compiled all the davinci boards with GNUEABI GCC 4.4.1 (binutils ver.2.19.1) and I didn't get a single compiler warning. I was playing with old tool chains actually. That was with gcc 3.3.x. There are 2 separate issues but they are not related to the above description. First is that it fails to compile with GNUEABI GCC but that is addressed in your recent arm build patch that works OK. Thanks for the confirmation! Much appreciated. Could you please send an Ack-by or Tested-by for that patch? Thanks in advance. The second one is that GCC 4.4.1 (don't know about the older ones, don't have those on my machine now) generates an error for inline weak functions in lib_arm/board.c (and I think it is totally correct -- what is an inline weak function?) Here is the failed build log excertpt: A patch for this has been posted some time ago. See http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/65397/focus=65559 we're just waiting for the ARM custodian to take appropriate action. As for those duplicate `volatile' warnings I don't see them (and have never seen them before) so I don't know what to fix. I can send you my build logs off the list if you want. Well, here is an example - building davinci_schmoogie using ELDK 3.1.1 (gcc version 3.3.3): davinci_emac.c:82: warning: duplicate `volatile' davinci_emac.c:83: warning: duplicate `volatile' davinci_emac.c:84: warning: duplicate `volatile' davinci_emac.c:85: warning: duplicate `volatile' davinci_emac.c: In function `davinci_eth_open': davinci_emac.c:257: warning: duplicate `volatile' davinci_emac.c: In function `davinci_eth_rcv_packet': davinci_emac.c:475: warning: duplicate `volatile' davinci_emac.c:476: warning: duplicate `volatile' davinci_emac.c:477: warning: duplicate `volatile' davinci_emac.c:496: warning: duplicate `volatile' Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Our business is run on trust. We trust you will pay in advance. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix all linker scripts for older binutils versions (pre-2.16)
On Monday 17 August 2009 08:00:53 Wolfgang Denk wrote: Mike, I am aware that Blackfin is already using the C preprocessor to generate it's linker scripts. I guess this step can now be folded into this general mechanism. Do you want to provide such a patch, or shall I do it? toolchains that are older than binutils-2.17 wont work with the Blackfin port, so compatibility with pre-2.16 isnt something this port needs to worry about -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix all linker script to handle all rodata sections
On Sun, 16 Aug 2009, Wolfgang Denk wrote: ... I change this to: *(.text) . = ALIGN(16); *(.eh_frame) *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) Unfortunately it turns out that this breaks some older tool chains. For example, using ELDK 3.1 (binutils 2.14-5) we get: arm-linux-ld:/home/wd/git/u-boot/work/cpu/s3c44b0/u-boot.lds:39: parse error It seems this old version of ld does not understand the *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) line yet. Do you see any want to make this backward compatible with older versions of ld? I don't have an ld old enough to not like that line so I'm not sure what the problem is exactly. There wouldn't be any significant downside to changing it to: *(SORT_BY_ALIGNMENT(.rodata*)) If that would work with your ld. Using *(.rodata*) will result in extra padding and a larger data segment. It may not be all that much extra though... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix all linker scripts for older binutils versions (pre-2.16)
Dear Mike, In message 200908171514.54018.vap...@gentoo.org you wrote: Mike, I am aware that Blackfin is already using the C preprocessor to generate it's linker scripts. I guess this step can now be folded into this general mechanism. Do you want to provide such a patch, or shall I do it? toolchains that are older than binutils-2.17 wont work with the Blackfin port, so compatibility with pre-2.16 isnt something this port needs to worry about Agreed, but the cpp step is now _always_ performed, and in your case twice - first in your board directory, and then again by the top level Makefile. You could save the local run now. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de God runs electromagnetics by wave theory on Monday, Wednesday, and Friday, and the Devil runs them by quantum theory on Tuesday, Thurs- day, and Saturday. -- William Bragg ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix all linker script to handle all rodata sections
Dear Trent, In message pine.lnx.4.58.0908171214470.11...@shell2.speakeasy.net you wrote: Do you see any want to make this backward compatible with older versions of ld? I don't have an ld old enough to not like that line so I'm not sure what the problem is exactly. The problem is that SORT_BY_ALIGNMENT() and SORT_BY_NAME() were introduced for binutils 2.16, so any older versions will barf on the linker scripts. There wouldn't be any significant downside to changing it to: *(SORT_BY_ALIGNMENT(.rodata*)) If that would work with your ld. Using *(.rodata*) will result in extra padding and a larger data segment. It may not be all that much extra though... Differences are minimal, actually. Please see my approach to solve this at http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/66080 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Veni, Vidi, VISA: I came, I saw, I did a little shopping. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] davinci_emac.c:*: warning: duplicate `volatile'
On Mon, 17 Aug 2009, Wolfgang Denk wrote: Dear k...@koi8.net, In message pine.lnx.4.64ksi.0908171053160.9...@home-gw.koi8.net you wrote: what compiler do you use? I just compiled all the davinci boards with GNUEABI GCC 4.4.1 (binutils ver.2.19.1) and I didn't get a single compiler warning. I was playing with old tool chains actually. That was with gcc 3.3.x. Ah, that's ancient... I don't think we need to something for this. I betcha it won't compile at all with something like 2.x.x but who cares? :) There are 2 separate issues but they are not related to the above description. First is that it fails to compile with GNUEABI GCC but that is addressed in your recent arm build patch that works OK. Thanks for the confirmation! Much appreciated. Could you please send an Ack-by or Tested-by for that patch? Thanks in advance. Sure I will. The second one is that GCC 4.4.1 (don't know about the older ones, don't have those on my machine now) generates an error for inline weak functions in lib_arm/board.c (and I think it is totally correct -- what is an inline weak function?) Here is the failed build log excertpt: A patch for this has been posted some time ago. See http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/65397/focus=65559 we're just waiting for the ARM custodian to take appropriate action. OK. As for those duplicate `volatile' warnings I don't see them (and have never seen them before) so I don't know what to fix. I can send you my build logs off the list if you want. Well, here is an example - building davinci_schmoogie using ELDK 3.1.1 (gcc version 3.3.3): davinci_emac.c:82: warning: duplicate `volatile' davinci_emac.c:83: warning: duplicate `volatile' davinci_emac.c:84: warning: duplicate `volatile' davinci_emac.c:85: warning: duplicate `volatile' davinci_emac.c: In function `davinci_eth_open': davinci_emac.c:257: warning: duplicate `volatile' davinci_emac.c: In function `davinci_eth_rcv_packet': davinci_emac.c:475: warning: duplicate `volatile' davinci_emac.c:476: warning: duplicate `volatile' davinci_emac.c:477: warning: duplicate `volatile' davinci_emac.c:496: warning: duplicate `volatile' Once again -- I don't think it requires any action. It builds without a single warning with newer compilers, even with 4.2.x less for 4.4.1... --- ** * k...@homeKOI8 Net The impossible we do immediately. * * Las Vegas NV, USA Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
On Mon, 17 Aug 2009, Wolfgang Denk wrote: Ack-by: Sergey Kubushyn k...@koi8.net --- For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier: - Even though all ARM systems basicy used the same compiler options to select a specific ABI from the tool chain, the code for this was distributed over all cpu/*/config.mk files. We move this one level up into lib_arm/config.mk instead. - So far, we only checked if -mapcs-32 was supported by the tool chain; if yes, this was used, if not, -mabi=apcs-gnu was selected, no matter if the tool chain actually understood this option. There was no support for EABI conformant tool chains. This patch implements the following logic: 1) If the tool chain supports -mabi=aapcs-linux -mno-thumb-interwork we use these options (EABI conformant tool chain). 2) Otherwise, we check first if -mapcs-32 is supported, and then check for -mabi=apcs-gnu If one test succeeds, we use the first found option. 3) In case 2), we also test if -mno-thumb-interwork, and use this if the test succeeds. [For -mabi=aapcs-linux we set -mno-thumb-interwork mandatorily.] This way we use a similar logic for the compile options as the Linux kenrel does. - Some EABI conformant tool chains cause external references to utility functions like raise(); such functions are provided in the new file lib_arm/eabi_compat.c Note that lib_arm/config.mk gets parsed several times, so we must make sure to add eabi_compat.o only once to the linker list. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Dirk Behme dirk.be...@googlemail.com Cc: Magnus Lilja lilja.mag...@gmail.com Cc: Tom Rix tom@windriver.com Cc: Prafulla Wadaskar prafu...@marvell.com --- --- ** * k...@homeKOI8 Net The impossible we do immediately. * * Las Vegas NV, USA Miracles require 24-hour notice. * ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Mon 17 Aug 2009 15:05, Wolfgang Denk pondered:
Dear Robin Getz,
In message 200908171315.40365.rg...@blackfin.uclinux.org you wrote:
Comments welcome...
I guess the code is largely untested?
I tested it on a single machine.
diff --git a/net/tftp.c b/net/tftp.c
index 9544691..56db247 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -66,6 +66,9 @@ static ulong TftpLastBlock; /* last packet
sequence number received */
static ulong TftpBlockWrap; /* count of sequence number
wraparounds */
static ulong TftpBlockWrapOffset;/* memory offset due to
wrapping*/
static int TftpState;
+#ifdef CONFIG_TFTP_TSIZE
+static int TftpTsize; /* Tsize */
+#endif
Why static int? This gives a random init value for the second and each
following TFTP transfers.
Nope - it is set to zero on the start of every transfer.
@@ -212,6 +215,10 @@ TftpSend (void)
sprintf((char *)pkt, %lu, TIMEOUT / 1000);
debug(send option \timeout %s\\n, (char *)pkt);
pkt += strlen((char *)pkt) + 1;
+#ifdef CONFIG_TFTP_TSIZE
+ pkt += sprintf((char *)pkt,tsize%c%d, 0,0);
+ pkt += strlen((char *)pkt) + 1;
Looks to me as if you were adding the length twice?
One zero is for the null char (delimiter), one zero is for ascii zero (length).
+#endif
/* try for more effic. blk size */
pkt += sprintf((char *)pkt,blksize%c%d%c,
0,TftpBlkSizeOption,0);
@@ -321,8 +328,14 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
simple_strtoul((char*)pkt+i+8,NULL,10);
debug(Blocksize ack: %s, %d\n,
(char*)pkt+i+8,TftpBlkSize);
- break;
}
+#ifdef CONFIG_TFTP_TSIZE
+ if (strcmp ((char*)pkt+i,tsize) == 0) {
+ TftpTsize =
simple_strtoul((char*)pkt+i+6,NULL,10);
+ debug(size = %s, %d\n,
+(char*)pkt+i+6, TftpTsize);
+ }
It seems you rely on TftpTsize to be zero otherwise. The current code
(with a static int) does not guarantee that, though.
It is set to zero below on start.
- } else {
+ }
+#ifdef CONFIG_TFTP_TSIZE
+ else if (TftpTsize) {
+
+ printf(%2d\b\b, NetBootFileXferSize * 100 /
TftpTsize);
+ }
+#endif
Hm... maybe we should rather print hashes (say one '#' for each 2%,
resulting in a maximum of 50 characters output.
Otherwise we actually increase the amount of characters sent over the
serial line (and the intention was to reduce it, right?)
Yeah, it was to reduce the output - this was easier :)
Plus spinning numbers are always nice. When you are doing a scp - do you
look at the bar moving, or the numbers going up to 100%? I always look
at the numbers...
I'll re-work it for a single line of 50 hashes. (one '#' == 2% of the file).
+#ifdef CONFIG_TFTP_TSIZE
+ if (TftpTsize)
+ puts(100%);
+#endif
+
puts_quiet(\ndone\n);
Here we see the bad consequences of this puts_quiet() stuff (which I
really dislike. The longer I see it, the more I tend to reject it.
Here, the (necessary!) newline terminating the 100% output, is not
always sent, only when puts_quiet() is active.
Yeah, sorry about that - I would switch the puts to the puts_quiet
if that is picked up - I just never heard an ack or nack on it...
@@ -550,6 +579,9 @@ TftpStart (void)
#ifdef CONFIG_TFTP_TIME
start_time = get_timer(0);
#endif
+#ifdef CONFIG_TFTP_TSIZE
+ TftpTsize = 0;
+#endif
Ah. I see :-)
So - you are OK with they way it is done (other comments still apply of
course).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] davinci_emac.c:*: warning: duplicate `volatile'
Dear k...@koi8.net, In message pine.lnx.4.64ksi.0908171235440.10...@home-gw.koi8.net you wrote: I was playing with old tool chains actually. That was with gcc 3.3.x. Ah, that's ancient... I don't think we need to something for this. I betcha it won't compile at all with something like 2.x.x but who cares? :) Indeed gcc 2.95 dies with a unrecognized option `-MQ' error message when attempting to generate the dependencies... Thanks for the confirmation! Much appreciated. Could you please send an Ack-by or Tested-by for that patch? Thanks in advance. Sure I will. Thanks a lot. ... davinci_emac.c:496: warning: duplicate `volatile' Once again -- I don't think it requires any action. It builds without a single warning with newer compilers, even with 4.2.x less for 4.4.1... Yes, I know. But I still would like to hush up this gcc 3.x warning, if possible. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can observe a lot just by watching. - Yogi Berra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix all linker scripts for older binutils versions (pre-2.16)
On Monday 17 August 2009 15:31:30 Wolfgang Denk wrote: Mike wrote: Mike, I am aware that Blackfin is already using the C preprocessor to generate it's linker scripts. I guess this step can now be folded into this general mechanism. Do you want to provide such a patch, or shall I do it? toolchains that are older than binutils-2.17 wont work with the Blackfin port, so compatibility with pre-2.16 isnt something this port needs to worry about Agreed, but the cpp step is now _always_ performed, and in your case twice - first in your board directory, and then again by the top level Makefile. You could save the local run now. ok, i missed that aspect. i think the changes needed are: lib_blackfin/Makefile: -$(obj)u-boot.lds: u-boot.lds.S - $(CPP) $(CPPFLAGS) -D__ASSEMBLY__ -P $^ $@ lib_blackfin/config.mk: -LDSCRIPT = $(obj)lib_$(ARCH)/u-boot.lds +LDSCRIPT = $(obj)lib_$(ARCH)/u-boot.lds.S i can post a patch once yours gets merged -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Hi Wolfgang, 2009/8/17 Wolfgang Denk w...@denx.de: For some time there have been repeated reports about build problems with some ARM (cross) tool chains. Especially issues about (in)compatibility with the tool chain provided runtime support library libgcc.a caused to add and support a private implementation of such runtime support code in U-Boot. A closer look at the code indicated that some of these issues are actually home-made. This patch attempts to clean up some of the most obvious problems and make building of U-Boot with different tool chains easier: - Even though all ARM systems basicy used the same compiler options to select a specific ABI from the tool chain, the code for this was distributed over all cpu/*/config.mk files. We move this one level up into lib_arm/config.mk instead. - So far, we only checked if -mapcs-32 was supported by the tool chain; if yes, this was used, if not, -mabi=apcs-gnu was selected, no matter if the tool chain actually understood this option. There was no support for EABI conformant tool chains. This patch implements the following logic: 1) If the tool chain supports -mabi=aapcs-linux -mno-thumb-interwork we use these options (EABI conformant tool chain). 2) Otherwise, we check first if -mapcs-32 is supported, and then check for -mabi=apcs-gnu If one test succeeds, we use the first found option. 3) In case 2), we also test if -mno-thumb-interwork, and use this if the test succeeds. [For -mabi=aapcs-linux we set -mno-thumb-interwork mandatorily.] This way we use a similar logic for the compile options as the Linux kenrel does. kenrel = kernel :-) - Some EABI conformant tool chains cause external references to utility functions like raise(); such functions are provided in the new file lib_arm/eabi_compat.c Note that lib_arm/config.mk gets parsed several times, so we must make sure to add eabi_compat.o only once to the linker list. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Cc: Dirk Behme dirk.be...@googlemail.com Cc: Magnus Lilja lilja.mag...@gmail.com Cc: Tom Rix tom@windriver.com Cc: Prafulla Wadaskar prafu...@marvell.com --- I have run a full MAKEALL arm for ELDK releases 3.1 (gcc 3.3.3), 3.1.1 (gcc 3.3.3), 4.1 (gcc 4.0.0) and 4.2 (gcc 4.2.2, both as arm [softfloat] and armVFP [VFP hardfloat]), and all of these both with USE_PRIVATE_LIBGCC=yes (i. e. using U-Boot internal libgcc replacement code) and without (i. e. using the tool chain provided standard libgcc instead). The ELDK fails to build the big-endian IXP boards, but this is a restriction of the ELDK, not a new issue introcued by this patch. Except of this, all build were succesful. Note 1: Please note that older tool chains (based on binutils versions older than 2.16) will have problems with the SORT_BY_ALIGNMENT() and SORT_BY_NAME() functions introduced to the linker scripts with commit f62fb99941c6. I'll soon submit a patch to fix this issue. Final tests are running right now. Note 2: Even though this is a bigger change, I consider it a bug fix and therefor tend to have it included into the upcoming release. Of course this requires sufficient test coverage and feedback. Please help!! I've done compile time testing for the ARM11 boards using a gcc 4.1.2 toolchain that I often use and also Codesourcery's 2009-q1 (gcc 4.3.3) (both with and without USE_PRIVATE_LIBGCC=yes), everything compiles fine. I hope to be able to do some run-time testing of some i.MX31 U-boot binaries later this week, so far I haven't tried them at all. Regards, Magnus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
Dear Robin Getz, In message 200908171555.31016.rg...@blackfin.uclinux.org you wrote: Why static int? This gives a random init value for the second and each following TFTP transfers. Nope - it is set to zero on the start of every transfer. Right, I saw this later, at the end of your patch, but was too lazy to change my whole message ;-) +#ifdef CONFIG_TFTP_TSIZE + pkt += sprintf((char *)pkt,tsize%c%d, 0,0); + pkt += strlen((char *)pkt) + 1; Looks to me as if you were adding the length twice? One zero is for the null char (delimiter), one zero is for ascii zero (length). Wel, the sprintf() already returns the number of output characters, i. e. 7. pkt then points at the terminating '\0' character. strlen() should always return 0, then. This makes not much sense to me. Also, why do you need sprintf() at all when the string is a constant anyway? Why not simply: memcpy (pkt, tsize\00, 7); pkt += 7; + printf(%2d\b\b, NetBootFileXferSize * 100 / TftpTsize); + } +#endif Hm... maybe we should rather print hashes (say one '#' for each 2%, resulting in a maximum of 50 characters output. Otherwise we actually increase the amount of characters sent over the serial line (and the intention was to reduce it, right?) Yeah, it was to reduce the output - this was easier :) Plus spinning numbers are always nice. When you are doing a scp - do you look at the bar moving, or the numbers going up to 100%? I always look at the numbers... I know what you mean. OTOH, I tend to dislike such characters sequences (with lots of backspace characters) because they always mess up log files ;-) I'll re-work it for a single line of 50 hashes. (one '#' == 2% of the file). Thanks. So - you are OK with they way it is done (other comments still apply of course). Right. Thanks a lot. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Many aligators will be slain, but the swamp will remain. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix all linker scripts for older binutils versions (pre-2.16)
Dear Mike Frysinger, In message 200908171615.45626.vap...@gentoo.org you wrote: twice - first in your board directory, and then again by the top level Makefile. You could save the local run now. ok, i missed that aspect. i think the changes needed are: lib_blackfin/Makefile: -$(obj)u-boot.lds: u-boot.lds.S - $(CPP) $(CPPFLAGS) -D__ASSEMBLY__ -P $^ $@ lib_blackfin/config.mk: -LDSCRIPT = $(obj)lib_$(ARCH)/u-boot.lds +LDSCRIPT = $(obj)lib_$(ARCH)/u-boot.lds.S Right. I just have no easy way to test this... i can post a patch once yours gets merged Thanks a lot in advance. There is a slight difference, though - I'm calling CPP with the -ansi switch to make sure that all system-specific predefined macros outside the reserved namespace are suppressed, i. e. only those starting with double-underscores will be seen. I am pretty sure that this is actually what you want, too. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Our business is run on trust. We trust you will pay in advance. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Dear Magnus Lilja, In message 59b21cf20908171317s10d7fdb5t631c37f06707e...@mail.gmail.com you wrote: This way we use a similar logic for the compile options as the Linux kenrel does. kenrel = kernel :-) Thanks, will try to remember to edit the commit message. I've done compile time testing for the ARM11 boards using a gcc 4.1.2 toolchain that I often use and also Codesourcery's 2009-q1 (gcc 4.3.3) (both with and without USE_PRIVATE_LIBGCC=yes), everything compiles fine. I hope to be able to do some run-time testing of some i.MX31 U-boot binaries later this week, so far I haven't tried them at all. Excellent., Thanks a lot. Can you please send an ACK or Tested-by, then? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Time is an illusion perpetrated by the manufacturers of space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix all linker scripts for older binutils versions (pre-2.16)
On Monday 17 August 2009 16:24:45 Wolfgang Denk wrote: There is a slight difference, though - I'm calling CPP with the -ansi switch to make sure that all system-specific predefined macros outside the reserved namespace are suppressed, i. e. only those starting with double-underscores will be seen. I am pretty sure that this is actually what you want, too. afaik, i only rely on __XXX__ defines from the toolchain and no XXX. if it does break something, that's good anyways so i can go fix it ;). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BMP display.
Dear Tuma, In message 200908171755.31690.chernigovs...@spb.gs.ru you wrote: make[1]: arm-linux-gcc: Command not found My old U-Boot used arm-none-linux-gnueabi-gcc which make system could easyly find on my system. Should I install some new software to build new U-Boot? Or configure existing Makefile? Maybe you should read the documetnation; then try: CROSS_COMPILE=arm-none-linux-gnueabi- export CROSS_COMPILE before running make. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A little knowledge is a dangerous thing.- Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Network defrag
On Mon 17 Aug 2009 16:20, Wolfgang Denk pondered: Dear Robin Getz, In message 200908171555.31016.rg...@blackfin.uclinux.org you wrote: Why static int? This gives a random init value for the second and each following TFTP transfers. Nope - it is set to zero on the start of every transfer. Right, I saw this later, at the end of your patch, but was too lazy to change my whole message ;-) +#ifdef CONFIG_TFTP_TSIZE + pkt += sprintf((char *)pkt,tsize%c%d, 0,0); + pkt += strlen((char *)pkt) + 1; Looks to me as if you were adding the length twice? One zero is for the null char (delimiter), one zero is for ascii zero (length). Wel, the sprintf() already returns the number of output characters, i. e. 7. pkt then points at the terminating '\0' character. strlen() should always return 0, then. This makes not much sense to me. Also, why do you need sprintf() at all when the string is a constant anyway? Why not simply: memcpy (pkt, tsize\00, 7); pkt += 7; That's is better - It was just a dumb copy/paste from the blksize option... + printf(%2d\b\b, NetBootFileXferSize * 100 / TftpTsize); + } +#endif Hm... maybe we should rather print hashes (say one '#' for each 2%, resulting in a maximum of 50 characters output. Otherwise we actually increase the amount of characters sent over the serial line (and the intention was to reduce it, right?) Yeah, it was to reduce the output - this was easier :) Plus spinning numbers are always nice. When you are doing a scp - do you look at the bar moving, or the numbers going up to 100%? I always look at the numbers... I know what you mean. OTOH, I tend to dislike such characters sequences (with lots of backspace characters) because they always mess up log files ;-) But they look pretty ... :) I'll re-work it for a single line of 50 hashes. (one '#' == 2% of the file). Thanks. Np. So - you are OK with they way it is done (other comments still apply of course). Right. Thanks a lot. New version tomorrow... Robin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for DevKit8000
Dear Dirk Behme,
In message 4a897571.9090...@googlemail.com you wrote:
Wolfgang commented already most of the topics.
:-)
So, only one comment left for me:
But a well spottet one, thanks!
+ /* Use OMAP DIE_ID as MAC address */
+ if (!eth_getenv_enetaddr(ethaddr, enetaddr)) {
+ enetaddr[0] = 0x02; /* locally administered */
+ enetaddr[1] = readl(id_base-die_id_1) 0xff;
+ *(u32*)enetaddr[2] = readl(id_base-die_id_0);
Who guarantess that enetaddr[2] will be 32 bit aligned?
And hat does this machine do on unaligned accesses?
Frederik: Please fix this.
+ eth_setenv_enetaddr(ethaddr, enetaddr);
+ }
With the OMAP DIE_ID thread we know what you are doing here. But do we
want to have this really in mainline? It looks to me like a workaround
for broken hardware (that is, having no proper MAC address
configured)? Or do I miss anything?
Indeed. It's fishy at best.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
When the tide of life turns against you
And the current upsets your boat
Don't waste tears on what might have been
Just lie on your back and float.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] e1000: fix PCI memory addressing
The Intel E1000 driver was making assumptions about the relationship between
some virtual, physical, and PCI addresses.
Also fix some bad usage of the DEBUGOUT macro
Signed-off-by: Timur Tabi ti...@freescale.com
---
drivers/net/e1000.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index e3c6cea..0f2a5fe 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -46,8 +46,7 @@ tested on both gig copper and gig fiber boards
#define TOUT_LOOP 10
-#undef virt_to_bus
-#definevirt_to_bus(x) ((unsigned long)x)
+#define virt_to_bus(devno, v) pci_virt_to_mem(devno, (void *) (v))
#define bus_to_phys(devno, a) pci_mem_to_phys(devno, a)
#define mdelay(n) udelay((n)*1000)
@@ -357,7 +356,7 @@ e1000_acquire_eeprom(struct e1000_hw *hw)
struct e1000_eeprom_info *eeprom = hw-eeprom;
uint32_t eecd, i = 0;
- DEBUGOUT();
+ DEBUGFUNC();
if (e1000_swfw_sync_acquire(hw, E1000_SWFW_EEP_SM))
return -E1000_ERR_SWFW_SYNC;
@@ -418,7 +417,7 @@ static int32_t e1000_init_eeprom_params(struct e1000_hw *hw)
int32_t ret_val = E1000_SUCCESS;
uint16_t eeprom_size;
- DEBUGOUT();
+ DEBUGFUNC();
switch (hw-mac_type) {
case e1000_82542_rev2_0:
@@ -2355,7 +2354,7 @@ e1000_copper_link_igp_setup(struct e1000_hw *hw)
int32_t ret_val;
uint16_t phy_data;
- DEBUGOUT();
+ DEBUGFUNC();
if (hw-phy_reset_disable)
return E1000_SUCCESS;
@@ -5017,7 +5016,7 @@ e1000_transmit(struct eth_device *nic, volatile void
*packet, int length)
txp = tx_base + tx_tail;
tx_tail = (tx_tail + 1) % 8;
- txp-buffer_addr = cpu_to_le64(virt_to_bus(packet));
+ txp-buffer_addr = cpu_to_le64(virt_to_bus(hw-pdev, packet));
txp-lower.data = cpu_to_le32(hw-txd_cmd | length);
txp-upper.data = 0;
E1000_WRITE_REG(hw, TDT, tx_tail);
@@ -5145,6 +5144,8 @@ e1000_initialize(bd_t * bis)
int idx = 0;
u32 PciCommandWord;
+ DEBUGFUNC();
+
while (1) { /* Find PCI device(s) */
if ((devno = pci_find_devices(supported, idx++)) 0) {
break;
@@ -5170,7 +5171,6 @@ e1000_initialize(bd_t * bis)
hw = (struct e1000_hw *) malloc(sizeof (*hw));
hw-pdev = devno;
nic-priv = hw;
- nic-iobase = bus_to_phys(devno, iobase);
sprintf(nic-name, e1000#%d, card_number);
@@ -5180,7 +5180,8 @@ e1000_initialize(bd_t * bis)
hw-autoneg_failed = 0;
hw-autoneg = 1;
hw-get_link_status = TRUE;
- hw-hw_addr = (typeof(hw-hw_addr)) iobase;
+ hw-hw_addr =
+ pci_map_bar(devno, PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
hw-mac_type = e1000_undefined;
/* MAC and Phy settings */
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] e1000: fix PCI memory addressing
FYI, there is no patch 1/2. It's just this one. On Mon, Aug 17, 2009 at 3:55 PM, Timur Tabiti...@freescale.com wrote: The Intel E1000 driver was making assumptions about the relationship between some virtual, physical, and PCI addresses. Also fix some bad usage of the DEBUGOUT macro Signed-off-by: Timur Tabi ti...@freescale.com -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding the PORTING of U-boot to ARM7 based board.
Dear uday bhaskar, please keep the mailing list on cc: In message 75bad7120908170826l6c4f494q480208f55ac93...@mail.gmail.com you wrote: Actually i have ARM7 based LPC2129 board taken from Emblitz (www.emblitz.com). Board name is EVAT104. My question is 1. Is this supports for U-boot. This board is not supported by the mainline U-Boot code. I have no idea if the vendore provides a port - or somebody else. 2. If so, will it be available or will be able to develope using any ARM7 u-boot loader with modifications It is a pretty straightforward task to port U-Boot to such a board - depending on your experience, of course. please give me the procedure to downloading and making image and details of tools required. Because i am new to it. Start reading the README, then the DULG, then the source code. Or hire an expert. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Every program has at least one bug and can be shortened by at least one instruction - from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Support for the Calao TNY-A9260/TNY-A9G20 boards
+ +#ifndef __CONFIG_H +#define __CONFIG_H + +#if defined(CONFIG_tny_a9260) || defined(CONFIG_tny_a9260_nandflash) || defined(CONFIG_tny_a9260_eeprom) too long and define must be upper case +#define CONFIG_TNY_A9260 +#define CONFIG_AT91SAM9260 +#elif defined(CONFIG_tny_a9g20) || defined(CONFIG_tny_a9g20_nandflash) || defined(CONFIG_tny_a9g20_eeprom) ditto +#define CONFIG_TNY_A9G20 +#define CONFIG_AT91SAM9G20 +#else +#error Unknown board +#endif + +#if defined(CONFIG_tny_a9260_nandflash) || defined(CONFIG_tny_a9g20_nandflash) +#define CONFIG_ENV_IS_IN_NAND +#else +#define CONFIG_ENV_IS_IN_EEPROM +#endif + Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v4] arm: A320: Add support for Faraday A320 evaluation board
On 23:10 Tue 04 Aug , Darius Augulis wrote: On 08/04/2009 10:48 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: On 09:42 Mon 03 Aug , Darius Augulis wrote: On 07/08/2009 02:30 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: On 15:14 Fri 03 Jul , Po-Yu Chuang wrote: This patch adds support for A320 development board from Faraday. This board uses FA526 processor by default and has 512kB and 32MB NOR flash, 64M RAM. FA526 is an ARMv4 processor and uses the ARM920T source in this patch. as I understand correctly the faraday and the CS3518 share the same core and IP so it will be better to have the same dir I don't think so. Both A320 and Gemini share the same FA526 core, but different peripheral. There is no reason to create generic dir for A320 and Gemini. Also, no reason to create cpu/fa526 because fa526 is almost arm920t. duplicate code is worse as example on at91 we do support multiple soc of the family in the same generic dir which allow us to factorize common code and ofcourse split soc specific code too Gemini and A320 are not from the same family. There isn't any common code *yet*. They share only the same core. There are more dirs in cpu/arm920t: imx, s3c24x0, etc. Perhaps you won't suggest to move all these SoC's into single dir? no as they do share nothing if the code is arm920t specific it will more to arm/920t if soc arm920t/at91 etc A320 and Gemini *maybe* have the same timer IP, but there are few 'small' problems. First: these processors, made in China, have very poor documentation. I must do lot of reverse-engineering work to create something working. Second, I don't have any A320 hardware to test something. It's very difficult to make most optimal release at the very beginning. After we have Gemini in main line, somebody interested in A320 should feel free to submit patches to optimize support for SoC's, based on FA526 core. Now I can't do this job and I guess it shouldn't be reason to reject my patches? you are two dev working to add both soc mainline so please sync together to not add duplicated code that all I want Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v4] arm: A320: Add support for Faraday A320 evaluation board
On 12:45 Thu 06 Aug , Po-Yu Chuang wrote: Dear Jean-Christophe and Darius, 2009/8/5 Darius Augulis augulis.dar...@gmail.com: On 08/04/2009 10:48 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: as I understand correctly the faraday and the CS3518 share the same core and IP so it will be better to have the same dir I don't think so. Both A320 and Gemini share the same FA526 core, but different peripheral. There is no reason to create generic dir for A320 and Gemini. Also, no reason to create cpu/fa526 because fa526 is almost arm920t. Let me summarize. Correct me if I am wrong. a320 is an soc with fa526 core which is similar to arm920t. Gemini is an soc with fa526 core. board | A320 evb | NAS4220 | soc family | | Gemini | soc| A320 | CS3516 | cpu| FA526| FA526 | CS3516 and A320 maybe have the same timer (but most IPs are different). duplicate code is worse as example on at91 we do support multiple soc of the family in the same generic dir which allow us to factorize common code and ofcourse split soc specific code too What is the definition of an SOC family? Gemini and A320 are not from the same family. There isn't any common code *yet*. They share only the same core. There are more dirs in cpu/arm920t: imx, s3c24x0, etc. Perhaps you won't suggest to move all these SoC's into single dir? Agree. Gemini and A320 are not the same family IMO. The only common parts are the FA526 core and the timer. (or is this sufficient to be a family?) this sufficient to not duplicate code The problem is how should the files be organized if two SOC families use the same IP. Maybe we can create a cpu/arm920t/common/ ? no it's must be fa526 dependant not arm920t common But what if that IP is used in another SOC with arm926 core? (This happens in Faraday's other SOCs) I think the easiest way is to treat A320 and Gemini patches unrelated. I do not want to have code duplicated for the other IP the will move for the most of them in drivers anyway as example on SH4 the Renesas ST socs share the same timer, interrupt handler and few other thinks we will not duplicate for this will use the same code Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v4] arm: A320: Add support for Faraday A320 evaluation board
On 14:13 Thu 06 Aug , Po-Yu Chuang wrote:
Dear Jean-Christophe,
2009/7/8 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com:
+.globl lowlevel_init
+lowlevel_init:
+ mov r11, lr
+
+ led 0x0
+
+ /* if REMAP bit is set - memory had been initialzed */
+
+ ldr r0, =CONFIG_SYS_AHBC_BASE
+ ldr r1, [r0, #FTAHBC020_OFFSET_ICR]
+ tst r1, #FTAHBC020_ICR_REMAP @ test REMAP bit
+ bne skip_remap
+
+ led 0x1
+
+ bl init_sdmc
+
+ led 0x2
+
+ /*
+ * copy U-Boot to RAM
+ */
+copy_code:
+ ldr r0, =ROM_DEFAULT_BASE /* r0 - source address */
+ ldr r1, =SDRAM_DEFAULT_BASE /* r1 - target address */
+
+ ldr r2, .LC5
+ ldr r3, .LC6
+ sub r2, r3, r2 /* r2 - size of armboot
*/
+ add r2, r0, r2 /* r2 - source end address
*/
+
+ led 0x3
+
+copy_loop:
+ ldmia r0!, {r3-r10} /* copy from source address [r0]
*/
+ stmia r1!, {r3-r10} /* copy to target address [r1]
*/
+ cmp r0, r2 /* until source end addreee [r2]
*/
+ ble copy_loop
+
I do not like to do this twice we need to find an otherway
do we really need to run in SDRAM before remap?
I am afraid so.
u-boot needs to be copied to SDRAM first to do the remap
(swap ROM and SDRAM bank) to make SDRAM base becomes 0x0.
cpu/arm920t/start.S then relocates u-boot to the end of SDRAM.
Anyway, I have an idea now.
I can submit a version that do not do the bank swap
(SDRAM stays at 0x1000).
The the mainline keeps beautiful as you wish.
Then I create another patch to do the bank swap for our internal use.
This should be a win-win. :-)
why not but show us the code please
and we will see
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding the PORTING of U-boot to ARM7 based board.
On Mon, Aug 17, 2009 at 4:48 PM, Wolfgang Denkw...@denx.de wrote: Dear uday bhaskar, please keep the mailing list on cc: In message 75bad7120908170826l6c4f494q480208f55ac93...@mail.gmail.com you wrote: Actually i have ARM7 based LPC2129 board taken from Emblitz (www.emblitz.com). Board name is EVAT104. My question is 1. Is this supports for U-boot. This board is not supported by the mainline U-Boot code. I have no idea if the vendore provides a port - or somebody else. This is more overblown microcontroller than processor - 16K internal RAM, 256K flash, no expansion bus that I saw. I would look more at RTOS stuff, it would be a better fit. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: DaVinci: Adding Support for DaVinci DM365 EVM
On 11:20 Sat 15 Aug , s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com This patch adds support for the DM365 EVM. It has been tested on a DM365 EVM. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- Makefile |3 + board/davinci/dm365evm/Makefile| 52 ++ board/davinci/dm365evm/config.mk | 11 ++ board/davinci/dm365evm/dm365evm.c | 60 include/configs/davinci_dm365evm.h | 182 5 files changed, 308 insertions(+), 0 deletions(-) create mode 100644 board/davinci/dm365evm/Makefile create mode 100644 board/davinci/dm365evm/config.mk create mode 100644 board/davinci/dm365evm/dm365evm.c create mode 100644 include/configs/davinci_dm365evm.h apply to u-boot-arm next Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: DaVinci: DaVinci DM365 SOC specific code
On 11:20 Sat 15 Aug , s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com This patch adds support for DaVinci DM365 SOC. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- cpu/arm926ejs/davinci/Makefile |1 + cpu/arm926ejs/davinci/dm365.c | 35 +++ 2 files changed, 36 insertions(+), 0 deletions(-) create mode 100644 cpu/arm926ejs/davinci/dm365.c apply to u-boot-arm next Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3: Fixed a problem with hwecc
On 10:03 Fri 14 Aug , Ben Goska wrote: In commit 187af954cf7958c24efcf0fd62289bbdb4f1f24e there was a typo that offset all the ecc registers by 4 bytes, fixed that. Signed-off-by: Ben Goska gos...@onid.oregonstate.edu --- include/asm-arm/arch-omap3/cpu.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) apply to u-boot-arm Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support
On 10:45 Tue 11 Aug , s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com This patch adds 4 BIT ecc support in the DaVinci NAND driver. Tested on both the DM355 and DM365. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- drivers/mtd/nand/davinci_nand.c | 290 +- include/asm-arm/arch-davinci/emif_defs.h | 10 + 2 files changed, 298 insertions(+), 2 deletions(-) Scoot is this ok for you? if yes I'd like to apply it with the board udpate to my next Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: DaVinci DM355: Updating the DM355 EVM config
On 10:49 Tue 11 Aug , s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com This patch enables NAND support on the DM355 EVM. Changes in this patch mostly relate to adding the NAND support. This patch also defines a boot delay. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- include/configs/davinci_dm355evm.h | 21 + 1 files changed, 13 insertions(+), 8 deletions(-) will be apply after nand patch handling ack Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Support for the Calao TNY-A9260/TNY-A9G20 boards
On Mon, Aug 17, 2009 at 11:41:06PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote : + +#ifndef __CONFIG_H +#define __CONFIG_H + +#if defined(CONFIG_tny_a9260) || defined(CONFIG_tny_a9260_nandflash) || defined(CONFIG_tny_a9260_eeprom) too long and define must be upper case Those defines are generated directly from the target names in the Makfile, and are used for internal purposes only. Moving them to uppercase would mean changing the target names from tny_a9g20_nandflash to TNY_A9G20_NANDFLASH, while the existing Calao-provided BSP uses lowercase. I'd rather not change that. By the way, I'd appreciate an answer on LED API matter Cheers, -- Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: Kirkwood: add SYSRSTn Duration Counter Support
On 22:03 Fri 07 Aug , Prafulla Wadaskar wrote:
This feature can be used to trigger special command sysrstcmd using
reset key long press event and environment variable sysrstdelay is set
(useful for reset to factory or manufacturing mode execution)
Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
The counter value is stored in the SYSRSTn Length Counter Register
The counter is based on the 25-MHz reference clock (40ns)
It is a 29-bit counter, yielding a maximum counting duration of
2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
it remains at this value until counter reset is triggered by setting
bit 31 of KW_REG_SYSRST_CNT
Implementation:
Upon long reset assertion ( ${sysrstdleay} in secs) sysrstcmd will be
executed if pre-defined in environment variables.
This feature will be disabled if sysrstdelay variable is unset.
for-ex.
setenv sysrst_cmd echo starting factory reset;
nand erase 0xa 0x2;
echo finish ed sysrst command;
will erase particular nand sector if triggered by this event
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
a readme would be nice
and maybe make it more generic so other soc could also implement it
---
Change log:
v2: command sysrst_cmd renamed as sysrstcmd
stsrstdelay variable added instead of hardcoding the value
cpu/arm926ejs/kirkwood/cpu.c| 79
+++
include/asm-arm/arch-kirkwood/cpu.h |2 +
2 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/cpu/arm926ejs/kirkwood/cpu.c b/cpu/arm926ejs/kirkwood/cpu.c
index 795a739..9a6ee57 100644
--- a/cpu/arm926ejs/kirkwood/cpu.c
+++ b/cpu/arm926ejs/kirkwood/cpu.c
@@ -195,6 +195,82 @@ int kw_config_mpp(u32 mpp0_7, u32 mpp8_15, u32 mpp16_23,
u32 mpp24_31,
return 0;
}
+/*
+ * SYSRSTn Duration Counter Support
+ *
+ * Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
+ * When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
+ * The SYSRSTn duration counter is useful for implementing a manufacturer
+ * or factory reset. Upon a long reset assertion that is greater than a
+ * pre-configured environment variable value for sysrstdelay,
+ * The counter value is stored in the SYSRSTn Length Counter Register
+ * The counter is based on the 25-MHz reference clock (40ns)
+ * It is a 29-bit counter, yielding a maximum counting duration of
+ * 2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
+ * it remains at this value until counter reset is triggered by setting
+ * bit 31 of KW_REG_SYSRST_CNT
+ */
+static void kw_sysrst_action(void)
+{
+#ifdef CONFIG_CMD_RUN
+ char cmd[BUFLEN];
+ char img[BUFLEN * 2];
+ char *argv[3];
+
+ if (getenv(sysrstcmd) == NULL) {
+ printf(Error.. %s failed, check sysrstcmd\n,
+ __FUNCTION__);
+ return;
+ }
+
+ printf(Starting %s process...\n, __FUNCTION__);
+ sprintf(cmd, run );
+ sprintf(img, sysrstcmd);
+ argv[0] = cmd;
+ argv[1] = img;
+ if ((do_run(NULL, 0, 2, argv)) != 0x0) {
+ printf(Error.. %s failed\n, __FUNCTION__);
+ } else {
+ printf(%s process finished\n, __FUNCTION__);
+ }
+#else/* CONFIG_CMD_RUN */
+ printf(Error.. %s needs run command support\n, __FUNCTION__);
+#endif /* CONFIG_CMD_RUN */
why not replace this by
char *s = getenv(sysrstcmd);
if (!s) {
printf(Error.. %s failed, check sysrstcmd\n,
__FUNCTION__);
return;
}
printf(Starting %s process...\n, __FUNCTION__);
#if !defined(CONFIG_SYS_HUSH_PARSER)
ret = run_command (s, 0);
#else
ret = parse_string_outer(s, FLAG_PARSE_SEMICOLON
| FLAG_EXIT_FROM_LOOP);
#endif
...
+}
+
+static void kw_sysrst_check(void)
+{
+ u32 sysrst_cnt, sysrst_dly;
+ char *s;
+
+ /*
+ * no action if sysrstdelay environment variable is not defined
+ */
+ s = getenv(sysrstdelay);
+ if (s == NULL)
+ return;
+
+ /* read sysrstdelay value */
+ sysrst_dly = (u32) simple_strtoul(s, NULL, 10);
+
+ /* read SysRst Length counter register (bits 28:0) */
+ sysrst_cnt = (0x1fff readl(KW_REG_SYSRST_CNT));
+ printf(H/w Rst hold time: %d.%d secs\n,
+ sysrst_cnt/SYSRST_CNT_1SEC_VAL,
+ sysrst_cnt%SYSRST_CNT_1SEC_VAL);
please add space before and after %/ etc..
+
+ /* clear the counter for next valid read*/
+ writel(1 31, KW_REG_SYSRST_CNT);
+
+ /*
+ * sysrst_action:
+ * if H/w Reset key is pressed and hold for time
+ * more than sysrst_dly in seconds
+ */
+ if (sysrst_cnt = SYSRST_CNT_1SEC_VAL * sysrst_dly)
+
Re: [U-Boot] [PATCH] Update the mtd driver name in bootargs for at91-based boards
On 18:30 Wed 22 Jul , Albin Tonnerre wrote: The name of the atmel nand driver in the kernel changed from at91_nand to atmel_nand back in June 2008, but the at91-based boards config files still refer to at91_nand. This patch updates them with the new name Signed-off-by: Albin Tonnerre albin.tonne...@free-electrons.com --- include/configs/at91cap9adk.h |4 ++-- include/configs/at91sam9260ek.h|6 +++--- include/configs/at91sam9261ek.h|6 +++--- include/configs/at91sam9263ek.h|4 ++-- include/configs/at91sam9m10g45ek.h |4 ++-- include/configs/at91sam9rlek.h |4 ++-- include/configs/pm9261.h |4 ++-- include/configs/pm9263.h |4 ++-- 8 files changed, 18 insertions(+), 18 deletions(-) I've recive a ack for the pm9263 recently so I apply this version Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Update the mtd driver name in bootargs for at91-based boards
On Tue, Aug 18, 2009 at 12:14:12AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote : I've recive a ack for the pm9263 recently so I apply this version Did you mean 9261 ? From your previous mail, I thought this was the one causing issues. Regards, -- Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support
Dear Jean-Christophe PLAGNIOL-VILLARD, In message 20090817220313.gk23...@game.jcrosoft.org you wrote: On 10:45 Tue 11 Aug , s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com This patch adds 4 BIT ecc support in the DaVinci NAND driver. Tested on both the DM355 and DM365. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- drivers/mtd/nand/davinci_nand.c | 290 +- include/asm-arm/arch-davinci/emif_defs.h | 10 + 2 files changed, 298 insertions(+), 2 deletions(-) Scoot is this ok for you? I guess you mean Scott here. if yes I'd like to apply it with the board udpate to my next You probably want to add him on cc: if you want his opinion. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Don't put off for tomorrow what you can do today, because if you enjoy it today you can do it again tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: Kirkwood: add SYSRSTn Duration Counter Support
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090817221152.gm23...@game.jcrosoft.org you wrote:
+ printf(Starting %s process...\n, __FUNCTION__);
+ sprintf(cmd, run );
+ sprintf(img, sysrstcmd);
+ argv[0] = cmd;
+ argv[1] = img;
+ if ((do_run(NULL, 0, 2, argv)) != 0x0) {
+ printf(Error.. %s failed\n, __FUNCTION__);
+ } else {
+ printf(%s process finished\n, __FUNCTION__);
+ }
+#else /* CONFIG_CMD_RUN */
+ printf(Error.. %s needs run command support\n, __FUNCTION__);
+#endif /* CONFIG_CMD_RUN */
why not replace this by
char *s = getenv(sysrstcmd);
if (!s) {
printf(Error.. %s failed, check sysrstcmd\n,
__FUNCTION__);
return;
}
printf(Starting %s process...\n, __FUNCTION__);
#if !defined(CONFIG_SYS_HUSH_PARSER)
ret = run_command (s, 0);
#else
ret = parse_string_outer(s, FLAG_PARSE_SEMICOLON
| FLAG_EXIT_FROM_LOOP);
#endif
Maybe because the original code does not need an #ifdef ?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
In the beginning there was nothing.
And the Lord said Let There Be Light!
And still there was nothing, but at least now you could see it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Update the mtd driver name in bootargs for at91-based boards
On 00:26 Tue 18 Aug , Albin Tonnerre wrote: On Tue, Aug 18, 2009 at 12:14:12AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote : I've recive a ack for the pm9263 recently so I apply this version Did you mean 9261 ? From your previous mail, I thought this was the one causing issues. yes a typo I've the ask for both Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Support for the Calao TNY-A9260/TNY-A9G20 boards
On 00:13 Tue 18 Aug , Albin Tonnerre wrote: On Mon, Aug 17, 2009 at 11:41:06PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote : + +#ifndef __CONFIG_H +#define __CONFIG_H + +#if defined(CONFIG_tny_a9260) || defined(CONFIG_tny_a9260_nandflash) || defined(CONFIG_tny_a9260_eeprom) too long and define must be upper case Those defines are generated directly from the target names in the Makfile, and are used for internal purposes only. Moving them to uppercase would mean changing the target names from tny_a9g20_nandflash to TNY_A9G20_NANDFLASH, while the existing Calao-provided BSP uses lowercase. I'd rather not change that. you make them uppercase before put them in the config.h Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AT91: Add support for blue_LED_* and add coloured_LED_init to at91/led.c
On 23:39 Wed 12 Aug , Albin Tonnerre wrote: On Wed, Aug 12, 2009 at 11:15:26PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote : On 18:10 Wed 12 Aug , Albin Tonnerre wrote: Currently, at91/led.c only provides _on and _off functions for green, yellow and red LEDs. This patch provides a generic coloured_LED_init function, which is a first step towards getting rid of the board-specific (and duplicated) board/*/*/led.c files on at91 This patch alos adds similar support for blue LEDs, mostly for the sake of completeness. we do need to stop adding more and more specific led api we do need to have a common api that we can use on any arch for c asm This does not *add* specific LED API, it merely implements the existing one. There /is/ a common led API, which currently has no support for ARM, as you probably know. Does you message mean you'd accept a patch which drops the coloured-LED API (whose only user is currently ARM) and use the one described in include/status_led.h ? no please take a look on the other LED thread I want to hape coloured-LED api and numbered led handle by the same api with the less size impact for c assembly Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: Kirkwood: add SYSRSTn Duration Counter Support
On 00:36 Tue 18 Aug , Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090817221152.gm23...@game.jcrosoft.org you wrote:
+ printf(Starting %s process...\n, __FUNCTION__);
+ sprintf(cmd, run );
+ sprintf(img, sysrstcmd);
+ argv[0] = cmd;
+ argv[1] = img;
+ if ((do_run(NULL, 0, 2, argv)) != 0x0) {
+ printf(Error.. %s failed\n, __FUNCTION__);
+ } else {
+ printf(%s process finished\n, __FUNCTION__);
+ }
+#else/* CONFIG_CMD_RUN */
+ printf(Error.. %s needs run command support\n, __FUNCTION__);
+#endif /* CONFIG_CMD_RUN */
why not replace this by
char *s = getenv(sysrstcmd);
if (!s) {
printf(Error.. %s failed, check sysrstcmd\n,
__FUNCTION__);
return;
}
printf(Starting %s process...\n, __FUNCTION__);
#if !defined(CONFIG_SYS_HUSH_PARSER)
ret = run_command (s, 0);
#else
ret = parse_string_outer(s, FLAG_PARSE_SEMICOLON
| FLAG_EXIT_FROM_LOOP);
#endif
Maybe because the original code does not need an #ifdef ?
but the size is bigger on the current implementation
and as we have this is other part of U-Boot we can add a inline to have the
ifdef at only one place
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Adding support for DevKit8000
This patch adds support for the DevKit8000 board. Signed-off-by: Frederik Kriewitz frede...@kriewitz.eu --- mach-types.h needs to be synced (MACH_TYPE_DEVKIT8000) --- MAINTAINERS |4 + Makefile|3 + board/omap3/devkit8000/Makefile | 52 + board/omap3/devkit8000/config.mk| 35 board/omap3/devkit8000/devkit8000.c | 124 board/omap3/devkit8000/devkit8000.h | 373 +++ doc/README.omap3| 11 + include/configs/omap3_devkit8000.h | 321 ++ 8 files changed, 923 insertions(+), 0 deletions(-) create mode 100644 board/omap3/devkit8000/Makefile create mode 100644 board/omap3/devkit8000/config.mk create mode 100644 board/omap3/devkit8000/devkit8000.c create mode 100644 board/omap3/devkit8000/devkit8000.h create mode 100644 include/configs/omap3_devkit8000.h diff --git a/MAINTAINERS b/MAINTAINERS index 620604c..12ad7f5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -706,6 +706,10 @@ Alex Z lartSA1100 dnp1110 SA1110 +Frederik Kriewitz frede...@kriewitz.eu + + omap3_devkit8000ARM CORTEX-A8 (OMAP3530 SoC) + - Unknown / orphaned boards: diff --git a/Makefile b/Makefile index 329e0f5..bed9f5e 100644 --- a/Makefile +++ b/Makefile @@ -3072,6 +3072,9 @@ omap3_beagle_config : unconfig omap3_overo_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 overo omap3 omap3 +omap3_devkit8000_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 devkit8000 omap3 omap3 + omap3_evm_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 evm omap3 omap3 diff --git a/board/omap3/devkit8000/Makefile b/board/omap3/devkit8000/Makefile new file mode 100644 index 000..38600c4 --- /dev/null +++ b/board/omap3/devkit8000/Makefile @@ -0,0 +1,52 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2009 +# Frederik Kriewitz frede...@kriewitz.eu +# +# 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 $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := devkit8000.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/omap3/devkit8000/config.mk b/board/omap3/devkit8000/config.mk new file mode 100644 index 000..6bfcef7 --- /dev/null +++ b/board/omap3/devkit8000/config.mk @@ -0,0 +1,35 @@ +# +# (C) Copyright 2006 +# Texas Instruments, www.ti.com +# +# (C) Copyright 2009 +# Frederik Kriewitz frede...@kriewitz.eu +# +# DevKit8000 uses OMAP3 (ARM-CortexA8) cpu +# see http://www.ti.com/ for more information on Texas Instruments +# +# 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 +# +# Physical Address: +# 8000' (bank0) +# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000 +# (mem base + reserved) + +# For use with external or internal boots. +TEXT_BASE = 0x80e8 diff
Re: [U-Boot] [PATCH 2/2] e1000: fix PCI memory addressing
On Aug 17, 2009, at 3:55 PM, Timur Tabi wrote: The Intel E1000 driver was making assumptions about the relationship between some virtual, physical, and PCI addresses. Also fix some bad usage of the DEBUGOUT macro Signed-off-by: Timur Tabi ti...@freescale.com --- drivers/net/e1000.c | 17 + 1 files changed, 9 insertions(+), 8 deletions(-) Acked-by: Kumar Gala ga...@kernel.crashing.org Note: This is related to the 85xx pull request I have for v2009.08. In testing e1000 w/out 36-bit address maps we ran into some issues addressed by this patch. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Where can I find some material about Xenomai/SOLO's usage and limit?
And is there any successful stories about Xenomai/SOLO? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM Pull Request
Hi, please pull The following changes since commit 7dedefdf749ff02c1086f7ddb8cb83a77b00d030: John Schmoller (1): flash: Fix CFI buffer size bug are available in the git repository at: git://git.denx.de/u-boot-arm.git master Albin Tonnerre (1): Update the mtd driver name in bootargs for at91-based boards Ben Goska (1): omap3: Fixed a problem with hwecc Wolfgang Denk (1): Monahans: avoid floating point calculations board/delta/nand.c |8 +--- board/zylonite/nand.c |8 +--- include/asm-arm/arch-omap3/cpu.h|4 ++-- include/asm-arm/arch-pxa/pxa-regs.h |2 +- include/configs/at91cap9adk.h |4 ++-- include/configs/at91sam9260ek.h |6 +++--- include/configs/at91sam9261ek.h |6 +++--- include/configs/at91sam9263ek.h |4 ++-- include/configs/at91sam9m10g45ek.h |4 ++-- include/configs/at91sam9rlek.h |4 ++-- include/configs/pm9261.h|4 ++-- include/configs/pm9263.h|4 ++-- 12 files changed, 31 insertions(+), 27 deletions(-) Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support
On Tue, Aug 11, 2009 at 10:45:05AM -0400, s-paul...@ti.com wrote:
+static void nand_davinci_4bit_enable_hwecc(struct mtd_info *mtd, int mode)
+{
+ u32 val;
+
+ switch (mode) {
+ case NAND_ECC_WRITE:
+ case NAND_ECC_READ:
+ /*
+ * Start a new ECC calculation for reading or writing 512 bytes
+ * of data.
+ */
+ val = (emif_regs-NANDFCR ~(3 4)) | (1 12);
+ emif_regs-NANDFCR = val;
+ break;
+ case NAND_ECC_READSYN:
+ val = emif_regs-NAND4BITECC1;
Use I/O accessors.
+ for (i = 0; i 100; i++)
+ udelay(this-chip_delay);
No explanation for the delay? Is there any status register you can poll?
Is it truly 100 times the chip delay (even if that changes), or is it a
fixed delay that just happens to work out to that?
+static int nand_davinci_4bit_correct_data(struct mtd_info *mtd, uint8_t *dat,
+ uint8_t *read_ecc, uint8_t *calc_ecc)
+{
+ return nand_davinci_4bit_compare_ecc(mtd, read_ecc, dat);
+}
Why have a wrapper? This seems to be the only place where compare_ecc is
used.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support
On Tue, Aug 18, 2009 at 12:03:13AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: On 10:45 Tue 11 Aug , s-paul...@ti.com wrote: From: Sandeep Paulraj s-paul...@ti.com This patch adds 4 BIT ecc support in the DaVinci NAND driver. Tested on both the DM355 and DM365. Signed-off-by: Sandeep Paulraj s-paul...@ti.com --- drivers/mtd/nand/davinci_nand.c | 290 +- include/asm-arm/arch-davinci/emif_defs.h | 10 + 2 files changed, 298 insertions(+), 2 deletions(-) Scoot is this ok for you? if yes I'd like to apply it with the board udpate to my next It won't build without a change destined for my next branch (NAND_ECC_HW_OOB_FIRST). Does it depend on anything in your next that isn't in Wolfgang's next? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v4] arm: A320: Add support for Faraday A320 evaluation board
Dear Jean-Christophe PLAGNIOL-VILLARD, 2009/8/18 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com: On 14:13 Thu 06 Aug , Po-Yu Chuang wrote: Anyway, I have an idea now. I can submit a version that do not do the bank swap (SDRAM stays at 0x1000). The the mainline keeps beautiful as you wish. Then I create another patch to do the bank swap for our internal use. This should be a win-win. :-) why not but show us the code please and we will see I have submitted a v5 patch. Please check. best regards, Po-Yu Chuang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] License Problems for standalone application at u-boot
Dear Wolfgang Denk,
On Mon, 2009-08-17 at 10:03 +0200, Wolfgang Denk wrote:
Dear Peter Chen,
In message 1250474437.13885.23.ca...@nchen-desktop you wrote:
1. Does jump table means the function lists which the standalone
applications uses?
The jump table provided by U-Boot exactly for this purpose is the
list of functions exported through the include/_exports.h header
file.
At my situation, the standalone program is hardware independent.
And the u-boot supplies hardware interfaces according to different
platforms.
Like at u-boot/board/myboard/myboard.c, there are a function lists
struct, and the address
of this struct will transfer to standalone program.
If you set up your own list of function pointers (in addition or
instead of the jump table provided by the include/_exports.h
header), then this is a form of linking against the U-Boot code, and
your application must be released under GPL.
I am sorry, I can't understand your meaning. For example, at
include/_exports.h
there is an EXPORT_FUNC(printf), do the standalone application must
under GPL if
it uses printf?
Then, what does include/_exports.h use?
In your COPYING, it writes:
NOTE! This copyright does *not* cover the so-called standalone
applications that use U-Boot services by means of the jump table
provided by U-Boot exactly for this purpose - this is merely
considered normal use of U-Boot, and does *not* fall under the
heading of derived work.
Is it free to license at below situation:
The function list which is defined at u-boot/board/myboard/myboard.c,
and all functions in this list
only uses functions at include/_exports.h and some of user-defined
functions.
Your description is really vague; it would be easier if you could
give specific code examples or such. If some of user-defined
functions refers to code that is covered by the GPL, then your
application must be released under GPL, too.
My code like belows:
typedef void (*pfn_t) (void);
pfn_t sc_gps_pfn[] = {
LoadToMemory,
SaveData,
RFPowerCtrl,
MiscConfig,
RegisterDspInterruptHandler,
GetPowerStatus,
IsUserResume,
DebugOutput,
ReturnToBootLoader
};
int LoadToMemory(void *pDestination, unsigned int storeID, unsigned int
size)
{
}
int SaveData(unsigned int storeID, void *pSource, unsigned int size)
{}
int RegisterDspInterruptHandler(unsigned int handler)
{
gps_intr = (pfn_t) handler;
return 1;
}
extern void ReturnToBootLoader(unsigned int nextRtcAlarmParam); /* which
is defined at *.S file */
...
int Launch()
{
Launch_apps(sc_gps_pfn, jumpaddr); /* Launch_apps is defined at *.S
file, and it just jumps to VMA of standalone application, sc_gps_pfn is
the address for function list */
}
We want to open this code, but want to close the code which use this
function list in binary pattern.
Or Need I to export my functions at include/_exports.h? At my standalone
application only uses address of
functions at function list, not the name of function, so It doesn't need
to include include_exports.h.
What you implement is some form of static linking.
... which technically is a stupid thing to do, as your application
will only be able to run with a very specific binary image of U-Boot.
Even rebuilding the same version of U-Boot (jut using a different
tool chain, for example) will most likely result in a U-Boot image
that cannot run your application code any more. Even worse, ther
ewill be not even a clear failure mode, instead you will execute
random code.
The standalone application is compiled by armcc, and this bin file is
shared by WinCE and Linux bootloader.
The standalone application uses bootloader functions by address not by
name.
We would like to release our u-boot under GPL, but standalone
Actually you have no choice; U-Boot is already covered by the GPL -
as soon as you distribute the code, you also have to fufil the
resulting requirements of the GPL.
application includes some IP properties code, so
we want to close it.
This is no problem, as long as you strictly follow the rules. I think
the exception from the GPL is pretty well defined and leaves not much
room for interpretation. What you describe sounds fishy to me.
Best regards,
Wolfgang Denk
Best Regards,
Peter Chen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
