Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
Dear Wolfgang, On 2010-11-15 08:51:29, Wolfgang Denk wrote: In message 20101110080708.ga8...@safe.home.local you wrote: Good suggestion, done in v3: I have to admit that I lost a bit of overview of the current state of this work. My understanding is that you are preparing a new version (V4 ?) of this patch? If yes, do you have any estimates when this will be available? I just uploaded the revised patch here: http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-libraries-to-partial-linking-v4.patch Version 4: Bring in Linux comment for cmd_link_o_target. Fix drivers/qe/Makefile to build libqe.o, not qe.o. I pulled the latest changes before making the patch and there was no conflict, but please let me know if you see anything wrong with it. -- Sébastien ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
Wolfgang Denk wrote: For now, I would like to ask all CUSTODIANS to register as users at patchwork.ozlabs.org, so we can arrange that the appropriate privileges will be granted to you. Registered as daniel Regards, Daniel Hellstrom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2][NEXT] Davinci: add support for the ea20 board
On 11/15/2010 08:36 AM, Sughosh Ganu wrote: hi Stefano, Hi, I had sent a patch some time back to move the misc.h under arm/include/asm/arch-davinci/davinci_misc.h. Should this patch be based off of that. [PATCH 1/3 V5] Move and rename common headers from under board/davinci. Thanks, I have not seen your patch. I rebase mine on top of yours. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3][NEXT] Davinci: add support for the ea20 board
This board uses the OMAP-L138 SOM stacked on a
custom baseboard. It supports SPI Flash, Ethernet
with RMII.
Signed-off-by: Stefano Babic sba...@denx.de
---
Changes since V2:
- Rebased on the following patch(Sughosh Ganu):
Sughosh Ganu: Move and rename common headers from under board/davinci
This patch requires also the patch for RMII:
Ben Gardiner: da850evm: Add RMII support for EMAC
MAINTAINERS |1 +
board/davinci/ea20/Makefile | 53 ++
board/davinci/ea20/ea20.c | 237 +++
boards.cfg |1 +
include/configs/ea20.h | 214 ++
5 files changed, 506 insertions(+), 0 deletions(-)
create mode 100644 board/davinci/ea20/Makefile
create mode 100644 board/davinci/ea20/ea20.c
create mode 100644 include/configs/ea20.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 9258cb1..386a7b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -551,6 +551,7 @@ Rowel Atienza ro...@diwalabs.com
Stefano Babic sba...@denx.de
+ ea20davinci
polaris xscale
trizepsiv xscale
mx51evk i.MX51
diff --git a/board/davinci/ea20/Makefile b/board/davinci/ea20/Makefile
new file mode 100644
index 000..ddd2564
--- /dev/null
+++ b/board/davinci/ea20/Makefile
@@ -0,0 +1,53 @@
+#
+# (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-y+= ea20.o
+
+COBJS := $(COBJS-y)
+
+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 *~ .depend
+
+#
+# This is for $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/davinci/ea20/ea20.c b/board/davinci/ea20/ea20.c
new file mode 100644
index 000..e3e07a3
--- /dev/null
+++ b/board/davinci/ea20/ea20.c
@@ -0,0 +1,237 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Based on da830evm.c. Original Copyrights follow:
+ *
+ * Copyright (C) 2009 Nick Thompson, GE Fanuc, Ltd. nick.thomp...@gefanuc.com
+ * Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+ *
+ * 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 i2c.h
+#include net.h
+#include netdev.h
+#include asm/arch/hardware.h
+#include asm/arch/emif_defs.h
+#include asm/arch/emac_defs.h
+#include asm/io.h
+#include asm/arch/davinci_misc.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define pinmux(x) (davinci_syscfg_regs-pinmux[x])
+
+/* SPI0 pin muxer settings */
+static const struct pinmux_config spi1_pins[] = {
+ { pinmux(5), 1, 1 },
+ { pinmux(5), 1, 2 },
+ { pinmux(5), 1, 4 },
+ { pinmux(5), 1, 5 }
+};
+
+/* UART pin muxer settings */
+static const struct pinmux_config uart_pins[] = {
+ { pinmux(0), 4, 6 },
+ { pinmux(0), 4, 7 },
+ { pinmux(4), 2, 4 },
+ { pinmux(4), 2, 5 }
+};
+
+#ifdef CONFIG_DRIVER_TI_EMAC
+#define HAS_RMII 1
+static const struct pinmux_config emac_pins[] = {
+ { pinmux(14), 8, 2
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
On 11/12/2010 08:31 PM, Scott Wood wrote: On Fri, 12 Nov 2010 13:26:17 -0600 Kumar Galaga...@kernel.crashing.org wrote: On Nov 12, 2010, at 11:22 AM, Scott Wood wrote: On Fri, 12 Nov 2010 09:58:53 -0600 Kumar Galaga...@kernel.crashing.org wrote: We only do the 'twi' for loads/in_beX not stores/out_beX. Yes, and the readback is a load. following the store with a load should be sufficient I dont think we need the twi in this case. Do we ever need it, or is guarded+cache inhibited sufficient to completely hold up execution of anything beyond the load? Sorry for being insistent : Is there any explanation why this issue only came up on Jocke's MPC8321 (?) and my MPC8377 ? As mentioned here (http://lists.denx.de/pipermail/u-boot/2010-November/081459.html) there's still a mysterious issue which might have the same root cause. Again : USB is working fine under Linux - it's an U-Boot only issue. Is anybody willing to have a closer look - I'm completely stuck here. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/11/15 10:57:30: On 11/12/2010 08:31 PM, Scott Wood wrote: On Fri, 12 Nov 2010 13:26:17 -0600 Kumar Galaga...@kernel.crashing.org wrote: On Nov 12, 2010, at 11:22 AM, Scott Wood wrote: On Fri, 12 Nov 2010 09:58:53 -0600 Kumar Galaga...@kernel.crashing.org wrote: We only do the 'twi' for loads/in_beX not stores/out_beX. Yes, and the readback is a load. following the store with a load should be sufficient I dont think we need the twi in this case. Do we ever need it, or is guarded+cache inhibited sufficient to completely hold up execution of anything beyond the load? Sorry for being insistent : Is there any explanation why this issue only came up on Jocke's MPC8321 (?) and my MPC8377 ? Has anyone else tested 83xx on NOR? My guess is that cache line crossing shifted so that now the CPU doesn't need to read in a new cache at the critical part. As mentioned here (http://lists.denx.de/pipermail/u-boot/2010-November/081459.html) there's still a mysterious issue which might have the same root cause. Again : USB is working fine under Linux - it's an U-Boot only issue. Is anybody willing to have a closer look - I'm completely stuck here. Nope, don't use USB. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP4: speed up booting on Pandaboard
On 11/14/2010 11:18 PM, Wolfgang Denk wrote: Dear Sergiy Kibrik, In message 4cd27f08.8060...@globallogic.com you wrote: Improved default config for OMAP4 Pandaboard for faster boot: -reduced environment size to speed up memory initialization; -USB TTY driver turned off; -tweaked blob load address to avoid image relocation (according to default uImage load address); Signed-off-by: Sergiy Kibrik sergiy.kib...@globallogic.com --- include/configs/omap4_panda.h |8 1 files changed, 4 insertions(+), 4 deletions(-) ... - * Total Size Environment - 256k + * Total Size Environment - 2k * Malloc - add 256k */ -#define CONFIG_ENV_SIZE (256 10) +#define CONFIG_ENV_SIZE (256 4) I think we had this discussion before. 256 4 makes no sense when you mean 2 KiB - it requires the reader to actually perform the calculation, which means it makes it hard for him to understand the code. Without need. Please either write 2048, which everybody can parse easily, or write 2 10 which can be parsed easily well. I've considered advices you gave me in this thread: http://marc.info/?t=12889762841r=1w=2 and resubmitted the patch http://marc.info/?l=u-bootm=128922349828119w=2 Haven't you received that? -regards, Sergey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Share header files of Faraday controllers from a320 SoC.
The following three device controller inside a320 SoC are Soft IP which are also used by other SoC products. Here we suggest to move those header files out from a320 SoC folder into drivers folder. This change should provide header file sharing with multiple SoC. Macpaul Lin (3): ftpmu010: move ftpmu010 power controller to drivers/power folder fttmr010: move fttmr010 controller to drivers/timer folder ftsdmc020: move ftsdmc020 sdram controller to driver/misc folder Some of these hardware function blocks in a SoC also used by another SoC may have only header files in U-boot. Some of these header files were used only in assembly such as lowlevel_init.S. Some of these hardware drivers provide both C level functions and assembly definitions which could be organized as drivers or could be used directly as assembly commands. However, if U-boot could access drivers folder as another include PATH just like include might be a good solution to avoid writing something like the following line. #include ../../../../drivers/timer/fttmr010.h The other solution is to collect these kind of source codes into a specific folder in include, such as include/faraday. But I think this method cannot help people to recognize the difference class of the devices. I'm not sure if add CPPFLAGS += -I$(TOPDIR)/drivers into $(TOPDIR)/config.mk is reasonable. Just trying to give some suggestion. Best regards, Macpaul Lin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: USB breaks board
On 11/11/2010 01:24 PM, Andre Schwarz wrote: Kim, Timur, some comments on this from your side would really help ! The issue can be summarized like this : - MPC8377 based board is basically running fine with both U-Boot and Linux. - Activating USB support within U-Boot leads to *very* early crash : No console output - not even PCI clocks enabled. - Within Linux USB is working without problems, i.e. there's no hardware issue. I have an SMSC USB3300 PHY connected via ULPI and a self powered SMSC 2514 1:4 Hub. This is exactly the same as on mvblm7 board (=MPC8343). This behaviour reminds me of e.g. one or more missing sync instructions during early init as discussed with Jocke in the past weeks. It is very unlikely that I'm the only one facing this problem. got it - line 330 in arch/powerpc/cpu/mpc83xx/cpu_init.c does some EHCI configs masked by #ifndef CONFIG_MPC834x Removing this makes the board work again. It still hangs during usb start but this is most propably due to missing initialization. Will have a look and send a proper patch. After all I do like mondays ;-) Cheers, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] da830: fixup ARM relocation support
Fixes build breakage in da830evm after commit 97003756249bd790910417eb66f0039bbf06a02c da8xx: fixup ARM relocation support The da8xx fixup commit changed da830/da850 common code to make relocation work in da850, but didn't add the required defines to da830evm_config.h resulting in build failure in the common code. This patch adds those defines for da830, but makes no sense without also referring to the commit mentioned above. Signed-off-by: Nick Thompson nick.thomp...@ge.com Reviewed-by: Ben Gardiner bengardi...@nanometrics.ca --- Changes since v1: removed CONFIG_SKIP_RELOCATE_UBOOT Changes since v2: removed #undef CONFIG_SYS_ARM_WITHOUT_RELOC as it is not defined in the first place. Changes since v3: Rebased to lastest include/configs/da830evm.h | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/include/configs/da830evm.h b/include/configs/da830evm.h index 1feada9..3a2631b 100644 --- a/include/configs/da830evm.h +++ b/include/configs/da830evm.h @@ -47,8 +47,7 @@ * Memory Info */ #define CONFIG_SYS_MALLOC_LEN (0x1 + 1*1024*1024) /* malloc() len */ -#define PHYS_SDRAM_1 DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start */ -#define PHYS_SDRAM_1_SIZE (64 20) /* SDRAM size 64MB */ +#define PHYS_SDRAM_1 0xc000 /* SDRAM Start */ #define CONFIG_SYS_MEMTEST_START PHYS_SDRAM_1 /* memtest start addr */ #define CONFIG_SYS_MEMTEST_END (PHYS_SDRAM_1 + 16*1024*1024) /* 16MB test */ #define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */ @@ -280,4 +279,11 @@ mtdparts=davinci_nand.1: PART_BOOT PART_PARAMS PART_KERNEL PART_REST #endif +#define CONFIG_MAX_RAM_BANK_SIZE (512 20) /* max size from SPRS586*/ + +/* additions for new relocation code, must be added to all boards */ +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR\ + (CONFIG_SYS_SDRAM_BASE + 0x1000 - GENERATED_GBL_DATA_SIZE) + #endif /* __CONFIG_H */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
Dear Sebastien Carlier, In message 20101115080950.ga26...@safe.home.local you wrote: I just uploaded the revised patch here: http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-libraries-to-partial-linking-v4.patch Version 4: Bring in Linux comment for cmd_link_o_target. Fix drivers/qe/Makefile to build libqe.o, not qe.o. I pulled the latest changes before making the patch and there was no conflict, but please let me know if you see anything wrong with it. Thanks a lot. I notice that the patch affects the size of the resulting U-Boot images. For example: Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP textdata bss dec hex filename 358144 35208 303248 696600 aa118 ./u-bootbefore 361340 35824 303332 700496 ab050 ./u-bootafter --- Delta: +3896 Bytes For other boards it's only a few hundred bytes, but why do we see such big increase here? MPC8xx boards break with long lists of multiple definitions of symbols, like that: Configuring for FPS860L board... lib/libgeneric.o: In function `vsprintf': /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:480: first defined here lib/libgeneric.o: In function `ustrtoul': /home/wd/git/u-boot/work/lib/vsprintf.c:74: multiple definition of `ustrtoul' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:74: first defined here lib/libgeneric.o: In function `simple_strtol': /home/wd/git/u-boot/work/lib/vsprintf.c:67: multiple definition of `simple_strtol' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:67: first defined here lib/libgeneric.o: In function `inflate': /home/wd/git/u-boot/work/lib/zlib.c:1385: multiple definition of `inflate' lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:1385: first defined here lib/libgeneric.o: In function `inflate_fast': /home/wd/git/u-boot/work/lib/zlib.c:448: multiple definition of `inflate_fast' lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:448: first defined here ... Have you seen that, too? Best regards, Viele Grüße, 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 He was so narrow minded he could see through a keyhole with both eyes ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 14/11/2010 22:22, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4cdba515.3050...@free.fr you wrote: Alright. I'll prepare a V5 patch set with fixes to all ARM cpus. Wolfgang, is a single *patch* for all cpus ok or do you want a single *patchset* with one patch per cpu? Please tell me the single patch approach is ok. :) It is. Thanks in advance. ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136, arm1176, armv7 and pxa) have ELF relocation support. Others still use GOT relocation (or the older fixed-location scheme maybe), which IIUC means all boards using these other cpus are broken unless a maintainer gets patches pulled in to support ELF relocs. I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board maintainers who want to fix their board support for ELF relocs may have to also fix their cpu if it is not yet. Does everyone agree? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - microblaze
Am Mittwoch, 13. Oktober 2010, um 06:53:37 schrieb Michal Simek: Dear Wolfgang, 2010/10/13 Wolfgang Denk w...@denx.de Dear Michal Simek, In message 4cb406ba.6030...@monstr.eu you wrote: The following changes since commit bfc7bea6adc46e1db2f5a5e3464d7652ed67c864: --snip-- Thanks. Umm.. this does not include the 3rd patch by Stephan Linz: microblaze: generic: enable FDT support Any reason for that? There were small issue around CONFIG_SYS_BOOTMAPSZ and I haven't got any information about testing that's why I didn't added to my tree. http://www.mail-archive.com/u-boot@lists.denx.de/msg33939.html Hi Michal, Hi Wolfgang I'm sorry for my late response. I solved the problem arround CONFIG_SYS_BOOTMAPSZ differently. See Patch fdt relocate: have more attention to use a bootmap or not http://www.mail-archive.com/u-boot@lists.denx.de/msg35821.html But Wolfgang is right. The third patch by me is missing: http://www.mail-archive.com/u-boot@lists.denx.de/msg34015.html We need both patches together to enable FDT support on Microblaze. In summary, we need this patch set: * fdt relocate: have more attention to use a bootmap or not (http://git.denx.de/?p=u-boot.git;a=commit;h=958e120) (http://git.denx.de/?p=u-boot/u-boot-microblaze.git;a=commit;h=958e120) * microblaze: generic: adding DHCP support (http://git.denx.de/?p=u-boot/u-boot-microblaze.git;a=commit;h=3faf987) * microblaze: generic: rename MTD partition set to 'flash-0' (http://git.denx.de/?p=u-boot/u-boot-microblaze.git;a=commit;h=c82a541) * microblaze: generic: enable FDT support (!!! MISSING !!!) -- Regards, Stephan Linz __ OpenDCC: http://www.li-pro.net/opendcc.phtml PC/M: http://www.li-pro.net/pcm.phtml CDK4AVR: http://cdk4avr.sourceforge.net/ CDK4NIOS: http://cdk4nios.sourceforge.net/ CDK4MSP: http://cdk4msp.sourceforge.net/ CPM4L: http://download.opensuse.org/repositories/home:/rexut:/CPM4L ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: Aligning arch initialisation sequences
On 15/11/10 07:05, Albert ARIBAUD wrote: Le 14/11/2010 20:34, Graeme Russ a écrit : On 15/11/10 06:23, Wolfgang Denk wrote: Dear Albert ARIBAUD, In message4ce0221a.7030...@free.fr you wrote: Alright, then I think we should document how we comply, or do not comply, with GNU EABI / AAPCS (maybe a README.arm that people could read up) -- and I think if there is a way to access GD both before and after relocation without making a register unavailable to the whole u-boot code, then we should use it. By the way - it should be not difficult to use a normal extern pointer to reference the global data; see arch/powerpc/include/asm/global_data.h: 194 #if 1 195 #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm (r2) 196 #else /* We could use plain global data, but the resulting code is bigger */ 197 #define XTRN_DECLARE_GLOBAL_DATA_PTRextern 198 #define DECLARE_GLOBAL_DATA_PTR XTRN_DECLARE_GLOBAL_DATA_PTR \ 199 gd_t *gd 200 #endif I think you will find this peculiar to PowerPC I don't think Wolfgang's idea is actually processor-specific. Each processor has a way to define globals, which end up in the initialized data or bss area. BSS is not available before relocation, but initialized data is, and remains so after relocation. So if we define gd as an initialized pointer (residing in the initialized data area), it will be available both before and after relocation. Before relocation, this pointer will be read-only. We can set it at compile time if we know for each arch (or board) a good address in RAM or IRAM where gd can exist. After relocation, the pointer becomes read-write: we can copy gd content from (I)RAM to RAM if necessary and then update the gd pointer. What you are talking about is exactly how x86 defines gd, but for x86, gd is not accessible until after relocation Could it become accessible with the idea I expose above? Yes - The following patch uses CONFIG_SYS_INIT_SP_ADDR as a temporary global data area which is copied to a permanent global data structure located in the data section. I honestly don't know where I stand on this solution though. By using FS, I can emulate the 'global register variable' and the initial global data structure can end up anywhere it needs to be without needing to define CONFIG_SYS_INIT_SP_ADDR but it will involve self-modifying code I would prefer not to re-introduce. However, this method requires CONFIG_SYS_INIT_SP_ADDR which is casting a certain memory location (in RAM) in stone. Now the eNET has some battery backed SRAM on board which I can point CONFIG_SYS_INIT_SP_ADDR. So I could move SDRAM initialisation into C code, but this is not guaranteed for every x86 board (and for the eNET, it reduces the amount of battery-backed configuration memory available). I am looking to port U-Boot to a VIA EPIA EN15000 single board computer. This has no SRAM. The VIA board has a C7 processor which coreboot has a 'Cache-as-RAM' (CAR) implementation for, and the SC520 might support CAR (still looking). If this is the case, I think I can unequivocally support the solution based on CONFIG_SYS_INIT_SP_ADDR and move low-level init into board_init_f() in line with the other arches. For now, consider it a +0.5 vote for the patch below :) Regards, Graeme commit e38af43f0246335578b8c207e8097fd0c5fca520 Author: Graeme Russ graeme.r...@gmail.com Date: Mon Nov 15 21:15:52 2010 +1100 x86 Global Data Mods diff --git a/arch/i386/cpu/start.S b/arch/i386/cpu/start.S index aaf9dba..4c04a5a 100644 --- a/arch/i386/cpu/start.S +++ b/arch/i386/cpu/start.S @@ -127,14 +127,14 @@ mem_ok: /* Set the upper memory limit parameter */ subl$CONFIG_SYS_STACK_SIZE, %eax - /* Reserve space for global data */ - subl$(GD_SIZE * 4), %eax - - /* %eax points to the global data structure */ + /* Load some required values into the global data structure */ + movl$CONFIG_SYS_INIT_SP_ADDR, %eax movl%esp, (GD_RAM_SIZE * 4)(%eax) - movl%ebx, (GD_FLAGS * 4)(%eax) movl%ecx, (GD_LOAD_OFF * 4)(%eax) + /* Setup bootflags parameter to board_init_f() */ + movl%ebx, %eax + callboard_init_f/* Enter, U-boot! */ /* indicate (lack of) progress */ diff --git a/arch/i386/include/asm/global_data.h b/arch/i386/include/asm/global_data.h index e9000c3..03ecc3c 100644 --- a/arch/i386/include/asm/global_data.h +++ b/arch/i386/include/asm/global_data.h @@ -88,6 +88,12 @@ extern gd_t *gd; #define GD_FLG_WARM_BOOT 0x00200 /* Warm Boot */ +#if 0 #define DECLARE_GLOBAL_DATA_PTR +#else +#define XTRN_DECLARE_GLOBAL_DATA_PTRextern +#define DECLARE_GLOBAL_DATA_PTR XTRN_DECLARE_GLOBAL_DATA_PTR \ +gd_t *gd +#endif #endif /* __ASM_GBL_DATA_H */ diff --git a/arch/i386/lib/board.c b/arch/i386/lib/board.c index 1a962d3..11e6569 100644 --- a/arch/i386/lib/board.c +++
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert ARIBAUD, Am 15.11.2010 12:01, schrieb Albert ARIBAUD: I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board maintainers who want to fix their board support for ELF relocs may have to also fix their cpu if it is not yet. Does everyone agree? arm920t/at91 is ongoing. I may need your help these days but first I need some time to get my last linker related issues fixed properly (segfault when linking empty weak symbol with -pie). regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert ARIBAUD, In message 4ce11314.50...@free.fr you wrote: ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136, arm1176, armv7 and pxa) have ELF relocation support. Others still use GOT relocation (or the older fixed-location scheme maybe), which IIUC means all boards using these other cpus are broken unless a maintainer gets patches pulled in to support ELF relocs. I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board maintainers who want to fix their board support for ELF relocs may have to also fix their cpu if it is not yet. Does everyone agree? I dislike having such a mix of different relocation methods. Let's face it: this discussion has been going on for so long already that every interested party could have adapted their code. I am afraid if we do not force the change now it will never happen. And I do not want to carry on such a bifurcation much longer. Do you think you could convert the remaining CPUs to ELF relocation as well? That would probably provide the best base for any further work. 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 is now. Later is later. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] at91 family status
Dear Reinhard Meyer 2010/11/13 Reinhard Meyer u-b...@emk-elektronik.de: The problem is related to the new MMC driver, simple the mmc driver don't recognize my cards and also mmc info returns no info. Just a blind shot: is your MCI on port B (like it is on the at91sam9xxx-ek)? Then define CONFIG_ATMEL_MCI_PORTB. Yes, my board is based on at91sam9g20-ek but also define CONFIG_ATMEL_MCI_PORTB don't help. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
On Monday, November 15, 2010 05:54:07 Wolfgang Denk wrote: Sebastien Carlier wrote: I just uploaded the revised patch here: http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archiv e-libraries-to-partial-linking-v4.patch Version 4: Bring in Linux comment for cmd_link_o_target. Fix drivers/qe/Makefile to build libqe.o, not qe.o. I pulled the latest changes before making the patch and there was no conflict, but please let me know if you see anything wrong with it. Thanks a lot. I notice that the patch affects the size of the resulting U-Boot images. For example: Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP textdata bss dec hex filename 358144 35208 303248 696600 aa118 ./u-boot before 361340 35824 303332 700496 ab050 ./u-boot after --- Delta: +3896 Bytes For other boards it's only a few hundred bytes, but why do we see such big increase here? some of this is probably because of missing build system support. there are some files which are always compiled when they shouldnt be but in the past, this wasnt a problem because they were stuck in an .a and the linker wouldnt pull them in since no one requested them. on my side, i see this with at least these files: cmd_pcmcia.c file.c ldiv.c memsize.c rpx_pcmcia.c tqm8xx_pcmcia.c although i'm still seeing a few hundred byte increase in my .text/.bss, but the symbol map is unchanged ... -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 v4] Switch from archive libraries to partial linking
Dear Wolfgang, On 2010-11-15 11:54:07, Wolfgang Denk wrote: I notice that the patch affects the size of the resulting U-Boot images. For example: Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP textdata bss dec hex filename 358144 35208 303248 696600 aa118 ./u-boot before 361340 35824 303332 700496 ab050 ./u-boot after --- Delta: +3896 Bytes For other boards it's only a few hundred bytes, but why do we see such big increase here? With archive library linking, definitions that were not used were not included in the final binary. This changes with partial linking (like it would if we passed the --whole-archive flag to ld). For this board (TQM5200), I am not sure exactly what happens yet, but this looks suspect to me: # ls -l ./post/lib_powerpc/fpu/mul-subnormal-single-1.[co] -rw-r--r-- 1 sebc sebc 2309 Nov 1 21:33 ./post/lib_powerpc/fpu/mul-subnormal-single-1.c -rw-r--r-- 1 sebc sebc 30288 Nov 15 12:09 ./post/lib_powerpc/fpu/mul-subnormal-single-1.o I would expect the object file to be much smaller based on source code size. MPC8xx boards break with long lists of multiple definitions of symbols, like that: Configuring for FPS860L board... lib/libgeneric.o: In function `vsprintf': /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:480: first defined here lib/libgeneric.o: In function `ustrtoul': /home/wd/git/u-boot/work/lib/vsprintf.c:74: multiple definition of `ustrtoul' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:74: first defined here lib/libgeneric.o: In function `simple_strtol': /home/wd/git/u-boot/work/lib/vsprintf.c:67: multiple definition of `simple_strtol' lib/vsprintf.o:/home/wd/git/u-boot/work/lib/vsprintf.c:67: first defined here lib/libgeneric.o: In function `inflate': /home/wd/git/u-boot/work/lib/zlib.c:1385: multiple definition of `inflate' lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:1385: first defined here lib/libgeneric.o: In function `inflate_fast': /home/wd/git/u-boot/work/lib/zlib.c:448: multiple definition of `inflate_fast' lib/zlib.o:/home/wd/git/u-boot/work/lib/zlib.c:448: first defined here ... Have you seen that, too? No, I had not seen that. It seems that some bits of U-Boot get included twice in this case... I will investigate this after looking a bit more at the code size increase for the TQM5200 board. -- Sebastien ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] tools/env: use host build flags
On Sunday, November 14, 2010 16:59:33 Wolfgang Denk wrote: Mike Frysinger wrote: Seems this was not a fix, but introduced an error. Dp you agree to revert that commit? of course i disagree. this change is a fix in my mind. Please reconsider. This has been working for nearly a decade, and now it's broken. I want to see this fixed. If needed, by reverting the commit that broke it. it's been working for your specific use cases. it hasnt been working without pains for everyone. I agree you have a point. But it is a change in behaviour, and what it makes worse it that it's an undocumented one. Users who have been doing the same thing for a decade suddenly find their old scripts are not working any more, and there it even a hint of what they do now. If we decide that such a change makes sense, then it must be explained and documented properly. i guess i can try harder to goad Daniel into getting his work going -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] at91 family status
Dear Claudio Mignanti, 2010/11/13 Reinhard Meyer u-b...@emk-elektronik.de: The problem is related to the new MMC driver, simple the mmc driver don't recognize my cards and also mmc info returns no info. Just a blind shot: is your MCI on port B (like it is on the at91sam9xxx-ek)? Then define CONFIG_ATMEL_MCI_PORTB. Yes, my board is based on at91sam9g20-ek but also define CONFIG_ATMEL_MCI_PORTB don't help. Did it work with the old driver? What #defines were used then? Can you #define DEBUG 1 in gen_atmel_mci.c and see what is printed? Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Andreas,
On 2010-11-15 12:09:58, Andreas Bießmann wrote:
arm920t/at91 is ongoing. I may need your help these days but first I
need some time to get my last linker related issues fixed properly
(segfault when linking empty weak symbol with -pie).
Can you please try the attached patch? It fixed this problem for me.
--
Sebastien
From f4007bb3d05768bbe5c0903f856809618a89e921 Mon Sep 17 00:00:00 2001
From: Sebastien Carlier sebastien.carl...@gmail.com
Date: Wed, 10 Nov 2010 14:41:44 +0100
Subject: [PATCH] arm920t: add .plt and .rel.plt to the linker script
Signed-off-by: Sebastien Carlier sebastien.carl...@gmail.com
---
arch/arm/cpu/arm920t/u-boot.lds |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm920t/u-boot.lds b/arch/arm/cpu/arm920t/u-boot.lds
index d1babcc..dd62bdd 100644
--- a/arch/arm/cpu/arm920t/u-boot.lds
+++ b/arch/arm/cpu/arm920t/u-boot.lds
@@ -42,6 +42,8 @@ SECTIONS
arch/arm/cpu/arm920t/start.o (.text)
*(.text)
}
+ .plt : { *(.plt) }
+ .rel.plt : { *(.rel.plt) }
. = ALIGN(4);
.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
--
1.7.3.2.161.g3089c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Switch from archive libraries to partial linking
On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote: This commit changes all Makefiles to use partial linking (ld -r) instead of creating library archives, which forces all symbols to participate in linking, allowing non-weak symbols to override weak symbols as intended. This approach is also used by Linux, from which the gmake function cmd_link_o_target (added at the end of config.mk and used in all Makefiles) is inspired. linux takes it a step further ... it partially links everything into one .o before turning that into the final ELF. why dont we do the same (partially link everything into u-boot.o and then just do u-boot.o-u-boot) ? it should allow us to drop the start/end group flags in the process. -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 V4 1/2] arm926ejs: fix linker file for newer ld support
Le 15/11/2010 12:13, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4ce11314.50...@free.fr you wrote: ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136, arm1176, armv7 and pxa) have ELF relocation support. Others still use GOT relocation (or the older fixed-location scheme maybe), which IIUC means all boards using these other cpus are broken unless a maintainer gets patches pulled in to support ELF relocs. I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board maintainers who want to fix their board support for ELF relocs may have to also fix their cpu if it is not yet. Does everyone agree? I dislike having such a mix of different relocation methods. Let's face it: this discussion has been going on for so long already that every interested party could have adapted their code. I am afraid if we do not force the change now it will never happen. And I do not want to carry on such a bifurcation much longer. Understood. Do you think you could convert the remaining CPUs to ELF relocation as well? That would probably provide the best base for any further work. I can make the changes for other cpus, but I cannot perform even basic testing beyond making sure it still builds. Besides, while I can reasonably provide a V5 patch by this evening for the five cpus which already support ELF, I won't be able to provide fixes for the whole of arch/arm/cpu/* until thursday evening/friday morning. Is that ok? Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
On Mon, Nov 15, 2010, Albert ARIBAUD wrote: I can make the changes for other cpus, but I cannot perform even basic testing beyond making sure it still builds. Would qemu be of any help there? You could use e.g. versatile or integrator, and pretend that they use any CPU by changing their config and passing -cpu on the qemu command-line -- Loïc Minier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert ARIBAUD, ATM on mainline master branch only five ARM cpus (arm926ejs, arm1136, arm1176, armv7 and pxa) have ELF relocation support. Others still use GOT relocation (or the older fixed-location scheme maybe), which IIUC means all boards using these other cpus are broken unless a maintainer gets patches pulled in to support ELF relocs. I therefore propose that V5 of my patch fixes arm926ejs, armv7, arm1136, arm1176 and pxa only, and leave the ten other ARM cpus untouched. Board maintainers who want to fix their board support for ELF relocs may have to also fix their cpu if it is not yet. Does everyone agree? I dislike having such a mix of different relocation methods. Let's face it: this discussion has been going on for so long already that every interested party could have adapted their code. I am afraid if we do not force the change now it will never happen. And I do not want to carry on such a bifurcation much longer. Understood. Do you think you could convert the remaining CPUs to ELF relocation as well? That would probably provide the best base for any further work. I can make the changes for other cpus, but I cannot perform even basic testing beyond making sure it still builds. Besides, while I can reasonably provide a V5 patch by this evening for the five cpus which already support ELF, I won't be able to provide fixes for the whole of arch/arm/cpu/* until thursday evening/friday morning. Is that ok? Would it not be nice to take the ARM-universal identical code for relocate, clear bss and transfer to relocated code out of each ARM/CPU/*/start.S and move it to ARM/LIB/relocate.S ? You would not have to duplicate and maintain that code in every ARM CPU type. That would also pave the path to the relocation in C which I have started a while ago. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert ARIBAUD, In message 4ce11e66.5060...@free.fr you wrote: Do you think you could convert the remaining CPUs to ELF relocation as well? That would probably provide the best base for any further work. I can make the changes for other cpus, but I cannot perform even basic testing beyond making sure it still builds. Understood. Eventually I can test on a small number of boards. The rest goes untested - but most of them are in a more or less broken state anyway. Besides, while I can reasonably provide a V5 patch by this evening for the five cpus which already support ELF, I won't be able to provide fixes for the whole of arch/arm/cpu/* until thursday evening/friday morning. Is that ok? That's OK. I will then try to get the recent changes in this night, and the others when the patch becomes available. 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 whole world is about three drinks behind. - Humphrey Bogart ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear =?iso-8859-1?Q?Lo=EFc?= Minier, In message 20101115115556.ga13...@bee.dooz.org you wrote: On Mon, Nov 15, 2010, Albert ARIBAUD wrote: I can make the changes for other cpus, but I cannot perform even basic = testing beyond making sure it still builds. Would qemu be of any help there? You could use e.g. versatile or integrator, and pretend that they use any CPU by changing their config and passing -cpu on the qemu command-line Do you have a working qemu setup and/or documentation how to run U-Boot on such an ARM config? 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 Conscious is when you are aware of something, and conscience is when you wish you weren't. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] Switch from archive libraries to partial linking
On 2010-11-15 11:54:07, Wolfgang Denk wrote:
I notice that the patch affects the size of the resulting U-Boot
images.
For example:
Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
textdata bss dec hex filename
358144 35208 303248 696600 aa118 ./u-boot before
361340 35824 303332 700496 ab050 ./u-boot after
---
Delta: +3896 Bytes
For other boards it's only a few hundred bytes, but why do we see
such big increase here?
In this case, these libraries contribute 3260 bytes in unused
definitions:
- fs/fat/libfat.a: (1712 bytes)
file.o:
0004 d current_filesystem
0004 0200 D file_cwd
0018 d filesystems
0250 0244 T file_cd
01d0 0080 T file_detectfs
0048 T file_getfsname
011c 00b4 T file_ls
0048 00d4 T file_read
- lib/libfdt/libfdt.a (1440 bytes)
fdt_sw.o:
006c T fdt_add_reservemap_entry
028c 00dc T fdt_begin_node
0504 009c T fdt_create
00b4 0078 T fdt_end_node
012c 0160 T fdt_finish
006c 0048 T fdt_finish_reservemap
0368 019c T fdt_property
- drivers/pci/libpci.a: (108 bytes)
pci_indirect.o:
01dc 006c T pci_setup_indirect
In each case, a whole object file contains exactly the unused
definitions, and could be excluded in the respective Makefile.
Re. my previous comment -- in other places objects get large when header
files define a lot of static inline functions, but these ('t' type)
definitions get squashed together during linking and do not add up. If
however a large static inline function is defined but never used, it
will increase final binary size.
--
Sebastien
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 15/11/2010 13:02, Wolfgang Denk a écrit : Besides, while I can reasonably provide a V5 patch by this evening for the five cpus which already support ELF, I won't be able to provide fixes for the whole of arch/arm/cpu/* until thursday evening/friday morning. Is that ok? That's OK. I will then try to get the recent changes in this night, and the others when the patch becomes available. All right then. I'll push the V5 tonight with support for the first five cpus, and another patch for the remaining ones by end of week. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
On Monday, November 15, 2010 06:33:40 Mike Frysinger wrote: On Monday, November 15, 2010 05:54:07 Wolfgang Denk wrote: Sebastien Carlier wrote: I just uploaded the revised patch here: http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from- arch iv e-libraries-to-partial-linking-v4.patch Version 4: Bring in Linux comment for cmd_link_o_target. Fix drivers/qe/Makefile to build libqe.o, not qe.o. I pulled the latest changes before making the patch and there was no conflict, but please let me know if you see anything wrong with it. Thanks a lot. I notice that the patch affects the size of the resulting U-Boot images. For example: Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP textdata bss dec hex filename 358144 35208 303248 696600 aa118 ./u-bootbefore 361340 35824 303332 700496 ab050 ./u-bootafter --- Delta: +3896 Bytes For other boards it's only a few hundred bytes, but why do we see such big increase here? some of this is probably because of missing build system support. there are some files which are always compiled when they shouldnt be but in the past, this wasnt a problem because they were stuck in an .a and the linker wouldnt pull them in since no one requested them. on my side, i see this with at least these files: cmd_pcmcia.c file.c ldiv.c memsize.c rpx_pcmcia.c tqm8xx_pcmcia.c although i'm still seeing a few hundred byte increase in my .text/.bss, but the symbol map is unchanged ... some of this is simply due to change in linking order and the implicit padding in between each symbol for alignment requirements you can check how much this adds with the attached script: $ ./align-padding u-boot .text | tail -n1 586 $ ./align-padding old/u-boot .text | tail -n1 490 replace the '$7 == 3' check with whatever section number you want to check. in my case, 3 is .text. i see a 96 byte change in my .text due to this, but i wouldnt blame this patch for it. and similar changes for .data/.bss/.rodata. -mike align-padding Description: application/shellscript 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 v4] Switch from archive libraries to partial linking
On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote: On 2010-11-15 11:54:07, Wolfgang Denk wrote: I notice that the patch affects the size of the resulting U-Boot images. For example: Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP textdata bss dec hex filename 358144 35208 303248 696600 aa118 ./u-bootbefore 361340 35824 303332 700496 ab050 ./u-bootafter --- Delta: +3896 Bytes For other boards it's only a few hundred bytes, but why do we see such big increase here? In this case, these libraries contribute 3260 bytes in unused definitions: In each case, a whole object file contains exactly the unused definitions, and could be excluded in the respective Makefile. or just use -ffunction-sections/-fdata-sections/-Wl,--gc-sections and dont worry about it. which is what we do for the Blackfin port. -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 v3] Switch from archive libraries to partial linking
On Monday, November 15, 2010 07:38:28 Mike Frysinger wrote: replace the '$7 == 3' check with whatever section number you want to check. in my case, 3 is .text. err, ignore this outdated comment -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 V4 1/2] arm926ejs: fix linker file for newer ld support
On Mon, 15 Nov 2010 12:49:58 +0100, Albert ARIBAUD albert.arib...@free.fr wrote: Do you think you could convert the remaining CPUs to ELF relocation as well? That would probably provide the best base for any further work. I can make the changes for other cpus, but I cannot perform even basic testing beyond making sure it still builds. Besides, while I can reasonably provide a V5 patch by this evening for the five cpus which already support ELF, I won't be able to provide fixes for the whole of arch/arm/cpu/* until thursday evening/friday morning. Is that ok? I would suggest get those 5 done, reviewed and well tested first. Otherwise, you might find yourself doing the same fix to many cpu's instead of only 5. Then do the other ones and ask maintainers (or somebody else with access to a suitable board on his desk) to perform the test. If you could provide them with a few instructions, they can do the tests real quick and you get consistent reports. Regards, -- Bas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
On Monday, November 15, 2010 07:38:28 Mike Frysinger wrote: some of this is simply due to change in linking order and the implicit padding in between each symbol for alignment requirements you can check how much this adds with the attached script: this version fixes handling with defined weak symbols and with very large symbols (readelf will use hex for them) -mike align-padding Description: application/shellscript 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 V4 1/2] arm926ejs: fix linker file for newer ld support
On Mon, Nov 15, 2010, Wolfgang Denk wrote: Do you have a working qemu setup and/or documentation how to run U-Boot on such an ARM config? Sometimes I do ;-) I use either: * Ubuntu QEMU packages - qemu-kvm-extras package has qemu-system-arm; it's usually fairly old because it's built from the qemu-kvm trees/releases * Linaro QEMU packages - currently the qemu-maemo package in this PPA https://launchpad.net/~linaro-maintainers/+archive/tools/+packages provides the qemu-maemo-system-arm command; can be installed along qemu-kvm-extras; this has patches to support OMAP machines from the qemu-maemo/-meego projects, hence the name; in the future, this might be a qemu-linaro instead * upstream QEMU built from git While U-Boot supports integrator, versatile and vexpress, QEMU only supports the first two. I get varying success depending on the exact combination of emulated machine and version of QEMU. Today, I tried the binary u-boot downloads from http://arm.com/community/software-enablement/linux.php (Linux OS Downloads tab) with with qemu-maemo 0.0~20100921+871d996-0ubuntu1~linaro1 and qemu-kvm-extras 0.13.0+noroms-0ubuntu3: machine: | realview-eb realview-pbx-a9 versatilepb QEMU: | + qemu-maemo | partial[1] works works qemu-kvm-extras | partial[1] works crash[2] Unfortunately, these are not built from upstream u-boot sources; I tried building some ARM boards from upstream u-boot with v2010.09 and got these results: machine: | integratorcp versatilepb QEMU: | +- qemu-maemo | crash[3]partial[4] qemu-kvm-extras | crash[3]partial[4] So I'm afraid I couldn't find a fully working combination of U-Boot supported board + QEMU, but I didn't try QEMU tip; I'm Cc:ing Peter who cares for QEMU in Linaro, maybe he has more idea or is tempted to try a tip QEMU :-) If you want to reproduce, run something like: qemu-system-arm -M versatilepb -serial stdio \ -kernel u-boot_bin_u-boot_versatilepb.axf or: qemu-system-arm -nographic -M versatilepb \ -kernel u-boot_bin_u-boot_versatilepb.axf replace qemu-system-arm with qemu-maemo-system-arm if you use qemu-maemo [1] crashes while initializing the NIC; qemu: hardware error: smc91c111_write: Bad reg 0:6 [2] qemu: hardware error: arm_timer_write: Bad offset 101e1fe0 [3] qemu: hardware error: pl011_write: Bad offset 14 [4] crashes after detecting 0 Bytes of DRAM: DRAM: 0 Bytes qemu: fatal: Trying to execute code outside RAM or ROM at 0x3400 -- Loïc Minier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Hi Eric, On 10.11.2010 00:43, Eric Cooper wrote: I have been periodically rebasing my patches for the Seagate DockStar on master. But ever since the elf_reloc changes were merged, I have been unable to get a working build. First I saw symptoms similar to what Alexander Holler reported (failing during NAND initialization due to incorrect BSS relocation), but the latest arm926ejs ld script patches did not fix it. The system would hang here: U-Boot 2010.12-rc1 (Nov 09 2010 - 17:52:38) Seagate FreeAgent DockStar SoC: Kirkwood 88F6281_A0 DRAM: 128 MiB NAND: This was built with the CodeSourcery 2010q1 toolchain. I also included Alexander's patch to double-check the relocation, and no error message gets printed. Did you locally fix arch/arm/cpu/arm926ejs/kirkwood/timer.c to not access uninitialized data (variables timestamp and lastdec) before relocation? Otherwise timer_init() will write into the relocation table which may lead to your problem. If you change unrelated code, timer_init() will overwrite some other relocation table entries and U-Boot seems to work. @Albert: If your patch is applied without fixing the accesses to BSS before relocation, some ARM ports will be broken even when compiling with ELDK 4.2. Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 15/11/2010 15:06, Loïc Minier a écrit : So I'm afraid I couldn't find a fully working combination of U-Boot supported board + QEMU, but I didn't try QEMU tip; I'm Cc:ing Peter who cares for QEMU in Linaro, maybe he has more idea or is tempted to try a tip QEMU :-) Not sure I get how this works. Do you need to build u-boot in a special way or with a special toolchain in order to run it in qemu? I'm asking because: If you want to reproduce, run something like: qemu-system-arm -M versatilepb -serial stdio \ -kernel u-boot_bin_u-boot_versatilepb.axf I assume that the -kernel option indicates the executable to run. Would it take an ELF executable? a binary? How would one go about testing running u-boot from RAM, NOR, NAND? Also: [1] crashes while initializing the NIC; qemu: hardware error: smc91c111_write: Bad reg 0:6 [2] qemu: hardware error: arm_timer_write: Bad offset 101e1fe0 [3] qemu: hardware error: pl011_write: Bad offset 14 [4] crashes after detecting 0 Bytes of DRAM: This seems to mean the HW is not 100% simulated, right? One last question: qemu: fatal: Trying to execute code outside RAM or ROM at 0x3400 Does this mean that qemu does not simulate data or instruction aborts? Not that it is required for u-boot, but it *could* be useful sometimes. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 15/11/2010 15:15, Daniel Hobi a écrit : @Albert: If your patch is applied without fixing the accesses to BSS before relocation, some ARM ports will be broken even when compiling with ELDK 4.2. Thanks for pointing this out. Indeed, my patch is actively based on the assumption that BSS is not used until after relocation, and I did this because not using BSS before relocation is already a known constraint. I'll add a note in the commit. Best regards, Daniel Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] don't touch non-existent EHCI regs on MPC837x.
Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de --- arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c b/arch/powerpc/cpu/mpc83xx/cpu_init.c index 7a1cae7..cfead18 100644 --- a/arch/powerpc/cpu/mpc83xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c @@ -327,7 +327,7 @@ void cpu_init_f (volatile immap_t * im) im-gpio[1].dir = CONFIG_SYS_GPIO2_DIR; #endif #ifdef CONFIG_USB_EHCI_FSL -#ifndef CONFIG_MPC834x +#if !defined(CONFIG_MPC834x) !defined(CONFIG_MPC837x) uint32_t temp; struct usb_ehci *ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR; -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
Has anyone else tested 83xx on NOR? My guess is that cache line crossing shifted so that now the CPU doesn't need to read in a new cache at the critical part. I notice this is hot thread for 83xx in these days. Anybody can share more background for the issue? I would like have a look the issue. Thanks, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] CONFIG_SYS_SDRAM and CONFIG_SYS_INIT_SP_ADDR defines for versatile boards.
Fine by me -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: 14 November 2010 20:58 To: Peter Pearse Cc: Himanshu Chauhan; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] CONFIG_SYS_SDRAM and CONFIG_SYS_INIT_SP_ADDR defines for versatile boards. Dear Peter, In message 1288293797-16422-1-git-send-email-hschau...@nulltrace.org Himanshu Chauhan wrote: Following is the patch for defining the subject line mentioned configuration defines for versatile boards. Signed-off-by: Himanshu Chauhan hschau...@nulltrace.org --- include/configs/versatile.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/configs/versatile.h b/include/configs/versatile.h index 45d8434..2da567a 100644 --- a/include/configs/versatile.h +++ b/include/configs/versatile.h @@ -231,4 +231,7 @@ #define CONFIG_SYS_FLASH_PROTECTION/* The devices have real protection */ #define CONFIG_SYS_FLASH_EMPTY_INFO/* flinfo indicates empty blocks */ +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_TEXT_BASE \ +- GENERATED_GBL_DATA_SIZE) #endif /* __CONFIG_H */ -- Is this OK with you? 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 haven't lost my mind -- it's backed up on tape somewhere. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
Dave, I notice this is hot thread for 83xx in these days. Anybody can share more background for the issue? I would like have a look the issue. during MPC8377 board bring up we couldn't get U-Boot up and running - the serial line has been dead. Using a bdi2000 debugger told us the CPU, RAM and Flash was basically working fine. Jocke had the same problems on a MPC8321 and found a solution/workaround (adding 4 nops in Start.S right after _start). I followed his proposal and it worked out fine. The experts found an issue within init code and it looks like a proper patch will be added to mainline shortly. The discussion of the proper fix is right in this thread ... This leaves the question why this only happens on Jocke's MPC8321 and my MPC8377. Looks like nobody else observed this. Our MPC8343 based boards never had this issue. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hanging in kmalloc of nand_scan_tail() function
On Nov 14, 2010, at 7:18 AM, terry wrote: 在 2010-11-13六的 10:24 -0600，Kumar Gala写道： On Nov 12, 2010, at 9:43 PM, terry wrote: by the way,I cann't find the prototype of malloc in the whole project,it seems that it is encapsulated in some libs. It's in common/malloc.c. There's weird preprocessor renaming going on, so it's called mALLOc in that file, but it shows up as malloc in the binary. Thanks very much for your carefully instruction. -Scott I haven't been following this thread, but just debugging a malloc/nand corruption issue myself. I'm going to start a new thread on the subject since its more related to malloc. However can you try the following and see what happens: diff --git a/include/malloc.h b/include/malloc.h I'm sorry, but I cann't understand you clearly. what do you mean by writting this? compare two different versions? if so, which two version? index 3e145ad..19f0f0b 100644 --- a/include/malloc.h +++ b/include/malloc.h @@ -850,7 +850,7 @@ extern Void_t* sbrk(); #endif #ifndef MORECORE_CLEARS -#define MORECORE_CLEARS 1 +#define MORECORE_CLEARS 0 #endif #endif /* INTERNAL_LINUX_C_LIB */ I read the malloc.h file in u-boot-2010.09. it's content like below: #ifdef INTERNAL_LINUX_C_LIB 819 820 #if __STD_C 821 822 Void_t * __default_morecore_init (ptrdiff_t); 823 Void_t *(*__morecore)(ptrdiff_t) = __default_morecore_init; 824 825 #else 826 827 Void_t * __default_morecore_init (); 828 Void_t *(*__morecore)() = __default_morecore_init; 829 830 #endif /* __STD_C */ 831 832 #define MORECORE (*__morecore) 833 #define MORECORE_FAILURE 0 834 #define MORECORE_CLEARS 1 #else /* INTERNAL_LINUX_C_LIB */ 837 838 #if __STD_C 839 extern Void_t* sbrk(ptrdiff_t); 840 #else 841 extern Void_t* sbrk(); 842 #endif 843 844 #ifndef MORECORE 845 #define MORECORE sbrk 846 #endif 847 848 #ifndef MORECORE_FAILURE 849 #define MORECORE_FAILURE -1 850 #endif 851 852 #ifndef MORECORE_CLEARS 853 #define MORECORE_CLEARS 1 854 #endif 855 856 #endif /* INTERNAL_LINUX_C_LIB */ Do you mean that I should change MORECORE_CLEARS from 1 to 0? Yes, I was asking you to modify include/malloc.h to change MORECORE_CLEARS from 1 to 0 and see if that helps your issue. You need to modify the one on lines 853. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] don't touch non-existent EHCI regs on MPC837x.
On Nov 15, 2010, at 8:53 AM, Andre Schwarz wrote: Signed-off-by: Andre Schwarz andre.schw...@matrix-vision.de --- arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) This doesn't seem quite right, the MPC837x has USB controllers. - k diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c b/arch/powerpc/cpu/mpc83xx/cpu_init.c index 7a1cae7..cfead18 100644 --- a/arch/powerpc/cpu/mpc83xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c @@ -327,7 +327,7 @@ void cpu_init_f (volatile immap_t * im) im-gpio[1].dir = CONFIG_SYS_GPIO2_DIR; #endif #ifdef CONFIG_USB_EHCI_FSL -#ifndef CONFIG_MPC834x +#if !defined(CONFIG_MPC834x) !defined(CONFIG_MPC837x) uint32_t temp; struct usb_ehci *ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR; -- 1.7.0.4 ___ 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] net: e1000: Add initialized eth_device e1000_hw structure
On Nov 14, 2010, at 4:24 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 1289556786-15201-1-git-send-email-ga...@kernel.crashing.org you
wrote:
nic and hw structures are allocated via malloc i.e. return memory
is not zero initialized. Because of this few structure member like
function pointers are initialized with garbage values.
It may cause problem. for eg. during eth_initialize, dev-write_hwaddr
is used.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/net/e1000.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 2825342..911eb2c 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -5177,7 +5177,21 @@ e1000_initialize(bd_t * bis)
}
nic = (struct eth_device *) malloc(sizeof (*nic));
+if (!nic) {
+printf(Error: e1000 - Can not alloc memory\n);
+return 0;
+}
+
hw = (struct e1000_hw *) malloc(sizeof (*hw));
+if (!nic) {
!hw
Applied after fixing the typo.
Thanks ;)
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: Move when we call cpu_init_r on PPC
On Nov 13, 2010, at 12:22 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message e20f32a5-0ef5-4cc3-ab70-0c1e2330e...@kernel.crashing.org you
wrote:
I'd like to move cpu_init_r to after env_relocate(). This is desirable
on 85xx based systems to deal with an issue when we boot from NAND (and
probably SPI or SDHC/MMC) in which we use the L2 cache in SRAM mode to
load the u-boot image from the storage device (NAND, SPI, SDHC/MMC,
etc.). In these cases we have an ordering issue between freeing up the
L2 cache and when the environment is relocated.
I don't think that's a good idea. cpu_init_r() starts a number of
pretty basic servies and must run as early as possible after
relocation. For example, it may initialize caches, load microcode
needed for some drivers soon, initialize interrupts and timers and
such...
Moving these things around requires extreme care and really intensive
testing on a lots of boards.
If we move cpu_init_r() after env_relocate() that addresses the issue.
I did an audit of all the other PPC chips and I dont believe it impacts
any of them if we move cpu_init_r after spi_init_{f,r}, nand_init,
mmc_initialize, env_relocate.
Um.. I doubt that. My fingers still carry the fire scars from my last
attempt to do something like that.
Please let me know if this is acceptable solution to my problem. I've
provided both the 'audit' details and example diff.
Thanks for that. It only shows that there is alot of pretty basic
stuff done, which might be needed. You will need to retest a ton of
boards.
Well I'm still stuck for a solution to my problem :)
So is a post_env_relocate_cleanup() the way to go? I can than differ L2 init
to that point in the case we use the L2 SRAM for boot memory?
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] don't touch non-existent EHCI regs on MPC837x.
Kumar, Signed-off-by: Andre Schwarzandre.schw...@matrix-vision.de --- arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) This doesn't seem quite right, the MPC837x has USB controllers. - k yes, it has - and it is working fine. But USB register range 0x00-0xff is reserved and hangs the CPU. With this patch USB is working fine on at least MPC8377. diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c b/arch/powerpc/cpu/mpc83xx/cpu_init.c index 7a1cae7..cfead18 100644 --- a/arch/powerpc/cpu/mpc83xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c @@ -327,7 +327,7 @@ void cpu_init_f (volatile immap_t * im) im-gpio[1].dir = CONFIG_SYS_GPIO2_DIR; #endif #ifdef CONFIG_USB_EHCI_FSL -#ifndef CONFIG_MPC834x +#if !defined(CONFIG_MPC834x) !defined(CONFIG_MPC837x) uint32_t temp; struct usb_ehci *ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR; -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] don't touch non-existent EHCI regs on MPC837x.
Dear Andre Schwarz, In message 4ce14e3e.7060...@matrix-vision.de you wrote: This doesn't seem quite right, the MPC837x has USB controllers. yes, it has - and it is working fine. But USB register range 0x00-0xff is reserved and hangs the CPU. With this patch USB is working fine on at least MPC8377. Then the commit message should make this clear. At the moment it is pretty much misleading. 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 Boss, n.: According to the Oxford English Dictionary, in the Middle Ages the words boss and botch were largely synonymous, except that boss, in addition to meaning a supervisor of workers also meant an ornamental stud. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
On Mon, Nov 15, 2010, Albert ARIBAUD wrote: I assume that the -kernel option indicates the executable to run. Correct, IOW u-boot.bin Would it take an ELF executable? a binary? You can pass an ELF as well How would one go about testing running u-boot from RAM, NOR, NAND? I guess you could only test from RAM with the way support for ARM boards is implemented Hmm another option would be OMAP emulation. It might allow you to test all of this; it's a bit more tricky to setup as you need to generate the flash contents, or some SD card. Also, things are a bit messier because this still uses x-loader. Problem is that x-loader probably requires armv7 itself ATM; this becomes quite far-fetched :-/ This seems to mean the HW is not 100% simulated, right? Well, these are either missing simulation or bugs; yes One last question: qemu: fatal: Trying to execute code outside RAM or ROM at 0x3400 Does this mean that qemu does not simulate data or instruction aborts? Not that it is required for u-boot, but it *could* be useful sometimes. I think the only thing it can do is halt :-) -- Loïc Minier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3][NEXT] Davinci: add support for the ea20 board
On Mon, Nov 15, 2010 at 4:46 AM, Stefano Babic sba...@denx.de wrote:
This board uses the OMAP-L138 SOM stacked on a
custom baseboard. It supports SPI Flash, Ethernet
with RMII.
Signed-off-by: Stefano Babic sba...@denx.de
---
Changes since V2:
- Rebased on the following patch(Sughosh Ganu):
[...]
diff --git a/board/davinci/ea20/ea20.c b/board/davinci/ea20/ea20.c
new file mode 100644
index 000..e3e07a3
--- /dev/null
+++ b/board/davinci/ea20/ea20.c
@@ -0,0 +1,237 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Based on da830evm.c. Original Copyrights follow:
It seems to me that this file is based off of da850evm.c; the
da850ev.c file contains this comment which is where it likely came
from. If it is based on da850evm.c then I think the file's comment
should reflect this.
[...]
+
+static void da850_emac_mii_mode_sel(int mode_sel)
+{
+ int val;
+
+ val = readl(davinci_syscfg_regs-cfgchip3);
+ if (mode_sel == 0)
+ val = ~(1 8);
+ else
+ val |= (1 8);
+ writel(val, davinci_syscfg_regs-cfgchip3);
+}
This is a function common to any da850 board using RMII, could it be
extracted to a shared .c file?
[...]
+#ifdef CONFIG_NAND_DAVINCI
+ /*
+ * NAND CS setup - cycle counts based on da850evm NAND timings in the
+ * Linux kernel @ 25MHz EMIFA
+ */
+ writel((DAVINCI_ABCR_WSETUP(0) |
+ DAVINCI_ABCR_WSTROBE(0) |
+ DAVINCI_ABCR_WHOLD(0) |
+ DAVINCI_ABCR_RSETUP(0) |
+ DAVINCI_ABCR_RSTROBE(1) |
+ DAVINCI_ABCR_RHOLD(0) |
+ DAVINCI_ABCR_TA(0) |
+ DAVINCI_ABCR_ASIZE_8BIT),
+ davinci_emif_regs-ab2cr); /* CS3 */
+#endif
This looks like it was copied from da850evm.c; note that these timings
are based on the integer multiples of EMA_CLK periods that meet the
timing specifications of the NAND chip found on the UI board. A
different part could have different timings...
Also, from your description of the ea20: It supports SPI Flash,
Ethernet with RMII. -- there is no NAND support.
[...]
+int board_eth_init(bd_t *bis)
+{
+ if (!davinci_emac_initialize()) {
+ printf(Error: Ethernet init failed!\n);
+ return -1;
+ }
+
+ /*
+ * This board has a RMII PHY. However, the MDC line on the SOM
+ * must not be disabled (there is no MII PHY on the
+ * baseboard) via the GPIO2[6], because this pin
+ * disables at the same time the SPI flash.
+ */
+
+ return 0;
+}
+#endif /* CONFIG_DRIVER_TI_EMAC */
Perhaps it would be prudent to _enable_ the MDC line via the GPIO2[6]
pin instead of a no-op.
--
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] don't touch non-existent EHCI regs on MPC837x.
Wolfgang, Dear Andre Schwarz, In message4ce14e3e.7060...@matrix-vision.de you wrote: This doesn't seem quite right, the MPC837x has USB controllers. yes, it has - and it is working fine. But USB register range 0x00-0xff is reserved and hangs the CPU. With this patch USB is working fine on at least MPC8377. Then the commit message should make this clear. At the moment it is pretty much misleading. I didn't add this #ifdef but extended it to not only match 834x but also 837x. All I see is that the ifdef'ed code accesses registers which are explicitely reserved on MPC834x and at least MPC837x. What would be an appropriate commit message from your point of view ? Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] don't touch non-existent EHCI regs on MPC837x.
Dear Andre Schwarz, In message 4ce1572c.6080...@matrix-vision.de you wrote: This doesn't seem quite right, the MPC837x has USB controllers. yes, it has - and it is working fine. But USB register range 0x00-0xff is reserved and hangs the CPU. With this patch USB is working fine on at least MPC8377. Then the commit message should make this clear. At the moment it is pretty much misleading. I didn't add this #ifdef but extended it to not only match 834x but also 837x. All I see is that the ifdef'ed code accesses registers which are explicitely reserved on MPC834x and at least MPC837x. Yes, I don't think this was objected at all. What would be an appropriate commit message from your point of view ? Well, above you wrote USB register range 0x00-0xff is reserved and hangs the CPU - this probably explains the situation pretty well. However, the subject non-existent EHCI regs suggests to me that there are no USB registers at all. 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 Uncertain fortune is thoroughly mastered by the equity of the calcu- lation. - Blaise Pascal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] don't touch non-existent EHCI regs on MPC837x.
Am 15.11.2010 17:16, schrieb Wolfgang Denk: Dear Andre Schwarz, In message4ce1572c.6080...@matrix-vision.de you wrote: This doesn't seem quite right, the MPC837x has USB controllers. yes, it has - and it is working fine. But USB register range 0x00-0xff is reserved and hangs the CPU. With this patch USB is working fine on at least MPC8377. Then the commit message should make this clear. At the moment it is pretty much misleading. I didn't add this #ifdef but extended it to not only match 834x but also 837x. All I see is that the ifdef'ed code accesses registers which are explicitely reserved on MPC834x and at least MPC837x. Yes, I don't think this was objected at all. What would be an appropriate commit message from your point of view ? Well, above you wrote USB register range 0x00-0xff is reserved and hangs the CPU - this probably explains the situation pretty well. However, the subject non-existent EHCI regs suggests to me that there are no USB registers at all. understood - will wait for further comments and resubmit tomorrow. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
The experts found an issue within init code and it looks like a proper patch will be added to mainline shortly. The discussion of the proper fix is right in this thread ... It should be timing issue in the SoC, software did not have a proper process to handle IMMR registers accessing. I agree Kumar on this. Adding the read back with load is needing for the LAW window changing. And something like sync/eieio instruction also need to be added between stw and lwz... to have a proper order accessing. Thanks, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
The experts found an issue within init code and it looks like a proper patch will be added to mainline shortly. The discussion of the proper fix is right in this thread ... It should be timing issue in the SoC, software did not have a proper process to handle IMMR registers accessing. I agree Kumar on this. Adding the read back with load is needing for the LAW window changing. And something like sync/eieio instruction also need to be added between stw and lwz... to have a proper order accessing. Then please drum up a patch. ATM there is a lot of comments on how it should be done by various freescale people but no patch. I am not entering this rat nest again. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Hanging in kmalloc of nand_scan_tail() function
On Sat, 13 Nov 2010 11:43:23 +0800 terry gliumailena...@gmail.com wrote: and the following is part of malloc after disassembled, you can find the detailed content of malloc in the attachment malloc.dis file(I'm not sure which part could be useful,so I attached whole malloc). 61 33f8fb84: 9a04bls 33f8fb9c malloc+0xf8 62 33f8fb88: e59f352cldr r3, [pc, #1324] ; 33f900bc malloc +0x618 63 33f8fb8c: e1520003cmp r2, r3 64 33f8fb90: 91a0392alsrls r3, sl, #18 65 33f8fb94: 83a0207emovhi r2, #126; 0x7e 66 33f8fb98: 9283207caddls r2, r3, #124; 0x7c 67 33f8fb9c: e59f3514ldr r3, [pc, #1300] ; 33f900b8 malloc +0x614 68 33f8fba0: e0834182add r4, r3, r2, lsl #3 69 33f8fba4: e594000cldr r0, [r4, #12] 70 33f8fba8: ea12b 33f8fbf8 malloc+0x154 71 33f8fbac: e5903004ldr r3, [r0, #4] 72 33f8fbb0: e3c33003bic r3, r3, #3 ; 0x3 //it seems that exception occurs here 73 33f8fbb4: e06a1003rsb r1, sl, r3 This is the instruction that it faulted on -- but it's not a memory access instruction. Could it be an asynchronous data abort (more like a machine check)? It's been a while since I've done ARM stuff. /me googles ARM exceptions Hmm, data aborts record PC+8 rather than PC? Who comes up with this stuff? :-P Could you look up the line number information for 0x33f8fbac? From the full-function disasm, I'd expect ip to equal r0 at this point -- but they don't in the dump. -scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ProgramCheck exception when u-boot starts
Hi, I am currently trying to get u-boot working on our new P2020E card. The card is using 512 Mbyte DDR3 memmory and a 128 MByte NOR flash. For my tests I also have a P2020-RDB card and a BDI3000. I have been able to get u-boot working from flash, but the problems begin when the in_ram function is called. The result is always a ProgramCheck exception. I have verified that the u-boot is correctly copied into ram (so the relocate_code seems to work) and I have made some simple memtests (run from flash) to test my DDR3 settings and verified the tests together with our hw guys and the signals seems to be ok. I haven't been able to run gdb on our board (don't know why, works great on the P2020-RDB) so I can't step in the code. What can be course of my ProgramCheck exception and how should I proceed with my tests? thanks in advance Per Dalén ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
[Responding here rather than directly to Dave since his e-mail showed up blank here for some reason] On Mon, 15 Nov 2010 18:30:46 +0100 Joakim Tjernlund joakim.tjernl...@transmode.se wrote: The experts found an issue within init code and it looks like a proper patch will be added to mainline shortly. The discussion of the proper fix is right in this thread ... It should be timing issue in the SoC, software did not have a proper process to handle IMMR registers accessing. I agree Kumar on this. Adding the read back with load is needing for the LAW window changing. And something like sync/eieio instruction also need to be added between stw and lwz... to have a proper order accessing. Wouldn't the fact that you're accessing the same address -- and that it's cache inhibited -- eliminate the need for a sync instruction between the stw and lwz? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
On Mon, Nov 15, 2010 at 03:15:53PM +0100, Daniel Hobi wrote: Did you locally fix arch/arm/cpu/arm926ejs/kirkwood/timer.c to not access uninitialized data (variables timestamp and lastdec) before relocation? I didn't before, but now I have made that change (moved the static vars in timer.c to global_data and reference them via gd). But I get the same behavior (freezing after printing NAND: ). Then I rebuilt my branch with the partial-linking patch applied, but rebased on today's master, and now that fails in the same way. So there's some low-level thing going on that unrelated changes in the source code or build process seem to trigger. Different link order, code placement, phase of moon, ...? I have a JTAG setup, but so far I've only used it to re-load u-boot to RAM after a flashing a bad image. If anyone can give me a clue how to use it with gdb to debug what's going on, please let me know. -- Eric Cooper e c c @ c m u . e d u ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] Blackfin: stick ins/outs funcs into their own .text section
This lets the linker garbage collect these functions when they aren't actually used by placing them into the standard .text.func section. Signed-off-by: Mike Frysinger vap...@gentoo.org --- arch/blackfin/lib/ins.S |1 + arch/blackfin/lib/outs.S |4 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/blackfin/lib/ins.S b/arch/blackfin/lib/ins.S index 4519596..3ac6d84 100644 --- a/arch/blackfin/lib/ins.S +++ b/arch/blackfin/lib/ins.S @@ -71,6 +71,7 @@ */ #define COMMON_INS(func, ops) \ +.section .text._ins##func; \ ENTRY(_ins##func) \ P0 = R0;/* P0 = port */ \ CLI_OUTER; /* 3 instructions before first read access */ \ diff --git a/arch/blackfin/lib/outs.S b/arch/blackfin/lib/outs.S index 90c6033..253d4c3 100644 --- a/arch/blackfin/lib/outs.S +++ b/arch/blackfin/lib/outs.S @@ -12,6 +12,7 @@ .align 2 +.section .text._outsl ENTRY(_outsl) P0 = R0;/* P0 = port */ P1 = R1;/* P1 = address */ @@ -23,6 +24,7 @@ ENTRY(_outsl) RTS; ENDPROC(_outsl) +.section .text._outsw ENTRY(_outsw) P0 = R0;/* P0 = port */ P1 = R1;/* P1 = address */ @@ -34,6 +36,7 @@ ENTRY(_outsw) RTS; ENDPROC(_outsw) +.section .text._outsb ENTRY(_outsb) P0 = R0;/* P0 = port */ P1 = R1;/* P1 = address */ @@ -45,6 +48,7 @@ ENTRY(_outsb) RTS; ENDPROC(_outsb) +.section .text._outsw_8 ENTRY(_outsw_8) P0 = R0;/* P0 = port */ P1 = R1;/* P1 = address */ -- 1.7.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] Blackfin: make sure bss len is multiple of 4 bytes
The Blackfin on-chip BootROM requires that fill operations (which is used for the bss) be aligned to 4 bytes (base addr and total len). Plus, the Blackfin early init asm code assumes the same thing. So rather than making things work for no real gain, make sure the bss len is padded to 4 bytes in the linker script. Signed-off-by: Mike Frysinger vap...@gentoo.org --- arch/blackfin/lib/u-boot.lds.S |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/blackfin/lib/u-boot.lds.S b/arch/blackfin/lib/u-boot.lds.S index 9163d20..f15c97e 100644 --- a/arch/blackfin/lib/u-boot.lds.S +++ b/arch/blackfin/lib/u-boot.lds.S @@ -147,6 +147,7 @@ SECTIONS *(.dynbss) *(.bss .bss.*) *(COMMON) + . = ALIGN(4); } ram_data __bss_vma = ADDR(.bss); __bss_len = SIZEOF(.bss); -- 1.7.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] writing board_nand_init for pollux vr3520F
On Sat, 13 Nov 2010 17:33:02 + Miguel José Amez Riendas miguel.a...@mercatest.com wrote: Hi list, this is my first post on u-boot list. I'm trying to write function board_nand_init for a Pollux VR3520F SoC based board. I'm having some troubles and really don't know very good where to start and which parts of nand_chip pointer have to be filled and which not. Could you please help me a little bit on this? Does its NAND controller resemble any of the drivers under drivers/mtd/nand? If so, look at what other boards using that controller are doing. If not, you'll need to write a controller driver. What that driver looks like depends on how the hardware works -- do you have a simple interface to read/write bytes or words, and raise/lower some signals? Maybe with an ECC accelerator? Or does the hardware isolate you more from the hardware details, such that you program it to do high level operations such as read page, erase block, etc? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking
On Monday, November 15, 2010 03:09:50 Sebastien Carlier wrote: On 2010-11-15 08:51:29, Wolfgang Denk wrote: In message 20101110080708.ga8...@safe.home.local you wrote: Good suggestion, done in v3: I have to admit that I lost a bit of overview of the current state of this work. My understanding is that you are preparing a new version (V4 ?) of this patch? If yes, do you have any estimates when this will be available? I just uploaded the revised patch here: http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from- archive- libraries-to-partial-linking-v4.patch Version 4: Bring in Linux comment for cmd_link_o_target. Fix drivers/qe/Makefile to build libqe.o, not qe.o. I pulled the latest changes before making the patch and there was no conflict, but please let me know if you see anything wrong with it. Tested-by: Mike Frysinger vap...@gentoo.org (Blackfin boards) -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] bug in malloc/calloc and setting of MORECORE_CLEARS
On Nov 13, 2010, at 10:34 AM, Kumar Gala wrote:
I've been debugging a memory corruption issue and it seems to come down to
how we set MORECORE_CLEARS
from malloc.h:
MORECORE (default: sbrk)
The name of the routine to call to obtain more memory from the system.
MORECORE_FAILURE (default: -1)
The value returned upon failure of MORECORE.
MORECORE_CLEARS (default 1)
True (1) if the routine mapped to MORECORE zeroes out memory (which
holds for sbrk).
So the issue I'm seeing is that we zero out memory in mem_malloc_init().
Thus our sbrk implementation just does simple record keeping. However we can
get into the following situation:
a1 = malloc(LARGE_SZ);/* causes internals to call sbrk */
...
/* use memory at 'a1' */
...
free(a1); /* causes internals to call malloc_trim, malloc_trim decides to
return memory to sbrk, memory is now nonzero */
a2 = calloc(SIZE);/* internals assume sbrk memory is zero because of
MORECORE_CLEARS setting, however its not */
... BAD THINGS HAPPEN ...
I'm guessing we haven't seen much of this because there aren't that many
users of calloc today. I happen to see it related to NAND code which has
kzalloc defined as calloc.
Here's an example test case that fails if execute right after:
mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);
{
void *p1;
u8 *p2;
int i;
printf(MALLOC TEST\n);
p1 = malloc(135176);
printf(P1 = %p\n, p1);
memset(p1, 0xab, 135176);
free(p1);
p2 = calloc(4097, 1);
printf(P2 = %p %p\n, p2, p2 + 4097);
for (i = 0; i 4097; i++) {
if (p2[i] != 0)
printf(miscompare at byte %d got %x\n, i,
p2[i]);
}
free(p2);
printf(END MALLOC TEST\n\n);
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ProgramCheck exception when u-boot starts
Dear =?ISO-8859-1?Q?Per_Dal=E9n?=, In message aanlktikvkzpqwxqpqtcp72tq6q0bmbasn_y_axg3h...@mail.gmail.com you wrote: What can be course of my ProgramCheck exception and how should I proceed with my tests? Re-check your memory initialization. See http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation 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 ADVISORY: There is an Extremely Small but Nonzero Chance That, Through a Process Know as Tunneling, This Product May Spontaneously Disappear from Its Present Location and Reappear at Any Random Place in the Universe, Including Your Neighbor's Domicile. The Manufacturer Will Not Be Responsible for Any Damages or Inconvenience That May Result. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bug in malloc/calloc and setting of MORECORE_CLEARS
Dear Kumar Gala, In message 9d70a5ef-48ad-4d65-85d6-b81ce0a0d...@kernel.crashing.org you wrote: Here's an example test case that fails if execute right after: I confirm that the test case shows errors for me, too (tested on TQM8555). I also confirm that switching MORECORE_CLEARS to 0 fixes the problem in this test. Are you going to submit a patch? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I wish Captain Vimes were here. He wouldn't have known what to do either, but he's got a much better vocabulary to be baffled in. - Terry Pratchett, _Guards! Guards!_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bug in malloc/calloc and setting of MORECORE_CLEARS
On Nov 15, 2010, at 2:39 PM, Wolfgang Denk wrote: Dear Kumar Gala, In message 9d70a5ef-48ad-4d65-85d6-b81ce0a0d...@kernel.crashing.org you wrote: Here's an example test case that fails if execute right after: I confirm that the test case shows errors for me, too (tested on TQM8555). I also confirm that switching MORECORE_CLEARS to 0 fixes the problem in this test. Are you going to submit a patch? Yes, but going to try a different solution in which we memset and sbrk calls that have a negative increment (free). - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V5 1/2] ARM: fix linker file for newer ld support
older ld emitted all ELF relocations in input sections named
.rel.dyn, whereas newer ld uses names of the form .rel*. The
linker script only collected .rel.dyn input sections. Rewrite
to collect all .rel* input sections.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
V1 Initial submission
V2 arm926ejs: added ALIGN between bss and .rel.dyn sections
tx25: removed GOT and datarel output sections
tx25: fixed typo in config file commit message
V3 arm926ejs: overlaid .bss and .rel.dyn sections
tx25: overlaid .bss and .rel.dyn sections
V4 arm926ejs and tx25: fixed overlay
tx25: removed third patch as u-boot size remains small enough
V5 added u-boot.lds/start.S fix for arm1136, arm1176, pxa, armv7.
arch/arm/cpu/arm1136/start.S | 16 -
arch/arm/cpu/arm1136/u-boot.lds | 38 --
arch/arm/cpu/arm1176/u-boot.lds | 37 ++---
arch/arm/cpu/arm926ejs/u-boot.lds | 30 ++-
arch/arm/cpu/armv7/start.S| 24 ---
arch/arm/cpu/armv7/u-boot.lds | 46 -
arch/arm/cpu/pxa/u-boot.lds | 35 +++-
7 files changed, 105 insertions(+), 121 deletions(-)
diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index aecc943..eec8bee 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -104,22 +104,6 @@ _bss_start_ofs:
_bss_end_ofs:
.word _end - _start
-.globl _datarel_start_ofs
-_datarel_start_ofs:
- .word __datarel_start - _start
-
-.globl _datarelrolocal_start_ofs
-_datarelrolocal_start_ofs:
- .word __datarelrolocal_start - _start
-
-.globl _datarellocal_start_ofs
-_datarellocal_start_ofs:
- .word __datarellocal_start - _start
-
-.globl _datarelro_start_ofs
-_datarelro_start_ofs:
- .word __datarelro_start - _start
-
#ifdef CONFIG_USE_IRQ
/* IRQ stack memory (calculated at run-time) */
.globl IRQ_STACK_START
diff --git a/arch/arm/cpu/arm1136/u-boot.lds b/arch/arm/cpu/arm1136/u-boot.lds
index 31f43f0..253adbe 100644
--- a/arch/arm/cpu/arm1136/u-boot.lds
+++ b/arch/arm/cpu/arm1136/u-boot.lds
@@ -20,7 +20,8 @@
*
* 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
+ * 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
@@ -49,23 +50,9 @@ SECTIONS
. = ALIGN(4);
.data : {
*(.data)
- __datarel_start = .;
- *(.data.rel)
- __datarelrolocal_start = .;
- *(.data.rel.ro.local)
- __datarellocal_start = .;
- *(.data.rel.local)
- __datarelro_start = .;
- *(.data.rel.ro)
}
. = ALIGN(4);
- __rel_dyn_start = .;
- .rel.dyn : { *(.rel.dyn) }
- __rel_dyn_end = .;
-
- __dynsym_start = .;
- .dynsym : { *(.dynsym) }
. = .;
__u_boot_cmd_start = .;
@@ -73,9 +60,24 @@ SECTIONS
__u_boot_cmd_end = .;
. = ALIGN(4);
- __bss_start = .;
- .bss (NOLOAD) : { *(.bss) . = ALIGN(4); }
- _end = .;
+
+ .rel.dyn : {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ }
+
+ .dynsym : {
+ __dynsym_start = .;
+ *(.dynsym)
+ }
+
+ .bss __rel_dyn_start (OVERLAY) : {
+ __bss_start = .;
+ *(.bss)
+. = ALIGN(4);
+ _end = .;
+ }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynamic*) }
diff --git a/arch/arm/cpu/arm1176/u-boot.lds b/arch/arm/cpu/arm1176/u-boot.lds
index d9ed954..fe31800 100644
--- a/arch/arm/cpu/arm1176/u-boot.lds
+++ b/arch/arm/cpu/arm1176/u-boot.lds
@@ -41,33 +41,32 @@ SECTIONS
. = ALIGN(4);
.data : {
*(.data)
- __datarel_start = .;
- *(.data.rel)
- __datarelrolocal_start = .;
- *(.data.rel.ro.local)
- __datarellocal_start = .;
- *(.data.rel.local)
- __datarelro_start = .;
- *(.data.rel.ro)
}
- . = ALIGN(4);
- __rel_dyn_start = .;
- .rel.dyn : { *(.rel.dyn) }
- __rel_dyn_end = .;
-
- __dynsym_start = .;
- .dynsym : { *(.dynsym) }
-
. = .;
__u_boot_cmd_start = .;
.u_boot_cmd : { *(.u_boot_cmd) }
__u_boot_cmd_end = .;
. = ALIGN(4);
- __bss_start = .;
- .bss (NOLOAD) : { *(.bss) . = ALIGN(4); }
- _end = .;
+
+ .rel.dyn : {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ }
+
+
[U-Boot] [PATCH V5 2/2] tx25: fix linker file for newer ld support
older ld emitted all ELF relocations in input sections named
.rel.dyn, whereas newer ld uses names of the form .rel*. The
linker script only collected .rel.dyn input sections. Rewrite
to collect all .rel* input sections.
Signed-off-by: Albert Aribaud albert.arib...@free.fr
---
nand_spl/board/karo/tx25/u-boot.lds | 40 --
1 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/nand_spl/board/karo/tx25/u-boot.lds
b/nand_spl/board/karo/tx25/u-boot.lds
index 5f95c87..ff289fb 100644
--- a/nand_spl/board/karo/tx25/u-boot.lds
+++ b/nand_spl/board/karo/tx25/u-boot.lds
@@ -43,35 +43,33 @@ SECTIONS
. = ALIGN(4);
.data : {
*(.data)
- __datarel_start = .;
- *(.data.rel)
- __datarelrolocal_start = .;
- *(.data.rel.ro.local)
- __datarellocal_start = .;
- *(.data.rel.local)
- __datarelro_start = .;
- *(.data.rel.ro)
}
. = ALIGN(4);
- __rel_dyn_start = .;
- __rel_dyn_end = .;
- __dynsym_start = .;
-
- __got_start = .;
- . = ALIGN(4);
- .got : { *(.got) }
-
- __got_end = .;
- . = .;
__u_boot_cmd_start = .;
.u_boot_cmd : { *(.u_boot_cmd) }
__u_boot_cmd_end = .;
. = ALIGN(4);
- __bss_start = .;
- .bss : { *(.bss) }
- _end = .;
+
+ .rel.dyn : {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ }
+
+ .dynsym : {
+ __dynsym_start = .;
+ *(.dynsym)
+ }
+
+ .bss __rel_dyn_start (OVERLAY) : {
+ __bss_start = .;
+ *(.bss)
+. = ALIGN(4);
+ _end = .;
+ }
+
/DISCARD/ : { *(.bss*) }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynsym*) }
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 1/2] ARM: fix linker file for newer ld support
Le 15/11/2010 21:46, Albert Aribaud a écrit : older ld emitted all ELF relocations in input sections named .rel.dyn, whereas newer ld uses names of the form .rel*. The linker script only collected .rel.dyn input sections. Rewrite to collect all .rel* input sections. Signed-off-by: Albert Aribaudalbert.arib...@free.fr --- V1Initial submission V2arm926ejs: added ALIGN between bss and .rel.dyn sections tx25: removed GOT and datarel output sections tx25: fixed typo in config file commit message V3arm926ejs: overlaid .bss and .rel.dyn sections tx25: overlaid .bss and .rel.dyn sections V4arm926ejs and tx25: fixed overlay tx25: removed third patch as u-boot size remains small enough V5added u-boot.lds/start.S fix for arm1136, arm1176, pxa, armv7. Builds for at least one board of each cpu, but otherwise untested except for arm926 openrd_base. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] malloc: Fix issue with calloc memory possibly being non-zero
Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always
returns zero'd out memory. However since its possible that free()
returns memory ack to sbrk() via malloc_trim we could possible get
non-zero'd memory from sbrk() if it allocates back memory that was
previously freed to it.
There are two possible solutions to this problem.
1. change #define MORECORE_CLEARS 0
2. memset to zero memory returned to sbrk.
We go with the second since the sbrk being called to free up memory
should be pretty rare.
The following code problems an example test to show the issue. This
test code was inserted right after the call to mem_malloc_init(). we
could possible get non-zero'd memory from sbrk() if it allocates back
memory that was previously freed to it.
There are two possible solutions to this problem.
1. change #define MORECORE_CLEARS 0
2. memset to zero memory returned to sbrk.
We go with the second since the sbrk being called to free up memory
should be pretty rare.
The following code problems an example test to show the issue. This
test code was inserted right after the call to mem_malloc_init().
...
u8 *p2;
int i;
printf(MALLOC TEST\n);
p1 = malloc(135176);
printf(P1 = %p\n, p1);
memset(p1, 0xab, 135176);
free(p1);
p2 = calloc(4097, 1);
printf(P2 = %p %p\n, p2, p2 + 4097);
for (i = 0; i 4097; i++) {
if (p2[i] != 0)
printf(miscompare at byte %d got %x\n, i, p2[i]);
free(p2);
printf(END MALLOC TEST\n\n);
...
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
common/dlmalloc.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 4871f4b..e9bab09 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1511,6 +1511,13 @@ void *sbrk(ptrdiff_t increment)
ulong old = mem_malloc_brk;
ulong new = old + increment;
+ /*
+* if we are giving memory back make sure we clear it out since
+* we set MORECORE_CLEARS to 1
+*/
+ if (increment 0)
+ memset((void *)new, 0, -increment);
+
if ((new mem_malloc_start) || (new mem_malloc_end))
return (void *)MORECORE_FAILURE;
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] malloc: Fix issue with calloc memory possibly being non-zero
On Monday, November 15, 2010 15:51:14 Kumar Gala wrote: returns memory ack to sbrk() via malloc_trim we could possible get ack - back The following code problems an example test to show the issue. i dont understand this sentence we could possible get non-zero'd memory from sbrk() if it allocates back memory that was previously freed to it. There are two possible solutions to this problem. 1. change #define MORECORE_CLEARS 0 2. memset to zero memory returned to sbrk. We go with the second since the sbrk being called to free up memory should be pretty rare. The following code problems an example test to show the issue. This test code was inserted right after the call to mem_malloc_init(). this looks like the changelog is partially duplicated -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] malloc: Fix issue with calloc memory possibly being non-zero
Dear Kumar Gala, In message 1289854274-7006-1-git-send-email-ga...@kernel.crashing.org you wrote: Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always returns zero'd out memory. However since its possible that free() returns memory ack to sbrk() via malloc_trim we could possible get non-zero'd memory from sbrk() if it allocates back memory that was previously freed to it. I confirm that the test case works fine here, too. So: Tested-by: Wolfgang Denk w...@denx.de But the commit message needs serious rework before this can get applied. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If ignorance is bliss, why aren't there more happy people? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] jz4740 nand spl files
On Thu, 11 Nov 2010 11:37:35 +0800
Xiangfu Liu xian...@openmobilefree.net wrote:
+$(nandobj)u-boot-spl-16k.bin: $(nandobj)u-boot-spl.bin
+ dd bs=1024 count=8 if=/dev/zero of=$(nandobj)junk1
+ cat $ $(nandobj)junk1 $(nandobj)junk2
+ dd bs=1024 count=8 if=$(nandobj)junk2 of=$(nandobj)junk3
+ cat $(nandobj)junk3 $(nandobj)junk3 $(nandobj)junk4
+ dd bs=1024 count=256 if=/dev/zero of=$(nandobj)junk5
+ cat $(nandobj)junk4 $(nandobj)junk5 $(nandobj)junk6
+ dd bs=1024 count=256 if=$(nandobj)junk6 of=$@
+ rm -f $(nandobj)junk*
Why do you need all this?
+#define __nand_enable() (REG_EMC_NFCSR |= EMC_NFCSR_NFE1 |
EMC_NFCSR_NFCE1)
+#define __nand_disable() (REG_EMC_NFCSR = ~(EMC_NFCSR_NFCE1))
+#define __nand_ecc_rs_encoding() \
+ (REG_EMC_NFECR = EMC_NFECR_ECCE | EMC_NFECR_ERST | EMC_NFECR_RS |
EMC_NFECR_RS_ENCODING)
+#define __nand_ecc_rs_decoding() \
+ (REG_EMC_NFECR = EMC_NFECR_ECCE | EMC_NFECR_ERST | EMC_NFECR_RS |
EMC_NFECR_RS_DECODING)
+#define __nand_ecc_disable() (REG_EMC_NFECR = ~EMC_NFECR_ECCE)
+#define __nand_ecc_encode_sync() while (!(REG_EMC_NFINTS EMC_NFINTS_ENCF))
+#define __nand_ecc_decode_sync() while (!(REG_EMC_NFINTS EMC_NFINTS_DECF))
+#define __nand_cmd(n)(REG8(NAND_COMMPORT) = (n))
+#define __nand_addr(n) (REG8(NAND_ADDRPORT) = (n))
+#define __nand_data8() REG8(NAND_DATAPORT)
+#define __nand_data16() REG16(NAND_DATAPORT)
Drop the leading underscores.
Use I/O accessors.
Consider making some of these inline functions -- or just open-coding
for the really simple ones.
+#if (JZ4740_NANDBOOT_CFG == JZ4740_NANDBOOT_B8R3)
+ #define NAND_BUS_WIDTH 8
+ #define NAND_ROW_CYCLE 3
+#elif (JZ4740_NANDBOOT_CFG == JZ4740_NANDBOOT_B8R2)
+ #define NAND_BUS_WIDTH 8
+ #define NAND_ROW_CYCLE 2
+#elif (JZ4740_NANDBOOT_CFG == JZ4740_NANDBOOT_B16R3)
+ #define NAND_BUS_WIDTH 16
+ #define NAND_ROW_CYCLE 3
+#elif (JZ4740_NANDBOOT_CFG == JZ4740_NANDBOOT_B16R2)
+ #define NAND_BUS_WIDTH 16
+ #define NAND_ROW_CYCLE 2
+#endif
+
+static inline void __nand_dev_ready(void)
+{
+ unsigned int timeout = 1;
+ while ((REG_GPIO_PXPIN(2) 0x4000) timeout--);
+ while (!(REG_GPIO_PXPIN(2) 0x4000));
+}
Hmm, why a timeout here and not on any of the other spin loops?
+/*
+ * NAND flash parameters
+ */
+static int page_size = 2048;
+static int oob_size = 64;
+static int ecc_count = 4;
+static int page_per_block = 64;
+static int bad_block_pos = 0;
+static int block_size = 131072;
You initialize these here, and then you set them to other constant
values in nand_boot(). And then you test them for specific values
later.
What's going on? If you're not dynamically detecting these, then have
them be constants (either #defines or static const int). It will
allow the compiler to generate smaller code.
+static unsigned char oob_buf[128] = {0};
Be careful, this may still go into the BSS even with the assignment.
Is the BSS getting cleared in the SPL boot code on this platform? Do
you actually rely on it being zero initially?
Either way, the assignment doesn't do much.
+/*
+ * External routines
+ */
+extern void flush_cache_all(void);
+extern int serial_init(void);
+extern void serial_puts(const char *s);
+extern void sdram_init(void);
+extern void pll_init(void);
+extern void usb_boot();
Get these from the appropriate header file.
+ /* Error occurred */
+ /* serial_puts(Error occurred\n); */
+ if (stat EMC_NFINTS_UNCOR) {
+ /* Uncorrectable error occurred */
+ /* serial_puts(Uncorrectable error
occurred\n); */
Why is this commented out?
If it's for space concerns, the strings could be shrunk and still get a
message out.
+ } else {
+ unsigned int errcnt, index, mask;
+
+ errcnt = (stat EMC_NFINTS_ERRCNT_MASK)
EMC_NFINTS_ERRCNT_BIT;
+ switch (errcnt) {
+ case 4:
+ index = (REG_EMC_NFERR3
EMC_NFERR_INDEX_MASK) EMC_NFERR_INDEX_BIT;
+ mask = (REG_EMC_NFERR3
EMC_NFERR_MASK_MASK) EMC_NFERR_MASK_BIT;
+ rs_correct(tmpbuf, index, mask);
+ /* FALL-THROUGH */
+ case 3:
+ index = (REG_EMC_NFERR2
EMC_NFERR_INDEX_MASK) EMC_NFERR_INDEX_BIT;
+ mask = (REG_EMC_NFERR2
EMC_NFERR_MASK_MASK) EMC_NFERR_MASK_BIT;
+ rs_correct(tmpbuf, index, mask);
+ /* FALL-THROUGH */
+ case 2:
+
Re: [U-Boot] [PATCH 4/5] jz4740 nand driver
On Thu, 11 Nov 2010 11:37:36 +0800 Xiangfu Liu xian...@openmobilefree.net wrote: From: Xiangfu Liu xian...@sharism.cc Signed-off-by: Xiangfu Liu xian...@openmobilefree.net --- drivers/mtd/nand/jz4740_nand.c | 250 1 files changed, 250 insertions(+), 0 deletions(-) create mode 100644 drivers/mtd/nand/jz4740_nand.c Same comments as on nand_spl. Also, this looks like the type of controller that could work with the standard nand_boot.c -- is there something preventing that? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: e1000: typo using wrong argument to sizeof
Typo from 4b29bdb0ed08412d225a8be94f61fc6c37a59dd5 Signed-off-by: Matthew McClintock m...@freescale.com --- drivers/net/e1000.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c index 18584ef..60b04c2 100644 --- a/drivers/net/e1000.c +++ b/drivers/net/e1000.c @@ -5189,7 +5189,7 @@ e1000_initialize(bd_t * bis) return 0; } - memset(nic, 0, sizeof(*dev)); + memset(nic, 0, sizeof(*nic)); memset(hw, 0, sizeof(*hw)); hw-pdev = devno; -- 1.6.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
Wouldn't the fact that you're accessing the same address -- and that it's cache inhibited -- eliminate the need for a sync instruction between the stw and lwz? You are right. If st and ld the same address, e300 core have a address collision inside. It will make sure the order. Here we don't need the sync. I meant we should access the IMMR register with something like I/O accessors to have a correct access order. Thanks, Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] malloc: Fix issue with calloc memory possibly being non-zero
On Nov 15, 2010, at 4:06 PM, Wolfgang Denk wrote: Dear Kumar Gala, In message 1289854274-7006-1-git-send-email-ga...@kernel.crashing.org you wrote: Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always returns zero'd out memory. However since its possible that free() returns memory ack to sbrk() via malloc_trim we could possible get non-zero'd memory from sbrk() if it allocates back memory that was previously freed to it. I confirm that the test case works fine here, too. So: Tested-by: Wolfgang Denk w...@denx.de But the commit message needs serious rework before this can get applied. Oops, will fix and repost. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] malloc: Fix issue with calloc memory possibly being non-zero
Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always
returns zero'd out memory. However since its possible that free()
returns memory back to sbrk() via malloc_trim we could possible get
non-zero'd memory from sbrk(). This is a problem for when code might
call calloc() and expect the memory to have been zero'd out.
There are two possible solutions to this problem.
1. change #define MORECORE_CLEARS 0
2. memset to zero memory returned to sbrk.
We go with the second since the sbrk being called to free up memory
should be pretty rare.
The following code problems an example test to show the issue. This
test code was inserted right after the call to mem_malloc_init().
...
u8 *p2;
int i;
printf(MALLOC TEST\n);
p1 = malloc(135176);
printf(P1 = %p\n, p1);
memset(p1, 0xab, 135176);
free(p1);
p2 = calloc(4097, 1);
printf(P2 = %p %p\n, p2, p2 + 4097);
for (i = 0; i 4097; i++) {
if (p2[i] != 0)
printf(miscompare at byte %d got %x\n, i, p2[i]);
free(p2);
printf(END MALLOC TEST\n\n);
...
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Tested-by: Wolfgang Denk w...@denx.de
---
* Fix commit message screw up
common/dlmalloc.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 4871f4b..e9bab09 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1511,6 +1511,13 @@ void *sbrk(ptrdiff_t increment)
ulong old = mem_malloc_brk;
ulong new = old + increment;
+ /*
+* if we are giving memory back make sure we clear it out since
+* we set MORECORE_CLEARS to 1
+*/
+ if (increment 0)
+ memset((void *)new, 0, -increment);
+
if ((new mem_malloc_start) || (new mem_malloc_end))
return (void *)MORECORE_FAILURE;
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Custodian changes, using Patchwork
For now, I would like to ask all CUSTODIANS to register as users at patchwork.ozlabs.org, so we can arrange that the appropriate privileges will be granted to you. Registered as 'macpaul'. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] mmc: Add multi-block read support to the generic mmc driver
Dear Steve Sakoman, On 29 October 2010 02:17, Steve Sakoman st...@sakoman.com wrote: From: Alagu Sankar alagusankar at embwise.com This patch adds multi-block read support for the generic MMC driver. Large reads are broken into chunks of 65535 blocks to ensure that the code works with controllers having a 16 bit block counter. This patch results in a significant performance improvement. Time to read a 45 MB file went from 36 seconds to 9 seconds on Overo Signed-off-by: Steve Sakoman steve.sako...@linaro.org Tested-by: Steve Sakoman steve.sako...@linaro.org --- This is based on Alagu's original patch, but heavily modified to reflect recent changes in the driver and to remove the CONFIG option as requested in the earlier discussion of the patch: http://www.mail-archive.com/u-boot@lists.denx.de/msg32319.html It also incorporates feedback on my previously submitted RFC multi-block read patch. I am leaving authorship with Alagu since he did the original work, but will leave it up to him to add his Signed-off-by --- Tested at s5p board. It works well and shows good performance. Tested-by: Minkyu Kang mk7.k...@samsung.com Thanks! Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] imx: Get fec mac address from fuse
diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h
b/arch/arm/include/asm/arch-mx5/imx-regs.h
index 0b6249a..93eef48 100644
--- a/arch/arm/include/asm/arch-mx5/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx5/imx-regs.h
@@ -205,6 +205,9 @@
#define BOARD_REV_1_0 0x0
#define BOARD_REV_2_0 0x1
+#define IMX_IIM_BASE (IIM_BASE_ADDR)
+#define IIM_MAC 0x109
Propably we can find a way to use a structure to access to the mac
address, see my last point.
Do you have any good method to put the mac address into one structure
and use that filed to access it?
Currently, we only use the MAC fuse, there is a lot of fuse not used?
if we defined as bellow, what your comments?
struct iim_regs {
u32 stat;
u32 statm;
u32 err;
u32 emask;
u32 fctl;
u32 ua;
u32 la;
u32 sdat;
u32 prev;
u32 srev;
u32 preg_p;
u32 scs0;
u32 scs1;
u32 scs2;
u32 scs3;
u32 res0[0x1f1];
u32 iim_bank_area0_1[9];
u32 mac_addr[6];
u32 iim_bank_area0_2[0x11];
u32 res1[0xe0];
u32 iim_bank_area1[0x20];
u32 res2[0xe0];
u32 iim_bank_area2[0x20];
u32 res3[0xe0];
u32 iim_bank_area3[0x20];
u32 res4[0xe0];
};
BR,
Jason
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
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 v2 1/1] imx: Get fec mac address from fuse
Dear Jason Liu,
In message aanlktimxrzanndrochbfpohu13vuwxsbdodbuun5f...@mail.gmail.com you
wrote:
Do you have any good method to put the mac address into one structure
and use that filed to access it?
Currently, we only use the MAC fuse, there is a lot of fuse not used?
if we defined as bellow, what your comments?
struct iim_regs {
u32 stat;
u32 statm;
u32 err;
u32 emask;
u32 fctl;
u32 ua;
u32 la;
u32 sdat;
u32 prev;
u32 srev;
u32 preg_p;
u32 scs0;
u32 scs1;
u32 scs2;
u32 scs3;
u32 res0[0x1f1];
u32 iim_bank_area0_1[9];
u32 mac_addr[6];
u32 iim_bank_area0_2[0x11];
u32 res1[0xe0];
u32 iim_bank_area1[0x20];
u32 res2[0xe0];
u32 iim_bank_area2[0x20];
u32 res3[0xe0];
u32 iim_bank_area3[0x20];
u32 res4[0xe0];
};
This struct is supposed to describe some register layout defined by
the hardware - but does the hardware know anything about teh special
meaning MAC address of this specific field, or is this an
interpretation that we just define as we like?
If this is not a hardware given thing, we should not define this in
iim_regs; instead, we should define a separate struct that describes
how we decided to use iim_bank_area0.
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
It follows that any commander in chief who undertakes to carry out a
plan which he considers defective is at fault; he must put forth his
reasons, insist of the plan being changed, and finally tender his
resignation rather than be the instrument of his army's downfall.
- Napoleon, Military Maxims and Thought
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/1] imx: Get fec mac address from fuse
2010/11/16 Wolfgang Denk w...@denx.de:
Dear Jason Liu,
In message aanlktimxrzanndrochbfpohu13vuwxsbdodbuun5f...@mail.gmail.com you
wrote:
Do you have any good method to put the mac address into one structure
and use that filed to access it?
Currently, we only use the MAC fuse, there is a lot of fuse not used?
if we defined as bellow, what your comments?
struct iim_regs {
u32 stat;
u32 statm;
u32 err;
u32 emask;
u32 fctl;
u32 ua;
u32 la;
u32 sdat;
u32 prev;
u32 srev;
u32 preg_p;
u32 scs0;
u32 scs1;
u32 scs2;
u32 scs3;
u32 res0[0x1f1];
u32 iim_bank_area0_1[9];
u32 mac_addr[6];
u32 iim_bank_area0_2[0x11];
u32 res1[0xe0];
u32 iim_bank_area1[0x20];
u32 res2[0xe0];
u32 iim_bank_area2[0x20];
u32 res3[0xe0];
u32 iim_bank_area3[0x20];
u32 res4[0xe0];
};
This struct is supposed to describe some register layout defined by
the hardware - but does the hardware know anything about teh special
meaning MAC address of this specific field, or is this an
interpretation that we just define as we like?
This is defined according to the IC spec and it should be hw layout.
We can read such kind of fuse just like read register. But currently, uboot
require that all the register array should be included into one
structure and not
use the *(offset + base_addr) method, this is also stefano suggestion. But for
fuse support, there are many fuses but we only use FEC_MAC fuse
currently, this is why
I ask how to handle it better in uboot.
Stefano, what's your comments?
Thanks for your help.
If this is not a hardware given thing, we should not define this in
iim_regs; instead, we should define a separate struct that describes
how we decided to use iim_bank_area0.
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
It follows that any commander in chief who undertakes to carry out a
plan which he considers defective is at fault; he must put forth his
reasons, insist of the plan being changed, and finally tender his
resignation rather than be the instrument of his army's downfall.
- Napoleon, Military Maxims and Thought
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Sebastien, Am 15.11.2010 um 12:43 schrieb Sebastien Carlier: Dear Andreas, On 2010-11-15 12:09:58, Andreas Bießmann wrote: arm920t/at91 is ongoing. I may need your help these days but first I need some time to get my last linker related issues fixed properly (segfault when linking empty weak symbol with -pie). Can you please try the attached patch? It fixed this problem for me. yes it works, the ASSERT/SEGFAULT are gone. I've never tested to place these two sections that early in the ELF. I used to place them between .rel.dyn and .bss (after applying Albert's approach of overloading .rel.dyn with .bss). At that place I still had ASSERT/SEGFAULT failures in linker. Thanks a lot, with this information I may get the arm920t elf relocation fixed. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
