Re: [U-Boot] BMP display.
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Tuma Sent: Monday, August 17, 2009 7:26 PM To: Wolfgang Denk; U-Boot Mailing List Subject: Re: [U-Boot] BMP display. On Monday 17 August 2009 16:38:31 you wrote: Dear Tuma, again: please keep the mailing list on Cc: !!! In message 200908171631.17975.chernigovs...@spb.gs.ru you wrote: Okay. Is new version configurable for OMAP3evm out of the box? Yes. And is the v2009.08-rc2 stable enought? Yes. Thank you. I've downloaded new U-Boot 2009.08.rc2. I have some error while making it. I do: make distclean (Okay) make omap3_evm_config (Okay) make And get: make[1]: arm-linux-gcc: Command not found My old U-Boot used arm-none-linux-gnueabi-gcc which make system could easyly find on my system. Should I install some new software to build new U-Boot? Or configure existing Makefile? Can you try: make CROSS_COMPILE=arm-none-linux-gnueabi- Best regards, Wolfgang Denk -- Software Developer General Satellite Corp. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Re-distributing mkimage binary
Hi, Is it possible to redistribute the mkimage binary outside the u-boot package? Best regards, Sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Re-distributing mkimage binary
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, August 26, 2009 8:20 PM To: Premi, Sanjeev Cc: U-Boot Mailing List Subject: Re: [U-Boot] Re-distributing mkimage binary Dear Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59301dd430...@dbde02.ent.ti.com you wrote: Is it possible to redistribute the mkimage binary outside the u-boot package? Yes, of course this is possible. It's Free Software under GPL, so you can modify and/or repackage it as you like. Just make sure to fulfill the requirements of the GPL which still apply, no matter how you split it off... U-boot and Linux kernel sources are available in the same package, but the intent was to allow linux developers to bypass the step to build u-boot just get this binary. Best regards, Sanjeev 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 Punishment becomes ineffective after a certain point. Men become in- sensitive. -- Eneg, Patterns of Force, stardate 2534.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add more expansionboard IDs
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Jason Kridner Sent: Friday, November 05, 2010 11:17 AM To: u-boot@lists.denx.de Cc: Koen Kooi Subject: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add more expansionboard IDs [sp] Is it really necessary to mention ARMV7 in the subject line? OMAP3 BeagbeBoard seem sufficient. From: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Jason Kridner jkrid...@beagleboard.org --- board/ti/beagle/beagle.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c index d9b6f01..520e57d 100644 --- a/board/ti/beagle/beagle.c +++ b/board/ti/beagle/beagle.c @@ -48,6 +48,10 @@ #define TINCANTOOLS_TRAINER 0x04000100 #define TINCANTOOLS_SHOWDOG 0x03000100 #define KBADC_BEAGLEFPGA 0x01000600 +#define LW_BEAGLETOUCH 0x01000700 +#define LCDOG_BRAINMUX 0x01000800 +#define LCDOG_BRAINMUXTOUCH 0x02000800 [sp] Don't see any mechanism to read these values. Assuming the detection mechanism is consistent i.e. no difference due to different eeprom etc. etc. +#define SF_HARDHAT 0x01000900 [sp] Don't see this used below #define BEAGLE_NO_EEPROM 0x @@ -223,6 +227,18 @@ int misc_init_r(void) MUX_KBADC_BEAGLEFPGA(); setenv(buddy, beaglefpga); break; + case LW_BEAGLETOUCH: + printf(Recognized Liquidware Beagletouch board\n); + setenv(buddy, beagletouch); + break; + case LCDOG_BRAINMUX: + printf(Recognized Brainmux LCDog board\n); + setenv(buddy, lcdog); + break; + case LCDOG_BRAINMUXTOUCH: + printf(Recognized Brainmux LCDog Touch board\n); + setenv(buddy, lcdogtouch); + break; case BEAGLE_NO_EEPROM: printf(No EEPROM on expansion board\n); setenv(buddy, none); -- 1.5.6.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] ARMV7: OMAP3: BeagleBoard: Enable pullups on i2c2.
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Jason Kridner
Sent: Friday, November 05, 2010 11:24 AM
To: u-boot@lists.denx.de; beaglebo...@googlegroups.com
Cc: Kipisz, Steven
Subject: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: Enable
pullups on i2c2.
From: Steve Kipisz s-kipi...@ti.com
[sp] Description missing.
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
arch/arm/include/asm/arch-omap3/omap3.h |9 +
board/ti/beagle/beagle.c|3 +++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/arch-omap3/omap3.h
b/arch/arm/include/asm/arch-omap3/omap3.h
index 3957c79..1860dff 100644
--- a/arch/arm/include/asm/arch-omap3/omap3.h
+++ b/arch/arm/include/asm/arch-omap3/omap3.h
@@ -50,6 +50,15 @@/ctr
/* CONTROL */
#define OMAP34XX_CTRL_BASE (OMAP34XX_L4_IO_BASE + 0x2000)
+/* Signal Integrity Parameter Control Registers */
+#define CONTROL_PROG_IO0 0x48002444
+#define CONTROL_PROG_IO1 0x48002448
+#define CONTROL_PROG_IO2 0x48002408
+#define CONTROL_PROG_IO_WKUP10x48002A80
[sp] Would be better if they are defined off OMAP34XX_CTRL_BASE
defined just above.
+
+/* Bit definition for CONTROL_PROG_IO1 */
+#define PRG_I2C2_PULLUPRESX 0x0001
+
/* UART */
#define OMAP34XX_UART1
(OMAP34XX_L4_IO_BASE + 0x6a000)
#define OMAP34XX_UART2
(OMAP34XX_L4_IO_BASE + 0x6c000)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index dd7b6b5..6074eca 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -160,6 +160,9 @@ int misc_init_r(void)
struct gpio *gpio5_base = (struct gpio *)OMAP34XX_GPIO5_BASE;
struct gpio *gpio6_base = (struct gpio *)OMAP34XX_GPIO6_BASE;
+ /* Enable i2c2 pullup resisters */
+ *(ulong *)(CONTROL_PROG_IO1) = ~(PRG_I2C2_PULLUPRESX);
[sp] Direct pointer access is not a good practice.
Can you look at struct ctrl and see whether it can be augmented/
similar approach can be used?
+
switch (get_board_revision()) {
case REVISION_AXBX:
printf(Beagle Rev Ax/Bx\n);
--
1.5.6.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] BeagleBoard: Added LED driver
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Jason Kridner
Sent: Friday, November 05, 2010 11:23 AM
To: u-boot@lists.denx.de; beaglebo...@googlegroups.com
Subject: [U-Boot] [PATCH] BeagleBoard: Added LED driver
Added LED driver using status_led. USR0 is set to monitor the boot
status. USR1 is set to be the green LED.
(cherry picked from commit 048b526fd7cc0c642f27c674b3e235321c880b66)
Signed-off-by: Jason Kridner jkrid...@beagleboard.org
---
board/ti/beagle/Makefile |4 ++-
board/ti/beagle/beagle.c |7
board/ti/beagle/led.c| 91
++
3 files changed, 101 insertions(+), 1 deletions(-)
create mode 100644 board/ti/beagle/led.c
diff --git a/board/ti/beagle/Makefile b/board/ti/beagle/Makefile
index f797112..4cc675c 100644
--- a/board/ti/beagle/Makefile
+++ b/board/ti/beagle/Makefile
@@ -25,8 +25,10 @@ include $(TOPDIR)/config.mk
LIB = $(obj)lib$(BOARD).a
-COBJS:= beagle.o
+COBJS-y := $(BOARD).o
+COBJS-$(CONFIG_STATUS_LED) += led.o
+COBJS:= $(sort $(COBJS-y))
SRCS := $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 93c452e..dd7b6b5 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -30,6 +30,9 @@
* MA 02111-1307 USA
*/
#include common.h
+#ifdef CONFIG_STATUS_LED
+#include status_led.h
+#endif
#include twl4030.h
#include asm/io.h
#include asm/arch/mmc_host_def.h
@@ -78,6 +81,10 @@ int board_init(void)
/* boot param addr */
gd-bd-bi_boot_params = (OMAP34XX_SDRC_CS0 + 0x100);
+#if defined(CONFIG_STATUS_LED) defined(STATUS_LED_BOOT)
+ status_led_set (STATUS_LED_BOOT, STATUS_LED_ON);
+#endif
+
return 0;
}
diff --git a/board/ti/beagle/led.c b/board/ti/beagle/led.c
new file mode 100644
index 000..df26552
--- /dev/null
+++ b/board/ti/beagle/led.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2010 Texas Instruments, Inc.
+ * Jason Kridner jkrid...@beagleboard.org
+ *
+ * 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 common.h
+#include status_led.h
+#include asm/arch/cpu.h
+#include asm/io.h
+#include asm/arch/sys_proto.h
+#include asm/arch/gpio.h
+
+static unsigned int saved_state[2] = {STATUS_LED_OFF,
STATUS_LED_OFF};
+
+/* GPIO pins for the LEDs */
+#define BEAGLE_LED_USR0 149
+#define BEAGLE_LED_USR1 150
+
+#ifdef STATUS_LED_GREEN
+void green_LED_off (void)
+{
+ __led_set (STATUS_LED_GREEN, 0);
+}
+
+void green_LED_on (void)
+{
+ __led_set (STATUS_LED_GREEN, 1);
+}
+#endif
+
+void __led_init (led_id_t mask, int state)
+{
+ __led_set (mask, state);
+}
+
+void __led_toggle (led_id_t mask)
+{
+#ifdef STATUS_LED_BIT
+ if (STATUS_LED_BIT mask) {
+ if (STATUS_LED_ON == saved_state[0])
+ __led_set(STATUS_LED_BIT, 0);
+ else
+ __led_set(STATUS_LED_BIT, 1);
+ }
+#endif
+#ifdef STATUS_LED_BIT1
+ if (STATUS_LED_BIT1 mask) {
+ if (STATUS_LED_ON == saved_state[1])
+ __led_set(STATUS_LED_BIT1, 0);
+ else
+ __led_set(STATUS_LED_BIT1, 1);
+ }
+#endif
+}
+
+void __led_set (led_id_t mask, int state)
+{
+#ifdef STATUS_LED_BIT
+ if (STATUS_LED_BIT mask) {
+ if (!omap_request_gpio(BEAGLE_LED_USR0)) {
+ omap_set_gpio_direction(BEAGLE_LED_USR0, 0);
+ omap_set_gpio_dataout(BEAGLE_LED_USR0, state);
+ }
+ saved_state[0] = state;
+ }
+#endif
+#ifdef STATUS_LED_BIT1
+ if (STATUS_LED_BIT1 mask) {
+ if (!omap_request_gpio(BEAGLE_LED_USR1)) {
+ omap_set_gpio_direction(BEAGLE_LED_USR1, 0);
+ omap_set_gpio_dataout(BEAGLE_LED_USR1, state);
+ }
+ saved_state[1] = state;
+ }
+#endif
+}
[sp] I see too many ifdef blocks in the code above. The also seems to be
repetitive.
Is user really expected to change the u-boot config for each LED bit/color?
Can this be simplified by one
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, November 06, 2010 8:35 AM To: Nishanth Menon Cc: u-boot@lists.denx.de; Koen Kooi Subject: Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table [snip] Note that for 36xx my patch sets the max to 720 -- this is because mainline/linux-omap currently does not support 1000. We can adjust that when kernel support for 1000 appears. [sp] 720MHz is not a valid frequency for 36x. It is the highest freq for OMAP35x - subject to associated bit set in the silicon. 600MHz would be be safe for all OMAP35x family processors. For 36xx, the freq should be 800MHz (if you don't want 1GHz). [snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: Overo: Automatically set clock rate to maximum if mpurate env variable is auto
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Monday, November 08, 2010 3:14 AM To: Steve Sakoman Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMV7: Overo: Automatically set clock rate to maximum if mpurate env variable is auto Dear Steve Sakoman, In message 1289012370.18546.66.ca...@quadra you wrote: The maximum clock rate for the OMAP3 processors on Overo depends on the processor type and revision. This patch sets the clock rate to the spec sheet maximum if the mpurate environment variable is set to auto. Otherwise it passes the mpurate variable unchanged on the kernel command line. I don't think this is a good idea. This logic does not belong into U-Boot; if anywhere, it belongs into the Linux kernel code. If I want to pass any specific value to the Linux kernel I want that U-Boot does not get in my way. And if I decide to set the mpurate to auto I want that U-Boot keeps this setting and does not change it silently behind my back into something else. [sp] I am in full agreement. It is too difficult to find root cause for transparent changes - usually lead to long debug times first in kernel an then in u-boot. ~sanjeev Both looks conceptually broken to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It became apparent that one reason why the Ice Giants were known as the Ice Giants was because they were, well, giants. The other was that they were made of ice. -Terry Pratchett, _Sourcery_ ___ 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] ARM: OMAP3/4: proposal: Cleanup MUX
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Nishanth Menon Sent: Tuesday, November 09, 2010 6:09 AM To: Peter Barada Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX Peter Barada wrote, on 11/05/2010 11:59 PM: Personally I'd like to see the kernel and u-boot disconnect on the Looks like we are getting to a consensus - we all seem to dislike the dependency of u-boot and kernel for mux as of today - can we think about [sp] In my opinion, we need to do minimal and necessary MUX settings in u-boot and let kernel manage itself. This also helps ensure that problems noticed in kernel are easy to replicate on other similar platforms. Last year I spent long time in convincing that wake-up on keypad was not working in Linux kernel; but folks using OMAP3430SDP maintained it worked fine. Root cause - relevant PADCONF was set in u-boot for 3430SDP. (not quoting mail-chain) We may not be able to eliminate such instances altogether - but can have less of such instances. post 2011March as a good time to start pushing the relevant changes in? if that is the case, I will start posting RFCs in the coming weeks so [sp] Can you list what chanages you are trying to propose? ...without going as far as RFC. the mails quoted in previous message are again too long and wide in discussion. A concise list will help. ~sanjeev that we can get the relevant changes ready on time. Ofcourse, if there are others wishing to collaborate, folks are more than welcome :) -- Regards, Nishanth Menon ___ 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] omap3 booting issues
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Murali K. Vemuri Sent: Friday, November 19, 2010 1:49 PM To: u-boot@lists.denx.de Subject: [U-Boot] omap3 booting issues Hi there, This may not be the ideal place to post this question, but I thought someone might know this. [sp] This is definitely not the right place. The question belongs to linux-omap mailing list. I have custom board using OMAP3 and I have a problem. We have more than one I2C slave connected on I2C1 u-boot was not displaying the slave addresses correctly. I fixed some issues in u-boot and am finally able to see the u-boot displaying the I2C devices correctly. But after this Kernel stopped to boot. It just gives the message: Starting kernel ... Uncompressing Linux. .. done, booting the kernel. and stops. I tried to find out the possible reason, but no use so far (about 2 days). Currently my MLO (x-loader), u-boot.bin, the kernel uImage reside on the SD Card . [sp] You have shared no information on versions of x-loader, u-boot and kernel. How is your custom board different from any known platform omap3evm, beagle, sdp, ... In absence, you should look at your customizations and ensure all board specific hook-ups or changes are properly handled in software. BTW, I found a curious comment in the kernel code: /* First I2C bus is not muxable */ Can this be a problem for the board not booting? As I had been playing with I2C only, I had to dig mainly on the I2C direction. any other pointers will be helpful [sp] Provide more details and move your kernel related queries to linux-omap. Thanks regards Murali ___ 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] AM/DM37X How to configure registers to get 1000MHz
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Enric Balletbò i Serra Sent: Friday, November 19, 2010 2:42 PM To: u-boot@lists.denx.de; Steve Sakoman Subject: [U-Boot] AM/DM37X How to configure registers to get 1000MHz Hi all, I would ask a question, maybe someone can help, which is the better way to configure the PRCM registers to get 1000MHz on AM/DM37X processor ? You need set the multipliers and dividers apprioriately - based on the sysclk. Would help to understand the context of better? ~sanjeev Thanks in advance, Enric ___ 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] AM/DM37X How to configure registers to get 1000MHz
-Original Message- From: Enric Balletbò i Serra [mailto:eballe...@gmail.com] Sent: Friday, November 19, 2010 6:30 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Steve Sakoman Subject: Re: [U-Boot] AM/DM37X How to configure registers to get 1000MHz Hi, Thanks for your reply 2010/11/19 Premi, Sanjeev pr...@ti.com: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Enric Balletbò i Serra Sent: Friday, November 19, 2010 2:42 PM To: u-boot@lists.denx.de; Steve Sakoman Subject: [U-Boot] AM/DM37X How to configure registers to get 1000MHz Hi all, I would ask a question, maybe someone can help, which is the better way to configure the PRCM registers to get 1000MHz on AM/DM37X processor ? You need set the multipliers and dividers apprioriately - based on the sysclk. Would help to understand the context of better? I'm thinking in two scenarios : 1. For OMAP35X there are devices that support 600MHz as max frequency but others supports 720MHz, I want to set by default 600MHz and if device supports 720MHz change to this frequency. [sp] You can look at one of my patches on linux kernel to identify the device capability for 600/720MHz. 2. For AM/DM37X, maybe I'm wrong, but the default frequency for AM/DM37X is set to 600MHz, Like OMAP35X i want to set default to 800MHz and i device supports change to 1000MHz. [sp] The device comes up at 600MHz for now, but there is no limitation on device to go all the way to 1GHz. Which is the better way to do this ? [sp] So, you are looking for common mechanism to go to highest supported frequency. Right? Thanks in advance, Enric ~sanjeev Thanks in advance, Enric ___ 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] AM/DM37X How to configure registers to get 1000MHz
-Original Message- From: Enric Balletbò i Serra [mailto:eballe...@gmail.com] Sent: Friday, November 19, 2010 6:43 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Steve Sakoman Subject: Re: [U-Boot] AM/DM37X How to configure registers to get 1000MHz [snip]...[snip] I'm thinking in two scenarios : 1. For OMAP35X there are devices that support 600MHz as max frequency but others supports 720MHz, I want to set by default 600MHz and if device supports 720MHz change to this frequency. [sp] You can look at one of my patches on linux kernel to identify the device capability for 600/720MHz. I''ll do, thanks 2. For AM/DM37X, maybe I'm wrong, but the default frequency for AM/DM37X is set to 600MHz, Like OMAP35X i want to set default to 800MHz and i device supports change to 1000MHz. [sp] The device comes up at 600MHz for now, but there is no limitation on device to go all the way to 1GHz. Which is the better way to do this ? [sp] So, you are looking for common mechanism to go to highest supported frequency. Right? Yes, I think should be interesting for all OMAP35/AM/DM37 a mechanism like this. [sp] I am stuck is a critical activity for next few days; would be able to work on this only next week. However, if you could start on it, I have quick thought process here: 1) Have a function that returns max supported freq for each device. - Function for OMAP35x can internally check the capability bit - While the one for AM37x would return 1GHz. 2) There is a mapping table for freq. and corresponding M, N, M2 values that can be used to pick select the right values. 3) Such a table exists in ASM; I have an intent to make it more readable in C - but always goes low in priority. 4) Another twist to 2) above can be use of env variable that gets pref. e.g. 37x support 1GHz; but you wantto still boot at 800MHz for some reason; then setting env var would make the function return 800 instead of 1000. ~sanjeev Thanks in advance, Enric ~sanjeev Thanks in advance, Enric ___ 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
[U-Boot] Build failures with older toolchain
Hi all, I pulled u-boot about an hour ago and master is at this commit: Author: Matthias Weisser weiss...@arcor.de Date: Thu Nov 18 09:35:09 2010 +0100 Makefile: Fix build with USE_PRIVATE_LIBGCC (plus a small change in omap3_config.h - unrelated) When trying to build u-boot I was constantly, getting these errors: arm-none-linux-gnueabi-ld: section .bss [8003f5c8 - 8007e327] overlaps section .rel.dyn [8003f5c8 - 80044e57] arm-none-linux-gnueabi-ld: section .dynsym [80044e58 - 80044ef7] overlaps section .bss [8003f5c8 - 8007e327] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c8 overlaps previous sections Tried to build omap3_beagle and there were no issues; unable to debug for long, I decided to come back on this problem later. Opened a new window and started working on my Linux tree. Returned back to u-boot, and this time build was successful for no evident change. Took me some time to realise that the toolchain I was using to work on Linux repo was different - I use an env script based on activity. To verify the doubts, I explicitly ran this command with two different versions of toolchain in my path and I see different results. Here are last few lines of final build step Failure with Codesourcery 2009q1-203: h/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3 -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: section .bss [8003f5c8 - 8007e327] overlaps section .rel.dyn [8003f5c8 - 80044e57] arm-none-linux-gnueabi-ld: section .dynsym [80044e58 - 80044ef7] overlaps section .bss [8003f5c8 - 8007e327] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c8 overlaps previous sections make: *** [u-boot] Error 1 premi # pwd /home/premi/git/u-boot premi # Success with Codesourcery 2010q1-202: 19/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e8 overlaps previous sections arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin premi # pwd /home/premi/git/u-boot premi # The configuration for beagle still build successfully for both toolchain versions. Any clues/ suggestions? Is there a recent change which hasn't yet been adapted or ported for omap3evm? Best regards, Sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Saturday, November 20, 2010 12:21 AM To: u-boot@lists.denx.de Subject: [U-Boot] Build failures with older toolchain Hi all, I pulled u-boot about an hour ago and master is at this commit: Author: Matthias Weisser weiss...@arcor.de Date: Thu Nov 18 09:35:09 2010 +0100 Makefile: Fix build with USE_PRIVATE_LIBGCC (plus a small change in omap3_config.h - unrelated) When trying to build u-boot I was constantly, getting these errors: arm-none-linux-gnueabi-ld: section .bss [8003f5c8 - 8007e327] overlaps section .rel.dyn [8003f5c8 - 80044e57] arm-none-linux-gnueabi-ld: section .dynsym [80044e58 - 80044ef7] overlaps section .bss [8003f5c8 - 8007e327] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c8 overlaps previous sections Tried to build omap3_beagle and there were no issues; unable to debug for long, I decided to come back on this problem later. Opened a new window and started working on my Linux tree. Returned back to u-boot, and this time build was successful for no evident change. Took me some time to realise that the toolchain I was using to work on Linux repo was different - I use an env script based on activity. To verify the doubts, I explicitly ran this command with two different versions of toolchain in my path and I see different results. Here are last few lines of final build step Failure with Codesourcery 2009q1-203: h/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnu eabi/4.3.3 -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: section .bss [8003f5c8 - 8007e327] overlaps section .rel.dyn [8003f5c8 - 80044e57] arm-none-linux-gnueabi-ld: section .dynsym [80044e58 - 80044ef7] overlaps section .bss [8003f5c8 - 8007e327] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c8 overlaps previous sections make: *** [u-boot] Error 1 premi # pwd /home/premi/git/u-boot premi # Success with Codesourcery 2010q1-202: 19/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnu eabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e8 overlaps previous sections arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin premi # pwd /home/premi/git/u-boot premi # The configuration for beagle still build successfully for both toolchain versions. Any clues/ suggestions? Is there a recent change which hasn't yet been adapted or ported for omap3evm? Here is my log of git-bisect: Was trying to find if any commit made changes that could be specific to toolchain version. Due to state of the omap3evm, 2 changes in configs/omap3_evm.h had to be done manually at some stage - to avoid compile errors due to undefined symbols. premi # git bisect log git bisect start # good: [e0ccbe367ed4465db930a37a850c889827fb076b] Merge branch 'master' of http://git.denx.de/u-boot git bisect good e0ccbe367ed4465db930a37a850c889827fb076b # bad: [e3dae922877505c89823b17acaefdf83a6d92ce2] work in progress git bisect bad e3dae922877505c89823b17acaefdf83a6d92ce2 # good: [f2b382ea066d02d5ba44870024cc1295e85782ef] Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx git bisect good f2b382ea066d02d5ba44870024cc1295e85782ef # good: [d75c2a3d7f34ff1eb9920ad72483cff7cb6d358f] Merge branch 'master' of git://git.denx.de/u-boot-imx git bisect good d75c2a3d7f34ff1eb9920ad72483cff7cb6d358f # good: [a72dbae2ccd38d2b32f8b814f5a528c88be65bd3] fsl_pci_init: Make fsl_pci_init_port() PCI/PCIe aware git bisect good a72dbae2ccd38d2b32f8b814f5a528c88be65bd3 # good: [a72dbae2ccd38d2b32f8b814f5a528c88be65bd3] fsl_pci_init: Make fsl_pci_init_port() PCI/PCIe aware git bisect good a72dbae2ccd38d2b32f8b814f5a528c88be65bd3 # good: [a72dbae2ccd38d2b32f8b814f5a528c88be65bd3] fsl_pci_init: Make fsl_pci_init_port() PCI/PCIe aware git bisect good a72dbae2ccd38d2b32f8b814f5a528c88be65bd3 # good: [227b72515546fca535dbd3274f6d875d97f494fe] Merge branch 'master' of git://git.denx.de/u-boot-ti git bisect good 227b72515546fca535dbd3274f6d875d97f494fe # good: [8ad25bf8d9233eb7d0b614612108622a59069354] Net: clarify board/cpu_eth_init calls git bisect good 8ad25bf8d9233eb7d0b614612108622a59069354 # bad: [f7ac99fdd9eaf64df9731c2e8fdf97e9d3e2c82a] net: e1000: typo using wrong argument to sizeof git bisect bad f7ac99fdd9eaf64df9731c2e8fdf97e9d3e2c82a # good: [858ecd9ac3434e011e84d5fd9013bd1ee199dbdc] tx25: fix linker file for newer ld support git bisect good 858ecd9ac3434e011e84d5fd9013bd1ee199dbdc # bad: [6d8962e814c15807dd6ac5757904be2a02d187b8] Switch from archive libraries to partial linking git bisect bad 6d8962e814c15807dd6ac5757904be2a02d187b8 premi # This points leads me
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Saturday, November 20, 2010 1:44 AM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59302477ea...@dbde02.ent.ti.com you wrote: This points leads me to this commit: commit 6d8962e814c15807dd6ac5757904be2a02d187b8 Author: Sebastien Carlier sebastien.carl...@gmail.com Date: Fri Nov 5 15:48:07 2010 +0100 Switch from archive libraries to partial linking Is this related to toolchain version? Still doesn't explain why failure occurs for omap3_evm; not omap3_beagle... This commit may require further changes to board specific linker scripts. [sp] Both boards share the same 'u-boot.lds' And there is no board specific lds. Still trying to figure what could be wrong. ~sanjeev 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 use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 22, 2010 2:44 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Saturday, November 20, 2010 1:44 AM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59302477ea...@dbde02.ent.ti.com you wrote: This points leads me to this commit: commit 6d8962e814c15807dd6ac5757904be2a02d187b8 Author: Sebastien Carlier sebastien.carl...@gmail.com Date: Fri Nov 5 15:48:07 2010 +0100 Switch from archive libraries to partial linking Is this related to toolchain version? Still doesn't explain why failure occurs for omap3_evm; not omap3_beagle... This commit may require further changes to board specific linker scripts. [sp] Both boards share the same 'u-boot.lds' And there is no board specific lds. Still trying to figure what could be wrong. Tried the same stuff for overo and no issues! Since there linker scripts are same between omap3_evm, omap3_beagle and omap3_overo, only difference could have been board specific code. I was hoping to find some code that might be offending the linker; unable to find by inspection, I reduced the default configuration for the evm to as low as I could - still see: arm-none-linux-gnueabi-ld: section .bss [800fe358 - 800fee1b] overlaps section .rel.dyn [800fe358 - 8010076f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x800fe358 overlaps previous sections I am still not sure why the start of .bss and .rel.dyn for omap3_evm start at same address but Looking for more pointers! Specifically, a big generic change that somehow didn't touch the omap3evm; but did touch others. ...will start looking at the git-log immediately after this mail. ~sanjeev ~sanjeev 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 use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra ___ 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] Build failures with older toolchain
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 22, 2010 8:02 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: Build failures with older toolchain Le 22/11/2010 14:50, Premi, Sanjeev a écrit : Tried the same stuff for overo and no issues! Since there linker scripts are same between omap3_evm, omap3_beagle and omap3_overo, only difference could have been board specific code. I was hoping to find some code that might be offending the linker; unable to find by inspection, I reduced the default configuration for the evm to as low as I could - still see: arm-none-linux-gnueabi-ld: section .bss [800fe358 - 800fee1b] overlaps section .rel.dyn [800fe358 - 8010076f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x800fe358 overlaps previous sections I am still not sure why the start of .bss and .rel.dyn for omap3_evm start at same address That is because they are voluntarily overlapped. This looks like the patch I recently did, which in essence does overlap BSS (which is not used before relocation) and relocation tables (which are not used after relocation) so that the FLASH and RAM footprint remain minimal. This should not result in a linker message unless the .lds does not follow the same structure (order and attributes of output sections) as, for instance, the arm926ejs u-boot.lds. [sp] Thanks for the pointer. I will take a look at it. I am still surprised why the problem doesn't show up on beagle and overo which share the same lds. but Looking for more pointers! Specifically, a big generic change that somehow didn't touch the omap3evm; but did touch others. will start looking at the git-log immediately after this mail. ~sanjeev Look up the u-boot.lds files. Are they shared? [sp] Before sending the previous mail. I compared the u-boot.lds generated for omap3_evm and omap3_beagle and they are identical! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 22, 2010 8:54 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: Build failures with older toolchain Le 22/11/2010 16:02, Premi, Sanjeev a écrit : -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 22, 2010 8:02 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: Build failures with older toolchain Le 22/11/2010 14:50, Premi, Sanjeev a écrit : Tried the same stuff for overo and no issues! Since there linker scripts are same between omap3_evm, omap3_beagle and omap3_overo, only difference could have been board specific code. I was hoping to find some code that might be offending the linker; unable to find by inspection, I reduced the default configuration for the evm to as low as I could - still see: arm-none-linux-gnueabi-ld: section .bss [800fe358 - 800fee1b] overlaps section .rel.dyn [800fe358 - 8010076f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x800fe358 overlaps previous sections I am still not sure why the start of .bss and .rel.dyn for omap3_evm start at same address That is because they are voluntarily overlapped. This looks like the patch I recently did, which in essence does overlap BSS (which is not used before relocation) and relocation tables (which are not used after relocation) so that the FLASH and RAM footprint remain minimal. [sp] Are you referring to this patch? http://git.denx.de/?p=u-boot.git;a=commitdiff;h=aaeb0a890a050b 58be87fa2b165eec5fa947dc86 I see the change for arm926ejs/u-boot.lds and armv7/u-boot.lds to be similar. Your commit mentions about the new ld vs. old; I had seen this earlier as well. It was the reason for me to try CodeSourcery Lite 2010-q1 but there I get a different error - mentioned in my first post. Which toolchain version are you using? I usually try the 2009q3 Code Sourcery and the ELDK 4.2 toolchains. Can you compare the ld invocation command lines for a failure case and a success case? The difference could be in the linker options. [sp] Identical :( Would you want me to share the build logs or the last step? The generated u-boot.lds is also same. It was my first step. Then I started looking if there is any forced addition on specific section that may not be going well with linker/ relocation changes - reason for trying a minimal config. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 22, 2010 8:57 PM To: Albert ARIBAUD Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 22, 2010 8:54 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: Build failures with older toolchain Le 22/11/2010 16:02, Premi, Sanjeev a écrit : -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 22, 2010 8:02 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: Build failures with older toolchain Le 22/11/2010 14:50, Premi, Sanjeev a écrit : Tried the same stuff for overo and no issues! Since there linker scripts are same between omap3_evm, omap3_beagle and omap3_overo, only difference could have been board specific code. I was hoping to find some code that might be offending the linker; unable to find by inspection, I reduced the default configuration for the evm to as low as I could - still see: arm-none-linux-gnueabi-ld: section .bss [800fe358 - 800fee1b] overlaps section .rel.dyn [800fe358 - 8010076f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x800fe358 overlaps previous sections I am still not sure why the start of .bss and .rel.dyn for omap3_evm start at same address That is because they are voluntarily overlapped. This looks like the patch I recently did, which in essence does overlap BSS (which is not used before relocation) and relocation tables (which are not used after relocation) so that the FLASH and RAM footprint remain minimal. [sp] Are you referring to this patch? http://git.denx.de/?p=u-boot.git;a=commitdiff;h=aaeb0a890a050b 58be87fa2b165eec5fa947dc86 I see the change for arm926ejs/u-boot.lds and armv7/u-boot.lds to be similar. Your commit mentions about the new ld vs. old; I had seen this earlier as well. It was the reason for me to try CodeSourcery Lite 2010-q1 but there I get a different error - mentioned in my first post. Which toolchain version are you using? I usually try the 2009q3 Code Sourcery and the ELDK 4.2 toolchains. Can you compare the ld invocation command lines for a failure case and a success case? The difference could be in the linker options. [sp] Identical :( Would you want me to share the build logs or the last step? The generated u-boot.lds is also same. It was my first step. Then I started looking if there is any forced addition on specific section that may not be going well with linker/ relocation changes - reason for trying a minimal config. Albert, I saw some more - what I believe related changes - since last week; but the linker error still persists. with 2009-q1 toolchain: --- busb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o common/libcommon.o lib/libfdt/libfdt.o api/libapi.o post/libpost.o arch/arm/cpu/armv7/omap-common/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3 -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: section .bss [8003f5c0 - 8007e31f] overlaps section .rel.dyn [8003f5c0 - 80044e4f] arm-none-linux-gnueabi-ld: section .dynsym [80044e50 - 80044eef] overlaps section .bss [8003f5c0 - 8007e31f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c0 overlaps previous sections make: *** [u-boot] Error 1 with 2010-q1 toolchain: --- mmon/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e0 overlaps previous sections arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin Best regards, Sanjeev ~sanjeev Amicalement, -- Albert. ___ 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] Build failures with older toolchain
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 29, 2010 4:03 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: Re: Build failures with older toolchain Le 29/11/2010 10:47, Premi, Sanjeev a écrit : Albert, I saw some more - what I believe related changes - since last week; but the linker error still persists. with 2009-q1 toolchain: --- busb_phy.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o common/libcommon.o lib/libfdt/libfdt.o api/libapi.o post/libpost.o arch/arm/cpu/armv7/omap-common/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnu eabi/4.3.3 -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: section .bss [8003f5c0 - 8007e31f] overlaps section .rel.dyn [8003f5c0 - 80044e4f] arm-none-linux-gnueabi-ld: section .dynsym [80044e50 - 80044eef] overlaps section .bss [8003f5c0 - 8007e31f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5c0 overlaps previous sections make: *** [u-boot] Error 1 with 2010-q1 toolchain: --- mmon/libomap-common.o board/ti/evm/libevm.o --end-group /db/psp_git/users/a0756819/u-boot/arch/arm/lib/eabi_compat.o -L /opt/codesourcery/2010q1-202/bin/../lib/gcc/arm-none-linux-gnu eabi/4.4.1/armv4t -lgcc -Map u-boot.map -o u-boot arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8e0 overlaps previous sections arm-none-linux-gnueabi-objcopy -O srec u-boot u-boot.srec arm-none-linux-gnueabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin Weird... I've compiled v2010.12-rc2, for boards omap3_evm, omap3_overo and omap3_beagle, with 2010q1, and here is what I get, which is quite different from what you get: alb...@lilith:~/src/u-boot$ ./MAKEALL omap3_evm omap3_overo omap3_beagle Configuring for omap3_evm board... start.S: Assembler messages: start.S:144: Error: constant expression expected -- `ldr sp,=((0x4020FFFC-CONFIG_SYS_GBL_DATA_SIZE))' make[1]: *** [start.o] Erreur 1 make: *** [arch/arm/cpu/armv7/start.o] Erreur 2 make: *** Attente des tâches non terminées arm-none-linux-gnueabi-size: './u-boot': No such file Configuring for omap3_overo board... text data bss dec hex filename 21296510840 210624 434429 6a0fd ./u-boot Configuring for omap3_beagle board... text data bss dec hex filename 24318211300 203648 458130 6fd92 ./u-boot - SUMMARY Boards compiled: 3 Boards with warnings or errors: 1 ( omap3_evm ) -- alb...@lilith:~/src/u-boot$ [sp] Did you apply the patch I sent to off-the-list? (pasted below) I had been holding this patch until until the problem is really solved - just in case there was a relation. [patch] diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index aeb45c6..c93f689 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -348,7 +348,9 @@ extern unsigned int boot_flash_type; * Support for relocation */ #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_D +#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK \ + - GENERATED_GBL_DATA_SIZE) + /* * Define the board revision statically [/patch] Best regards, Sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, November 29, 2010 4:05 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain Dear Premi, Sanjeev, can you please quote onlye _relevant_ parts of previous messages? Thanks. [sp] I do try to snip the messages. I didn't do so this time to maintain context - but, may be, I erred on wrong side. In message b85a65d85d7eb246be421b3fb0fbb5930247a0a...@dbde02.ent.ti.com you wrote: [snip] Are you sure these are the only errors you see? Because for me, building for omap3_evm fails like this: start.S: Assembler messages: start.S:144: Error: constant expression expected -- `ldr sp,=((0x4020FFFC-CONFIG_SYS_GBL_DATA_SIZE))' make[1]: *** [/work/wd/tmp-arm/arch/arm/cpu/armv7/start.o] Error 1 make: *** [/work/wd/tmp-arm/arch/arm/cpu/armv7/start.o] Error 2 make: *** Waiting for unfinished jobs make: *** wait: No child processes. Stop. And this is a clear indication that the board support code has not been adapted yet (CONFIG_SYS_GBL_DATA_SIZE has been replaced by GENERATED_GBL_DATA_SIZE some time ago). [sp] I just responded to Albert' message on same issue. I stumbled on the current problem while trying to fix just the problem you notice here. Assuming relation, I had not submitted the patch - so far. But it looks to be causing more confusion - so patch follows in next few mins. ~sanjeev Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You said you didn't want to use CGI.pm, but methinks you are needlessly reinventing the wheel, one spoke at a time. Either you are masochistic, or you just haven't seen enough of what CGI.pm can do for you. -- Randal L. Schwartz in 8cyb81rg81@gadget.cscaper.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, November 29, 2010 5:00 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain [snip] I had been holding this patch until until the problem is really solved - just in case there was a relation. You mean you are complaining about problems with code you have modified locally, and then expect us to diagnose your problems without even telling us 1) that you changed the code and 2) what exactly you changed? [sp] In my original message I did mention about local change. At least, then, I believed them to be unrelated... and mentioned so. This patch is corrupted.and does not apply. Please see http://www.denx.de/wiki/U-Boot/Patches [sp] I shared the patch with Albert off-the-list as he had planned to work on it... It was to indicate the change that I was doing. BTW, I now notice that few chars on the pasted diff seem to have been trimed (not sure why) therefore patch didn't apply. Should have been more careful... I have posted an updated patch refreshed against the latest master few mins back. I have no idea if it results in a running system (as I have no hardware to test it), but I can confirm that a patch like this: diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 84b2986..f3df8de 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -330,7 +330,7 @@ extern unsigned int boot_flash_type; * Support for relocation */ #define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1 -#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - CONFIG_SYS_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_SP_ADDR (LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE) [sp] Although, you the patch I send earlier didn't apply cleanly, I was making the same change... and noticing the failures. As mentioned earlier, I did not expect to see any errors after making this change. I am process of downloading the 2009q3 version from codesourcery Albert mentioned he is using it. Are you on the same version as well? ~sanjeev [snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, November 29, 2010 5:35 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb5930247a0a...@dbde02.ent.ti.com you wrote: I am process of downloading the 2009q3 version from codesourcery Albert mentioned he is using it. Are you on the same version as well? No, I'm using ELDk 4.2 [sp] Okay, so I downloaded both 2009-q3 and 2010.09-50 versions of the Codesourcery Lite edition. There is no difference in the observations between 2009q3 and 2010q1. However, the 2010.09-50 returns with screen pages full of the undefined reference errors and assertion failures in linker - probably due to undefined symbols. I tried to revert sort shared by Wolfgang; even that didn't help. I will start working backwards from the errors I notice with 2010.09-50. Should I post the errors? ~sanjeev 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 Vulcans do not approve of violence. -- Spock, 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] v2010-rc2: OMAP3 broken
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Heiko Schocher Sent: Monday, November 29, 2010 8:35 PM To: Albert ARIBAUD Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] v2010-rc2: OMAP3 broken [snip] in arch/arm/cpu/armv7/omap-common/timer.c timer_init() sets timestamp to 0, before relocation is executed, which leads that the memory @80046d7c gets overwritten to 0, which results in crashing in the fixrel case ... So it seems to me the sort version intermix the rel dyn section entries with normal vars in bss ... Which raises the question: Why is the rel.dyn Section in the bss section? I have been facing the linker errors due to overlap of these sections. Using git-bisect, I was able to narrow down the failure to commit 6d8962e814c15807dd6ac5757904be2a02d187b8. I had the same question above. See these: http://marc.info/?l=u-bootm=129043627514796w=2 http://marc.info/?l=u-bootm=129041727622164w=2 ~sanjeev 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Monday, November 29, 2010 9:04 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain Le 29/11/2010 16:08, Premi, Sanjeev a écrit : I will start working backwards from the errors I notice with 2010.09-50. Should I post the errors? You should post patches against the master branch for others to be able to build the same code as you build. Do not post the compile errors, though: rather, try and find why they occur and post your conclusions. [sp] I am working on analysis. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
Sent: Monday, November 29, 2010 8:38 PM
To: Wolfgang Denk
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Build failures with older toolchain
[snip]...[snip]
I am process of downloading the 2009q3 version from
codesourcery
Albert mentioned he is using it. Are you on the same
version as
well?
No, I'm using ELDk 4.2
[sp] Okay, so I downloaded both 2009-q3 and 2010.09-50 versions of the
Codesourcery Lite edition.
There is no difference in the observations between
2009q3 and 2010q1.
[sp] I have been able to narrow down the problem to one variable defined
in board/ti/evm.c - omap3_evm_version - declared as:
static u8 omap3_evm_version;
Any attempt to assign value this variable in omap3_evm_get_revision()
leads to the linker error I noted with Codesourcery 2010q1-202.
With 2009q1-203, definition of variable itself is sufficient to cause
the linker error.
I have pasted a patch below that constructs the testcase I have created
to explain these observations:
1) When macros both _EXCLUDE_ME_1 and _EXCLUDE_ME_2 are undefined, the
problem is - as described.
2) When only macro _EXCLUDE_ME_1 is defined, the compilation succeeds
with Codesourcery 2010q1-202; but fails with 2009q1-203.
3) When both macros _EXCLUDE_ME_1 and _EXCLUDE_ME_2 are defined, the
compilation succeeds with both codesourcery versions.
OMAP3EVM is obviously not the only file using statics. I see their usage
in many files including OMAP3Beagle as well - one reason I did not even
suspect this to be problem.
I haven't yet been able to conclude the cause of failure - but appears
to be related to handling of static variables across compiler versions.
Still need to investigate further on this...
Board revision needs to be detected early during initialization. How is
this handled for other boards? (I am currently trying to browse non-omap
boards for pointers). Any quick suggestions would be helpful.
[patch]
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 09d14f7..e766355 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -37,15 +37,30 @@
#include asm/mach-types.h
#include evm.h
+/* #define _EXCLUDE_ME_1 *//* Uncomment - works with 2010q1 only */
+/* #define _EXCLUDE_ME_2 *//* Uncomment - works with 2009q3 as well */
+
+#if !defined(_EXCLUDE_ME_2)
static u8 omap3_evm_version;
+#endif
u8 get_omap3_evm_rev(void)
{
+#ifdef _EXCLUDE_ME_2
+ return OMAP3EVM_BOARD_GEN_1; /* Debugging: Don't use the variable */
+#else
return omap3_evm_version;
+#endif
+
}
static void omap3_evm_get_revision(void)
{
+#ifdef _EXCLUDE_ME_COMPLETELY_
+ /*
+* Original code in the function is being removed completely to reduce
+* scope of the debug exercise.
+*/
#if defined(CONFIG_CMD_NET)
/*
* Board revision can be ascertained only by identifying
@@ -80,6 +95,20 @@ static void omap3_evm_get_revision(void)
omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
#endif
#endif /* CONFIG_CMD_NET */
+
+#else
+ /*
+* Dummy implementation of function just for testing
+*/
+
+#if !defined(_EXCLUDE_ME_1) !defined(_EXCLUDE_ME_2)
+ /*
+* Dummy assignment just for testing
+*/
+ omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
+#endif
+
+#endif /* _EXCLUDE_ME_COMPLETELY_ */
}
#ifdef CONFIG_USB_OMAP3
[/patch]
[snip]
Removed my observations for Codesourcery 2010.09-50.
Did not get chance to look at them so far...
[/snip]
Best regards,
Sanjeev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: relocation and bss usage (timer, gpmc, ...)
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Alexander Holler Sent: Tuesday, November 30, 2010 9:59 PM To: u-boot@lists.denx.de Subject: [U-Boot] OMAP3: relocation and bss usage (timer, gpmc, ...) Hello, browsing through some code searching for a reason why an u-boot compiled with gcc 4.5.1 fails to boot on a beagleboard, I've come through another place where bss is used before relocation: gpmc_init (gpmc_cfg) in arch/arm/cpu/armv7/omap3/mem.c. I haven't fixed it up to now, but I want to inform the people actually working with that board (currently I don't have any to do with that board and just touching at from time to time for fun), that there might be other places than the already mentioned timer_init() and that gpmc_init(). All candidates for such problems could be found in board_init_f() in arch/arm/lib/board.c, escpecially all functions which appear in init_sequence in board.c. For omap3evm - I was getting multiple errors during compilation. Most for undefined symbols - which existed in the compiled objects but, I suspect, not in right sequence. Haven't still been able to look back at these errors; still surprised to find that you had the code running on beagle. ~sanjeev Someone should take the time and check them all. ;) Regards, Alexander ___ 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] Build failures with older toolchain
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Tuesday, November 30, 2010 10:15 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Build failures with older toolchain
On 30.11.2010 15:25, Premi, Sanjeev wrote:
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
Sent: Monday, November 29, 2010 8:38 PM
To: Wolfgang Denk
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] Build failures with older toolchain
[snip]...[snip]
I am process of downloading the 2009q3 version from
codesourcery
Albert mentioned he is using it. Are you on the same
version as
well?
No, I'm using ELDk 4.2
[sp] Okay, so I downloaded both 2009-q3 and 2010.09-50
versions of the
Codesourcery Lite edition.
There is no difference in the observations between
2009q3 and 2010q1.
[sp] I have been able to narrow down the problem to one
variable defined
in board/ti/evm.c - omap3_evm_version - declared as:
static u8 omap3_evm_version;
Any attempt to assign value this variable in
omap3_evm_get_revision()
leads to the linker error I noted with Codesourcery
2010q1-202.
With 2009q1-203, definition of variable itself is
sufficient to cause
the linker error.
Maybe CCing Codesourcery's mailing list
http://www.codesourcery.com/archives/arm-gnu-discuss/maillist.html
could help, too? At least it's worth a try?
I was thinking of same - only after we understand if there isn't
something we are, possibly, missing in changes to linker scripts.
Dirk
I have pasted a patch below that constructs the
testcase I have created
to explain these observations:
1) When macros both _EXCLUDE_ME_1 and _EXCLUDE_ME_2
are undefined, the
problem is - as described.
2) When only macro _EXCLUDE_ME_1 is defined, the
compilation succeeds
with Codesourcery 2010q1-202; but fails with 2009q1-203.
3) When both macros _EXCLUDE_ME_1 and _EXCLUDE_ME_2
are defined, the
compilation succeeds with both codesourcery versions.
OMAP3EVM is obviously not the only file using
statics. I see their usage
in many files including OMAP3Beagle as well - one
reason I did not even
suspect this to be problem.
I haven't yet been able to conclude the cause of
failure - but appears
to be related to handling of static variables across
compiler versions.
Still need to investigate further on this...
Board revision needs to be detected early during
initialization. How is
this handled for other boards? (I am currently trying
to browse non-omap
boards for pointers). Any quick suggestions would be helpful.
[patch]
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 09d14f7..e766355 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -37,15 +37,30 @@
#includeasm/mach-types.h
#include evm.h
+/* #define _EXCLUDE_ME_1 *//* Uncomment - works
with 2010q1 only */
+/* #define _EXCLUDE_ME_2 *//* Uncomment - works
with 2009q3 as well */
+
+#if !defined(_EXCLUDE_ME_2)
static u8 omap3_evm_version;
+#endif
u8 get_omap3_evm_rev(void)
{
+#ifdef _EXCLUDE_ME_2
+ return OMAP3EVM_BOARD_GEN_1; /* Debugging: Don't use
the variable */
+#else
return omap3_evm_version;
+#endif
+
}
static void omap3_evm_get_revision(void)
{
+#ifdef _EXCLUDE_ME_COMPLETELY_
+ /*
+* Original code in the function is being removed
completely to reduce
+* scope of the debug exercise.
+*/
#if defined(CONFIG_CMD_NET)
/*
* Board revision can be ascertained only by identifying
@@ -80,6 +95,20 @@ static void omap3_evm_get_revision(void)
omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
#endif
#endif/* CONFIG_CMD_NET */
+
+#else
+ /*
+* Dummy implementation of function just for testing
+*/
+
+#if !defined(_EXCLUDE_ME_1) !defined(_EXCLUDE_ME_2)
+ /*
+* Dummy assignment just for testing
+*/
+ omap3_evm_version = OMAP3EVM_BOARD_GEN_2;
+#endif
+
+#endif /* _EXCLUDE_ME_COMPLETELY_ */
}
#ifdef CONFIG_USB_OMAP3
[/patch]
[snip]
Removed my observations for Codesourcery 2010.09-50.
Did not get chance to look at them so far...
[/snip]
Best regards,
Sanjeev
___
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] Build failures with older toolchain
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Tuesday, November 30, 2010 7:56 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, November 29, 2010 8:38 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures with older toolchain [snip]...[snip] I am process of downloading the 2009q3 version from codesourcery Albert mentioned he is using it. Are you on the same version as well? No, I'm using ELDk 4.2 [sp] Okay, so I downloaded both 2009-q3 and 2010.09-50 versions of the Codesourcery Lite edition. There is no difference in the observations between 2009q3 and 2010q1. [snip]...[snip] There were some good patches posted recently esp the bss_debug tool and fix for ARM relocation from Andreas. Applied them in order to get more information. In addition, added print indicating the function being called in for (init_funcptr= ) loop within board_init_f(). Also added a print in the function omap3_evm_get_revision() just to see if it ever gets called in due to incorrect sequencing. I could confirm that functions in init_sequence[] are called and omap3_evm_get_revision() is not called in this sequence. When everything failed, I went back to the u-boot.lds and changed the way overlay is defined. ...AND PROBLEM SEEMS TO BE SOLVED! I can now compile u-boot with both 2009q1 and 2010q1 without any error. (yet to try with 2010.09) To verify, I wanted to do a before-and-after comparison but couldn't have done for the omap3_evm - used omap3_beagle instead. I haven't yet tried running the binary on the board; but here are top level observations: 1) .bss and .rel.dyn are starting at same address. 2) The size of .rodata has increased. (Why? not yet spent time on?) Sending the patch in next few mins: ~sanjeev (Comparison: before and after) 753c753 .rodata 0x80035578 0x9f38 --- .rodata 0x80035578 0x9f46 757c757 .rodata0x8003571c 0xbc arch/arm/lib/libarm.o --- === [contents deleted] === .u_boot_cmd 0x80041aac 0x658 --- .u_boot_cmd 0x80041abc 0x658 === [contents deleted] === 967,968c967,973 .rel.dyn0x80042104 0x5af0 0x80042104__rel_dyn_start = . --- .dynsym 0x80042114 0xa0 0x80042114__dynsym_start = . *(.dynsym) .dynsym0x80042114 0xa0 arch/arm/cpu/armv7/start.o .rel.dyn0x800421b4 0x5af0 0x800421b4__rel_dyn_start = . === [contents deleted] === 984,985c986,987 .bss0x800421040x31ba8 0x80042104__bss_start = . --- .bss0x800421b40x31bb4 load address 0x80047ca4 0x80073d68__bss_start = . === [contents deleted] === .dynbss 0x80073cac0x0 --- .dynbss 0x80073d680x0 load address 0x80079858 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures with older toolchain
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Wednesday, December 01, 2010 8:33 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Wolfgang Denk Subject: Re: [U-Boot] Build failures with older toolchain Le 01/12/2010 15:56, Premi, Sanjeev a écrit : When everything failed, I went back to the u-boot.lds and changed the way overlay is defined. ...AND PROBLEM SEEMS TO BE SOLVED! This most probably means some of the code running before relocation uses BSS; see below. I can now compile u-boot with both 2009q1 and 2010q1 without any error. (yet to try with 2010.09) To verify, I wanted to do a before-and-after comparison but couldn't have done for the omap3_evm - used omap3_beagle instead. I haven't yet tried running the binary on the board; but here are top level observations: 1) .bss and .rel.dyn are starting at same address. This is normal and should not have any negative impact as long as code that runs before relocation does not access BSS -- and it should not, since BSS only exists after relocation. [sp] Yes. This is what I wanted to confirm to ensure that relocation isn't breaking after the changes. In a way it was my testcase to see that I get similar map for omap3_beagle before and after making changes. 2) The size of .rodata has increased. (Why? not yet spent time on?) Weird. Can you provide all necessary info for duplicating these two builds? Sending the patch in next few mins: If that's a patch to remove the overlay in the .lds, it's a Nak from me already. [sp] No. I am not removing relocation. Do look at the patch. I just sent from my Linux box.. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: Premi, Sanjeev
Sent: Wednesday, December 01, 2010 8:47 PM
To: u-boot@lists.denx.de
Cc: Premi, Sanjeev
Subject: [PATCH] ARMv7: Fix linker errors across toolchain versions
This patch fixes the linker problems noticed while
building the omap3_evm with Codesourcery toolchains
2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both
omap3_evm and omap3_beagle with toolchain versions
2009q1 and 2010q1.
[1] http://marc.info/?l=u-bootm=129104332808386w=2
Signed-off-by: Sanjeev Premi pr...@ti.com
---
The patch touches all ARMv7 architectures, will need
to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely
hands-on. Impact would have to be reviewd as well.
This is the reason for sending the patch early - before
i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
[snip]...[snip]
The u-boot built after this change alone gets stuck somewhere after
dram_init(). However, removing the sort from LIBS (as suggested
by Wolfgang), the u-boot comes up fine on the omap3_evm.
[patch]
diff --git a/Makefile b/Makefile
index 87a383d..a530261 100644
--- a/Makefile
+++ b/Makefile
@@ -263,7 +263,7 @@ ifeq ($(SOC),s5pc2xx)
LIBS += $(CPUDIR)/s5p-common/libs5p-common.o
endif
-LIBS := $(addprefix $(obj),$(sort $(LIBS)))
+LIBS := $(addprefix $(obj),$(LIBS))
.PHONY : $(LIBS) $(TIMESTAMP_FILE) $(VERSION_FILE)
LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).o
[/patch]
U-Boot 2010.12-rc2-00030-g4998cdc-dirty (Dec 01 2010 - 21:09:59)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz
OMAP3 EVM board + LPDDR/NAND
I2C: ready
DRAM: 256 MiB
NAND: 256 MiB
In:serial
Out: serial
Err: serial
Read back SMSC id 0x9220
Die ID #6092000404032d460c01201a
Net: smc911x-0
Hit any key to stop autoboot: 0
OMAP3_EVM #
OMAP3_EVM #
Here is my git-log (including the patch above):
premi # g-log-10
4998cdc : ARMv7: Fix linker errors across toolchain versions
49733aa : Merge branch 'master' of /home/wd/git/u-boot/custodians
f8264e0 : Merge branch 'master' of git://git.denx.de/u-boot-arm
b194577 : hwconfig: Fix dummy initialization of {board, cpu}_hwconfig
a55bb83 : powerpc/85xx: Introduce CONFIG_SYS_EXTRA_ENV_RELOC
52eb2c7 : Merge branch 'master' of git://git.denx.de/u-boot-samsung
83b622a : Merge branch 'master' of /home/wd/git/u-boot/custodians
3410a99 : Merge branch 'master' of git://git.denx.de/u-boot-sh
a7bf3ec : Merge branch 'master' of /home/wd/git/u-boot/custodians
e45c98a : mpc83xx: Make it boot again
premi #
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert ARIBAUD
Sent: Wednesday, December 01, 2010 10:43 PM
To: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Le 01/12/2010 16:17, Sanjeev Premi a écrit :
This patch fixes the linker problems noticed while
building the omap3_evm with Codesourcery toolchains
2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both
omap3_evm and omap3_beagle with toolchain versions
2009q1 and 2010q1.
[1] http://marc.info/?l=u-bootm=129104332808386w=2
Signed-off-by: Sanjeev Premipr...@ti.com
---
The patch touches all ARMv7 architectures, will need
to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely
hands-on. Impact would have to be reviewd as well.
This is the reason for sending the patch early - before
i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/u-boot.lds
b/arch/arm/cpu/armv7/u-boot.lds
index 5725c30..faf6ad8 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,22 +55,26 @@ SECTIONS
. = ALIGN(4);
- .rel.dyn : {
- __rel_dyn_start = .;
- *(.rel*)
- __rel_dyn_end = .;
- }
-
.dynsym : {
__dynsym_start = .;
*(.dynsym)
}
- .bss __rel_dyn_start (OVERLAY) : {
- __bss_start = .;
- *(.bss)
-. = ALIGN(4);
- _end = .;
+ OVERLAY : NOCROSSREFS
+ {
+ .rel.dyn {
+ __rel_dyn_start = .;
+ *(.rel*)
+ __rel_dyn_end = .;
+ }
+
+ .bss
+ {
+ __bss_start = .;
+ *(.bss)
+. = ALIGN(4);
+ _end = .;
+ }
}
/DISCARD/ : { *(.dynstr*) }
Nak -- what we want to overlay is .bss on one hand, and
.rel.dyn *plus*
.dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay was supposed
to be .rel.dyn and .bss.
Let me get the .rel.dyn + .dynsym overlay with .bss.
If it works across compiler versions would that be okay?
~sanjeev
Also, this change modifies the mapping, so if mi makes an obvious bug
disappear, it may be only because the resulting u-boot corrupts
relocation now in a less obvious way.
Amicalement,
--
Albert.
___
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] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Wednesday, December 01, 2010 11:02 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Le 01/12/2010 18:19, Premi, Sanjeev a écrit :
Nak -- what we want to overlay is .bss on one hand, and
.rel.dyn *plus*
.dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay
was supposed
to be .rel.dyn and .bss.
That's because I avoid saying .rel.dyn plus .dynsym and
just go for
short .rel.dyn instead. Sorry for that.
Let me get the .rel.dyn + .dynsym overlay with .bss.
If it works across compiler versions would that be okay?
Getting .rel.dyn + .dynsym overlay with .bss is exactly what the
current linker file does, by emitting .rel.dyn, then .dynsym, then
overlaying .bss back at the start of .rel.dyn. Look up a
readelf -a of
./u-boot and see where each section starts and ends.
[sp] I did the same - but focused only on .rel.dyn and .bss
If you find another way to do this overlay yet end up producing a
different binary, I'll be interested in the result, but I
honestly don't
think you will find any.
[sp] I am trying on this. Getting back to linker scripts after many
years. But assuming that there is no way; I am still looking
for an explanation on:
1) why the current metod produces different errors across
different toolchain versions.
2) How does presence of one variable alone breaks the build?
At least, compiler doesn't complain. Even moving it out
of .bss by explicit initialization doesn't help.
BTW, I verified that it is not used anywhere till end of
board_init_f() - didn't go further. Should I?
Can yo help me on these?
~sanjeev
~sanjeev
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message-
From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
Sent: Wednesday, December 01, 2010 11:02 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
toolchain versions
Le 01/12/2010 18:19, Premi, Sanjeev a écrit :
Nak -- what we want to overlay is .bss on one hand, and
.rel.dyn *plus*
.dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay
was supposed
to be .rel.dyn and .bss.
That's because I avoid saying .rel.dyn plus .dynsym and
just go for
short .rel.dyn instead. Sorry for that.
Let me get the .rel.dyn + .dynsym overlay with .bss.
If it works across compiler versions would that be okay?
Getting .rel.dyn + .dynsym overlay with .bss is exactly what the
current linker file does, by emitting .rel.dyn, then .dynsym, then
overlaying .bss back at the start of .rel.dyn. Look up a
readelf -a of
./u-boot and see where each section starts and ends.
If you find another way to do this overlay yet end up producing a
different binary, I'll be interested in the result, but I
honestly don't
think you will find any.
[sp] Had a quick question - hence separate mail.
Do we really need to preserve section .dynsym in the final
binary. OR are we okay with single section that contains
contents from both?
~sanjeev
~sanjeev
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 12:07 AM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions [snip]...[snip] For the moment we should focus on what happens when we use the current .lds -- it causes a linker error, right? Once we get this sorted out, we'll see if the build actually runs. Can yo help me on these? As for the linker error, I am sorry I got a bit lost: I know which toolchains you tried (2010q1 and 2009q1) but not exactly which codebase you build (is it v2010.12-rc2 ? master ? specific patches?) or which board you build. Please refresh me on this, so that I can reproduce the issue locally (I've got 2010q1 already installed). I tried with 2009q1-203, 2009q3-68 and 2010q1-202. But results with 2009q3 and 2010q1 were same - till I tried all three; so, currently using 2009q1 and 2010q1. Yes. I was on latest master when I sent patch. Had included the git log as reference for same reason when I got it running. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 1:21 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Hi Wolfgang, Le 02/12/2010 08:34, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4cf743e6.60...@free.fr you wrote: Starting with the fact that the linker issue is only for one board, omap3_evm, I looked up the board-specific code. First thing that I noticed was static u8 omap3_evm_version; I changed this to static u8 omap3_evm_version = 1; so that the static was moved out of BSS and the linker warning disappeared (reminder: v2010.12-rc2, omap3_evm, arm-2010q1). Now this is not the first static BSS variable we use in U-Boot, and the others did not cause linker warnings (not *all* the others, at least), so the real cause is yet unknown to me. But that's at least a lead we can follow. Write access is only in omap3_evm_get_revision() which in turn only gets called in misc_init_r(), i. e. after relocation. Read access is only in get_omap3_evm_rev() [which is not called outside this file and thus should be made static!] which gets called only in omap3_evm_need_extvbus() which gets acalled only in musb_platform_init(), i. e. during USB init. This should be safe. Alright. You could try out what happens if you make get_omap3_evm_rev() static... No change: the warning remains, and so do the two segments. Maybe I should subscribe the binutils list and ask there. Meanwhile, this variable could be initialized to some safe value such as OMAP3EVM_BOARD_UNKNOWN. One of the things I did to move it away from .bss BTW... Why on Earth is it an uint8? Probably a space saving measure, but one I think is not really fruitful, because of probable paddings and alignments; making it an int would allow using smsc_id directly as values for the OMAP3EVM_BOARD_GEN_1 and OMAP3EVM_BOARD_GEN_2... ... plus it removes the linker warning! I thus suggest turning omap3_evm_version from uint8 to int and get on with debugging the board. Albert, I have already done this - may not be exactly same. while trying to debug linker script problem; did not want to deviate from the current problem so it is in my working code. ~sanjeev 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] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 12:30 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev; Wolfgang Denk Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Le 01/12/2010 22:39, Albert ARIBAUD a écrit : This one is a conundrum. Using 2010q1, building omap3_evm causes a linker warning arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e8f0 overlaps previous sections while building omap3_beagle does not cause any linker warning. Both boards use the same armv7 u-boot.lds and have a .bss which is way bigger than the .rel.dyn plus .dynsym sections that it does overlay. IOW, they have a similar layout for .rel.dyn, .dynsym and .bss, but one gets the warning and one does not. The one difference a readelf shows is that for beagle, there is only one segment: 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .dynsym While for evm there is 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .bss 01 .dynsym Note that .bss has appeared in segment 00 for evm, whereas it was absent for beagle, and that .dynsym was rejected to a second segment -- why? I don't know. Note: I've tried with putting input sections .rel.dyn and .dynsym into a single output section .rel.dyn: this makes the second segment disappear, but for evm the warning remains and .bss remains in the segment. I have a tiny clue. Starting with the fact that the linker issue is only for one board, omap3_evm, I looked up the board-specific code. First thing that I noticed was static u8 omap3_evm_version; I changed this to static u8 omap3_evm_version = 1; so that the static was moved out of BSS and the linker warning disappeared (reminder: v2010.12-rc2, omap3_evm, arm-2010q1). Now this is not the first static BSS variable we use in U-Boot, and the others did not cause linker warnings (not *all* the others, at least), so the real cause is yet unknown to me. But that's at least a lead we can follow. If this BSS variable is used before relocation (I haven't checked this), then anyway it'll have to move; in that case I'll keep an eye on this linker warning and try to sort it out if I get time. I did explain yesterday that variable is not used in relocation. If you notice the code snippet I sent yesterday, I had removed every assignment to the variable. And 2009q1 was still not happy! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 1:57 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions [snip] So Sanjeev would change the u8 to an int and proceed with board debug, I will be away from desk for an hour. Will have the patch posted immediately after... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 2:12 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Hi Sanjeev, Le 02/12/2010 09:30, Premi, Sanjeev a écrit : -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Thursday, December 02, 2010 1:57 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions [snip] So Sanjeev would change the u8 to an int and proceed with board debug, I will be away from desk for an hour. Will have the patch posted immediately after... Please let us know the current status of the board, i.e. whether it works or not, and if not, what the console output is. Just posted the patch. The u-boot comes up on the EVM - only after sort related change in the Makefile. Haven't debuged it yet. Also noticed a difference between the changes I made yesterday; and your mail - maintaining 'u8' vs. 'int' for the omap3_evm_revision. ~sanjeev Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, December 02, 2010 5:09 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb5930247b9a...@dbde02.ent.ti.com you wrote: Just posted the patch. The u-boot comes up on the EVM - only after sort related change in the Makefile. Haven't debuged it yet. Could you ***please*** be a bit more precise? What EXACTLY was that sort related change? Do you still need to remove the $(sort) call for the LIBS? That should NOT be done. Wolfgang, I know it shouldn't be done - but just trying to take problem one by one. Unless you want me to report the problems onl after I have a fix for them - and not seek any help. ~sanjeev Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can't evaluate a man by logic alone. -- McCoy, I, Mudd, stardate 4513.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, December 02, 2010 5:07 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code. Dear Sanjeev Premi, In message 1291288812-12653-1-git-send-email-pr...@ti.com you wrote: This patch does following changes: * Change the type (u8 - int) for omap3_evm_version. * Introduce an 'undefined' board revision for init value. * Use of #define instead of magic numbers Signed-off-by: Sanjeev Premi pr...@ti.com --- board/ti/evm/evm.c | 39 +++ board/ti/evm/evm.h | 17 +++-- 2 files changed, 30 insertions(+), 26 deletions(-) diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c index 09d14f7..8d9ce73 100644 --- a/board/ti/evm/evm.c +++ b/board/ti/evm/evm.c @@ -37,36 +37,43 @@ #include asm/mach-types.h #include evm.h -static u8 omap3_evm_version; +static int omap3_evm_version = OMAP3EVM_BOARD_UNDEF; ... +#define OMAP3EVM_BOARD_UNDEF -1 /* EVM revision not detected */ Sorry, but I will not accept this patch. The only purpose of this initialization with a non-zero value is to paper over a problem. As a result, the problem will be left unsolved, so it bites us again elsewhere, and we increase the memory footprint of the U-Boot image without need. At least I haven't deserted the problem; but the patch will help some one to test beyond the basic boot and see if there is any other impact on the functionality. The board has been broken for many weeks. As we see problem with sort($LIBS); there could be more issues that are yet to be discovered. ~sanjeev 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 You get a wonderful view from the point of no return. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3: EVM: Linker errors across tool chain versions
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Dirk Behme Sent: Friday, December 17, 2010 4:10 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] OMAP3: EVM: Linker errors across tool chain versions [snip]...[snip] GNU ld (Sourcery G++ Lite 2010.09-50) 2.20.51.20100809 -rwxr-xr-x 1 dirk users 981801 16. Dez 10:41 u-boot I would really like to nail this down to a specific tool / version. Does this help? Any comments on this? If we would come to a conclusion, soon, I'd like to get a fix integrated for v2010.12. [sp] I had to be away from work for most of this month to attend a personal emergency. Haven't yet followed on this/ related threads to check if the issue has really been taken care of. Will spend next few days to get current on it... ~sanjeev Thanks Dirk ___ 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] potential Uboot Ping problem
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steven Zedeck Sent: Monday, June 01, 2009 8:05 PM To: u-boot@lists.denx.de Subject: [U-Boot] potential Uboot Ping problem Hi, It appears the ping in UBOOT is broken. The ping works fine if you have a network connection. But if the network connection is disconnected the ping hangs the system. There is no response to Control-C either. I have to power cycle the proto to get back to a UBOOT prompt. Is this a known issue or did I possibly break something? I have a board based on the Atmel AT91SAM9RL-EK. My theory is that it may be a generic problem with the uboot ping. I can't confirm that since the only hardware I have is our protos. It was noticed on the OMAP3EVM last FRI and we were suspecting it to be problem with the omap3 board configuration itself. (Though did not spend much time in debug). Now, I too get a feeling that it could be a generic problem. Best regards, Sanjeev Does anyone else have a board with another MAC/PHY that you can try this on? As for UBOOT code, our environment is based on 2008.10 code. Our MAC/PHY is the Microchip ENC28J60. Thanks, Steve -- View this message in context: http://www.nabble.com/potential-Uboot-Ping-problem-tp23815872p 23815872.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ 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] potential Uboot Ping problem
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Peter Tyser Sent: Tuesday, June 02, 2009 3:53 AM To: Steven Zedeck Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] potential Uboot Ping problem Hi Steven, On Mon, 2009-06-01 at 08:03 -0700, Steven Zedeck wrote: I guess thats good news. I looked inside the cmd_ping code a bit. I bet there's a while loop somewhere that is waiting for something and may not have a timeout loop. Any ideas? Thanks, Steve Please don't top post, it makes the conversation hard to follow. http://www.caliburn.nl/topposting.html Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steven Zedeck Sent: Monday, June 01, 2009 8:05 PM To: u-boot@lists.denx.de Subject: [U-Boot] potential Uboot Ping problem Hi, It appears the ping in UBOOT is broken. The ping works fine if you have a network connection. But if the network connection is disconnected the ping hangs the system. There is no response to Control-C either. I have to power cycle the proto to get back to a UBOOT prompt. Is this a known issue or did I possibly break something? I have a board based on the Atmel AT91SAM9RL-EK. My theory is that it may be a generic problem with the uboot ping. I can't confirm that since the only hardware I have is our protos. It was noticed on the OMAP3EVM last FRI and we were suspecting it to be problem with the omap3 board configuration itself. (Though did not spend much time in debug). Now, I too get a feeling that it could be a generic problem. Best regards, Sanjeev Does anyone else have a board with another MAC/PHY that you can try this on? Ideally, if there is no link, the ping command should just exit gracefully without attempting network operations. Eg on my 8561-based board with no cables plugged in: = ping 192.168.1.1 Auto-neg error, defaulting to 10BT/HD eTSEC1: No link. Auto-neg error, defaulting to 10BT/HD eTSEC2: No link. ping failed; host 192.168.1.1 is not alive there is no delay in the printing of the above info. The tsec driver's init function returns -1 when link isn't detected. Perhaps your ethernet driver should do the same? What happens if you ping a non-existent IP address? Does that also hang the board? Do other network operations hang the board if no ethernet cable is plugged in? Here is a session from OMAP3EVM: OMAP3_EVM # setenv autoload no OMAP3_EVM # dhcp smc911x: initializing smc911x: detected LAN9115 controller smc911x: phy initialized smc911x: MAC 00:50:c2:7e:88:72 BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 192.168.1.10 OMAP3_EVM # ping 192.168.1.1 smc911x: initializing smc911x: detected LAN9115 controller smc911x: phy initialized smc911x: MAC 00:50:c2:7e:88:72 ping failed; host 192.168.1.1 is not alive OMAP3_EVM # Best, Peter ___ 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] Build breaks on some OMAP3 configs
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Gadiyar, Anand Sent: Friday, October 30, 2009 10:25 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] Build breaks on some OMAP3 configs Hi, I was trying to build u-boot for omap3_3430sdp and omap3_zoom2, and the build fails with the error below. I'm on commit f2b4bc0 from the master branch. I'm using CodeSourcery's 2008q3 toolchain. The commands I ran were: make CROSS_COMPILE=arm-none-linux-gnueabi- omap3_3430sdp_config; make CROSS_COMPILE=arm-none-linux-gnueabi- Any ideas what I'm doing wrong? make -C examples/standalone all make[1]: Entering directory `/data/git/denx-uboot/u-boot/examples/standalone' arm-none-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e8 -I/data/git/denx-uboot/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /data/arm-2008q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/i nclude -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e8 -I/data/git/denx-uboot/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /data/arm-2008q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/i nclude -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -I.. -Bstatic -T u-boot.lds -Ttext 0x80e8 -o .c arm-none-linux-gnueabi-gcc: no input files make[1]: *** [.c] Error 1 make[1]: Leaving directory `/data/git/denx-uboot/u-boot/examples/standalone' make: *** [examples/standalone] Error 2 I took a look at examples/standalone/Makefile: The patch below gets things going again. So looks like something clobbered $(ELF-y). Any ideas what it could be? Thanks in advance, Anand diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile index 5e2f2bc..73b19e9 100644 --- a/examples/standalone/Makefile +++ b/examples/standalone/Makefile @@ -39,6 +39,7 @@ ELF-ppc += sched ELF-oxc += eepro100_eeprom ELF := $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU)) +ELF := hello_world [sp] This will break the earlier definition for ELF. I am submitting the right fix in few mins.. ~sanjeev SREC = $(addsuffix .srec,$(ELF)) BIN = $(addsuffix .bin,$(ELF)) ___ 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] Fix build failure in examples/standalone
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, November 09, 2009 4:16 AM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] Fix build failure in examples/standalone Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59301de31f...@dbde02.ent.ti.com you wrote: I was surprised too. It is the first time ever I have seen this problem with any Makefile over years. To debug I tried this: ... Makefile:47: *** *** COBJS evaluates to [hello_world.o smc911x_eeprom.o .o]. Stop. make[1]: Leaving directory `/home/sanjeev/u-boot/examples/standalone' make: *** [examples/standalone] Error 2 Notice the empty .o in the output. This prompted me to use $(strip ...) Indeed. I do not doubt that your modification fixes the issue. [sp] I was only illustrating the problem. premi # make --version GNU Make 3.80 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It seems very much to me as if this was a bug in GNU Make 3.80, then. May I please ask you to modify your poatch such that both the code and the commit message contain a comment that the added strip call is a workaround for a white-space handling problem in some versions of GNU make, especially version 3.80? [sp] Sure I will do so today. Best regards, Sanjeev Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A conservative is a man who believes that nothing should be done for the first time. - Alfred E. Wiggam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Fix build failure in examples/standalone
-Original Message- From: Premi, Sanjeev Sent: Monday, November 09, 2009 10:43 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH v2] Fix build failure in examples/standalone Some versions of 'make' do not handle trailing white-spaces properly. Trailing spaces in ELF causes a 'fake' source to be added to the variable COBJS; leading to build failure (listed below). The problem was found with GNU Make 3.80. Using text-function 'strip' as a workaround for the problem. make[1]: Entering directory `/home/sanjeev/u-boot/examples/standalone' arm-none-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e8 -I/home/sanjeev/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/codesourcery/2009q1- 203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/include -pipe -DCONFIG_ ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -g -Os -fno-common -ff ixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e8 -I/home/sanje ev/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/co desourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4. 3.3/includ e -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-inte rwork -march=armv5 -I.. -Bstatic -T u-boot.lds -Ttext 0x80e8 -o .c arm-none-linux-gnueabi-gcc: no input files make[1]: *** [.c] Error 1 make[1]: Leaving directory `/home/sanjeev/u-boot/examples/standalone' make: *** [examples/standalone] Error 2 premi # Signed-off-by: Sanjeev Premi pr...@ti.com --- examples/standalone/Makefile |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile index 5e2f2bc..c02ce43 100644 --- a/examples/standalone/Makefile +++ b/examples/standalone/Makefile @@ -38,7 +38,13 @@ ELF-mpc8260 += mem_to_mem_idma2intr ELF-ppc += sched ELF-oxc += eepro100_eeprom -ELF := $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU)) +# +# Some versions of make do not handle trailing white spaces properly; +# leading to build failures. The problem was found with GNU Make 3.80. +# Using 'strip' as a workaround for the problem. +# +ElF := $(strip $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU))) + SREC = $(addsuffix .srec,$(ELF)) BIN = $(addsuffix .bin,$(ELF)) -- 1.6.2.2 Hi, Just wanted to check if this update is okay? Best regards, Sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] omap3: Is lowlevel_init() ever called?
Hi all,
I have been trying to debug 'strange' clock settings in the omap3evm; that would
surface quite infrequently. However, today I was able to get them regularly.
Symptom: the MPU clock is set at 381MHz instead of expected 500MHz.
Tracing back from prcm_init() to s_init() to lowlevel_init() and cpu_init_crit()
I feel that lowlevel_init() is being skipped at together.
In the patch below, I am updating a flag on very beginning of s_init() and later
printing in print_cpuinfo(). To exclude any other (possible) foul-play by stray
pointer, I initialized this flag to 11 and expect it to be 55 after s_init() is
called. But the value remains 11 - when printed in print_cpuinfo().
Also, CONFIG_SKIP_LOWLEVEL_INIT is not defined in omap3_evm_config.
Though I am at 2009.08, I did not see any differences in start.S that could have
an apparent effect.
Am I missing something completely?
Best regards,
Sanjeev
diff --git a/cpu/arm_cortexa8/omap3/board.c b/cpu/arm_cortexa8/omap3/board.c
index 939ed6c..5dfd8f3 100644
--- a/cpu/arm_cortexa8/omap3/board.c
+++ b/cpu/arm_cortexa8/omap3/board.c
@@ -42,6 +42,8 @@ extern omap3_sysinfo sysinfo;
extern u32 is_mem_sdr(void);
+int s_init_flag=11;
+
/**
* Routine: delay
* Description: spinning delay to use before udelay works
@@ -193,6 +195,8 @@ void s_init(void)
{
int in_sdram = is_running_in_sdram();
+ s_init_flag=55;
+
watchdog_init();
try_unlock_memory();
diff --git a/cpu/arm_cortexa8/omap3/lowlevel_init.S
b/cpu/arm_cortexa8/omap3/lowlevel_init.S
index 73063ec..d83dd53 100644
--- a/cpu/arm_cortexa8/omap3/lowlevel_init.S
+++ b/cpu/arm_cortexa8/omap3/lowlevel_init.S
@@ -174,7 +174,11 @@ lowlevel_init:
ldr sp, SRAM_STACK
str ip, [sp]/* stash old link register */
mov ip, lr /* save link reg across call */
+ nop
+ nop
bl s_init /* go setup pll, mux, memory */
+ nop
+ nop
ldr ip, [sp]/* restore save ip */
mov lr, ip /* restore link reg */
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index 2fb6c10..2f29032 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -31,6 +31,8 @@
#include asm/arch/sys_proto.h
#include i2c.h
+extern int s_init_flag;
+
extern omap3_sysinfo sysinfo;
static struct sdrc *sdrc_base = (struct sdrc *)OMAP34XX_SDRC_BASE;
static struct ctrl *ctrl_base = (struct ctrl *)OMAP34XX_CTRL_BASE;
@@ -414,6 +416,8 @@ int print_cpuinfo (void)
cpu_s, sec_s, rev_s[get_cpu_rev()],
(cpu_family == CPU_AM35XX) ? : CPU-OPP2);
+ printf (s_init_flag = %d\n, s_init_flag);
+
return 0;
}
#endif /* CONFIG_DISPLAY_CPUINFO */
==
U-Boot 2009.08-00047-gd5ef5fe-dirty (Nov 30 2009 - 23:15:59)
OMAP3430/3530-GP ES3.1, CPU-OPP2 L3-165MHz
s_init_flag = 11
OMAP3 EVM board + LPDDR/NAND
DRAM: 128 MB
NAND: 256 MiB
In:serial
Out: serial
Err: serial
Die ID #6092000404032d460c01201a
Net: smc911x-0
Hit any key to stop autoboot: 0
OMAP3_EVM #
OMAP3_EVM #
OMAP3_EVM #
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] omap3: Is lowlevel_init() ever called?
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
Sent: Monday, November 30, 2009 11:41 PM
To: u-boot@lists.denx.de
Subject: [U-Boot] omap3: Is lowlevel_init() ever called?
Hi all,
I have been trying to debug 'strange' clock settings in the
omap3evm; that would
surface quite infrequently. However, today I was able to get
them regularly.
Symptom: the MPU clock is set at 381MHz instead of expected 500MHz.
Tracing back from prcm_init() to s_init() to lowlevel_init()
and cpu_init_crit()
I feel that lowlevel_init() is being skipped at together.
In the patch below, I am updating a flag on very beginning of
s_init() and later
printing in print_cpuinfo(). To exclude any other (possible)
foul-play by stray
pointer, I initialized this flag to 11 and expect it to be 55
after s_init() is
called. But the value remains 11 - when printed in print_cpuinfo().
Also, CONFIG_SKIP_LOWLEVEL_INIT is not defined in omap3_evm_config.
Though I am at 2009.08, I did not see any differences in
start.S that could have
an apparent effect.
Am I missing something completely?
Ok. I was misled by a portion of code+comment that states:
[quote]Copy DPLL code into SRAM[/quote] but goes on to copy
384*32 bytes.
I don't understand the startup bit of this code well, so
have few doubts:
1) What does the magic number #384 correspond to?
384 * 32 = 12288 (0x3000)
2) Going by the comment, we possibly need to copy only the
function _go_to_speed and constants used in it.
Currently, we seem to be copying and relocating 0x3000 bytes.
Isn't it an overhead?
3) While we are executing from SRAM, the variables are (possibly)
being updated in relocated offsets, not 'in place' expected
by the code.
This goes with the behavior I described earlier.
I have made changes to u-boot to optimize the re-execution of the
code detecting silicon version for OMAP3. I have been able to make
it work by calling it twice - once when execution happens from
SRAM and then again in arch_cpu_init().
However, I feel we can optimize this - not just detecting si revision;
but amount of code copied and relocated.
Answers to 3 questions above will help me a lot.
Best regards,
Sanjeev
Best regards,
Sanjeev
diff --git a/cpu/arm_cortexa8/omap3/board.c
b/cpu/arm_cortexa8/omap3/board.c
index 939ed6c..5dfd8f3 100644
--- a/cpu/arm_cortexa8/omap3/board.c
+++ b/cpu/arm_cortexa8/omap3/board.c
@@ -42,6 +42,8 @@ extern omap3_sysinfo sysinfo;
extern u32 is_mem_sdr(void);
+int s_init_flag=11;
+
/*
*
* Routine: delay
* Description: spinning delay to use before udelay works
@@ -193,6 +195,8 @@ void s_init(void)
{
int in_sdram = is_running_in_sdram();
+ s_init_flag=55;
+
watchdog_init();
try_unlock_memory();
diff --git a/cpu/arm_cortexa8/omap3/lowlevel_init.S
b/cpu/arm_cortexa8/omap3/lowlevel_init.S
index 73063ec..d83dd53 100644
--- a/cpu/arm_cortexa8/omap3/lowlevel_init.S
+++ b/cpu/arm_cortexa8/omap3/lowlevel_init.S
@@ -174,7 +174,11 @@ lowlevel_init:
ldr sp, SRAM_STACK
str ip, [sp]/* stash old link register */
mov ip, lr /* save link reg across call */
+ nop
+ nop
bl s_init /* go setup pll, mux, memory */
+ nop
+ nop
ldr ip, [sp]/* restore save ip */
mov lr, ip /* restore link reg */
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index 2fb6c10..2f29032 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -31,6 +31,8 @@
#include asm/arch/sys_proto.h
#include i2c.h
+extern int s_init_flag;
+
extern omap3_sysinfo sysinfo;
static struct sdrc *sdrc_base = (struct sdrc *)OMAP34XX_SDRC_BASE;
static struct ctrl *ctrl_base = (struct ctrl *)OMAP34XX_CTRL_BASE;
@@ -414,6 +416,8 @@ int print_cpuinfo (void)
cpu_s, sec_s, rev_s[get_cpu_rev()],
(cpu_family == CPU_AM35XX) ? : CPU-OPP2);
+ printf (s_init_flag = %d\n, s_init_flag);
+
return 0;
}
#endif /* CONFIG_DISPLAY_CPUINFO */
==
U-Boot 2009.08-00047-gd5ef5fe-dirty (Nov 30 2009 - 23:15:59)
OMAP3430/3530-GP ES3.1, CPU-OPP2 L3-165MHz
s_init_flag = 11
OMAP3 EVM board + LPDDR/NAND
DRAM: 128 MB
NAND: 256 MiB
In:serial
Out: serial
Err: serial
Die ID #6092000404032d460c01201a
Net: smc911x-0
Hit any key to stop autoboot: 0
OMAP3_EVM #
OMAP3_EVM #
OMAP3_EVM #
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot
Re: [U-Boot] [PATCH v2] Fix build failure in examples/standalone
-Original Message- From: Peter Tyser [mailto:pty...@xes-inc.com] Sent: Monday, November 09, 2009 10:58 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v2] Fix build failure in examples/standalone Hi Sanjeev, snip -ELF := $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU)) +# +# Some versions of make do not handle trailing white spaces properly; +# leading to build failures. The problem was found with GNU Make 3.80. +# Using 'strip' as a workaround for the problem. +# +ElF := $(strip $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU))) + I haven't been following the thread, but am assuming the the capitalization of ElF above is a typo? Sorry, Got back to regular activity much late than expected. Yes. This is a typo; will fix it. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Fix build failure in examples/standalone
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Thursday, December 03, 2009 5:15 PM To: Peter Tyser Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v2] Fix build failure in examples/standalone -Original Message- From: Peter Tyser [mailto:pty...@xes-inc.com] Sent: Monday, November 09, 2009 10:58 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v2] Fix build failure in examples/standalone Hi Sanjeev, snip -ELF := $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU)) +# +# Some versions of make do not handle trailing white spaces properly; +# leading to build failures. The problem was found with GNU Make 3.80. +# Using 'strip' as a workaround for the problem. +# +ElF := $(strip $(ELF-y) $(ELF-$(ARCH)) $(ELF-$(BOARD)) $(ELF-$(CPU))) + I haven't been following the thread, but am assuming the the capitalization of ElF above is a typo? Sorry, Got back to regular activity much late than expected. Yes. This is a typo; will fix it. Just noticed that patch has already been committed with the fix. Thanks Wolfgang. Best regards, Sanjeev Best, Peter ___ 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 0/2] omap3: Optimize detection of cpu revision
-Original Message- From: Tom [mailto:tom@windriver.com] Sent: Tuesday, December 15, 2009 10:44 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 0/2] omap3: Optimize detection of cpu revision Sanjeev Premi wrote: Each call to get_cpu_rev() leads to repetitive execution of code to detect the cpu revision. This patchset ensures that mechanism to detect revision is not executed each time; instead a stored value is returned. Since, revision info is needed in s_init(), the function to identify cpu revision needs to be called twice. At the moment, it is necessary/ unavoidable. Is there some other reason to read this register only once? This function is not used frequently and i do not think the complexity of optimizing is necessary. As more processors and revision specific code gets added, there will be more occurrences for this check. I have just posted patches for basic support for the AM35x processors. Now, the cpurev for this silicon is ES1.0; but have otherwise similar features that the OMAP35x ES3.1 si (I am not accounting other IP differences between the processors here). Also, I don't believe there is any complexity added as the contents of register are being read and saved in a global variable for use later. Best regards, Sanjeev Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Build failures at bb3bcfa2
Hi all, Just pulled latest master at: commit bb3bcfa2426cc6a0aecec7270e3ee67ca843a125 Merge: a200a7c 4b142fe Author: Wolfgang Denk w...@denx.de Date: Tue Dec 15 23:38:34 2009 +0100 Merge branch 'next' of ../next However, I am noticing build failures. See log below: Best regards, Sanjeev premi # make distclean premi # make omap3_evm_config Configuring for omap3_evm board... premi # make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- Generating include/autoconf.mk Generating include/autoconf.mk.dep for dir in tools examples/standalone examples/api ; do make -C $dir _depend ; done make[1]: Entering directory `/home/premi/u-boot/tools' make[1]: Leaving directory `/home/premi/u-boot/tools' make[1]: Entering directory `/home/premi/u-boot/tools' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/premi/u-boot/tools' make[1]: Entering directory `/home/premi/u-boot/examples/standalone' make[1]: Leaving directory `/home/premi/u-boot/examples/standalone' make[1]: Entering directory `/home/premi/u-boot/examples/standalone' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/premi/u-boot/examples/standalone' make[1]: Entering directory `/home/premi/u-boot/examples/api' make[1]: Nothing to be done for `_depend'. make[1]: Leaving directory `/home/premi/u-boot/examples/api' make -C tools all make[1]: Entering directory `/home/premi/u-boot/tools' arm-none-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e8 -I/home/premi/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -o crc32.o crc32.c -c arm-none-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e8 -I/home/premi/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -o env_embedded.o env_embedded.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/premi/u-boot/include -idirafter /home/premi/u-boot/include2 -idirafter /home/premi/u-boot/include -I /home/premi/u-boot/libfdt -I /home/premi/u-boot/tools -DTEXT_BASE=0x80e8 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o envcrc.o envcrc.c -c arm-none-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e8 -I/home/premi/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/codesourcery/2009q1-203/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -o sha1.o sha1.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/premi/u-boot/include -idirafter /home/premi/u-boot/include2 -idirafter /home/premi/u-boot/include -I /home/premi/u-boot/libfdt -I /home/premi/u-boot/tools -DTEXT_BASE=0x80e8 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o envcrc crc32.o env_embedded.o envcrc.o sha1.o /usr/bin/ld: crc32.o: Relocations in generic ELF (EM: 40) crc32.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[1]: *** [envcrc] Error 1 make[1]: Leaving directory `/home/premi/u-boot/tools' make: *** [tools] Error 2 premi # ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build failures at bb3bcfa2
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, December 16, 2009 8:47 PM To: Premi, Sanjeev Cc: Stefan Roese; u-boot@lists.denx.de Subject: Re: [U-Boot] Build failures at bb3bcfa2 Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59301e157b...@dbde02.ent.ti.com you wrote: Yes. I do have them. I looked at the thread; and the problem is same. One question: Theses links were not manually created. They would have been created earlier by some script; and or specific patch. They used to be created by the Makefiles. This was changed by commit fb8b33c1 tools/Makefile: Remove symlinks for remaining source files. If they are not needed; is it possible to remove them by a make distclean/mrproper - I had tried both. When they were created by the Makefiles, they were also removed by the distclean/mrproper targets. It seems you left them hanging around while updating the code - you should always run make mrproper before updating the tree. Even better: always use out-of-tree builds, so your repository does not collect any such crap. I ran distclean/mrproper after git-pull. If it makes sense; I can attempt making a quick patch. I consider this a usage error. No fix is needed. Agreed. Stefan provided good explanation earlier. Best regards, Sanjeev 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 Quantum Mechanics is God's version of Trust me. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Compiling for ARMv7-a
Hi, I am trying to build the u-boot for ARM Cortex-A8 (OMAP3). By default the code is built for ARMv5. So, I made this change in cpu/arm_cortexa8/config.mk: # Make ARMv5 to allow more compilers to work, even though its v7a. -PLATFORM_CPPFLAGS += -march=armv5 +PLATFORM_CPPFLAGS += -march=armv7-a But when I run make, command-line looks like: arm-none-linux-gnueabi-gcc -g -Os -fno-strict-aliasing -fno-common -ffixed-r8 -msoft-float -fno-strict-aliasing -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e8 -I/home/premi/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/codesourcery/lib/gcc/arm-none-linux- gnueabi/4.3.2/include -pipe -DCONFIG_ARM -D__ARM__ -march=armv7-a -mno-thumb-interwork -march=armv5 -mno-thumb-interwork -Wall -Wstrict-prototypes -fno-stack-protector -c -o date.o date.c Notice that -march=armv7-a is followed by -march=armv5. Which option will take precedence? What is required to make sure both are same. My attempt at this change was not successful: omap3_evm_config : unconfig - @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 evm omap3 omap3 + @$(MKCONFIG) $(@:_config=) arm_cortexa8 arm_cortexa8 evm omap3 omap3 Also, many other options are duplicate on the command-line. May be okay, but is there a way to remove this duplication? Best regards, Sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling for ARMv7-a
-Original Message- From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] Sent: Saturday, April 04, 2009 9:41 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Compiling for ARMv7-a On 21:27 Thu 02 Apr , Premi, Sanjeev wrote: Hi, I am trying to build the u-boot for ARM Cortex-A8 (OMAP3). By default the code is built for ARMv5. So, I made this change in cpu/arm_cortexa8/config.mk: # Make ARMv5 to allow more compilers to work, even though its v7a. -PLATFORM_CPPFLAGS += -march=armv5 +PLATFORM_CPPFLAGS += -march=armv7-a you do not need to modify any thing the current tree support omap3 we just not use the armv7-a optimization to be compatible with the maximum of toolchains maybe you could explain us why you need it? [sp] Only as an exercise to see if compiling for ARM v7 provides any better performance - speed and/or power-consumption. Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling for ARMv7-a
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, April 06, 2009 1:29 PM To: Premi, Sanjeev Cc: Jean-Christophe PLAGNIOL-VILLARD; u-boot@lists.denx.de Subject: Re: [U-Boot] Compiling for ARMv7-a Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59301cc6fb...@dbde02.ent.ti.com you wrote: maybe you could explain us why you need it? [sp] Only as an exercise to see if compiling for ARM v7 provides any better performance - speed and/or power-consumption. ...both of which are most probably irrelevant in a boot loader, thatunder normal operating conditions has a total execution time of just a few hundred milliseconds per power-cycle. [sp] No, it was not for measuring u-boot but for a small application that I wanted to compare for power consumption. It is probably easier to play with caches, MMU, etc. in the u-boot than in Linux kernel. Application is merely a calculate-wait-calculate kind of loop. ~sanjeev 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 Just because your doctor has a name for your condition doesn't mean he knows what it is. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Query: console.c
Hi, While browsing common/console.c, I found 2 banners: - U-Boot INITIAL CONSOLE-NOT COMPATIBLE FUNCTIONS - U-Boot INITIAL CONSOLE-COMPATIBLE FUNCTION What does this indicate? One first pass, I also appeared that some functionality is duplicated e.g. serial_puts, puts, serial_printf, printf, et. Is there a specific reason for it? Best regards, Sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Timur Tabi
Sent: Thursday, April 09, 2009 1:55 AM
To: Jerry Van Baren
Cc: U-Boot-Users ML; Kumar Gala
Subject: Re: [U-Boot] use of C99
On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren
gerald.vanba...@ge.com wrote:
ACK. I don't expect to see variables spring into life in
the middle of
nowhere.
I don't see what's wrong with that. The advantage is that the
variable is close to where it's being used, so that you can see the
context more easily.
If I'm not confused, I've seen block-local u-boot variables, has the
advantages of being more distinctive and limits the lifetime of the
variable.
I don't see what the value is of limiting the lifetime of the
variable. The compiler isn't going to use that as a hint, anyway.
It's just going to use this for syntax checking. If you define and
initialize a variable at the top of the function, but don't use that
variable until a hundred lines later, the compiler is going to
initialize the variable when it's first used, not when the function is
first entered. Chances are it's not even going to define stack space
for it.
One of the biggest problem is uncontrolled variable definitions that
gets even nasty when variables have same names with different types;
though under different set of #ifdefs. Quite possible for commonly
used variable names - i, ptr, tmp, etc.
I feel, here, ifdefs provide a false sense of 'enclosure' with possibility
of frequent breaches - in code (while implementing) and in simple reading
(for understanding).
~sanjeev
#ifdef CONFIG_COOL_FEATURE
{
u32 myvarrocks = foo * bar * bar;
gd-neato = myvarrocks
}
#endif
Is this an acceptable compromise?
This is what we do today, and I think it's ugly.
--
Timur Tabi
Linux kernel developer at Freescale
___
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] use of C99
-Original Message- From: Timur Tabi [mailto:ti...@freescale.com] Sent: Thursday, April 09, 2009 2:28 AM To: Premi, Sanjeev Cc: Jerry Van Baren; U-Boot-Users ML; Kumar Gala Subject: Re: [U-Boot] use of C99 Premi, Sanjeev wrote: One of the biggest problem is uncontrolled variable definitions that gets even nasty when variables have same names with different types; though under different set of #ifdefs. Quite possible for commonly used variable names - i, ptr, tmp, etc. Then let's just say that if you're going to define a variable in the middle of a function, it can't have the same name as another variable in that function. I feel, here, ifdefs provide a false sense of 'enclosure' with possibility of frequent breaches - in code (while implementing) and in simple reading (for understanding). Sorry, I don't understand what you're talking about. The #ifdefs are used to enable feature-specific code on platforms that have that feature. I was referring to declaring variable within #ifdefs with belief that use will be contained. e.g. #ifdef CONFIG_COOL_FEATURE int i; int* ptr ; ... ... #endif ... ... 2 screenful down; in same function... ... #ifdef CONFIG_HOT_FEATURE u32 i; void* ptr; ... ... #endif Maybe for sometime the usage seems contained. Until someone decides to have both the COOL and HOT feature. ~sanjeev -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of C99
-Original Message- From: Ben Warren [mailto:biggerbadder...@gmail.com] Sent: Thursday, April 09, 2009 2:33 AM To: Premi, Sanjeev Cc: Timur Tabi; Jerry Van Baren; U-Boot-Users ML; Kumar Gala Subject: Re: [U-Boot] use of C99 Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Timur Tabi Sent: Thursday, April 09, 2009 1:55 AM To: Jerry Van Baren Cc: U-Boot-Users ML; Kumar Gala Subject: Re: [U-Boot] use of C99 On Wed, Apr 8, 2009 at 2:46 PM, Jerry Van Baren gerald.vanba...@ge.com wrote: ACK. I don't expect to see variables spring into life in the middle of nowhere. I don't see what's wrong with that. The advantage is that the variable is close to where it's being used, so that you can see the context more easily. If I'm not confused, I've seen block-local u-boot variables, has the advantages of being more distinctive and limits the lifetime of the variable. I don't see what the value is of limiting the lifetime of the variable. The compiler isn't going to use that as a hint, anyway. It's just going to use this for syntax checking. If you define and initialize a variable at the top of the function, but don't use that variable until a hundred lines later, the compiler is going to initialize the variable when it's first used, not when the function is first entered. Chances are it's not even going to define stack space for it. One of the biggest problem is uncontrolled variable definitions that gets even nasty when variables have same names with different types; though under different set of #ifdefs. Quite possible for commonly used variable names - i, ptr, tmp, etc. I'm showing extreme ignorance here, but does C99 let you do this? for (int i = 0; i x ; i++) ? That's much better contained than declaring in a ifdef. Doing a lot of C++ has rotted my brain, but this is one thing I like. I love C++; still avoid declare as you go. Iterators (as you mention above) are only exception. ~sanjeev regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Tuesday, April 21, 2009 10:26 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Dear Premi,
Sanjeev Premi wrote:
The function display_board_info() displays the silicon
revision as 2 - based on the return value from get_cpu_rev().
This is incorrect as the current Si version is 3.1
Thanks for the patch and fixing this!
This patch displays the correct version; but does not
change get_cpu_rev() to minimize the code impact.
I wonder if it wouldn't be better (and cleaner) to fix get_cpu_rev()?
Yes. This is what I started with; but then this is where I felt that
fix may run 'deeper
u32 get_board_type(void)
{
if (get_cpu_rev() == CPU_3430_ES2)
return sysinfo.board_type_v2;
else
return sysinfo.board_type_v1;
}
I couldn't figure out how this impacts boards other than the EVM.
A quick grep resulted in 5 (?) locations which might be affected:
./cpu/arm_cortexa8/cpu.c:104: if (get_cpu_rev() == CPU_3430_ES2) {
./cpu/arm_cortexa8/cpu.c:134: if (get_cpu_rev() == CPU_3430_ES2) {
./cpu/arm_cortexa8/omap3/clock.c:173: sil_index =
get_cpu_rev() - 1;
./cpu/arm_cortexa8/omap3/sys_info.c:144:if (get_cpu_rev() ==
CPU_3430_ES2)
./cpu/arm_cortexa8/omap3/sys_info.c:237: sec_s,
get_cpu_rev());
If we extend the existing macros
#define CPU_3430_ES1 1
#define CPU_3430_ES2 2
to e.g.
#define CPU_3430_ES10 1
#define CPU_3430_ES20 2
#define CPU_3430_ES21 3
#define CPU_3430_ES30 4
#define CPU_3430_ES31 5
then the three
== CPU_3430_ES2
will simply become
= CPU_3430_ES20
The sil_index = get_cpu_rev() - 1; needs a deeper look, though.
Regarding the ASCII strings: With the numbers get_cpu_rev() returns
we then could index a const struct with the ASCII strings for the
revision print. E.g.
printf( ... %s ..., ... omap_revision[get_cpu_rev()] ...);
What do you think?
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/sys_info.c | 37
+++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..8c6a4d6 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -36,6 +36,8 @@ static gpmc_csx_t *gpmc_cs_base =
(gpmc_csx_t *)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char omap_revision[8] = ;
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -90,6 +92,36 @@ u32 get_cpu_rev(void)
}
+/**
+ * Converts cpu revision into a string
+ */
+void set_omap_revision(void)
+{
+ u32 idcode;
+ ctrl_id_t *id_base;
+ char *str_rev = omap_revision[0];
+
+ if (get_cpu_rev() == CPU_3430_ES1) {
+ strcat (str_rev, ES1.0);
+ }
+ else {
+ id_base = (ctrl_id_t *)OMAP34XX_ID_L4_IO_BASE;
+
+ idcode = readl(id_base-idcode);
+
+ if (idcode == 0x1B7AE02F)
+ strcat (str_rev, ES2.0);
+ else if (idcode == 0x2B7AE02F)
+ strcat (str_rev, ES2.1);
+ else if (idcode == 0x3B7AE02F)
+ strcat (str_rev, ES3.0);
+ else if (idcode == 0x4B7AE02F)
It looks to me that only the highest nibble of idcode changes here?
Maybe we could better mask shift it a little and create a
nice macro
for it?
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
-Original Message-
From: Premi, Sanjeev
Sent: Tuesday, April 21, 2009 11:37 PM
To: 'Dirk Behme'
Cc: u-boot@lists.denx.de
Subject: RE: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Tuesday, April 21, 2009 10:26 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Dear Premi,
Sanjeev Premi wrote:
The function display_board_info() displays the silicon
revision as 2 - based on the return value from get_cpu_rev().
This is incorrect as the current Si version is 3.1
Thanks for the patch and fixing this!
This patch displays the correct version; but does not
change get_cpu_rev() to minimize the code impact.
I wonder if it wouldn't be better (and cleaner) to fix
get_cpu_rev()?
Yes. This is what I started with; but then this is where I felt that
fix may run 'deeper
u32 get_board_type(void)
{
if (get_cpu_rev() == CPU_3430_ES2)
return sysinfo.board_type_v2;
else
return sysinfo.board_type_v1;
}
...sorry, mail 'went' before I wanted to!
I couldn't figure out how this impacts boards other than the EVM.
Though I admit not having much time looking for the impact. Beyond
this, I believe the fix could be straight forward.
A quick grep resulted in 5 (?) locations which might be affected:
./cpu/arm_cortexa8/cpu.c:104: if (get_cpu_rev() ==
CPU_3430_ES2) {
./cpu/arm_cortexa8/cpu.c:134: if (get_cpu_rev() ==
CPU_3430_ES2) {
./cpu/arm_cortexa8/omap3/clock.c:173: sil_index =
get_cpu_rev() - 1;
./cpu/arm_cortexa8/omap3/sys_info.c:144:if
(get_cpu_rev() ==
CPU_3430_ES2)
./cpu/arm_cortexa8/omap3/sys_info.c:237: sec_s,
get_cpu_rev());
If we extend the existing macros
#define CPU_3430_ES11
#define CPU_3430_ES22
to e.g.
#define CPU_3430_ES10 1
#define CPU_3430_ES20 2
#define CPU_3430_ES21 3
#define CPU_3430_ES30 4
#define CPU_3430_ES31 5
then the three
== CPU_3430_ES2
will simply become
= CPU_3430_ES20
There seems to be a slight differene between the silicon
revision between 34x and 35x for the highest nibble value
for early si revs - ES 1.0 and ES2.0.
The sil_index = get_cpu_rev() - 1; needs a deeper look, though.
Regarding the ASCII strings: With the numbers get_cpu_rev()
returns
we then could index a const struct with the ASCII strings for the
revision print. E.g.
printf( ... %s ..., ... omap_revision[get_cpu_rev()] ...);
What do you think?
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/sys_info.c | 37
+++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..8c6a4d6 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -36,6 +36,8 @@ static gpmc_csx_t *gpmc_cs_base =
(gpmc_csx_t *)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char omap_revision[8] = ;
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -90,6 +92,36 @@ u32 get_cpu_rev(void)
}
+/**
+ * Converts cpu revision into a string
+ */
+void set_omap_revision(void)
+{
+ u32 idcode;
+ ctrl_id_t *id_base;
+ char *str_rev = omap_revision[0];
+
+ if (get_cpu_rev() == CPU_3430_ES1) {
+ strcat (str_rev, ES1.0);
+ }
+ else {
+ id_base = (ctrl_id_t *)OMAP34XX_ID_L4_IO_BASE;
+
+ idcode = readl(id_base-idcode);
+
+ if (idcode == 0x1B7AE02F)
+ strcat (str_rev, ES2.0);
+ else if (idcode == 0x2B7AE02F)
+ strcat (str_rev, ES2.1);
+ else if (idcode == 0x3B7AE02F)
+ strcat (str_rev, ES3.0);
+ else if (idcode == 0x4B7AE02F)
It looks to me that only the highest nibble of idcode changes here?
Maybe we could better mask shift it a little and create a
nice macro
for it?
It is already done in the kernel; but I am not sure if we could save
much - unless we use the index as you suggest above.
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Wednesday, April 22, 2009 1:04 AM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Dear Premi,
Premi, Sanjeev wrote:
-Original Message-
From: Premi, Sanjeev
Sent: Tuesday, April 21, 2009 11:37 PM
To: 'Dirk Behme'
Cc: u-boot@lists.denx.de
Subject: RE: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Tuesday, April 21, 2009 10:26 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3: Print correct
silicon revision
Dear Premi,
Sanjeev Premi wrote:
The function display_board_info() displays the silicon
revision as 2 - based on the return value from get_cpu_rev().
This is incorrect as the current Si version is 3.1
Thanks for the patch and fixing this!
This patch displays the correct version; but does not
change get_cpu_rev() to minimize the code impact.
I wonder if it wouldn't be better (and cleaner) to fix
get_cpu_rev()?
Yes. This is what I started with; but then this is where I
felt that
fix may run 'deeper
u32 get_board_type(void)
{
if (get_cpu_rev() == CPU_3430_ES2)
return sysinfo.board_type_v2;
else
return sysinfo.board_type_v1;
}
...sorry, mail 'went' before I wanted to!
I couldn't figure out how this impacts boards other than the EVM.
Though I admit not having much time looking for the impact. Beyond
this, I believe the fix could be straight forward.
What's about something like in the attachment? Compile tested
only. Do
you like to test it?
Sure. Will do it in the morning...
I did make few changes since your last mail as well.
Will post the updates later in the day.
~sanjeev
Best regards
Dirk
A quick grep resulted in 5 (?) locations which might be affected:
./cpu/arm_cortexa8/cpu.c:104: if (get_cpu_rev() ==
CPU_3430_ES2) {
./cpu/arm_cortexa8/cpu.c:134: if (get_cpu_rev() ==
CPU_3430_ES2) {
./cpu/arm_cortexa8/omap3/clock.c:173: sil_index =
get_cpu_rev() - 1;
./cpu/arm_cortexa8/omap3/sys_info.c:144:if
(get_cpu_rev() ==
CPU_3430_ES2)
./cpu/arm_cortexa8/omap3/sys_info.c:237: sec_s,
get_cpu_rev());
If we extend the existing macros
#define CPU_3430_ES1 1
#define CPU_3430_ES2 2
to e.g.
#define CPU_3430_ES10 1
#define CPU_3430_ES20 2
#define CPU_3430_ES21 3
#define CPU_3430_ES30 4
#define CPU_3430_ES31 5
then the three
== CPU_3430_ES2
will simply become
= CPU_3430_ES20
There seems to be a slight differene between the silicon
revision between 34x and 35x for the highest nibble value
for early si revs - ES 1.0 and ES2.0.
The sil_index = get_cpu_rev() - 1; needs a deeper look, though.
Regarding the ASCII strings: With the numbers get_cpu_rev()
returns
we then could index a const struct with the ASCII strings for the
revision print. E.g.
printf( ... %s ..., ... omap_revision[get_cpu_rev()] ...);
What do you think?
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/sys_info.c | 37
+++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..8c6a4d6 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -36,6 +36,8 @@ static gpmc_csx_t *gpmc_cs_base =
(gpmc_csx_t *)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char omap_revision[8] = ;
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -90,6 +92,36 @@ u32 get_cpu_rev(void)
}
+/**
+ * Converts cpu revision into a string
+ */
+void set_omap_revision(void)
+{
+u32 idcode;
+ctrl_id_t *id_base;
+char *str_rev = omap_revision[0];
+
+if (get_cpu_rev() == CPU_3430_ES1) {
+strcat (str_rev, ES1.0);
+}
+else {
+id_base = (ctrl_id_t *)OMAP34XX_ID_L4_IO_BASE;
+
+idcode = readl(id_base-idcode);
+
+if (idcode == 0x1B7AE02F)
+strcat (str_rev, ES2.0);
+else if (idcode == 0x2B7AE02F)
+strcat (str_rev, ES2.1);
+else if (idcode == 0x3B7AE02F)
+strcat (str_rev, ES3.0);
+else
Re: [U-Boot] OMAP3: Pending patches
-Original Message- From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Saturday, April 25, 2009 11:05 AM To: U-Boot user list; Jean-Christophe PLAGNIOL-VILLARD; Premi, Sanjeev; Tom Rix Cc: Wolfgang Denk Subject: Re: OMAP3: Pending patches Short status update after scanning the recent mails: Dirk Behme wrote: To avoid loosing the overview, here my list of pending OMAP3 patches ready to be applied. From my point of view there are no open comments on these which will prevent to apply them. But please correct if I overlooked anything or add what (patches? comments?) I missed. 1. OMAP3: Beagle: Set pinmux conditionally for Rev C boards http://lists.denx.de/pipermail/u-boot/2009-April/051013.html 2. OMAP3: Remove legacy NAND defines http://lists.denx.de/pipermail/u-boot/2009-April/050882.html 3. OMAP3: Fix timer handling to 1ms and CONFIG_SYS_HZ to 1000 http://lists.denx.de/pipermail/u-boot/2009-April/051178.html 4. OMAP3: Fix changed mmc init command http://lists.denx.de/pipermail/u-boot/2009-April/051179.html 5. OMAP3: Remove unused board-types http://lists.denx.de/pipermail/u-boot/2009-April/051338.html We will try to switch to print_cpuinfo checkboard http://lists.denx.de/pipermail/u-boot/2009-April/051365.html Premi: Do you like to have a look? Hopefully it wouldn't be too hard. [SP] Sure, I will... Jean-Christophe: Please fix the test-only and add the documentation as requested by Wolfgang as soon as possible, that we can safely use it. http://lists.denx.de/pipermail/u-boot/2009-April/051382.html 6. OMAP3: Print correct silicon revision http://lists.denx.de/pipermail/u-boot/2009-April/051339.html 7. Zoom2 respin II (10 patches) http://lists.denx.de/pipermail/u-boot/2009-April/050863.html http://lists.denx.de/pipermail/u-boot/2009-April/050864.html http://lists.denx.de/pipermail/u-boot/2009-April/050865.html http://lists.denx.de/pipermail/u-boot/2009-April/050866.html http://lists.denx.de/pipermail/u-boot/2009-April/050868.html http://lists.denx.de/pipermail/u-boot/2009-April/050867.html http://lists.denx.de/pipermail/u-boot/2009-April/050869.html http://lists.denx.de/pipermail/u-boot/2009-April/050870.html http://lists.denx.de/pipermail/u-boot/2009-April/050871.html http://lists.denx.de/pipermail/u-boot/2009-April/050872.html After http://lists.denx.de/pipermail/u-boot/2009-April/051383.html http://lists.denx.de/pipermail/u-boot/2009-April/051384.html http://lists.denx.de/pipermail/u-boot/2009-April/051385.html http://lists.denx.de/pipermail/u-boot/2009-April/051386.html Tom has to check if an update of this series is necessary. Note: There might be some dependencies between some of these patches. Different authors, sent at different time, unfortunately this can't be avoided. So dependent on the order the patches will be applied, there might be some conflicts. Let us know them, we will try to update/fix then as soon as possible! Most probably 5. and 7. will have some conflicts, as 5. removes some code 7. assumes it is still there. If this results in a conflict, let us apply the 10 patches from 7. first and then update 5. Jean-Christophe: If series 7. needs an update, it would be really helpful if you could apply the other patches so that updated 7. can be rebased against them. This will reduce the risk of conflicts. Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates
-Original Message- From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Monday, April 27, 2009 8:47 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates Hi Premi, Sanjeev Premi wrote: This series contains 3 specific updates: - Use common API to print cpu and board related information. - Remove unused board type definitions. - Print correct silicon revision in the board information These updates have been tested on OMAP3EVM with ES 3.0 and ES3.1 silicon versions. Thanks to Dirk Behme [dirk.be...@googlemail.com] for converting a quick hack into complete solution. Sanjeev Premi (3): OMAP3: Use functions print_cpuinfo() and checkboard() OMAP3: Remove unused board-types OMAP3: Print correct silicon revision Applying all 3 patches I get sys_info.c: In function 'print_cpuinfo': sys_info.c:297: warning: no return statement in function returning non-void board.c: In function 'checkboard': board.c:349: warning: implicit declaration of function 'is_mem_sdr' board.c:357: warning: no return statement in function returning non-void I usually do a distclean followed by make; but let me do this again. ~sanjeev Not sure which patch it is, though. Best regards Dirk Btw.: You can easily check this by doing a ./MAKEALL ARM_CORTEX_A8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Monday, April 27, 2009 8:49 PM To: Dirk Behme Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates -Original Message- From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Monday, April 27, 2009 8:47 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCHv3 0/3] OMAP3: Board specific updates Hi Premi, Sanjeev Premi wrote: This series contains 3 specific updates: - Use common API to print cpu and board related information. - Remove unused board type definitions. - Print correct silicon revision in the board information These updates have been tested on OMAP3EVM with ES 3.0 and ES3.1 silicon versions. Thanks to Dirk Behme [dirk.be...@googlemail.com] for converting a quick hack into complete solution. Sanjeev Premi (3): OMAP3: Use functions print_cpuinfo() and checkboard() OMAP3: Remove unused board-types OMAP3: Print correct silicon revision Applying all 3 patches I get sys_info.c: In function 'print_cpuinfo': sys_info.c:297: warning: no return statement in function returning non-void board.c: In function 'checkboard': board.c:349: warning: implicit declaration of function 'is_mem_sdr' board.c:357: warning: no return statement in function returning non-void I usually do a distclean followed by make; but let me do this again. Yeah. found it... a miss in interactive commit 3/3. Should I re-submit the whole series? OR Is it okay to re-send just the last one. ~sanjeev ~sanjeev Not sure which patch it is, though. Best regards Dirk Btw.: You can easily check this by doing a ./MAKEALL ARM_CORTEX_A8 ___ 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] OMAP3EVM: Set default bootfile
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Tuesday, May 05, 2009 3:51 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Pillai, Manikandan Subject: Re: [U-Boot] [PATCH] OMAP3EVM: Set default bootfile Dear Sanjeev Premi, In message 1241515371-24359-1-git-send-email-pr...@ti.com you wrote: The current configuration doesn't define default bootfile; leading to this warning at execution: Note that this is not a problem, but a decision of the board maintainer. Also, you can always just use setenv + saveenv if you want this changed on your board. OMAP3_EVM # dhcp ... ... DHCP client bound to address 192.168.1.11 *** Warning: no boot file name; using 'AC18BE16.img' TFTP from server 0.0.0.0; our IP address is 192.168.1.11; sending through gateway 192.168.1.1 Filename 'AC18BE16.img'. Load address: 0x8200 Loading: * TFTP error: 'File not found' (1) This is standard behaviour and not a problem. Signed-off-by: Sanjeev Premi pr...@ti.com --- include/configs/omap3_evm.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h index 549cef9..e205c01 100644 --- a/include/configs/omap3_evm.h +++ b/include/configs/omap3_evm.h @@ -149,6 +149,8 @@ /* Environment information */ #define CONFIG_BOOTDELAY 10 +#define CONFIG_BOOTFILEuImage + You should probably add the board maintainer on Cc: (done here) to get his ACK. In this case, the board maintainer works with me. He will ACK it. 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 thing is, as you progress in the Craft, you'll learn there is another rule... When you break rules, break 'em good and hard. - Terry Pratchett, _Wyrd Sisters_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM: Updating mach-types.h
Hi, I have added OMAP3517EVM at: http://www.arm.linux.org.uk/developer/machines/ What is the preferred way to bring this definition into u-boot (include/asm-arm/mach-types.h)? Best regards, Sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: Updating mach-types.h
-Original Message- From: Dirk Behme [mailto:dirk.be...@googlemail.com] Sent: Thursday, May 07, 2009 10:02 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Jean-Christophe PLAGNIOL-VILLARD Subject: Re: [U-Boot] ARM: Updating mach-types.h Premi, Sanjeev wrote: Hi, I have added OMAP3517EVM at: http://www.arm.linux.org.uk/developer/machines/ What is the preferred way to bring this definition into u-boot (include/asm-arm/mach-types.h)? Bad timing, mach-types.h was updated recently in U-Boot :( http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=0b3cc4d 75f85b1114fe06522d5394391ddc54823 The official way is http://lists.denx.de/pipermail/u-boot/2008-September/040553.html If your new mach type isn't available yet, looks like you have to ask Jean-Christophe if he kindly likes to update again. Jean-Christophe: Is it too early to send another sync request? ~sanjeev Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Kyungmin Park Sent: Tuesday, September 14, 2010 7:48 PM To: Stefan Roese Cc: u-boot@lists.denx.de; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On Tue, Sep 14, 2010 at 10:51 PM, Stefan Roese s...@denx.de wrote: Hi Aneesh, On Tuesday 14 September 2010 15:33:53 V, Aneesh wrote: I wanted to know if there is a generic way to create two binaries from the u-boot source both compiled for different address ranges. The first initializes the RAM (may be something else as well) and the second is the u-boot binary responsible for loading OS etc. It's sheer coincidence that I also wanted to post a very similar query today. We have a similar requirement for OMAP platforms. Presently, we are maintaining a mini bootloader(called x-loader, based on u-boot)separately. We want to integrate x-loader with u-boot and up-stream the source code. That's definitely a good idea. Take a look at the NAND_SPL infrastructure (nand_spl/*). It was created for platforms booting from NAND with tight restrictions (e.g. 4k image size for inital setup, mostly DDR). General idea here is that 2 images are created: a) Very small SPL (secondary program loader) image with only basic setup, like DDR and NAND b) RAM based U-Boot image Both images are combined in the build process creating a single image that can be flashed into NAND. doc/README.nand-boot-ppc440 might be interesting to get some more infos about this, some of it PPC4xx specific though. This looks promising. However, our SPL has to load u-boot from MMC. Is it OK to keep it under nand_spl directory or should we create something like 'mmc_spl'? Good question, It created the mmc_ipl and use it for mmc booting e.g., eMMC boot. Not sure. Perhaps we should now really think about a more generic approach and merge all this IPL/SPL stuff into a single directory. Perhaps something like this: spl/ spl/nand spl/onenand spl/mmc spl/board Good, and use the CONFIG_PRELOADER as existing. but what's the SPL stand for? SPL (secondary program loader)? [sp] I was pointed to this thread through another discussion. I did see (almost) an agreement reached here. But, wanted to share my experience on the same topic. Posed with same problem, I had looked at minimizing the u-boot binary and had managed to reach 29-30KB In short, shouldn't we make u-boot more configurable so that parts we consider integral in u-boot today can also be excluded e.g. support for unzip, tftp, ... Best regards, Sanjeev Thank you, Kyungmin Park ... Comments welcome. Cheers, Stefan -- 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
-Original Message- From: Scott Wood [mailto:scottw...@freescale.com] Sent: Thursday, September 16, 2010 11:30 PM To: Premi, Sanjeev Cc: Kyungmin Park; Stefan Roese; u-boot@lists.denx.de; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On Thu, 16 Sep 2010 21:14:57 +0530 Premi, Sanjeev pr...@ti.com wrote: [sp] I was pointed to this thread through another discussion. I did see (almost) an agreement reached here. But, wanted to share my experience on the same topic. Posed with same problem, I had looked at minimizing the u-boot binary and had managed to reach 29-30KB NAND SPL typically needs to fit in just 4 KiB (sometimes even less). In short, shouldn't we make u-boot more configurable so that parts we consider integral in u-boot today can also be excluded e.g. support for unzip, tftp, ... Those things are configurable. That doesn't mean we don't need makefile infrastructure to build the two (or sometimes three) separate images, or some special code for an extremely minimal image. [sp] Yes. When we need to be extremely small separate infra may be needed. But for rest, I feel we could/ should continue using the generic makefile infra - with more configuration options - that keeps maintenance low. I also feel that needs/requirements for the extremely small images will differ between the users. Maintaining compatibility will be a challenge for a common codebase. ~sanjeev -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Multiple binaries built through u-boot source
-Original Message- From: Mike Frysinger [mailto:vap...@gentoo.org] Sent: Friday, September 17, 2010 12:02 AM To: u-boot@lists.denx.de Cc: Premi, Sanjeev; Kyungmin Park; Stefan Roese; Shiraz HASHIM Subject: Re: [U-Boot] Multiple binaries built through u-boot source On Thursday, September 16, 2010 11:44:57 Premi, Sanjeev wrote: But, wanted to share my experience on the same topic. Posed with same problem, I had looked at minimizing the u-boot binary and had managed to reach 29-30KB the Blackfin one is in the range of 200-600 bytes. i dont care how configurable you make u-boot, it isnt getting to that. In short, shouldn't we make u-boot more configurable so that parts we consider integral in u-boot today can also be excluded e.g. support for unzip, tftp, ... yes, we should do this anyways. i have another use of u-boot where i wanted it down to the 30KiB range, and that required posting patches to make things more configurable. most have been merged already. [sp] I will rebase my work on latest and submit patches. ~sanjeev -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Move function to identify board revision
-Original Message- From: Premi, Sanjeev Sent: Tuesday, October 19, 2010 6:37 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] omap3evm: Move function to identify board revision Function omap3_evm_get_revision() - to identify the board revision was called at end of setup_net_chip(). Board revision can be ascertained only by identifying the Ethernet chipset - but combining setup operations with revision detection isn;t a good idea. Moved the function and added detailed comment to set the context. Signed-off-by: Sanjeev Premi pr...@ti.com --- board/ti/evm/evm.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c index 73330db..6163b12 100644 --- a/board/ti/evm/evm.c +++ b/board/ti/evm/evm.c @@ -109,6 +109,12 @@ int misc_init_r(void) #if defined(CONFIG_CMD_NET) setup_net_chip(); + + /* + * Board revision can be ascertained only by identifying + * the Ethernet chipset. + */ + omap3_evm_get_revision(); #endif [sp] While reviewing the code, I realized a latent bug that can hit us when CONFIG_CMD_NET is not defined. omap3_evm_get_revision() never gets called - value of omap3_evm_version is never set. So, value returned by get_omap3_evm_rev() depends upon compiler used. Please disregard this patch. I will submit a cleaned-up patch with takes care of this latent bug as well. ~sanjeev dieid_num_r(); @@ -163,9 +169,6 @@ static void setup_net_chip(void) writel(GPIO0, gpio3_base-cleardataout); udelay(1); writel(GPIO0, gpio3_base-setdataout); - - /* determine omap3evm revision */ - omap3_evm_get_revision(); } int board_eth_init(bd_t *bis) -- 1.7.2.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot
-Original Message- From: Loïc Minier [mailto:l...@dooz.org] Sent: Tuesday, October 19, 2010 10:14 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot On Tue, Oct 19, 2010, Sanjeev Premi wrote: +#undef CONFIG_FAST_BOOT I wonder whether CONFIG_FAST_BOOT would cause confusion if u-boot gains support for Android fastboot someday? http://en.wikipedia.org/wiki/Fastboot http://android-dls.com/wiki/index.php?title=Fastboot [sp] The intent here is to boot faster - hence the name. Wasn't aware of any Android overlap. How about any of these: - CONFIG_SMALL_SIZE - CONFIG_FASTER_BOOT :) ^^ Any other suggestions? ~sanjeev -- Loïc Minier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, October 23, 2010 2:20 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards Commit c3d3a54 uses CONFIG_ARMV7 to determine whether to call the v7_flush_cache_all function. This breaks the build for all non-OMAP3 boards (like Panda and OMAP4430SDP) since there is only a v7_flush_cache_all implementation for OMAP3. This patch uses CONFIG_OMAP3XXX instead of CONFIG_ARMV7 so that only boards with a v7_flush_cache_all will make the call. [sp] Is this call board specific? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
-Original Message- From: Steve Sakoman [mailto:st...@sakoman.com] Sent: Monday, October 25, 2010 6:52 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards On Mon, 2010-10-25 at 15:28 +0530, Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, October 23, 2010 2:20 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards Commit c3d3a54 uses CONFIG_ARMV7 to determine whether to call the v7_flush_cache_all function. This breaks the build for all non-OMAP3 boards (like Panda and OMAP4430SDP) since there is only a v7_flush_cache_all implementation for OMAP3. This patch uses CONFIG_OMAP3XXX instead of CONFIG_ARMV7 so that only boards with a v7_flush_cache_all will make the call. [sp] Is this call board specific? No, it is not. [sp] I asked because I can see omap3/cache.S but not under omap-common/ (as I was expecting) - neither in omap4/ Doesn't this patch works-around the problem by using CONFIG_OMAP34XX? Wouldn't change in cache.S (or Makefile) be better solution/ or workaround. At least workaround will be visible to more eyes. ~sanjeev Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Tuesday, October 19, 2010 10:25 PM To: Loïc Minier Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot -Original Message- From: Loïc Minier [mailto:l...@dooz.org] Sent: Tuesday, October 19, 2010 10:14 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot On Tue, Oct 19, 2010, Sanjeev Premi wrote: +#undef CONFIG_FAST_BOOT I wonder whether CONFIG_FAST_BOOT would cause confusion if u-boot gains support for Android fastboot someday? http://en.wikipedia.org/wiki/Fastboot http://android-dls.com/wiki/index.php?title=Fastboot [sp] The intent here is to boot faster - hence the name. Wasn't aware of any Android overlap. How about any of these: - CONFIG_SMALL_SIZE - CONFIG_FASTER_BOOT :) ^^ Any other suggestions? [sp] Didn't hear any other suggestions. But I had one more, CONFIG_QUICK_BOOT. Loic, does this seem okay? ~sanjeev ~sanjeev -- Loïc Minier ___ 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] ARMV7: Fix build for non-OMAP3 boards
-Original Message- From: Steve Sakoman [mailto:st...@sakoman.com] Sent: Monday, October 25, 2010 8:38 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards On Mon, 2010-10-25 at 20:10 +0530, Premi, Sanjeev wrote: -Original Message- From: Steve Sakoman [mailto:st...@sakoman.com] Sent: Monday, October 25, 2010 6:52 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards On Mon, 2010-10-25 at 15:28 +0530, Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, October 23, 2010 2:20 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards Commit c3d3a54 uses CONFIG_ARMV7 to determine whether to call the v7_flush_cache_all function. This breaks the build for all non-OMAP3 boards (like Panda and OMAP4430SDP) since there is only a v7_flush_cache_all implementation for OMAP3. This patch uses CONFIG_OMAP3XXX instead of CONFIG_ARMV7 so that only boards with a v7_flush_cache_all will make the call. [sp] Is this call board specific? No, it is not. [sp] I asked because I can see omap3/cache.S but not under omap-common/ (as I was expecting) - neither in omap4/ Doesn't this patch works-around the problem by using CONFIG_OMAP34XX? Yes, this is a hopefully temporary fix to allow non-OMAP3 ARMV7 boards to build. Wouldn't change in cache.S (or Makefile) be better solution/ or workaround. At least workaround will be visible to more eyes. Ideally we would have a generic ARMV7 implementation that would work for even non-OMAP ARMV7 processors. Someone who is familiar with the differences in ARMV7 cache implementations from the various silicon vendors would need to do this. This beyond my knowledge. A second best solution would be to have a cache.S that worked for both OMAP3 and OMAP4 in omap-common/ If this isn't possible, then we should add an OMAP4 specific cache.S in omap4/ But until we settle on the proper long term strategy this patch should be applied so that non-OMAP3 ARMV7 boards will build. Can we indicate either in the title/ description that patch is temporary? Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, October 27, 2010 7:19 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot [snip]...[snip] +#undef CONFIG_QUICK_BOOT +#undef CONFIG_QUICK_BOOT_MMC +#undef CONFIG_QUICK_BOOT_NAND If you use this here to show the options, then please move it into the comment above. [sp] Will do. Otherwise, it is just dead code as you undefine things that are not defiend anyway. In any case, please remove the #undef's. +#ifdef CONFIG_QUICK_BOOT + /* +* Generic config options +*/ + #ifndef CONFIG_SILENT_CONSOLE + #define CONFIG_SILENT_CONSOLE 1 + #endif + + #ifndef CONFIG_ENV_IS_NOWHERE + #define CONFIG_ENV_IS_NOWHERE 1 + #endif Style issue: Please always start preprocessor commands in column 1. [sp] I was following style from another file which uses nesting. Maybe, my choice of reference was incorect. Will make the change. [snip]...[snip] + #undef CONFIG_CMD_USB I do not like this approach at all. It will make the board config file basicly unreadable - it becomes a mess of defiunitions here and (even conditional) #undef's and re-definitions there. I suggest you chose a different approach, for example move the common (always used) configuration settings into a separate header file, and then provide two separate board configurations (normal and quick boot) which include the common settings. [sp] I did think about it, infact, I was initially planning to follow the config_cmd_default.h; because, same set of changes can apply across multiple boards. I did test the patch against Beagle board as well. This has the additional benefit that you can actually build both configurations without the need to modify any source files. [sp] Was only concerned about possibility of multiple configurations per platform. Keeping them in sync could be pain. Do you have suggestions on this? 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 Lack of skill dictates economy of style.- Joey Ramone ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, October 27, 2010 8:32 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v2] omap3evm: Support for quick boot Dear Premi, Sanjeev, In message b85a65d85d7eb246be421b3fb0fbb59302346c6...@dbde02.ent.ti.com you wrote: This has the additional benefit that you can actually build both configurations without the need to modify any source files. [sp] Was only concerned about possibility of multiple configurations per platform. Keeping them in sync could be pain. Do you have suggestions on this? Well, if the common parts are indeed in some common header file, then the remaining content should all be specific for the selected configuration, so what needs to be kept in sync? I think I have been able to do what you have suggested above. But got a small set of config options that could be duplicated. I am following this mail with an RFC series with specific code changes. Have tried to be explicit in my comments. There is one TBD in 2/3 that indicates possible duplication. Your comments would be really useful. Best regards, Sanjeev 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 paid too much for it, but its worth it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 0/3] omap3evm: Add support for quick boot
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, October 28, 2010 10:24 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [RFC 0/3] omap3evm: Add support for quick boot Dear Sanjeev Premi, In message 1288283919-3837-1-git-send-email-pr...@ti.com you wrote: This series is based on the comments received [1] on my earlier submission[2]. Intent of sending as RFC is to thrash out the ideas and then send a formal patch. Sorry, as you submitted this I see only 3 completely new files without relation to each other nor with any relation to the existing code. I suggest the following approach: Patch 1: move common code out of include/configs/omap3_evm.h into a new file include/configs/omap3_evm_common.h; this patch should result in exactly the same code for the board as we have now. Do not rename omap3_evm.h into omap3_evm_full.h; this makes no sense to me. omap3_evm.h is and remains the default configuration. [sp] Since I was also moving the related config options next to each other - as against current spread. I couldn't make much sens of patch. Thought it could be confusing to others as well. Appears, I was wrong! Patch 2: Create a new file omap3_evm_quick.h, which contains the speed optimized configuration settings. Get rid of all the #ifndef FOO #define FOO #endif stuff there. This is a plain simple and fixed configuration, so this is not needed. [sp] Sorry, I didn't clean this up considering the focus would be on the first 2 patches. You may even consider to splitting this more - into omap3_evm_quick_nand.h and omap3_evm_quick_mmc.h to eliminate even more of the #ifdeffery. [sp] That's a good idea. Will have it implemented tomorrow morning. best regards, Sanjeev Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A modem is a baudy house. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFCv2 0/3] Add support for quick boot
-Original Message- From: Premi, Sanjeev Sent: Friday, October 29, 2010 9:35 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [RFCv2 0/3] Add support for quick boot This series attempts to address specific feedback[1] from Wolfgang Denk to my previous submission. Since this series is based on u-boot master, it is missing these patches for successful build: a) omap3evm: Support relocation http://marc.info/?l=u-bootm=128748423503307w=2 b) omap3evm: Move function to identify board revision http://marc.info/?l=u-bootm=128749414618147w=2 c) omap3evm: Fix mechanism to identify board revision http://marc.info/?l=u-bootm=128757192518074w=2 I am hoping this series illustrates exact changes done. However, my choice of filenames results in rather long config names for two new configurations. I plan to replace quick with simple q. Does it sound ok? References: [1] http://marc.info/?l=u-bootm=128828487429161w=2 [2] http://marc.info/?l=u-bootm=128818733126234w=2 [3] http://marc.info/?l=u-bootm=128818664024766w=2 Patch (a) is required for successful build for current configuration. Patches (b) and (c) were required for successful build of quick configurations. I am yet to test these on this patchset. Will do before final submission. Sanjeev Premi (3): omap3evm: Reorder related config options omap3evm: move common config options to new file omap3evm: Add quick boot configurations Hi Wolfgang, Did you get chance to look at this series? ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Fix mechanism to identify board revision
-Original Message- From: Premi, Sanjeev Sent: Wednesday, October 20, 2010 4:21 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] omap3evm: Fix mechanism to identify board revision [snip] Sandeep, Pinging for status... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Support relocation
-Original Message- From: Premi, Sanjeev Sent: Tuesday, October 19, 2010 4:00 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] omap3evm: Support relocation This patch adds relocation support for omap3evm. Content of the patch is based on changes for Beagleboard. Signed-off-by: Sanjeev Premi pr...@ti.com --- Sandeep, Pinging for status... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Wrap function under CONFIG_USB_OMAP3
-Original Message- From: Premi, Sanjeev Sent: Tuesday, October 19, 2010 6:36 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] omap3evm: Wrap function under CONFIG_USB_OMAP3 The function omap3_evm_need_extvbus() is required only when USB support is configured. Wrapped this function in #ifdef CONFIG_USB_OMAP3. Signed-off-by: Sanjeev Premi pr...@ti.com --- Sandeep, Pinging for status... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] omap3evm: Add support for EFI partitions
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Tuesday, November 15, 2011 12:15 PM To: Tom Rini Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 0/2] omap3evm: Add support for EFI partitions -Original Message- From: Tom Rini [mailto:tom.r...@gmail.com] Sent: Monday, November 14, 2011 9:05 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 0/2] omap3evm: Add support for EFI partitions On Mon, Nov 14, 2011 at 8:19 AM, Sanjeev Premi pr...@ti.com wrote: After enabling CONFIG_EFI_PARTITION, following errors were noticed. part_efi.c: In function 'print_part_efi': part_efi.c:133:5: warning: passing argument 3 of 'is_gpt_valid' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'get_partition_info_efi': part_efi.c:173:4: warning: passing argument 3 of 'is_gpt_valid ' from incompatible pointer type part_efi.c:95:12: note: expected 'struct gpt_header *' but arg ument is of type 'struct gpt_header **' part_efi.c: In function 'alloc_read_gpt_entries': part_efi.c:384:18: error: 'CONFIG_SYS_CACHELINE_SIZE' undeclar ed (first use in this function) part_efi.c:384:18: note: each undeclared identifier is reporte d only once for each function it appears in make[1]: *** [part_efi.o] Error 1 make[1]: Leaving directory `/db/psp_git/users/a0756819/u-boot/ disk' make: *** [disk/libdisk.o] Error 2 Is there a reason EFI doesn't use ARCH_DMA_MINALIGN ? I have no idea, but use of CONFIG_SYS_CACHELINE_SIZE in part_efi.c was introduced in: commit f75dd584cdfe29dfdcfd424bb237b9238cfb8fe4 Author: Anton staaf robot...@chromium.org Date: Wed Oct 12 13:56:04 2011 + ~sanjeev After a bit more digging, I see that ARCH_DMA_MINALIGN is set to 64 OR CONFIG_SYS_CACHELINE_SIZE (if defined) - in this commit: commit 3b75eeef620c018c312e8149246cd330cc27d16d Author: Anton Staaf robot...@chromium.org Date: Mon Oct 17 16:46:03 2011 -0700 arm: cache: define ARCH_DMA_MINALIGN for DMA buffer alignment So, CONFIG_SYS_CACHELINE_SIZE shouldn't really be used in the file. I will submit fresh set soon. ~sanjeev -- Tom ___ 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] disk: part_efi: Fix parameters passed to is_gpt_valid().
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Thierry Reding
Sent: Thursday, November 17, 2011 12:35 PM
To: u-boot@lists.denx.de
Cc: Tom Warren
Subject: [U-Boot] [PATCH] disk: part_efi: Fix parameters
passed to is_gpt_valid().
Something apparently went wrong when the patch in commit deb5ca8 was
applied. Commit f75dd58 changed the type of gpt_head to be a
pointer and
correctly adjusted the calls to is_gpt_valid(). But when deb5ca8 got
applied, the gpt_head was again reverted to (gpt_head), which was the
state before deb5ca8.
This commit fixes the passing of gpt_head into is_gpt_valid().
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
disk/part_efi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index e7f2714..ddf80a7 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -130,7 +130,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
}
/* This function validates AND fills in the GPT header
and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
- (gpt_head), gpt_pte) != 1) {
+ gpt_head, gpt_pte) != 1) {
printf(%s: *** ERROR: Invalid GPT ***\n, __func__);
return;
}
@@ -169,7 +169,7 @@ int
get_partition_info_efi(block_dev_desc_t * dev_desc, int part,
/* This function validates AND fills in the GPT header
and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
- (gpt_head), gpt_pte) != 1) {
+ gpt_head, gpt_pte) != 1) {
printf(%s: *** ERROR: Invalid GPT ***\n, __func__);
return -1;
}
--
I had already posted 2 revisions of this patch:
http://lists.denx.de/pipermail/u-boot/2011-November/109791.html
http://lists.denx.de/pipermail/u-boot/2011-November/109899.html
And they are included in this pull request:
http://lists.denx.de/pipermail/u-boot/2011-November/110017.html
1.7.7.3
___
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] Coding Style cleanup
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Monday, December 19, 2011 4:41 PM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH] Coding Style cleanup Fix trailing white space, indentation by spaces instead of TABs, excessive blank lines, trailing blank lines. Signed-off-by: Wolfgang Denk w...@denx.de [snip]...[snip] @@ -563,6 +556,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); tftp $fdtaddr $tftppath/$fdtfile; \ bootm $loadaddr - $fdtaddr + #define CONFIG_RAMBOOTCOMMAND This appears to be a stray addition. ~sanjeev [snip]...[snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Coding Style cleanup
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Monday, December 19, 2011 9:07 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] Coding Style cleanup Dear Premi, Sanjeev, In message e28aafd00efaa646ae3df9b89cd24a8909b...@dbde01.ent.ti.com you wrote: @@ -563,6 +556,7 @@ extern unsigned long=20 get_board_sys_clk(unsigned long dummy); tftp $fdtaddr $tftppath/$fdtfile; =09 \ bootm $loadaddr - $fdtaddr =20 + #define CONFIG_RAMBOOTCOMMAND=09 This appears to be a stray addition. ...which appears to be added by your mailer. I don;t see it in the patch. I was referring to the extra line added by the + sign. [quoting from original patch] @@ -563,6 +556,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); tftp $fdtaddr $tftppath/$fdtfile; \ bootm $loadaddr - $fdtaddr + #define CONFIG_RAMBOOTCOMMAND \ setenv bootargs root=/dev/ram rw \ console=$consoledev,$baudrate $othbootargs; \ [/quote] ~sanjeev Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When the ax entered the forest, the trees said, The handle is one of us! -- Turkish proverb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Graeme Russ Sent: Monday, May 16, 2011 11:54 AM To: Wolfgang Denk Cc: U-Boot Mailing List; Simon Schwarz Subject: Re: [U-Boot] [PATCH 0/4] Accurate boot time measurement On Mon, May 16, 2011 at 3:48 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, [snip]...[snip] Well, the timing parser, as you callit, can be written in 10 lines or less of your scripting language of choice. See for example here for a solution in expect/tcl: ftp://ftp.denx.de/pub/tools/time_log We've been using this for about 10 years by now (see for example this 7 year old boot time analysis: http://www.denx.de/wiki/DULG/AN2004_11_BootTimeOptimization). As we can trivially use regular expressions, the effort to implement a timing parser can be ignored. And it is independet of what sort of boot device we are using. Fine if your running Linux - What if the only tool tyou have is Hyperterminal? [sp] I have personally found Realterm quite good specifically for for attaching timing info to the prints received. It is available at: http://realterm.sourceforge.net/ For measurement, I send the output directly to a log file - not displayed on the screen. BTW, Teraterm is my choice for regular use. ~sanjeev [snip]...[snip] ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Thursday, June 23, 2011 2:38 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan
Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet
reset sequence for Rev.G board
Hi Sanjeev,
On 06/22/11 22:24, Sanjeev Premi wrote:
From: Sriramakrishnan s...@ti.com
The GPIO pin used for resetting the external LAN chip has
changed for Rev.G board.
Signed-off-by: Sriramakrishnan s...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
---
board/ti/evm/evm.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 8f9f141..57e5fa5 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -181,17 +181,26 @@ static void setup_net_chip(void)
*/
static void reset_net_chip(void)
{
- struct gpio *gpio3_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
-
- /* Make GPIO 64 as output pin */
- writel(readl(gpio3_base-oe) ~(GPIO0), gpio3_base-oe);
-
- /* Now send a pulse on the GPIO pin */
- writel(GPIO0, gpio3_base-setdataout);
+ struct gpio *gpio_base;
+ u32 pin;
+
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1) {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
+ pin = GPIO0;/* Output pin: GPIO Bank 3, pin 0 */
+ } else {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO1_BASE;
+ pin = GPIO7;/* Output pin: GPIO Bank 0, pin 7 */
+ }
+
+ /* Configure the pin as output */
+ writel(readl(gpio_base-oe) ~(pin), gpio_base-oe);
+
+ /* Send a pulse on the GPIO pin */
+ writel(pin, gpio_base-setdataout);
udelay(1);
- writel(GPIO0, gpio3_base-cleardataout);
+ writel(pin, gpio_base-cleardataout);
udelay(1);
- writel(GPIO0, gpio3_base-setdataout);
+ writel(pin, gpio_base-setdataout);
Why keep messing with the gpio registers?
Why not use gpio framework?
Though it is omap specific, but it will be much cleaner then
the above.
[sp] I guess the intent was to keep code similar. But yes,
gpio framework can be used.
~sanjeev
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
Sent: Thursday, June 23, 2011 4:43 PM
To: Igor Grinberg
Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet
reset sequence for Rev.G board
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Thursday, June 23, 2011 2:38 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan
Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet
reset sequence for Rev.G board
Hi Sanjeev,
On 06/22/11 22:24, Sanjeev Premi wrote:
From: Sriramakrishnan s...@ti.com
The GPIO pin used for resetting the external LAN chip has
changed for Rev.G board.
Signed-off-by: Sriramakrishnan s...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
---
board/ti/evm/evm.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 8f9f141..57e5fa5 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -181,17 +181,26 @@ static void setup_net_chip(void)
*/
static void reset_net_chip(void)
{
- struct gpio *gpio3_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
-
- /* Make GPIO 64 as output pin */
- writel(readl(gpio3_base-oe) ~(GPIO0), gpio3_base-oe);
-
- /* Now send a pulse on the GPIO pin */
- writel(GPIO0, gpio3_base-setdataout);
+ struct gpio *gpio_base;
+ u32 pin;
+
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1) {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
+ pin = GPIO0;/* Output pin: GPIO Bank 3, pin 0 */
+ } else {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO1_BASE;
+ pin = GPIO7;/* Output pin: GPIO Bank 0, pin 7 */
+ }
+
+ /* Configure the pin as output */
+ writel(readl(gpio_base-oe) ~(pin), gpio_base-oe);
+
+ /* Send a pulse on the GPIO pin */
+ writel(pin, gpio_base-setdataout);
udelay(1);
- writel(GPIO0, gpio3_base-cleardataout);
+ writel(pin, gpio_base-cleardataout);
udelay(1);
- writel(GPIO0, gpio3_base-setdataout);
+ writel(pin, gpio_base-setdataout);
Why keep messing with the gpio registers?
Why not use gpio framework?
Though it is omap specific, but it will be much cleaner then
the above.
[sp] I guess the intent was to keep code similar. But yes,
gpio framework can be used.
[sp] Sorry, mail went earlier than I wanted :(
The only issue is that I couln't see gpio framework for omap.
Let me dig further...
~sanjeev
--
Regards,
Igor.
___
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 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
-Original Message- From: Premi, Sanjeev Sent: Thursday, June 23, 2011 4:48 PM To: Premi, Sanjeev; Igor Grinberg Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Thursday, June 23, 2011 4:43 PM To: Igor Grinberg Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board -Original Message- From: Igor Grinberg [mailto:grinb...@compulab.co.il] Sent: Thursday, June 23, 2011 2:38 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board Hi Sanjeev, On 06/22/11 22:24, Sanjeev Premi wrote: From: Sriramakrishnan s...@ti.com The GPIO pin used for resetting the external LAN chip has changed for Rev.G board. Signed-off-by: Sriramakrishnan s...@ti.com Signed-off-by: Sanjeev Premi pr...@ti.com --- board/ti/evm/evm.c | 27 ++- 1 files changed, 18 insertions(+), 9 deletions(-) [snip]...[snip] + /* Send a pulse on the GPIO pin */ + writel(pin, gpio_base-setdataout); udelay(1); - writel(GPIO0, gpio3_base-cleardataout); + writel(pin, gpio_base-cleardataout); udelay(1); - writel(GPIO0, gpio3_base-setdataout); + writel(pin, gpio_base-setdataout); Why keep messing with the gpio registers? Why not use gpio framework? Though it is omap specific, but it will be much cleaner then the above. [sp] I guess the intent was to keep code similar. But yes, gpio framework can be used. [sp] Sorry, mail went earlier than I wanted :( The only issue is that I couln't see gpio framework for omap. Let me dig further... [sp] Implementing GPIO for OMAP would be a long task. It should be done for long term; but is it necessary pre-condition for the patch? ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
-Original Message- From: Igor Grinberg [mailto:grinb...@compulab.co.il] Sent: Monday, June 27, 2011 12:17 PM To: Premi, Sanjeev Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board On 06/27/11 08:06, Premi, Sanjeev wrote: -Original Message- From: Premi, Sanjeev Sent: Thursday, June 23, 2011 4:48 PM To: Premi, Sanjeev; Igor Grinberg Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Thursday, June 23, 2011 4:43 PM To: Igor Grinberg Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board -Original Message- From: Igor Grinberg [mailto:grinb...@compulab.co.il] Sent: Thursday, June 23, 2011 2:38 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board Hi Sanjeev, On 06/22/11 22:24, Sanjeev Premi wrote: From: Sriramakrishnan s...@ti.com The GPIO pin used for resetting the external LAN chip has changed for Rev.G board. Signed-off-by: Sriramakrishnan s...@ti.com Signed-off-by: Sanjeev Premi pr...@ti.com --- board/ti/evm/evm.c | 27 ++- 1 files changed, 18 insertions(+), 9 deletions(-) [snip]...[snip] + /* Send a pulse on the GPIO pin */ + writel(pin, gpio_base-setdataout); udelay(1); - writel(GPIO0, gpio3_base-cleardataout); + writel(pin, gpio_base-cleardataout); udelay(1); - writel(GPIO0, gpio3_base-setdataout); + writel(pin, gpio_base-setdataout); Why keep messing with the gpio registers? Why not use gpio framework? Though it is omap specific, but it will be much cleaner then the above. [sp] I guess the intent was to keep code similar. But yes, gpio framework can be used. [sp] Sorry, mail went earlier than I wanted :( The only issue is that I couln't see gpio framework for omap. Let me dig further... [sp] Implementing GPIO for OMAP would be a long task. It should be done for long term; but is it necessary pre-condition for the patch? There is no need to implement GPIO for OMAP. It is already there, you just need to use it instead of writing directly to the GPIO registers. You can find all the implementation in: arch/arm/cpu/armv7/omap3/gpio.c and the header is: arch/arm/include/asm/arch-omap3/gpio.h [sp] No wonder, I couldn't find it in drivers/gpio. (Didn't occur that it could be in ARCH specific dir) Will rebase and send an updated patch soon. ~sanjeev All you need is to include the header, request the appropriate gpio, send the pulse and maybe (if you don't need it anymore) free that gpio. This is not hard or long at all. -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3 Move declaration of gpmc_cfg.
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Tom Rix
Sent: Tuesday, November 17, 2009 2:20 AM
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] OMAP3 Move declaration of gpmc_cfg.
Every omap3 board config file declared the global variable gpmc_cfg.
This changes moves the declaration to a better location in the
arch dependent header file cpu.h.
Hi Tom,
Wouldn't omap_gpmc.h be a better place for this?
Sorry, I had missed this post earlier; but found after implementing
the change for omap3evm and am3517evm; Came across this port while
following the trail for removing other externs from the config files.
Best regards,
Sanjeev
Signed-off-by: Tom Rix tom@windriver.com
---
include/asm-arm/arch-omap3/cpu.h |4
include/configs/devkit8000.h |1 -
include/configs/omap3_beagle.h |1 -
include/configs/omap3_evm.h |1 -
include/configs/omap3_overo.h|1 -
include/configs/omap3_pandora.h |1 -
include/configs/omap3_sdp3430.h |1 -
include/configs/omap3_zoom1.h|1 -
include/configs/omap3_zoom2.h|1 -
9 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/include/asm-arm/arch-omap3/cpu.h
b/include/asm-arm/arch-omap3/cpu.h
index e51c4f3..aa8de32 100644
--- a/include/asm-arm/arch-omap3/cpu.h
+++ b/include/asm-arm/arch-omap3/cpu.h
@@ -136,6 +136,10 @@ struct gpmc {
u32 ecc8_result;/* 0x21C */
u32 ecc9_result;/* 0x220 */
};
+
+/* Used for board specific gpmc initialization */
+extern struct gpmc *gpmc_cfg;
+
#else /* __ASSEMBLY__ */
#define GPMC_CONFIG1 0x00
#define GPMC_CONFIG2 0x04
diff --git a/include/configs/devkit8000.h
b/include/configs/devkit8000.h
index 1011770..7487bb7 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -299,7 +299,6 @@
#define CONFIG_ENV_OFFSETboot_flash_off
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_beagle.h
b/include/configs/omap3_beagle.h
index 024b9b8..70186ce 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -314,7 +314,6 @@
#define CONFIG_SYS_JFFS2_NUM_BANKS 1
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 6709edc..162bfea 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -295,7 +295,6 @@
#define CONFIG_SYS_JFFS2_NUM_BANKS 1
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_overo.h
b/include/configs/omap3_overo.h
index 0f812a7..ff25aba 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -299,7 +299,6 @@
#define CONFIG_SYS_JFFS2_NUM_BANKS 1
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_pandora.h
b/include/configs/omap3_pandora.h
index 0cafeb8..838b1ad 100644
--- a/include/configs/omap3_pandora.h
+++ b/include/configs/omap3_pandora.h
@@ -292,7 +292,6 @@
#define CONFIG_SYS_JFFS2_NUM_BANKS 1
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_sdp3430.h
b/include/configs/omap3_sdp3430.h
index d91c8ff..a2a4b8a 100644
--- a/include/configs/omap3_sdp3430.h
+++ b/include/configs/omap3_sdp3430.h
@@ -361,7 +361,6 @@
/*
--*/
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_zoom1.h
b/include/configs/omap3_zoom1.h
index 2aef973..62a6340 100644
--- a/include/configs/omap3_zoom1.h
+++ b/include/configs/omap3_zoom1.h
@@ -300,7 +300,6 @@
#define CONFIG_SYS_JFFS2_NUM_BANKS 1
#ifndef __ASSEMBLY__
-extern struct gpmc *gpmc_cfg;
extern unsigned int boot_flash_base;
extern volatile unsigned int boot_flash_env_addr;
extern unsigned int boot_flash_off;
diff --git a/include/configs/omap3_zoom2.h
b/include/configs/omap3_zoom2.h
index 5b03fb6..5296630 100644
--- a/include/configs/omap3_zoom2.h
+++
Re: [U-Boot] Breakage on arm/next
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Tom Sent: Tuesday, December 01, 2009 8:10 PM To: apgmoorthy Cc: 'Scott Wood'; u-boot@lists.denx.de; kyungmin.p...@samsung.com Subject: Re: [U-Boot] Breakage on arm/next apgmoorthy wrote: Hi Tom, snip Moving these Macro definitions to include/linux/mtd/onenand.h looks more viable. I can send across the patch. Please comment. Could the macros defined in apollo.h also be defined in the other target board's config file ? Thank you for looking into this Tom Is there any update on the fix/proposal? I am trying to build for omap3_evm; but see the same problem. My repo is currently at: bb3bcfa : Merge branch 'next' of ../next a200a7c : Update CHANGELOG; prepare Prepare v2009.11 Best regards, Sanjeev With Regards Moorthy ___ 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] RFC common omap3 subconfig ? was Re: [PATCH] OMAP3EVM: Increase bootargs string length.
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Tom Sent: Thursday, December 17, 2009 9:25 PM To: Dirk Behme Cc: u-boot@lists.denx.de Subject: [U-Boot] RFC common omap3 subconfig ? was Re: [PATCH] OMAP3EVM: Increase bootargs string length. Dirk Behme wrote: On 17.12.2009 14:29, Sriramakrishnan wrote: Increase the bootargs string length as multiple options (especially for Video settings) are passed to the kernel through bootargs. Also increase the number of args. snip Should we do this for some more OMAP3 boards, too? E.g. Overo and Beagle? Or for all OMAP3 boards? It seems like a lot of the omap3 boards share common config options. What do you think about consolidating the common options to a sub config file ? Seems a good idea; only if we are sure that the next board doesn't break the current list of common configs. Else, we would be having patches to move config options back to board specific files. ~sanjeev Tom Best regards Dirk ___ 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Broken OMAP3 EVM and SMDKC100
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Dirk Behme Sent: Thursday, December 24, 2009 11:48 AM To: u-boot@lists.denx.de Subject: [U-Boot] Broken OMAP3 EVM and SMDKC100 Doing ./MAKEALL ARM_CORTEX_A8 with recent mainline head, omap3_evm and smdkc100 fail with env_onenand.c: In function 'env_relocate_spec': env_onenand.c:70: error: 'CONFIG_ENV_ADDR_FLEX' undeclared (first use in this function) env_onenand.c:70: error: (Each undeclared identifier is reported only once env_onenand.c:70: error: for each function it appears in.) env_onenand.c: In function 'saveenv': env_onenand.c:106: error: 'CONFIG_ENV_ADDR_FLEX' undeclared (first use in this function) env_onenand.c:107: error: 'CONFIG_ENV_SIZE_FLEX' undeclared (first use in this function) This should already have been fixed by my patch. See: http://www.mail-archive.com/u-boot@lists.denx.de/msg26698.html Just fyi, in case somebody has time to look into this. Ah, and omap3_evm additionally has omap3.c: In function 'musb_platform_init': omap3.c:126: warning: label 'end' defined but not used Didn't notice it yesterday. Will look into it now. Best regards, Sanjeev Best regards Dirk ___ 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
