Re: [U-Boot] SPL framework re-design
On Sat, Jun 18, 2011 at 3:58 AM, Scott Wood scottw...@freescale.com wrote: On Fri, 17 Jun 2011 22:18:57 +0530 Aneesh V ane...@ti.com wrote: @@ -1158,6 +1164,7 @@ clobber: clean @[ ! -d $(obj)nand_spl ] || find $(obj)nand_spl -name * -type l -print | xargs rm -f @[ ! -d $(obj)onenand_ipl ] || find $(obj)onenand_ipl -name * -type l -print | xargs rm -f @[ ! -d $(obj)mmc_spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f + @[ ! -d $(obj)spl ] || find $(obj)mmc_spl -name * -type l -print | xargs rm -f That last mmc_spl should just be spl. +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += mmc/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += mmc/libonenand.o Oops!! That was a copy paste error. It was intended to be: +LIBS-$(CONFIG_SYS_SPL_NAND_SUPPORT) += nand/libnand.o +LIBS-$(CONFIG_SYS_SPL_ONENAND_SUPPORT) += onenand/libonenand.o Why are these in mmc? What is it you propose would be in these files? +$(LIBS-y): depend + $(MAKE) -C $(dir $(subst $(obj),,$@)) all If no libraries are selected, this will produce a rule with an empty target, which is undefined behavior. The top-level Makefile doesn't include any source files by itself. All SPL content comes from one or more of libraries. So, there will be at least one library defined, I believe(unless there is an error, of course). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: make it possible to build tools unconfigured
On Sunday, June 19, 2011 13:55:13 Ilya Yanok wrote: On 18.06.2011 23:03, Mike Frysinger wrote: - tools/Makefile put common/env_embedded.o and envcrc.o to object list conditionally. This fixes errors during dependency generation. pretty sure this breaks board builds. if the only thing this fixes is a I'm sorry but I can't see how this can break the builds. Could you please be more specific? I've tried to build some boards, it actually works... i might be thinking of a different env_embedded situation. a different problem with your patch to tools/Makefile: you copied the same logic multiple times which means more bitrot. why dont you do something like: diff --git a/tools/Makefile b/tools/Makefile index 623f908..97f83f8 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -48,17 +48,21 @@ CONFIG_NETCONSOLE = y CONFIG_SHA1_CHECK_UB_IMG = y endif +# Merge all the different vars for envcrc into one +ENVCRC-$(CONFIG_ENV_IS_EMBEDDED) = y +ENVCRC-$(CONFIG_ENV_IS_IN_DATAFLASH) = y +ENVCRC-$(CONFIG_ENV_IS_IN_EEPROM) = y +ENVCRC-$(CONFIG_ENV_IS_IN_FLASH) = y +ENVCRC-$(CONFIG_ENV_IS_IN_ONENAND) = y +ENVCRC-$(CONFIG_ENV_IS_IN_NAND) = y +ENVCRC-$(CONFIG_ENV_IS_IN_NVRAM) = y +ENVCRC-$(CONFIG_ENV_IS_IN_SPI_FLASH) = y +CONFIG_BUILD_ENVCRC ?= $(ENVCRC-y) + # Generated executable files BIN_FILES-$(CONFIG_LCD_LOGO) += bmp_logo$(SFX) BIN_FILES-$(CONFIG_VIDEO_LOGO) += bmp_logo$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_EMBEDDED) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_DATAFLASH) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_EEPROM) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_FLASH) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_ONENAND) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_NAND) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_NVRAM) += envcrc$(SFX) -BIN_FILES-$(CONFIG_ENV_IS_IN_SPI_FLASH) += envcrc$(SFX) +BIN_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc$(SFX) BIN_FILES-$(CONFIG_CMD_NET) += gen_eth_addr$(SFX) BIN_FILES-$(CONFIG_CMD_LOADS) += img2srec$(SFX) BIN_FILES-$(CONFIG_INCA_IP) += inca-swap-bytes$(SFX) @@ -67,7 +71,7 @@ BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX) BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX) # Source files which exist outside the tools directory -EXT_OBJ_FILES-y += common/env_embedded.o +EXT_OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += common/env_embedded.o EXT_OBJ_FILES-y += common/image.o EXT_OBJ_FILES-y += lib/crc32.o EXT_OBJ_FILES-y += lib/md5.o @@ -77,7 +81,7 @@ EXT_OBJ_FILES-y += lib/sha1.o OBJ_FILES-$(CONFIG_LCD_LOGO) += bmp_logo.o OBJ_FILES-$(CONFIG_VIDEO_LOGO) += bmp_logo.o NOPED_OBJ_FILES-y += default_image.o -OBJ_FILES-y += envcrc.o +OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc.o NOPED_OBJ_FILES-y += fit_image.o OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o harmless warning when generating dependency files, then i say ignore it. after all, this is how it has always worked in the past and no one really cared. Yep, they are harmless but they are not warnings but rather scary errors actually. ;) I think it's better to fix them. i guess my threshold for being scared is a bit higher :p -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] tools: make it possible to build tools unconfigured
Hi Mike, thanks for your comments. On 18.06.2011 23:03, Mike Frysinger wrote: i think you'll need to split this up in logical sep changesets since you are fixing different problems. Ok, will do. Things changed: - config.mk disable 'ld script not found error' in case if we are building tools only. i dont like copying pasting the same logic in multiple places. this is how code rots and bug fixes diverge. Agreed. How should I fix this? considering LDSCRIPT/CONFIG_SYS_LDSCRIPT only get used by the top level u-boot file, and only when the system is configured, i wonder if we shouldnt just rip it out of config.mk and into the top level Makefile. let's see what Scott thinks ... I see. Let's wait for Scott's comments then. - tools/Makefile put common/env_embedded.o and envcrc.o to object list conditionally. This fixes errors during dependency generation. pretty sure this breaks board builds. if the only thing this fixes is a I'm sorry but I can't see how this can break the builds. Could you please be more specific? I've tried to build some boards, it actually works... harmless warning when generating dependency files, then i say ignore it. after all, this is how it has always worked in the past and no one really cared. Yep, they are harmless but they are not warnings but rather scary errors actually. ;) I think it's better to fix them. Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: make it possible to build tools unconfigured
Hi Mike, On 19.06.2011 22:27, Mike Frysinger wrote: i might be thinking of a different env_embedded situation. a different problem with your patch to tools/Makefile: you copied the same logic multiple times which means more bitrot. Yes, that's a good point. Your patch looks good to me. Should I write a commit message and repost it or will you? Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: make it possible to build tools unconfigured
On Sunday, June 19, 2011 18:46:42 Ilya Yanok wrote: On 19.06.2011 22:27, Mike Frysinger wrote: i might be thinking of a different env_embedded situation. a different problem with your patch to tools/Makefile: you copied the same logic multiple times which means more bitrot. Yes, that's a good point. Your patch looks good to me. Should I write a commit message and repost it or will you? respin your patches taking my suggestions into account -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
[U-Boot] ARMv7 clock rate issue (U-Boot vs. X-Loader)
Hi, I decided to post my questions on this list even though they also concern the X-Loader. However, since the X-Loader is derived from U-Boot, I thought they are placed well here. I'm a bit confused about the clock rate which is set for the ARMv7 processor of the BeagleBoard-xM (Rev C; DM3730) by U-Boot and X-Loader. As far as I understand it, the clock rate is only set to a safe initial low value and not to the highest possible value the CPU is actually able to run at. According to the TI TRM [1] (p. 349), the ARM_CLK can be calculated as follows: I) MPU_CLK = SYS_CLK * M / ([N+1] * M2) II) ARM_CLK = MPU_CLK If I am correct, SYS_CLK equals to the oscillator frequency (26 MHz) divided by 2, so SYS_CLK = 13 MHz. Therefore, ARM_CLK should be 600 MHz, because M = 600, N = 12, and M2 = 1. (I got these values from the table in U-Boot-root/arch/arm/cpu/armv7/omap3/lowlevel_init.S, but I also verified them by some printfs after prcm_init().) Now, what confuses me: When I set exactly the same values for M, N, and M2 (SYS_CLK is also 13 MHz) in X-Loader (I used this version: [2]), then the CPU seems to perform significantly slower than in U-Boot. To see the difference I ran a simple standalone application with a constant number of instructions in both X-Loader and U-Boot. The CR (Control Register [3]) was set to the same value (0xC5087A - instruction and data caches disabled). I measured the execution time for both cases and got these values: U-Boot: 35066 ms X-Loader: 23389 ms 1) Is there anything initialized/activated in U-Boot -- but not in X-Loader -- which could affect the performance in such a way? 2) Am I correct that the CPU is clocked at 600 MHz at all (at least in U-Boot)? Thank you. Best regards, Chris [1] AM/DM37x Multimedia Device Silicon -- Technical Reference Manual http://focus.ti.com/lit/ug/sprugn4l/sprugn4l.pdf [2] x-loader - Gitorius http://gitorious.org/x-loader [3] Cortex-A8 Technical Reference Manual -- Control Register http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Bgbffjhh.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request u-boot-marvell.git
-Original Message- From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] Sent: Saturday, June 18, 2011 11:16 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de Subject: Re: Pull request u-boot-marvell.git (resent as this was not sent to the list, sorry Prafulla for the duplicate) Hi Prafulla, Le 16/06/2011 13:23, Prafulla Wadaskar a écrit : Hi Albert Please kindly pull The following changes since commit 7b2fac7654f7420c2787f74ec3b1540fa3b343e9: Aneesh V (1): omap730p2: fix build breaks are available in the git repository at: u-boot-marvell.git next branch. Are these meant for this release, i.e. should I pull that in u-boot-arm/master? If so, can you please rebase your master branch onto your next branch? Next is supposed to hold commits waiting for next merge window. Hi Albert By default they should go in next release that's why I put them in next branch Regards.. Prafulla . . Also: uboot@lilith:~/src/u-boot-arm$ git fetch u-boot-marvell remote: error: refs/remotes/origin/mkimage does not point to a valid object! remote: Counting objects: 88, done. remote: Compressing objects: 100% (38/38), done. remote: Total 68 (delta 51), reused 38 (delta 29) Unpacking objects: 100% (68/68), done. From git://git.denx.de/u-boot-marvell + 0b41af5...7b2fac7 master - u-boot-marvell/master (forced update) + 02e1082...7e481f6 next - u-boot-marvell/next (forced update) uboot@lilith:~/src/u-boot-arm$ Anyone know what the error message about refs/remote/origin/mkimage means? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
