Re: [U-Boot] ARM ld: .bss overlaps section .rel.dyn
Albert, On Sat, Feb 4, 2012 at 8:35 AM, viresh kumar wrote: > On Fri, Feb 3, 2012 at 10:24 AM, Albert ARIBAUD > wrote: > >>> On 2/1/12, Amit Virdi wrote: > I'm in the process of updating platform support for spear series of > SoC on the latest u-boot. > I picked u-boot v2011.12. I tried compiling for different spear boards > (spear 300, 310, 300 and spear600). In every compilation, I'm getting > following errors: > > --- > arm-linux-ld: section .bss [007263cc -> 00728c5b] overlaps section > .rel.dyn [007263cc -> 0072a623] > arm-linux-ld: u-boot: section .bss lma 0x7263cc overlaps previous > sections > make: *** [u-boot] Error 1 > --- > > This is one case. > > > > > > In fact, .bss overlapping .rel.dyn is normal -- the linker file even > > explicitly states this with ".bss __rel_dyn_start (OVERLAY)". > > > > Ok. > > > Which compiler do you use and which board exactly are you building? > > > We are using internal STLinux distribution. I tried compiling for spear320, and I couldn't succeed. Just to move a step further, can you please try "make spear320" at your end? If the error is not received at your end, I can be sure that the problem is due to the distribution at my end. Thanks in advance. Regards Amit Virdi PS: I used v2011.12. "spear320" entry isn't there in the boards.cfg file. I shall be sending patch to update the same once I resolve this linking error. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
> On Sunday 05 February 2012 01:44:19 Simon Glass wrote: > > This permits disabling the code relation in U-Boot which is useful when > > debugging with an ICE. > > > > To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board. > > any reason for "ARM" in there ? Because this is only for ARM? M ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
> This permits disabling the code relation in U-Boot which is useful when
> debugging with an ICE.
>
> To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
>
> Signed-off-by: Simon Glass
> ---
> arch/arm/config.mk |2 ++
> arch/arm/cpu/armv7/start.S |3 +--
> arch/arm/include/asm/global_data.h |3 +++
> arch/arm/lib/board.c | 10 ++
> 4 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/config.mk b/arch/arm/config.mk
> index 45f9dca..46b52af 100644
> --- a/arch/arm/config.mk
> +++ b/arch/arm/config.mk
> @@ -79,5 +79,7 @@ endif
>
> # needed for relocation
> ifndef CONFIG_NAND_SPL
> +ifndef CONFIG_SYS_SKIP_ARM_RELOCATION
> LDFLAGS_u-boot += -pie
> endif
> +endif
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index ef08a55..82eac7c 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -183,8 +183,7 @@ stack_setup:
> mov sp, r4
>
> adr r0, _start
> - cmp r0, r6
> - moveq r9, #0 /* no relocation. relocation offset(r9) = 0 */
> + subsr9, r6, r0 /* r9 <- relocation offset */
> beq clear_bss /* skip relocation */
> mov r1, r6 /* r1 <- scratch for copy_loop */
> ldr r3, _image_copy_end_ofs
> diff --git a/arch/arm/include/asm/global_data.h
> b/arch/arm/include/asm/global_data.h index c3ff789..23a6077 100644
> --- a/arch/arm/include/asm/global_data.h
> +++ b/arch/arm/include/asm/global_data.h
> @@ -77,6 +77,9 @@ typedef struct global_data {
> unsigned long tlb_addr;
> #endif
> const void *fdt_blob; /* Our device tree, NULL if none */
> +#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION
> + ulong malloc_end; /* End of malloc region (addr + 1) */
> +#endif
> void**jt; /* jump table */
> charenv_buf[32];/* buffer for getenv() before reloc. */
> #if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index 3d78274..81293c3 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -355,6 +355,7 @@ void board_init_f(ulong bootflag)
> #endif /* CONFIG_FB_ADDR */
> #endif /* CONFIG_LCD */
>
> +#ifndef CONFIG_SYS_SKIP_ARM_RELOCATION
> /*
>* reserve memory for U-Boot code, data & bss
>* round down to next 4 kB limit
> @@ -363,6 +364,7 @@ void board_init_f(ulong bootflag)
> addr &= ~(4096 - 1);
>
> debug("Reserving %ldk for U-Boot at: %08lx\n", gd->mon_len >> 10, addr);
> +#endif
>
> #ifndef CONFIG_SPL_BUILD
> /*
> @@ -419,6 +421,10 @@ void board_init_f(ulong bootflag)
> dram_init_banksize();
> display_dram_config(); /* and display it */
>
> +#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION
> + gd->malloc_end = addr;
> + addr = _TEXT_BASE;
> +#endif
> gd->relocaddr = addr;
> gd->start_addr_sp = addr_sp;
> gd->reloc_off = addr - _TEXT_BASE;
> @@ -478,7 +484,11 @@ void board_init_r(gd_t *id, ulong dest_addr)
> #endif
>
> /* The Malloc area is immediately below the monitor copy in DRAM */
> +#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION
> + malloc_start = gd->malloc_end - TOTAL_MALLOC_LEN;
> +#else
> malloc_start = dest_addr - TOTAL_MALLOC_LEN;
> +#endif
> mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);
>
> #if !defined(CONFIG_SYS_NO_FLASH)
Why would you need this one ? Is there any user for this patch?
M
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM ld: .bss overlaps section .rel.dyn
Hi Amit, Le 05/02/2012 12:29, Amit Virdi a écrit : Albert, On Sat, Feb 4, 2012 at 8:35 AM, viresh kumar wrote: On Fri, Feb 3, 2012 at 10:24 AM, Albert ARIBAUD wrote: On 2/1/12, Amit Virdi wrote: I'm in the process of updating platform support for spear series of SoC on the latest u-boot. I picked u-boot v2011.12. I tried compiling for different spear boards (spear 300, 310, 300 and spear600). In every compilation, I'm getting following errors: --- arm-linux-ld: section .bss [007263cc -> 00728c5b] overlaps section .rel.dyn [007263cc -> 0072a623] arm-linux-ld: u-boot: section .bss lma 0x7263cc overlaps previous sections make: *** [u-boot] Error 1 --- This is one case. In fact, .bss overlapping .rel.dyn is normal -- the linker file even explicitly states this with ".bss __rel_dyn_start (OVERLAY)". Ok. Which compiler do you use and which board exactly are you building? We are using internal STLinux distribution. I tried compiling for spear320, and I couldn't succeed. Just to move a step further, can you please try "make spear320" at your end? If the error is not received at your end, I can be sure that the problem is due to the distribution at my end. Thanks in advance. Regards Amit Virdi PS: I used v2011.12. "spear320" entry isn't there in the boards.cfg file. I shall be sending patch to update the same once I resolve this linking error. Sorry, I should have stated this in the first place: I didn't see any warning with ELDK4.2 or with Linaro toolchain available in Ubuntu. I just tried some CodeSource toolchains, and the 2009q1 emits the same error whereas the 2010q1 and 2011q1 don't. Definitely a toolchain setting somewhere, and one that has disappeared in CS two years ago. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] RFC: Let linker create phy array
Hi Mike,
Le 05/02/2012 04:38, Mike Frysinger a écrit :
On Saturday 04 February 2012 22:02:46 Troy Kisky wrote:
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
-static struct phy_driver BCM5461S_driver = {
+struct phy_driver BCM5461S_driver __phy_entry = {
why do you have to remove the static ? that shouldn't affect the section name
that it gets placed into.
--- a/include/phy.h
+++ b/include/phy.h
+extern struct phy_driver __phy_entry_start, __phy_entry_end;
linker symbols should be declared like:
extern char __phy_entry_start[];
Why should they?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
On 04/02/2012 17:57, Albert ARIBAUD wrote: > Hi Stefano, > Hi Albert, > Do you want me to ignore these and honor the initial 11-commit pull > request, or would you prefer to issue an [UPDATE] pull req for the whole > 16 commits? I send yaou an update pull req, thanks. 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
Re: [U-Boot] [UPDATED] Pull request: u-boot-imx
Hi Albert, I have updated my pull request: The following changes since commit 778a2c5f846b1d0b78152747af96bcd0ca04e562: arm, davinci: cam_enc_4xx board updates (2012-02-02 10:54:37 -0700) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master Dirk Behme (4): imximage: Add MX53 to the documentation imximage: Add support for i.MX6 imximage: Sort bootops alphabetically i.mx6q: configs: Add fdt_high and initrd_high variables Fabio Estevam (3): sdhc_boot: Introduce CONFIG_FSL_FIXED_MMC_LOCATION option configs: Remove CONFIG_NET_MULTI from board files mx28: Show CPU frequency Helmut Raiger (3): mmc: access mxcmmc from mx31 boards mc13783.h: create and add regulator mode 0 and 1 tt01: add MMC support Jason Liu (2): i.mx6q: mx6qsabrelite: Add the ethernet function support i.mx: i.mx5: update imx_get_mac_from_fuse function Matthias Fuchs (1): mx28: fix i.MX28 spi driver Stefano Babic (1): imx6: mx6qarm2: updated board_mmc_getcd() to the new prototype Troy Kisky (2): i.mx6: mx6x_pins: Fix uart txd definitions i.mx6q: mx6qsabrelite: Setup uart1 pinmux arch/arm/cpu/arm1136/mx31/generic.c |1 + arch/arm/cpu/arm926ejs/mx27/generic.c | 35 ++-- arch/arm/cpu/arm926ejs/mx28/mx28.c|3 +- arch/arm/cpu/armv7/mx5/soc.c |2 +- arch/arm/include/asm/arch-mx27/clock.h| 22 ++--- arch/arm/include/asm/arch-mx31/clock.h|3 +- arch/arm/include/asm/arch-mx31/imx-regs.h | 11 +++ arch/arm/include/asm/arch-mx31/sys_proto.h|2 +- arch/arm/include/asm/arch-mx6/mx6x_pins.h | 36 +++- board/freescale/common/Makefile |2 +- board/freescale/mx6qarm2/mx6qarm2.c |9 +- board/freescale/mx6qsabrelite/mx6qsabrelite.c | 114 + board/hale/tt01/tt01.c| 34 +++- doc/README.imximage | 13 ++-- drivers/mmc/mxcmmc.c |8 +- drivers/spi/mxs_spi.c | 12 ++- include/configs/MPC8536DS.h |1 + include/configs/P1010RDB.h|5 +- include/configs/P1_P2_RDB.h |1 + include/configs/P2020COME.h |1 + include/configs/P2020DS.h |1 + include/configs/P2041RDB.h|1 + include/configs/PM826.h |2 - include/configs/PM828.h |2 - include/configs/cam_enc_4xx.h |1 - include/configs/coreboot.h|6 -- include/configs/corenet_ds.h |1 + include/configs/ecovec.h |1 - include/configs/efikamx.h |1 - include/configs/enbw_cmc.h|1 - include/configs/ethernut5.h |1 - include/configs/flea3.h |1 - include/configs/m28evk.h |1 - include/configs/mx6qarm2.h|2 + include/configs/mx6qsabrelite.h | 15 +++- include/configs/omap3_evm_common.h|1 - include/configs/omap3_mvblx.h |1 - include/configs/p1_p2_rdb_pc.h|7 +-- include/configs/tam3517-common.h |1 - include/configs/tt01.h| 12 +++ include/mc13783.h | 80 + tools/imximage.c |8 +- tools/imximage.h |2 + 43 files changed, 358 insertions(+), 106 deletions(-) create mode 100644 include/mc13783.h -- = 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
Re: [U-Boot] Avoiding reload on ARM U-BOOT
> Hello again > > Sorry for slipping the u-boot list e-mail address > > i understand the benefit of relocating u-boot to the end of DRAM but in > systems where boot time is critical this redundant copy is undesirable. > anyway i understand there is no official way of avoiding it. You can boot linux directly via SPL if your boottime is critical. And, if you do not want to boot linux directly, implement some "hit key to interrupt direct booting sequence" into SPL. > > One more question i have is regarding the SPL Framework. i read all the > documentation i could find about the SPL but i don't think i fully > understand the usage of this framework. since i noticed several SPL Macros > around the relocation code i suspected it has something to do with > relocation or u-boot running as secondary boot program If you can read only a small piece of eg. NAND with your bootrom, you use SPL. The purpose is to init the system (ram, gpio ...) and load the u-boot (the big bootloader). M > > i would appreciate a short explanation when CONFIG_SPL or CONFIG_NAND_SPL > should be set ? > > Thanks again > > Yehuda > > On Fri, Feb 3, 2012 at 10:15 AM, Marek Vasut wrote: > > > Hello Marek > > > > ALWAYS CC U-BOOT ML > > > > > Thank you for your answer > > > > > > My SOC (Marvells Armada Controller) uses a bootrom code to copy to > > > initialize the DRAM and to copy the u-boot image. so the entire DRAM > > > init and copy sequence in u-boot is redundant. > > > > I see. I know about this soc's bootrom. Though it still can't place the > > bootloader properly to the end of DRAM. > > > > > in previous version there was a way to avoid this. i find it limiting > > > > that > > > > > there isn't a way in the new version. > > > > > > Why would i want to relocate the code anyway ? > > > > See above, to place it to the end of DRAM. > > > > > Yehuda > > > > > > On Thu, Feb 2, 2012 at 11:34 AM, Marek Vasut > > > > wrote: > > > > > Hello everyone > > > > > > > > > > im trying to port u-boot 2011-09 to a new board with an arm based > > > > > SOC > > > > > > > > > > i found that u-boot will always relocate the code even if it is > > > > placed > > > > > > > already in DDR which is the case with my SOC. > > > > > > > > The u-boot is always relocated to the end of the DRAM, which is > > > > likely what you > > > > want. And it's quite a quick process. So if you are manufacturing > > > > your soc with > > > > various size of RAM, you want the relocation to happen. What SoC is > > > > that > > > > > > anyway? > > > > > > > > > is there any clean way to avoid relocating the u-boot ? does the > > > > > various SPL configs have something to do with that ? > > > > > > > > Not really and you don't want this to happen. > > > > > > > > M > > > > > > > > > if yes which one should i define ? > > > > > > > > > > Thanks in advance > > > > > > > > > > Yehuda ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V7] mcx: support for HTKW mcx board
From: Ilya Yanok
This patch adds support for the HTKW mcx AM3517-based board.
Serial, Ethernet, NAND, MMC, RTC, EHCI USB host and both
NAND and MMC SPLs are supported.
Signed-off-by: Ilya Yanok
Signed-off-by: Stefano Babic
CC: Tom Rini
Cc: Detlev Zundel
---
Changes from V6:
- rebased on current u-boot-ti
- applied and tested on top of EHCI Gavindraj's patches
- uses ULPI framework
Changes from V5
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/120254
- added comments on CONFIG_SYS_TEXT_BASE and SPL_{MALLOC,BSS}
Changes from V4
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/120148
- board_mmc_init return value fixed
- machine id added locally
- CONFIG_SYS_NAND_U_BOOT_SIZE removed
Changes from V3
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/118530
- Comment for misc_init_r function fixed
- Added check for gpio_request return value.
- Removed #if defined(CONFIG_GENERIC_MMC) around board_mmc_init
- CONFIG_USE_IRQ and related stuff removed from config
- CONFIG_OMAP3_MICRON_DDR removed
- CONFIG_SYS_MAXRAGS changed 32 -> 16
- Incorrect multiline comments (/*--- ones) fixed
- CONFIG_SPL_MAX_SIZE rewritten 0xB400 -> (45 << 10)
- CONFIG_SPL_NAND_WORKSPACE removed
Changes from V2
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/116548
- None
Changes from V1
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/115026
- Calls to gpio_set_value after gpio_direction_output removed
- Minor style problem (tab instead of space) fixed
SPL series:
Changes from V1
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/112892
- OMAP EHCI support enabled in config
- MMC SPL support enabled in config
"DaVinci EMAC and HTKW mcx support" series:
Changes from V3
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/112884
- NAND SPL support enabled in config
Changes from V2
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/112317
- removed dead code from board/htkw/mcx/Makefile as Mike suggested
- removed EMAC reset (now done in generic cpu_eth_init())
- removed some unsuned defines from configuration header
Changes from V1
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/97
- various style fixes to make checkpatch (almost) happy
- FSF address removed from GPL comments
- CONFIG_SYS_TEXT_BASE moved to configuration header, config.mk droped
- CONFIG_MACH_TYPE is used instead of setting mach type from board code
- i2c_init removed from misc_init_r
- cpu_eth_init removed (added to generic place by another patch)
- CONTROL_PADCONF defines removed
- Fixed boolean config options not to have a value
- CONFIG_MUSB_* and related defines removed
MAINTAINERS |4 +
board/htkw/mcx/Makefile | 38 +
board/htkw/mcx/mcx.c| 122 ++
board/htkw/mcx/mcx.h| 408 +++
boards.cfg |1 +
include/configs/mcx.h | 378 +++
6 files changed, 951 insertions(+), 0 deletions(-)
create mode 100644 board/htkw/mcx/Makefile
create mode 100644 board/htkw/mcx/mcx.c
create mode 100644 board/htkw/mcx/mcx.h
create mode 100644 include/configs/mcx.h
diff --git a/MAINTAINERS b/MAINTAINERS
index a8e56bb..7e52f50 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -920,6 +920,10 @@ Richard Woodruff
omap2420h4 ARM1136EJS
+Ilya Yanok
+
+ mcx ARM ARMV7 (AM35x SoC)
+
Syed Mohammed Khasim
Sughosh Ganu
diff --git a/board/htkw/mcx/Makefile b/board/htkw/mcx/Makefile
new file mode 100644
index 000..4c8db10
--- /dev/null
+++ b/board/htkw/mcx/Makefile
@@ -0,0 +1,38 @@
+#
+# Copyright (C) 2011 Ilya Yanok, Emcraft Systems
+#
+# Based on ti/evm/Makefile
+#
+# 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.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := $(BOARD).o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
diff --git a/board/htkw/mcx/mcx.c b/board/htkw/mcx/mcx.c
new file mode 100644
index 000..dcc8707
--- /dev/null
+++ b/board/htkw/mcx/mcx.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2011 Ilya Yan
Re: [U-Boot] Avoiding reload on ARM U-BOOT
On 05/02/2012 15:22, Marek Vasut wrote: >> Hello again >> >> Sorry for slipping the u-boot list e-mail address >> >> i understand the benefit of relocating u-boot to the end of DRAM but in >> systems where boot time is critical this redundant copy is undesirable. >> anyway i understand there is no official way of avoiding it. > > You can boot linux directly via SPL if your boottime is critical. To this purpose I have posted the final version of the patchset to boot Linux directly from SPL - maybe you can try this way on your hardware. Best regards, Stefano Babic -- = 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
Re: [U-Boot] ARM ld: .bss overlaps section .rel.dyn
Albert, > Definitely a toolchain setting somewhere, and one that has disappeared in > CS two years ago. > > Amicalement, > -- > Albert. > Thanks a lot. Now I have got specific direction. Best Regards Amit Virdi ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
Dear Simon Glass, In message <1328424259-12914-1-git-send-email-...@chromium.org> you wrote: > This permits disabling the code relation in U-Boot which is useful when > debugging with an ICE. > > To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board. > > Signed-off-by: Simon Glass NAK. We are trying really hard to unify the code, i. e. to make all architectures behave the same. I will not accept any such architecture-specific implementation. All the more, there is really ne need for this. Relocation does not cause any specific problems to debugging. We know exaclt when it happens, and it happens exaclty once during the life time of U-Boot. And all you have to do is load the symbol tables to the right address. Before relcation this just works, and after relocation you just need to issue a single GDB command. This is even documented. Adding this options also creates the risk that people who don't really understand the inner workings of U-Boot will try and use this for other purposes. Read: mis-use it. Sorry, but NAK. 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 One does not thank logic. -- Sarek, "Journey to Babel", stardate 3842.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
On Sunday 05 February 2012 07:05:13 Marek Vasut wrote: > > On Sunday 05 February 2012 01:44:19 Simon Glass wrote: > > > This permits disabling the code relation in U-Boot which is useful when > > > debugging with an ICE. > > > > > > To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board. > > > > any reason for "ARM" in there ? > > Because this is only for ARM? yes, *this* patch only touches arm code, but that doesn't mean it needs to be scoped that way from the start -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 2/2] RFC: Let linker create phy array
On Sunday 05 February 2012 08:26:57 Albert ARIBAUD wrote: > Le 05/02/2012 04:38, Mike Frysinger a écrit : > > On Saturday 04 February 2012 22:02:46 Troy Kisky wrote: > >> --- a/include/phy.h > >> +++ b/include/phy.h > >> > >> +extern struct phy_driver __phy_entry_start, __phy_entry_end; > > > > linker symbols should be declared like: > > extern char __phy_entry_start[]; > > Why should they? because that's what the GNU linker documentation says to, and that's how all existing symbols have been handled. look at asm/sections.h in every Linux arch. -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 1/2] RFC: create u-boot-common.lds
On Saturday 04 February 2012 22:02:45 Troy Kisky wrote:
> arch/blackfin/cpu/u-boot.lds
> is warranted.
yes, this change will break Blackfin boards for sure
> --- a/arch/blackfin/cpu/u-boot.lds
> +++ b/arch/blackfin/cpu/u-boot.lds
>
> MEMORY
> {
> #if CONFIG_MEM_SIZE
> - ram : ORIGIN = CONFIG_SYS_MONITOR_BASE, LENGTH =
> CONFIG_SYS_MONITOR_LEN
> # define ram_code ram
> # define ram_data ram
> + ram (rwx): ORIGIN = CONFIG_SYS_MONITOR_BASE, LENGTH =
> CONFIG_SYS_MONITOR_LEN
> + l1_code : ORIGIN = L1_CODE_ORIGIN, LENGTH = L1_INST_SRAM_SIZE
> + l1_data : ORIGIN = L1_DATA_B_SRAM, LENGTH = L1_DATA_B_SRAM_SIZE
> #else
> # define ram_code l1_code
> # define ram_data l1_data
> + l1_code (rx) : ORIGIN = L1_CODE_ORIGIN, LENGTH =
> L1_INST_SRAM_SIZE
> + l1_data (!rx) : ORIGIN = L1_DATA_B_SRAM, LENGTH =
> L1_DATA_B_SRAM_SIZE
> #endif
> - l1_code : ORIGIN = L1_CODE_ORIGIN, LENGTH = L1_INST_SRAM_SIZE
> - l1_data : ORIGIN = L1_DATA_B_SRAM, LENGTH = L1_DATA_B_SRAM_SIZE
> }
i don't understand ... why is this change necessary ?
i'm not sure the attr's are correct ... the manual says "r" is "read-only"
while "w" is "read/write". so i'd expect:
ram (wx)
l1_code (x)
l1_data (w)
> + INCLUDE u-boot-common.lds
since we preprocess our linker scripts now, i'd suggest using #include rather
than INCLUDE
> --- /dev/null
> +++ b/u-boot-common.lds
>
> + . = ALIGN(4);
> + __u_boot_cmd_start = .;
> + .u_boot_cmd : {
> + KEEP(*(.u_boot_cmd))
> + }
> + __u_boot_cmd_end = .;
rather than storing this in the top level dir, i'd suggest going the linux
route and add a include/asm-generic/u-boot.lds.h header. then we can migrate
people over time and piece by piece without having to worry about breaking
everyone at once ...
that also allows us to cater to arches (like Blackfin) that have a symbol prefix
(underscore in the Blackfin case). add the VMLINUX_SYMBOL() macro, and then
this code will look like:
VMLINUX_SYMBOL(__u_boot_cmd_end) = .;
(i picked VMLINUX_SYMBOL() only because that's what Linux already has defined)
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
Hi Mike, Wolfgang, On Sun, Feb 5, 2012 at 12:38 PM, Mike Frysinger wrote: > On Sunday 05 February 2012 07:05:13 Marek Vasut wrote: >> > On Sunday 05 February 2012 01:44:19 Simon Glass wrote: >> > > This permits disabling the code relation in U-Boot which is useful when >> > > debugging with an ICE. >> > > >> > > To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board. >> > >> > any reason for "ARM" in there ? >> >> Because this is only for ARM? > > yes, *this* patch only touches arm code, but that doesn't mean it needs to be > scoped that way from the start This patch shows how to do this sort of thing on ARM. I would like to see this feature in mainline, but it makes more sense to do it properly if/when generic relocation is in. Then it will automatically work for all archs. For now it is a useful patch. Regards, Simon > -mike > > ___ > 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 1/2] RFC: create u-boot-common.lds
Hi Mike,
On Mon, Feb 6, 2012 at 8:01 AM, Mike Frysinger wrote:
> On Saturday 04 February 2012 22:02:45 Troy Kisky wrote:
>
> since we preprocess our linker scripts now, i'd suggest using #include rather
> than INCLUDE
+1
>> --- /dev/null
>> +++ b/u-boot-common.lds
>>
>> + . = ALIGN(4);
>> + __u_boot_cmd_start = .;
>> + .u_boot_cmd : {
>> + KEEP(*(.u_boot_cmd))
>> + }
>> + __u_boot_cmd_end = .;
>
> rather than storing this in the top level dir, i'd suggest going the linux
> route and add a include/asm-generic/u-boot.lds.h header. then we can migrate
Except it's not a 'header' :) - include/asm-generic/u-boot.lds (or maybe
u-boot.lds.common) should be what is included in u-boot.lds and
include/asm-generic/u-boot.lds.h should be the externs for the symbols
exported from the linker script
> people over time and piece by piece without having to worry about breaking
> everyone at once ...
Here we go again ;) - Queue the 'what incentive will maintainers have to
migrate to the common case' discussion...
On a (related) side not, do we need to lay down some ground rules for
migrating to 'common' case? There seems to be a fair amount of new 'common
code' or 'common architecture' being developed, but only being applied to
one arch. I'm guilty too - my init sequence cleanups which lay the
foundation for a common init sequence are only implemented for x86.
> that also allows us to cater to arches (like Blackfin) that have a symbol
> prefix
> (underscore in the Blackfin case). add the VMLINUX_SYMBOL() macro, and then
> this code will look like:
> VMLINUX_SYMBOL(__u_boot_cmd_end) = .;
> (i picked VMLINUX_SYMBOL() only because that's what Linux already has defined)
How about U_BOOT_LDS_SYMBOL()?
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
Dear Simon Glass, In message you wrote: > > This patch shows how to do this sort of thing on ARM. I would like to > see this feature in mainline, but it makes more sense to do it > properly if/when generic relocation is in. Then it will automatically > work for all archs. For now it is a useful patch. Sorry, as I see it your chances to get this in are epsilon. 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 lesser of two evils -- is evil." - Seymour (Sy) Leon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
Hi Wolfgang, Simon, On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message > you > wrote: >> >> This patch shows how to do this sort of thing on ARM. I would like to >> see this feature in mainline, but it makes more sense to do it >> properly if/when generic relocation is in. Then it will automatically >> work for all archs. For now it is a useful patch. > > Sorry, as I see it your chances to get this in are epsilon. I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online Once these have been done, any board can just specific: SKIP_INIT(RELOC) And this can be wrapped: #ifdef CONFIG_SYS_SKIP_RELOC SKIP_INIT(RELOC) #endif Done ;) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
Hi Wolfgang, On Sun, Feb 5, 2012 at 2:44 PM, Wolfgang Denk wrote: > Dear Simon Glass, > > In message > you > wrote: >> >> This patch shows how to do this sort of thing on ARM. I would like to >> see this feature in mainline, but it makes more sense to do it >> properly if/when generic relocation is in. Then it will automatically >> work for all archs. For now it is a useful patch. > > Sorry, as I see it your chances to get this in are epsilon. OK, I was hoping for a little higher. Regards, Simon > > 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 lesser of two evils -- is evil." - Seymour (Sy) Leon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
Hi Graeme, On Sun, Feb 5, 2012 at 3:23 PM, Graeme Russ wrote: > Hi Wolfgang, Simon, > > On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wrote: >> Dear Simon Glass, >> >> In message >> you >> wrote: >>> >>> This patch shows how to do this sort of thing on ARM. I would like to >>> see this feature in mainline, but it makes more sense to do it >>> properly if/when generic relocation is in. Then it will automatically >>> work for all archs. For now it is a useful patch. >> >> Sorry, as I see it your chances to get this in are epsilon. > > I think the immediate focus should be on centralising the init sequence > processing into /common/init.c and then bringing the new'initcall' > architecture online > > Once these have been done, any board can just specific: > > SKIP_INIT(RELOC) > > And this can be wrapped: > > #ifdef CONFIG_SYS_SKIP_RELOC > SKIP_INIT(RELOC) > #endif > > Done ;) Which reminds me - did you do that pull request for your x86 refactor? If not, what is the plan? Regards, Simon > > Regards, > > Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
Hi Simon On Mon, Feb 6, 2012 at 10:32 AM, Simon Glass wrote: > Hi Graeme, > > On Sun, Feb 5, 2012 at 3:23 PM, Graeme Russ wrote: >> Hi Wolfgang, Simon, >> >> On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wrote: >>> Dear Simon Glass, >>> >>> In message >>> you >>> wrote: This patch shows how to do this sort of thing on ARM. I would like to see this feature in mainline, but it makes more sense to do it properly if/when generic relocation is in. Then it will automatically work for all archs. For now it is a useful patch. >>> >>> Sorry, as I see it your chances to get this in are epsilon. >> >> I think the immediate focus should be on centralising the init sequence >> processing into /common/init.c and then bringing the new'initcall' >> architecture online >> >> Once these have been done, any board can just specific: >> >> SKIP_INIT(RELOC) >> >> And this can be wrapped: >> >> #ifdef CONFIG_SYS_SKIP_RELOC >> SKIP_INIT(RELOC) >> #endif >> >> Done ;) > > Which reminds me - did you do that pull request for your x86 refactor? > If not, what is the plan? I pushed the changes into the x86 sub-repo but noticed a minor glitch which breaks the build. On top of that, I've upgraded my dev machine to a 64-bit arch, moved from Ubuntu to Fedora and got a dud motherboard in the mix. So my dev machine is only just now back online, but I need to sort out the last few 64-bit build issues (which require U-Boot patches) and fix up the x86 sub-repo before sending the pull request. Sorry for the dealy, but hopefully I'll have it all sorted by the end of the week Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
Hi Graeme, On Sun, Feb 5, 2012 at 3:37 PM, Graeme Russ wrote: > Hi Simon > > On Mon, Feb 6, 2012 at 10:32 AM, Simon Glass wrote: >> Hi Graeme, >> >> On Sun, Feb 5, 2012 at 3:23 PM, Graeme Russ wrote: >>> Hi Wolfgang, Simon, >>> >>> On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wrote: Dear Simon Glass, In message you wrote: > > This patch shows how to do this sort of thing on ARM. I would like to > see this feature in mainline, but it makes more sense to do it > properly if/when generic relocation is in. Then it will automatically > work for all archs. For now it is a useful patch. Sorry, as I see it your chances to get this in are epsilon. >>> >>> I think the immediate focus should be on centralising the init sequence >>> processing into /common/init.c and then bringing the new'initcall' >>> architecture online >>> >>> Once these have been done, any board can just specific: >>> >>> SKIP_INIT(RELOC) >>> >>> And this can be wrapped: >>> >>> #ifdef CONFIG_SYS_SKIP_RELOC >>> SKIP_INIT(RELOC) >>> #endif >>> >>> Done ;) >> >> Which reminds me - did you do that pull request for your x86 refactor? >> If not, what is the plan? > > I pushed the changes into the x86 sub-repo but noticed a minor glitch > which breaks the build. On top of that, I've upgraded my dev machine to > a 64-bit arch, moved from Ubuntu to Fedora and got a dud motherboard in > the mix. So my dev machine is only just now back online, but I need to > sort out the last few 64-bit build issues (which require U-Boot patches) > and fix up the x86 sub-repo before sending the pull request. > > Sorry for the dealy, but hopefully I'll have it all sorted by the end of > the week OK thanks for the update. Would be keen to get my generic board stuff tested on x86 also, but that might be a separate problem. For initcalls, are you still thinking of looking at that? Regards, Simon > > Regards, > > Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
Hi Simon, On Mon, Feb 6, 2012 at 10:41 AM, Simon Glass wrote: > Hi Graeme, > > On Sun, Feb 5, 2012 at 3:37 PM, Graeme Russ wrote: >> Hi Simon >> [snip] >> Sorry for the dealy, but hopefully I'll have it all sorted by the end of >> the week > > OK thanks for the update. Would be keen to get my generic board stuff > tested on x86 also, but that might be a separate problem. For > initcalls, are you still thinking of looking at that? I have already started work on it - I have a dedicated linker script which produces the binary file containin the dependancy information and the helper-tool to process it is underway - It currently strips out all the textual information, just need to build the code which sorts it and generates the C file Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PING] Re: [PATCH] ARM: activate DISPLAY_CPUINFO for VCMA9 + SMDK2410 board
On 4 February 2012 04:43, Albert ARIBAUD wrote: > Hi David, > > Le 09/01/2012 08:23, "David Müller (ELSOFT AG)" a écrit : >> >> Hello >> >> Any news? > > > Adding Minkyu. > > Amicalement, > -- > Albert. > Acked-by: Minkyu Kang 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 1/2] RFC: create u-boot-common.lds
On Sunday 05 February 2012 17:07:41 Graeme Russ wrote:
> On Mon, Feb 6, 2012 at 8:01 AM, Mike Frysinger wrote:
> > On Saturday 04 February 2012 22:02:45 Troy Kisky wrote:
> >> --- /dev/null
> >> +++ b/u-boot-common.lds
> >>
> >> + . = ALIGN(4);
> >> + __u_boot_cmd_start = .;
> >> + .u_boot_cmd : {
> >> + KEEP(*(.u_boot_cmd))
> >> + }
> >> + __u_boot_cmd_end = .;
> >
> > rather than storing this in the top level dir, i'd suggest going the
> > linux route and add a include/asm-generic/u-boot.lds.h header. then we
> > can migrate
>
> Except it's not a 'header' :)
what Troy has posted isn't a header, but what i'm suggesting is. Linux's
vmlinux.lds.h does things like:
#define DISCARDS \
/DISCARDS/ : { \
EXIT_TEXT \
*(.discard) \
}
and then the arch linker scripts just use:
DISCARDS
> > people over time and piece by piece without having to worry about
> > breaking everyone at once ...
>
> Here we go again ;) - Queue the 'what incentive will maintainers have to
> migrate to the common case' discussion...
it isn't just that. i don't think a single u-boot.lds for every arch is
feasible. the kernel method allows all the common pieces to be in a common
header, and then the arches to expand the specific pieces in the specific order.
-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 1/2] RFC: create u-boot-common.lds
Hi Mike,
On Mon, Feb 6, 2012 at 2:24 PM, Mike Frysinger wrote:
> On Sunday 05 February 2012 17:07:41 Graeme Russ wrote:
>> On Mon, Feb 6, 2012 at 8:01 AM, Mike Frysinger wrote:
>> > On Saturday 04 February 2012 22:02:45 Troy Kisky wrote:
>> >> --- /dev/null
>> >> +++ b/u-boot-common.lds
>> >>
>> >> + . = ALIGN(4);
>> >> + __u_boot_cmd_start = .;
>> >> + .u_boot_cmd : {
>> >> + KEEP(*(.u_boot_cmd))
>> >> + }
>> >> + __u_boot_cmd_end = .;
>> >
>> > rather than storing this in the top level dir, i'd suggest going the
>> > linux route and add a include/asm-generic/u-boot.lds.h header. then we
>> > can migrate
>>
>> Except it's not a 'header' :)
>
> what Troy has posted isn't a header, but what i'm suggesting is. Linux's
> vmlinux.lds.h does things like:
> #define DISCARDS \
> /DISCARDS/ : { \
> EXIT_TEXT \
> *(.discard) \
> }
>
> and then the arch linker scripts just use:
> DISCARDS
Ah, I see. So we could have
#define LDS_U_BOOT_CMD \
__u_boot_cmd_start = .; \
.u_boot_cmd : { \
KEEP(*(.u_boot_cmd)) \
} \
__u_boot_cmd_end = .;
And each arch linker script would just have
. = ALIGN(4);
LDS_U_BOOT_CMD
Or some such
>> > people over time and piece by piece without having to worry about
>> > breaking everyone at once ...
>>
>> Here we go again ;) - Queue the 'what incentive will maintainers have to
>> migrate to the common case' discussion...
>
> it isn't just that. i don't think a single u-boot.lds for every arch is
> feasible. the kernel method allows all the common pieces to be in a common
> header, and then the arches to expand the specific pieces in the specific
> order.
I can't say I'm a fan of the 'common bits' approach - It really does reduce
the readability of the linker script IMHO. It took me long enough to deal
with the fact that the lds file is pre-processed for TEXT_BASE ;)
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] RFC: create u-boot-common.lds
On Sunday 05 February 2012 22:43:33 Graeme Russ wrote: > On Mon, Feb 6, 2012 at 2:24 PM, Mike Frysinger wrote: > > it isn't just that. i don't think a single u-boot.lds for every arch is > > feasible. the kernel method allows all the common pieces to be in a > > common header, and then the arches to expand the specific pieces in the > > specific order. > > I can't say I'm a fan of the 'common bits' approach - It really does reduce > the readability of the linker script IMHO. It took me long enough to deal > with the fact that the lds file is pre-processed for TEXT_BASE ;) yes, it does make the linker scripts a bit more opaque, but since each arch is doing something unique, it's fairly hard to merge them into a single file. the Linux approach represents what we can do in the real world -- get beyond board-specific linker scripts and to one linker script per arch. then the vmlinux.lds.h merges a lot of the stuff that can be shared between arches. i've unified all the board/SoC linker scripts for Blackfin and now there is just one -- arch/blackfin/cpu/u-boot.lds. -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 1/2] RFC: create u-boot-common.lds
Hi Mike, On Mon, Feb 6, 2012 at 3:27 PM, Mike Frysinger wrote: > On Sunday 05 February 2012 22:43:33 Graeme Russ wrote: >> On Mon, Feb 6, 2012 at 2:24 PM, Mike Frysinger wrote: >> > it isn't just that. i don't think a single u-boot.lds for every arch is >> > feasible. the kernel method allows all the common pieces to be in a >> > common header, and then the arches to expand the specific pieces in the >> > specific order. >> >> I can't say I'm a fan of the 'common bits' approach - It really does reduce >> the readability of the linker script IMHO. It took me long enough to deal >> with the fact that the lds file is pre-processed for TEXT_BASE ;) > > yes, it does make the linker scripts a bit more opaque, but since each arch is > doing something unique, it's fairly hard to merge them into a single file. > the > Linux approach represents what we can do in the real world -- get beyond > board-specific linker scripts and to one linker script per arch. then the > vmlinux.lds.h merges a lot of the stuff that can be shared between arches. > > i've unified all the board/SoC linker scripts for Blackfin and now there is > just > one -- arch/blackfin/cpu/u-boot.lds. Ditto for x86 Maybe we should wait until all the arches have unified linker scripts before looking at a global script (parallels with 'skip relocation')? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] flash post test
hi albert Yes,actually there is already support of flash test in POST of latest uboot.They are testing flash on every power on so am I for my board.But i don't want to disturb sectors in which uboot code relies. Can you help me here? On Sat, Feb 4, 2012 at 3:02 AM, Albert ARIBAUD wrote: > Hi vk, > > Le 31/01/2012 10:27, vk a écrit : > > Hi all, >> >> >> Currently I am testing the Flash memory by using "Write and Read the >> same pattern" method (Protecting the UBoot Flash Sectors). >> >> Is it safer to test flash memory during bootup?what if power gets off >> during >> process? >> >> I want to know whether there is any alternative method to test the >> complete FLASH MEMORY. >> > > Do you mean that you want to test the flash by writing to it on every > power-up? What is the point? > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] da850evm: add board specific functions
Christian, On Thu, Feb 02, 2012 at 19:56:45, Christian Riesch wrote: > Hi, > Thank you for re-submitting the patchset! > > On Thu, Feb 2, 2012 at 2:42 PM, Manjunath Hadli > wrote: > > There are two da850 SOC based EVMs, one from Spectrum digital and > > other from Logic PD. Boards from Spectrum digital have mac address > > stored in I2C EEPROM and they have spi flash manufactured by WINBOND. > > Boards from Logic PD store mac address in ST Microelectronics SPI > > flash. This patch series adds support to read mac address from the > > appropriate device. > > Ok, so we have two configurations, we have da850evm which is for LogicPD's > OMAP-L138 SoM and for LogicPD's AM1808 SoM, and we have da850_am18xxevm which > must be used for the AM1808 board from Spectrum Digital. Is that correct? Yes. > > I wonder if we should change the name of the da850_am18xxevm configuration. > It's quite confusing, until today I thought that the da850_am18xxevm was a > configuration for LogicPD's AM1808 SoM... Are there also OMAP-L138 boards > from Spectrum Digital? Spectrum Digital do not have any OMAP-L138 EVMs. They have only AM18x evms. Regards, --Manju > > Regards, Christian > > > > > These patches have undergone a review previously, but since the tree > > has moved ahead Christian and Tom asked to resubmit the patches for > > review. > > (http://www.mail-archive.com/u-boot@lists.denx.de/msg76220.html) > > > > Manjunath Hadli (2): > > da850evm: add support to read mac address from spi flash > > da850evm: read mac address from I2C EEPROM on AM18x EVM > > > > board/davinci/da8xxevm/da850evm.c | 66 > > + > > boards.cfg | 4 +- > > 2 files changed, 68 insertions(+), 2 deletions(-) > > > > ___ > > 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 1/2] RFC: create u-boot-common.lds
On Sunday 05 February 2012 23:34:27 Graeme Russ wrote: > On Mon, Feb 6, 2012 at 3:27 PM, Mike Frysinger wrote: > > On Sunday 05 February 2012 22:43:33 Graeme Russ wrote: > >> On Mon, Feb 6, 2012 at 2:24 PM, Mike Frysinger wrote: > >> > it isn't just that. i don't think a single u-boot.lds for every arch > >> > is feasible. the kernel method allows all the common pieces to be in > >> > a common header, and then the arches to expand the specific pieces in > >> > the specific order. > >> > >> I can't say I'm a fan of the 'common bits' approach - It really does > >> reduce the readability of the linker script IMHO. It took me long > >> enough to deal with the fact that the lds file is pre-processed for > >> TEXT_BASE ;) > > > > yes, it does make the linker scripts a bit more opaque, but since each > > arch is doing something unique, it's fairly hard to merge them into a > > single file. the Linux approach represents what we can do in the real > > world -- get beyond board-specific linker scripts and to one linker > > script per arch. then the vmlinux.lds.h merges a lot of the stuff that > > can be shared between arches. > > > > i've unified all the board/SoC linker scripts for Blackfin and now there > > is just one -- arch/blackfin/cpu/u-boot.lds. > > Ditto for x86 > > Maybe we should wait until all the arches have unified linker scripts > before looking at a global script (parallels with 'skip relocation')? i don't think we need to wait for that. if we have a header with defines, then any linker script can be converted to that. the arches that have cleaned up can convert over now. seems like the big offenders in the tree are arm/m68k/mips/ppc. i have a hard time seeing them merging into their arch/ anytime soon. -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] TRATS: set gpio of UART correctly
On 26 January 2012 20:21, Minkyu Kang wrote: > Signed-off-by: Minkyu Kang > Signed-off-by: HeungJun, Kim > Cc: Chander Kashyap > --- > board/samsung/trats/trats.c | 18 +++--- > 1 files changed, 7 insertions(+), 11 deletions(-) > applied to u-boot-samsung -- 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 v8 4/4] EXYNOS: SMDK5250: Add MMC SPL support
Hi,
As there are no changes in other patches. So is it fine to only send this patch.
On 4 February 2012 01:01, Mike Frysinger wrote:
> On Friday 03 February 2012 11:05:57 Chander Kashyap wrote:
>> board/samsung/smdk5250/tools/mkexynos_image.c | 117
>> create mode 100644 tools/mksmdk5250spl.c
>
> something funky in your diffstat ... says you're creating tools/ but the
> diffstat shows board/.../tools/. but the diff below looks correct.
>
>> --- /dev/null
>> +++ b/tools/mksmdk5250spl.c
>
> you could still name it "mkexynos_image". up to you.
>
>> + if (fstat(ifd, &stat)) {
>> + close(ifd);
>> + close(ofd);
>> + }
>
> looks like you should issue a warning + exit here
> -mike
--
with warm regards,
Chander Kashyap
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sh: i2c: Add support I2C controller of SH7734
Hello Nobuhiro,
Nobuhiro Iwamatsu wrote:
> Renesas SH7734 has two I2C interfaceis.
> This supports these I2C.
>
> Signed-off-by: Nobuhiro Iwamatsu
> ---
> drivers/i2c/Makefile|1 +
> drivers/i2c/sh_sh7734_i2c.c | 468
> +++
> 2 files changed, 469 insertions(+), 0 deletions(-)
> create mode 100644 drivers/i2c/sh_sh7734_i2c.c
[...]
> diff --git a/drivers/i2c/sh_sh7734_i2c.c b/drivers/i2c/sh_sh7734_i2c.c
> new file mode 100644
> index 000..6c514b4
> --- /dev/null
> +++ b/drivers/i2c/sh_sh7734_i2c.c
> @@ -0,0 +1,468 @@
[...]
> +static void sh_i2c_send_stop(struct sh_i2c *base)
> +{
> + writeb(readb(&base->iccr2) & ~(SH_I2C_ICCR2_BBSY | SH_I2C_ICCR2_SCP),
> + &base->iccr2);
Please use clrbits_*
[...]
> +static int check_tend(struct sh_i2c *base, int stop)
> +{
> + int i, ret = 1;
> +
> + for (i = 0 ; i < IRQ_WAIT ; i++) {
> + if (SH_I2C_ICSR_TEND & readb(&base->icsr)) {
> + ret = 0;
> + break;
> + }
> + udelay(10);
> + }
> +
> + if (stop) {
> + u8 data;
> +
> + writeb(readb(&base->icsr) & ~SH_I2C_ICSR_STOP, &base->icsr);
> +
> + sh_i2c_send_stop(base);
> + }
> +
> + writeb(readb(&base->icsr) & ~SH_I2C_ICSR_TEND, &base->icsr);
here too... please check globally.
[...]
> +#ifdef CONFIG_I2C_MULTI_BUS
> +static unsigned int current_bus;
> +
> +/**
wrong comment style.
[...]
> +/**
here too.
> + * i2c_get_bus_num - returns index of active I2C bus
> + */
> +unsigned int i2c_get_bus_num(void)
[...]
> +int i2c_read(u8 chip, u32 addr, int alen, u8 *buffer, int len)
> +{
> + int i = 0;
new line please.
> + for (i = 0 ; i < len ; i++)
> + buffer[i] = i2c_raw_read(base, chip, addr + i);
[...]
Beside of this minor comments patch looks good, thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/20] tegra: i2c: Add function to find DVC bus
Hello Simon,
Simon Glass wrote:
> Hi Heiko,
>
> On Jan 14, 2012 11:28 PM, "Heiko Schocher" wrote:
>> Hello Simon,
>>
>> Simon Glass wrote:
>>> Add tegra_i2c_get_dvc_bus_num() to obtain the I2C bus number of DVC bus.
>>> This allows us to talk to the PMU.
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>> Changes in v2:
>>> - Add patch to find DVC bus number
>>>
>>> arch/arm/include/asm/arch-tegra2/tegra2_i2c.h |7 +++
>>> drivers/i2c/tegra2_i2c.c | 14 ++
>>> 2 files changed, 21 insertions(+), 0 deletions(-)
>> just one minor comment, beside of this:
>>
>> Acked-by: Heiko Schocher
>>
>>> diff --git a/arch/arm/include/asm/arch-tegra2/tegra2_i2c.h
> b/arch/arm/include/asm/arch-tegra2/tegra2_i2c.h
>>> index 86f6a01..4816cc7 100644
>>> --- a/arch/arm/include/asm/arch-tegra2/tegra2_i2c.h
>>> +++ b/arch/arm/include/asm/arch-tegra2/tegra2_i2c.h
>>> @@ -157,4 +157,11 @@ struct i2c_ctlr {
>>> #define I2C_INT_ARBITRATION_LOST_SHIFT 2
>>> #define I2C_INT_ARBITRATION_LOST_MASK(1 <<
> I2C_INT_ARBITRATION_LOST_SHIFT)
>>> +/**
>> wrong comment style ...
>
> I am trying to follow the Doxygen convention. Many editors like this also
> and display the parameters etc. nicely highlighted. Does yours? Hoping it
> encourages more function prototype comments in U-Boot and reduce the time I
> need to spend wading through code to see what a function is supposed to do.
added Wolfgang to cc:
Do we want to accept this? If so, it must be documented somewhere!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Add option to disable code relocation
Dear Graeme Russ, In message you wrote: > > I think the immediate focus should be on centralising the init sequence > processing into /common/init.c and then bringing the new'initcall' > architecture online Agreed. > Once these have been done, any board can just specific: > > SKIP_INIT(RELOC) I will probably object to his, too - for the same reasons. 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'm frequently appalled by the low regard you Earthmen have for life. -- Spock, "The Galileo Seven", stardate 2822.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
