Re: [U-Boot] RFC: make DESTDIR=xxx install ?
Dear Ulf Samuelsson, In message 4a864121@atmel.com you wrote: I think the open source community has converged on the make DESTDIR=dir install method $ cd linux $ make at91rm9200dk_defconfig $ make uImage $ mkdir /tmp/foo $ mkdir DESTDIR=/tmp/foo install ... CHK include/linux/compile.h Kernel: arch/arm/boot/Image is ready /bin/sh /home/wd/git/linux/work/arch/arm/boot/install.sh 2.6.30-rc8-01295-g06b727a \ arch/arm/boot/Image System.map /boot Installing normal kernel /home/wd/git/linux/work/arch/arm/boot/install.sh: line 40: /boot/vmlinux-2.6.30-rc8-01295-g06b727a: Permission denied cp: cannot create regular file `/boot/System.map-2.6.30-rc8-01295-g06b727a': Permission denied You have to install it yourself Hmmm... doesn't seem to ork for me. The important thing is however that the solution is Important for what? 1) INSIDE the U-Boot tree 2) Designed to be stable, even if U-Boot evolves. 3) Documented so it is easy to use. So far you seem to be the only person who needs this. If your proposal is that the wrapper script is outside u-boot, then this is nothing new. This is how it is done today, Having wrapper scripts to an unstable interface is an accident waiting to happen. Could you please explain which part of this has been an unstable interface? As far as I can tell PPCBoot / ARMBoot / U-Boot have always created the final binary image as you called it in the top level directory, and also it's name has never changed. So what exactly is unstable here? You have a unique position as the maintainer of U-Boot. I don't. The U-Boot project is driven by a community. If a clear majority of voices requests something I would have hard times to make my way. You know immediately when your scripts needs to be updated. Fact is that I am using some scripts that are 10 years old now, and there has never been need to change them because of changes in the PPCBoot/ARMBoot/U-Boot interface - not even when ARMBoot was forked from PPCBoot, nor when PPCBoot and ARMBoot were merged back into U-Boot. People working on a build environment does not neccessarily have that knowledge, and if not, will run into trouble, or rather their customers might. Maybe I misunderstand you and you propose that the build-script should be inside the tree. Please clarify! I still fail to understand which sort of trouble you are talking about. BTW: the usual way to suggest code changes is to submit a patch as RFC. If your code looks clean and works fine across architectures, with and without out-of-tree builds, and if it includes some documentation I see little reason to reject it. Our general policy has always been to accept stuff that is technically clean, when it is useful to at least some, as long as it doesn't hurt all the others. 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 programming was easy, they wouldn't need something as complicated as a human being to do it, now would they? - L. Wall R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: kirkwood: updates: used eth_setenv_enetaddr api
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Mike Frysinger
Sent: Thursday, August 13, 2009 10:47 AM
To: u-boot@lists.denx.de
Cc: Ashish Karkare; Prabhanjan Sarnaik; Ben Warren
Subject: Re: [U-Boot] [PATCH] net: kirkwood: updates: used
eth_setenv_enetaddr api
On Friday 07 August 2009 17:37:51 Ben Warren wrote:
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 22:17 Fri 07 Aug , Prafulla Wadaskar wrote:
eth_setenv_enetaddr is avaible by upper layer using this
saves 204
bytes on total image size
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
drivers/net/kirkwood_egiga.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/kirkwood_egiga.c
b/drivers/net/kirkwood_egiga.c index 3d908f8..1a208f2 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -606,7 +606,7 @@ int kirkwood_egiga_initialize(bd_t * bis)
struct kwgbe_device *dkwgbe;
struct eth_device *dev;
int devnum;
-char *s, buf[NAMESIZE * 2];
+char *s;
u8 used_ports[MAX_KWGBE_DEVS] =
CONFIG_KIRKWOOD_EGIGA_PORTS;
for (devnum = 0; devnum MAX_KWGBE_DEVS;
devnum++) { @@ -665,10
+665,13 @@ int kirkwood_egiga_initialize(bd_t * bis)
while (!eth_getenv_enetaddr(s, dev-enetaddr)) {
/* Generate Ramdom MAC
addresses if not set */
-sprintf(buf, 00:50:43:%02x:%02x:%02x,
-get_random_hex(),
get_random_hex(),
-get_random_hex());
-setenv(s, buf);
+dev-enetaddr[0] = 0x00;
+dev-enetaddr[1] = 0x50;
+dev-enetaddr[2] = 0x43;
+dev-enetaddr[3] = get_random_hex();
+dev-enetaddr[4] = get_random_hex();
+dev-enetaddr[5] = get_random_hex();
+eth_setenv_enetaddr(s, dev-enetaddr);
it will be also good to use a private mac address
dev-enetaddr[0] = 0x02;
Full ACK. If you're generating something random, it MUST have the
private bit. Unless Marvell owns this block and is giving
it away and
is keeping track of all used numbers and ...
really we should add a new common eth function that generates
a random local mac address ... and have each arch implement a
random function. you can see the one i use for Blackfin
systems in asm-blackfin/net.h ...
Good Idea,
I hope each arch will have support to generate random values :-)
Regards..
Prafulla . .
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: make DESTDIR=xxx install ?
Dear Ulf Samuelsson, In message 4a86814f.1070...@atmel.com you wrote: The important thing is however that the solution is Important for what? To avoid that external build systems break if anything changes in u-boot. I don;t see any risk of such breakage, because U-Boot does not exactly have a tradition to change these things avery few weeks. Could you please explain which part of this has been an unstable interface? As far as I can tell PPCBoot / ARMBoot / U-Boot have always created the final binary image as you called it in the top level directory, and also it's name has never changed. So what exactly is unstable here? You mentioned yourself that Marvell want to have something different than u-boot.bin New features get added, indeed. But this does not count here - we were discussing stability of existing interfaces, and these haven't changed. I don't. The U-Boot project is driven by a community. If a clear majority of voices requests something I would have hard times to make my way. I am not talking about decisions, I am talking about you not running into problems, if anything changes, because you know it by heart. Well, if there would be changes to any install interface you had to know about these as well. Fact is that I am using some scripts that are 10 years old now, and there has never been need to change them because of changes in the PPCBoot/ARMBoot/U-Boot interface - not even when ARMBoot was forked from PPCBoot, nor when PPCBoot and ARMBoot were merged back into U-Boot. ... You say that you did not write any new buildscripts which did not copy anything except u-boot.bin? No, I didn't day that. Don't twist my words. I wrote that I did not have to change existing scripts because existing interfaces never changed. And that was what you complained about: the rist that existing interfaces might change below your feet. 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 Unix: Some say the learning curve is steep, but you only have to climb it once. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Incorrect memtest range on MPC8536DS
Hi, Wolfgang Wolfgang Denk wrote: Dear Felix Radensky, In message 4a843b9b.2000...@embedded-sol.com you wrote: Hi, If run without arguments, mtest hangs on MPC8536DS. I guess this is because of the following definitions: #define CONFIG_SYS_MEMTEST_START0x #define CONFIG_SYS_MEMTEST_END0x7fff I was able to successfully run mtest on 0x0010 - 0x1000. What is the largest safe range for this platform ? It depends on RAM size and stack usage. Usually 1 or 2 MB below stack base is safe enough. Thanks for clarifying. This platform has 512MB of RAM. The stack pointer is at 0x1fe2df48. Test works fine with upper limit set to 0x1fd2df48. For some reason I cannot set lower limit to 0x. The lowest working address is 0x0a98. At 0x0a97 the test hangs, and at 0x0a96 I get the following crash: IP: 1FF3 XER: 2000 LR: 1FF3 REGS: 1fe2dbd0 TRAP: 0700 DAR: MSR: 1000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 1FF3 1FE2DCC0 1FE2DF64 1FE2DCD0 0001 000C GPR08: 1FF99715 398C 1FFB0120 48022084 5E36E3C4 1FFA9F00 GPR16: 1FF54880 1FF96508 1FF996F8 1000 1FE2DCC0 1FF3 GPR24: 1FF33AE8 0A96 0001 1FD2DF48 1FE35648 1FFAABE0 0003 ** Illegal Instruction ** Call backtrace: 1FF3 1FF4A524 1FF56924 1FF5600C 1FF5618C 1FF58CEC 1FF33748 1FF315FC Program Check Exception ### ERROR ### Please RESET the board ### The faulting address (0x1FF3) seems to be the relocation address, as the following debug messages indicate: Top of RAM usable for U-Boot at: 2000 Reserving 805k for U-Boot at: 1ff3 Reserving 1032k for malloc() at: 1fe2e000 Reserving 80 Bytes for Board Info at: 1fe2dfb0 Reserving 76 Bytes for Global Data at: 1fe2df64 Stack Pointer at: 1fe2df48 New Stack Pointer is: 1fe2df48 Now running in RAM - U-Boot at: 1ff3 Can you (or Kumar) please explain what's going on here ? Thanks a lot. Felix. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Incorrect memtest range on MPC8536DS
Dear Felix Radensky, In message 4a869531.2090...@embedded-sol.com you wrote: Thanks for clarifying. This platform has 512MB of RAM. The stack pointer is at 0x1fe2df48. Test works fine with upper limit set to 0x1fd2df48. I recommend to set CONFIG_SYS_MEMTEST_END to 0x1F00, then. For some reason I cannot set lower limit to 0x. The lowest working address is 0x0a98. At 0x0a97 the test hangs, and at 0x0a96 I get the following crash: Indeed. The exception vectors are located there, and as soon as you overwrite these the next timer interrupt will crash your system. Can you (or Kumar) please explain what's going on here ? Set CONFIG_SYS_MEMTEST_START to 0x001 or so. 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 only perfect science is hind-sight. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add ability for arch code to make changes before we boot
On 15:45 Fri 14 Aug , Kumar Gala wrote:
On Aug 14, 2009, at 3:13 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 14:00 Fri 14 Aug , Kumar Gala wrote:
Added a arch_preboot() function that cpu specific code can
implement to
allow for various modifications to the state of the machine
right before
we boot. This can be useful to setup register state to a specific
configuration.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
common/cmd_bootm.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 86c8122..766889a 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -166,6 +166,13 @@ void __arch_lmb_reserve(struct lmb *lmb)
}
void arch_lmb_reserve(struct lmb *lmb) __attribute__((weak,
alias(__arch_lmb_reserve)));
+/* Allow for arch specific config before we boot */
+void __arch_preboot(void)
+{
+ /* please define platform specific arch_preboot() */
+}
+void arch_preboot(void) __attribute__((weak,
alias(__arch_preboot)));
+
why not a section so you will be able to have multiple callback so
it can be
arch or soc or board too in any combination
Because the use I have for it is a simple single case at this point.
If and when we need more complexity we can add it.
we have already it
as example the usb drivers that need to be stop before start an os
I forget some but I'm sure to have seen oher
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP DIE_ID
On 16:24 Fri 14 Aug , Frederik Kriewitz wrote: I'm a bit confused about the u-boot code which reads the OMAP die id. From the OMAP TRM: CONTROL.CONTROL_DIE_ID[127:0] Address: 0x4830A218 Size: 128 u-boot code: http://gitorious.org/u-boot-omap3/mainline/blobs/master/cpu/arm_cortexa8/omap3/sys_info.c#line44 result: Die ID #: 04ba0054 0020 0401463b 0401c214 Memory Dump: 4830a218: 0401c214 0401463b 0020 04ba0054 Shouldn't u-boot read/show the die id the other way around (just as in the memory dump)? Please just tell me that I'm wrong :) Honnesty it's not really important the order except you have a special need it's really a personnal preference NB: until someone give us a good reason to change we will keep it this way Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: DaVinci: DaVinci DM365 SOC specific code
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
diff --git a/cpu/arm926ejs/davinci/Makefile b/cpu/arm926ejs/davinci/Makefile
index e45ad25..7501a85 100644
--- a/cpu/arm926ejs/davinci/Makefile
+++ b/cpu/arm926ejs/davinci/Makefile
@@ -29,6 +29,7 @@ LIB = $(obj)lib$(SOC).a
COBJS-y+= cpu.o timer.o psc.o
COBJS-$(CONFIG_SOC_DM355) += dm355.o
+COBJS-$(CONFIG_SOC_DM365) += dm365.o
COBJS-$(CONFIG_SOC_DM644X) += dm644x.o
COBJS-$(CONFIG_DRIVER_TI_EMAC) += lxt972.o dp83848.o
diff --git a/cpu/arm926ejs/davinci/dm365.c b/cpu/arm926ejs/davinci/dm365.c
new file mode 100644
index 000..56c1bc0
--- /dev/null
+++ b/cpu/arm926ejs/davinci/dm365.c
@@ -0,0 +1,35 @@
+/*
+ * SoC-specific code for tms320dm365 and similar chips
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include common.h
+#include asm/arch/hardware.h
+
+void davinci_enable_uart0(void)
+{
+ lpsc_on(DAVINCI_LPSC_UART0);
+}
+
+#ifdef CONFIG_DRIVER_DAVINCI_I2C
+void davinci_enable_i2c(void)
+{
+ lpsc_on(DAVINCI_LPSC_I2C);
+}
+#endif
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: DaVinci: Adding Support for DaVinci DM365 EVM
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
diff --git a/Makefile b/Makefile
index 329e0f5..959e857 100644
--- a/Makefile
+++ b/Makefile
@@ -2879,6 +2879,9 @@ davinci_sonata_config : unconfig
davinci_dm355evm_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm926ejs dm355evm davinci davinci
+davinci_dm365evm_config : unconfig
+ @$(MKCONFIG) $(@:_config=) arm arm926ejs dm365evm davinci davinci
+
lpd7a400_config \
lpd7a404_config: unconfig
@$(MKCONFIG) $(@:_config=) arm lh7a40x lpd7a40x
diff --git a/board/davinci/dm365evm/Makefile b/board/davinci/dm365evm/Makefile
new file mode 100644
index 000..26b0705
--- /dev/null
+++ b/board/davinci/dm365evm/Makefile
@@ -0,0 +1,52 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+#
+# 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 := $(BOARD).o
+SOBJS :=
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+# This is for $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/davinci/dm365evm/config.mk b/board/davinci/dm365evm/config.mk
new file mode 100644
index 000..86472ff
--- /dev/null
+++ b/board/davinci/dm365evm/config.mk
@@ -0,0 +1,11 @@
+#
+# Spectrum Digital DM365 EVM board
+# DM365 EVM board has 1 bank of 128 MB DDR RAM
+# Physical Address: 8000' to 8800'
+#
+# Linux Kernel is expected to be at 8000'8000, entry 8000'8000
+# (mem base + reserved)
+#
+
+#Provide at least 16MB spacing between us and the Linux Kernel image
+TEXT_BASE = 0x8108
diff --git a/board/davinci/dm365evm/dm365evm.c
b/board/davinci/dm365evm/dm365evm.c
new file mode 100644
index 000..e30184b
--- /dev/null
+++ b/board/davinci/dm365evm/dm365evm.c
@@ -0,0 +1,60 @@
+/*
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include common.h
+#include nand.h
+#include linux/io.h
+#include asm/arch/hardware.h
+#include asm/arch/emif_defs.h
+#include asm/arch/nand_defs.h
+#include ../common/misc.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ gd-bd-bi_arch_number = MACH_TYPE_DAVINCI_DM365_EVM;
+ gd-bd-bi_boot_params = PHYS_SDRAM_1 + 0x100;
+
+ return 0;
+}
+
+#ifdef CONFIG_NAND_DAVINCI
+static void nand_dm365evm_select_chip(struct mtd_info *mtd, int chip)
+{
+ struct nand_chip*this = mtd-priv;
+
Re: [U-Boot] OMAP DIE_ID
On 17:02 Sat 15 Aug , Frederik Kriewitz wrote: On Sat, Aug 15, 2009 at 4:35 PM, Jean-Christophe PLAGNIOL-VILLARDplagn...@jcrosoft.com wrote: Honnesty it's not really important the order except you have a special need it's really a personnal preference I intent to use some bytes of the die id as MAC address. So I'm interested in the bytes which change often. for private mac address or public? for public you may need to remember that you are supposed to trac all of them and do not loose any of them if you want to be able to buy a new lot of mac address IIRC the term of sell Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP DIE_ID
On Sat, Aug 15, 2009 at 6:12 PM, Jean-Christophe PLAGNIOL-VILLARDplagn...@jcrosoft.com wrote: I intent to use some bytes of the die id as MAC address. So I'm interested in the bytes which change often. for private mac address or public? for public you may need to remember that you are supposed to trac all of them and do not loose any of them if you want to be able to buy a new lot of mac address private of course. I didn't develop the hardware. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] CONFIG_CMDLINE_EDITING breaks CONFIG_SYS_CBSIZE
Hello, I noticed that enabling CONFIG_CMDLINE_EDITING breaks CONFIG_SYS_CBSIZE. Once CONFIG_CMDLINE_EDITING is enabled, it's not possible to enter more than 256 characters (CONFIG_SYS_CBSIZE is ignored). Probably related to #define MAX_CMDBUF_SIZE 256 in common/main.c I guess replacing MAX_CMDBUF_SIZE with CONFIG_SYS_CBSIZE might help. At the moment I don't have the time to check the code. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] tools: mkimage: Fixed build warnings
uninitialized retval variable warning fixed
crc32 APIs moved to crc.h (newly added) and build warnings fixed
some indentation tabs fixed
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log:
v2: updated as per review feedback for v1
include/common.h |4 +---
include/u-boot/crc.h | 33 +
tools/mkimage.c | 20 +++-
3 files changed, 45 insertions(+), 12 deletions(-)
create mode 100644 include/u-boot/crc.h
diff --git a/include/common.h b/include/common.h
index a6922fd..c0db3ff 100644
--- a/include/common.h
+++ b/include/common.h
@@ -622,9 +622,7 @@ int vsprintf(char *buf, const char *fmt, va_list args);
char * strmhz(char *buf, long hz);
/* lib_generic/crc32.c */
-uint32_t crc32 (uint32_t, const unsigned char *, uint);
-uint32_t crc32_wd (uint32_t, const unsigned char *, uint, uint);
-uint32_t crc32_no_comp (uint32_t, const unsigned char *, uint);
+#include u-boot/crc.h
/* common/console.c */
intconsole_init_f(void); /* Before relocation; uses the serial stuff
*/
diff --git a/include/u-boot/crc.h b/include/u-boot/crc.h
new file mode 100644
index 000..61bce67
--- /dev/null
+++ b/include/u-boot/crc.h
@@ -0,0 +1,33 @@
+/*
+ * (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
+ */
+
+#ifndef _UBOOT_CRC_H
+#define _UBOOT_CRC_H
+
+/* lib_generic/crc32.c */
+uint32_t crc32 (uint32_t, const unsigned char *, uint);
+uint32_t crc32_wd (uint32_t, const unsigned char *, uint, uint);
+uint32_t crc32_no_comp (uint32_t, const unsigned char *, uint);
+
+#endif /* _UBOOT_CRC_H */
diff --git a/tools/mkimage.c b/tools/mkimage.c
index dc42924..0cd16dd 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -24,8 +24,8 @@
#include mkimage.h
#include image.h
+#include u-boot/crc.h
-extern unsigned long crc32 (unsigned long crc, const char *buf, unsigned int
len);
static voidcopy_file (int, const char *, int);
static voidusage (void);
static int image_verify_header (char *, int);
@@ -60,7 +60,7 @@ main (int argc, char **argv)
struct stat sbuf;
unsigned char *ptr;
char *name = ;
- int retval;
+ int retval = 0;
cmdname = *argv;
@@ -334,9 +334,10 @@ NXTARG:;
hdr = (image_header_t *)ptr;
checksum = crc32 (0,
- (const char *)(ptr + image_get_header_size ()),
- sbuf.st_size - image_get_header_size ()
-);
+ (const unsigned char *)(ptr +
+ image_get_header_size ()),
+ sbuf.st_size - image_get_header_size ()
+ );
/* Build new header */
image_set_magic (hdr, IH_MAGIC);
@@ -352,7 +353,8 @@ NXTARG: ;
image_set_name (hdr, name);
- checksum = crc32 (0, (const char *)hdr, image_get_header_size ());
+ checksum = crc32 (0, (const unsigned char *)hdr,
+ image_get_header_size ());
image_set_hcrc (hdr, checksum);
@@ -485,7 +487,7 @@ static int
image_verify_header (char *ptr, int image_size)
{
int len;
- char *data;
+ const unsigned char *data;
uint32_t checksum;
image_header_t header;
image_header_t *hdr = header;
@@ -504,7 +506,7 @@ image_verify_header (char *ptr, int image_size)
return -FDT_ERR_BADMAGIC;
}
- data = (char *)hdr;
+ data = (const unsigned char *)hdr;
len = sizeof(image_header_t);
checksum = be32_to_cpu(hdr-ih_hcrc);
@@ -517,7 +519,7 @@ image_verify_header (char *ptr, int image_size)
return -FDT_ERR_BADSTATE;
}
- data = ptr + sizeof(image_header_t);
+ data = (const unsigned char *)ptr + sizeof(image_header_t);
len = image_size - sizeof(image_header_t) ;
if (crc32 (0, data, len) != be32_to_cpu(hdr-ih_dcrc)) {
--
1.5.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
[U-Boot] [PATCH 2/2] tools: mkimage: split code into core, default and FIT image specific
This is first step towards cleaning mkimage code for kwbimage
support in clean way. Current mkimage code is very specific to
uimg generation whereas the same framework can be used to
generate other image types like Kirkwood boot image (kwbimage-TBD).
For this, the architecture of mkimage code need to modified.
Here is the brief plan for the same:-
a) Split mkimage code into core and image specific support
b) Implement callback function for image specific functions
c) Move image type specific code to respective c files
Currently there are two types of file generation/list
supported (i.e uimg, FIT), the code is abstracted from
mkimage.c/h and put in default_image.c and fit_image.c
all code in these file is static except init function call
d) mkimage_register API is added to add new image type support
All above is addressed in this patch
e) Add kwbimage type support to this new framework (TBD)
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
tools/Makefile|9 +-
tools/default_image.c | 149 ++
tools/fit_image.c | 212 +++
tools/mkimage.c | 539 +++--
tools/mkimage.h | 101 +-
5 files changed, 720 insertions(+), 290 deletions(-)
create mode 100644 tools/default_image.c
create mode 100644 tools/fit_image.c
diff --git a/tools/Makefile b/tools/Makefile
index 7036b34..10b36f2 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -177,7 +177,8 @@ $(obj)inca-swap-bytes$(SFX):$(obj)inca-swap-bytes.o
$(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^
$(STRIP) $@
-$(obj)mkimage$(SFX): $(obj)crc32.o $(obj)mkimage.o $(obj)image.o $(obj)md5.o
$(obj)mkimage.o \
+$(obj)mkimage$(SFX): $(obj)crc32.o $(obj)default_image.o $(obj)fit_image.o
$(obj)image.o \
+ $(obj)md5.o $(obj)mkimage.o \
$(obj)os_support.o $(obj)sha1.o $(LIBFDT_OBJS)
$(CC) $(CFLAGS) $(HOST_LDFLAGS) -o $@ $^
$(STRIP) $@
@@ -190,6 +191,12 @@ $(obj)ubsha1$(SFX):$(obj)os_support.o $(obj)sha1.o
$(obj)ubsha1.o
$(CC) $(CFLAGS) -o $@ $^
# Some files complain if compiled with -pedantic, use FIT_CFLAGS
+$(obj)default_image.o: $(SRCTREE)/tools/default_image.c
+ $(CC) -g $(FIT_CFLAGS) -c -o $@ $
+
+$(obj)fit_image.o: $(SRCTREE)/tools/fit_image.c
+ $(CC) -g $(FIT_CFLAGS) -c -o $@ $
+
$(obj)image.o: $(SRCTREE)/common/image.c
$(CC) -g $(FIT_CFLAGS) -c -o $@ $
diff --git a/tools/default_image.c b/tools/default_image.c
new file mode 100644
index 000..50dd2e6
--- /dev/null
+++ b/tools/default_image.c
@@ -0,0 +1,149 @@
+/*
+ * (C) Copyright 2008 Semihalf
+ *
+ * (C) Copyright 2000-2004
+ * DENX Software Engineering
+ * Wolfgang Denk, w...@denx.de
+ *
+ * Updated-by: Prafulla Wadaskar prafu...@marvell.com
+ * default_image specific code abstracted from mkimage.c
+ * some functions added to address abstraction
+ *
+ * All rights reserved.
+ *
+ * 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 mkimage.h
+#include image.h
+#include u-boot/crc.h
+
+static image_header_t header;
+
+static int image_check_image_types (uint8_t type)
+{
+ if ((type IH_TYPE_INVALID) (type IH_TYPE_FLATDT))
+ return EXIT_SUCCESS;
+ else
+ return EXIT_FAILURE;
+}
+
+static int image_check_params (struct mkimage_params *params)
+{
+ return ((params-dflag (params-fflag || params-lflag)) ||
+ (params-fflag (params-dflag || params-lflag)) ||
+ (params-lflag (params-dflag || params-fflag)));
+}
+
+static int image_verify_header (unsigned char *ptr, int image_size,
+ struct mkimage_params *params)
+{
+ uint32_t len;
+ const unsigned char *data;
+ uint32_t checksum;
+ image_header_t header;
+ image_header_t *hdr = header;
+
+ /*
+* create copy of header so that we can blank out the
+* checksum field for checking - this can't be done
+* on the PROT_READ mapped data.
+*/
+ memcpy (hdr, ptr, sizeof(image_header_t));
+
+ if (be32_to_cpu(hdr-ih_magic) != IH_MAGIC) {
+ fprintf (stderr,
+ %s: Bad Magic Number: \%s\ is no
Re: [U-Boot] [PATCH] Fix all linker script to handle all rodata sections
Dear Trent Piepho, on Mon, 10 Aug 2009 10:35:08 +0200 I wrote: Dear Trent Piepho, In message 1234999325-13456-1-git-send-email-tpie...@freescale.com you wrote: A recent gcc added a new unaligned rodata section called '.rodata.str1.1', which needs to be added the the linker script. Instead of just adding this one section, we use a wildcard .rodata* to get all rodata linker section gcc has now and might add in the future. ... 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? Thanks in advance. Any comments on this? Or anybody else? 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 Each honest calling, each walk of life, has its own elite, its own aristocracy based on excellence of performance. - James Bryant Conant ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] davinci_emac.c:*: warning: duplicate `volatile'
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. 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 Drawing on my fine command of language, I said nothing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Incorrect board init with 256M RAM on MX31
Hi All, When i use 128M in my board configuration and pass the same to he kernel using bd_info , the linux kernel just boots up fine. But when i change the config to put 256M which is the actual physical DDR size on our board, the userspace crashes because of a unhandled page fault via Unable to handle kernel NULL pointer dereference. First off, perhaps the U-boot is not initializing the memory properly. Although i thought, the board specific dram_init does it with the correct config params picked up from the board config file. I change the following in the board specific config: #define CONFIG_NR_DRAM_BANKS2 #define PHYS_SDRAM_1CSD0_BASE #define PHYS_SDRAM_1_SIZE (256 * 1024 * 1024) What else does the uboot need to convey to the kernel. I am using Freescale MX31 board. Any hints/clues? Thanks in advance for your help. -Alfred. ___ 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: OK, I'll try to fix it tomorrow or Monday, very busy right now... 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. 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 Drawing on my fine command of language, I said nothing. --- ** * 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
