Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add more expansionboard IDs
Dear Jason Kridner, In message 1288936010-30462-1-git-send-email-jkrid...@beagleboard.org you wrote: 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 +#define SF_HARDHAT 0x01000900 ^^ Where is this being used? 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 Respect is a rational process -- McCoy, The Galileo Seven, stardate 2822.3 ___ 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] mpc83xx: Make it boot again
On 11/04/2010 08:49 PM, Wood Scott-B07421 wrote: Timur Tabi wrote: Wood Scott-B07421 wrote: To be totally safe, we probably want to do a readback plus twi (to turn a data dependency into a flow dependency) before the isync. twi == trap word immediate? Yes. If so, I don't see how that will turn a data dependency into a flow dependency. Is that some sort of side effect of twi? It decides based on the input register (data dependency) whether to cause a trap (flow dependency). We never want it to actually trap, so we set a condition that says never trap, but the dependency is still there -- the hardware doesn't decode it as a no-op. Might there be any other location this could be used for ? Actually my 8377 is running fine up to 533MHz core and csb up to 400MHz. As soon as core frequency rises to 600MHz+ there'll be frequent hangs during flush_dcache. core voltage is clean at 1.05V without any glitches or significant load steps. Can anybody confirm that current code runs stable on MPC837x at 600MHz+ ? Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Enabling the API
Hi, I am currently running U-Boot on our Renesas SH4 (SH7723) based system. I would like to add the API functionality, but am finding the documentation covering this area a little sparse. Can anybody offer me any helpful tips and advice to help me along. Many thanks, Andrew = Andrew Holt Senior Software Engineer Email: andrew.h...@electrans.com Phone: 0151 347 2270 Mobile: 07841 340608 Skype: andrewtholt De Omnibus Dubitandum = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Dear Albert Aribaud, older ld emitted all ELF relocations in input sections named .rel.dyn, whereas newer ld uses names of the form .rel*. The linker script only collected .rel.dyn input sections. Rewrite to collect all .rel* input sections and overlay with .bss. Signed-off-by: Albert Aribaud albert.arib...@free.fr --- Thank you, works fine with: gcc 4.2.4 (binary size 258700) gcc 4.3.5 (binary size 251600 - nice!) (ARM9 AT91SAM9XE512, top9000, TOT u-boot-atmel at91cleanup-rework branch) Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
Le 05/11/2010 09:38, Reinhard Meyer a écrit : Dear Albert Aribaud, older ld emitted all ELF relocations in input sections named .rel.dyn, whereas newer ld uses names of the form .rel*. The linker script only collected .rel.dyn input sections. Rewrite to collect all .rel* input sections and overlay with .bss. Signed-off-by: Albert Aribaudalbert.arib...@free.fr --- Thank you, works fine with: gcc 4.2.4 (binary size 258700) gcc 4.3.5 (binary size 251600 - nice!) (ARM9 AT91SAM9XE512, top9000, TOT u-boot-atmel at91cleanup-rework branch) Thanks for testing. The size reduction is due to the gcc ARM backend which has obviously undergone many improvements since gcc 4.2.x. Openrd_base goes from 376 to 360k, and edminiv2 (untested yet, though) from 152 to 144k when using the CS arm-2010q1-202 toolchain (4.4.1) instead of the ELDK 4.2 one (gcc 4.2.2). Signed-off-by: Reinhard Meyeru-b...@emk-elektronik.de Did you mean 'Tested-by:'? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] adopt avr32 to latest changes in u-boot-atmel/at91cleanup-rework
Dear Reinhard Meyer,
This series is on top of da94dc9ab80b30da0cd3ecadea27fd04f03a4489 in
u-boot-atmel/at91cleanup-rework. It renames memory-map.h to hardware.h and do
the rename of definitions like ATMEL_BASE_xx schema used in at91.
Tested to work on atstk1002 and selfmade, not jet upstream board.
regards
Andreas Bießmann
Andreas Bießmann (2):
avr32: rename memory-map.h - hardware.h
avr32: fixup definitions to ATMEL_BASE_xxx
arch/avr32/cpu/at32ap700x/clk.c|2 +-
arch/avr32/cpu/at32ap700x/portmux.c|2 +-
arch/avr32/cpu/at32ap700x/sm.h |4 +-
arch/avr32/cpu/cpu.c |2 +-
arch/avr32/cpu/hsdramc.c |2 +-
arch/avr32/cpu/hsdramc1.h |4 +-
arch/avr32/cpu/hsmc3.h |4 +-
arch/avr32/cpu/interrupts.c|4 +-
arch/avr32/cpu/portmux-gpio.c |2 +-
arch/avr32/cpu/portmux-pio.c |2 +-
arch/avr32/include/asm/arch-at32ap700x/gpio.h | 12 ++--
.../arch-at32ap700x/{memory-map.h = hardware.h} | 76 ++--
arch/avr32/include/asm/arch-at32ap700x/portmux.h | 10 ++--
arch/avr32/include/asm/hmatrix-common.h|2 +-
board/atmel/atngw100/atngw100.c|4 +-
board/atmel/atstk1000/atstk1000.c |4 +-
board/earthlcd/favr-32-ezkit/favr-32-ezkit.c |2 +-
board/mimc/mimc200/mimc200.c |4 +-
board/miromico/hammerhead/hammerhead.c |4 +-
drivers/mmc/atmel_mci.c|2 +-
drivers/mmc/atmel_mci.h|4 +-
include/configs/atngw100.h |6 +-
include/configs/atstk1002.h|8 +--
include/configs/atstk1003.h|8 +--
include/configs/atstk1004.h|8 +--
include/configs/atstk1006.h|8 +--
include/configs/favr-32-ezkit.h|8 +--
include/configs/hammerhead.h |3 +-
include/configs/mimc200.h |6 +-
29 files changed, 100 insertions(+), 107 deletions(-)
rename arch/avr32/include/asm/arch-at32ap700x/{memory-map.h = hardware.h}
(53%)
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] avr32: fixup definitions to ATMEL_BASE_xxx
Signed-off-by: Andreas Bießmann biessm...@corscience.de
---
changes since v1:
- only rename definitions to ATMEL_BASE_xx schema in this patch
- rename of memeory-map.h - hardweare.h is required before
arch/avr32/cpu/at32ap700x/sm.h|4 +-
arch/avr32/cpu/hsdramc1.h |4 +-
arch/avr32/cpu/hsmc3.h|4 +-
arch/avr32/cpu/interrupts.c |2 +-
arch/avr32/include/asm/arch-at32ap700x/gpio.h | 10 ++--
arch/avr32/include/asm/arch-at32ap700x/hardware.h | 76 ++--
arch/avr32/include/asm/arch-at32ap700x/portmux.h | 10 ++--
arch/avr32/include/asm/hmatrix-common.h |2 +-
board/atmel/atngw100/atngw100.c |4 +-
board/atmel/atstk1000/atstk1000.c |4 +-
board/earthlcd/favr-32-ezkit/favr-32-ezkit.c |2 +-
board/mimc/mimc200/mimc200.c |4 +-
board/miromico/hammerhead/hammerhead.c|2 +-
drivers/mmc/atmel_mci.h |4 +-
include/configs/atngw100.h|4 +-
include/configs/atstk1002.h |6 +-
include/configs/atstk1003.h |6 +-
include/configs/atstk1004.h |6 +-
include/configs/atstk1006.h |6 +-
include/configs/favr-32-ezkit.h |6 +-
include/configs/hammerhead.h |3 +-
include/configs/mimc200.h |4 +-
22 files changed, 83 insertions(+), 90 deletions(-)
diff --git a/arch/avr32/cpu/at32ap700x/sm.h b/arch/avr32/cpu/at32ap700x/sm.h
index b6e4409..9a3804e 100644
--- a/arch/avr32/cpu/at32ap700x/sm.h
+++ b/arch/avr32/cpu/at32ap700x/sm.h
@@ -197,8 +197,8 @@
/* Register access macros */
#define sm_readl(reg) \
- readl((void *)SM_BASE + SM_##reg)
+ readl((void *)ATMEL_BASE_SM + SM_##reg)
#define sm_writel(reg,value) \
- writel((value), (void *)SM_BASE + SM_##reg)
+ writel((value), (void *)ATMEL_BASE_SM + SM_##reg)
#endif /* __CPU_AT32AP_SM_H__ */
diff --git a/arch/avr32/cpu/hsdramc1.h b/arch/avr32/cpu/hsdramc1.h
index 305d2cb..e18e074 100644
--- a/arch/avr32/cpu/hsdramc1.h
+++ b/arch/avr32/cpu/hsdramc1.h
@@ -136,8 +136,8 @@
/* Register access macros */
#define hsdramc1_readl(reg)\
- readl((void *)HSDRAMC_BASE + HSDRAMC1_##reg)
+ readl((void *)ATMEL_BASE_HSDRAMC + HSDRAMC1_##reg)
#define hsdramc1_writel(reg,value) \
- writel((value), (void *)HSDRAMC_BASE + HSDRAMC1_##reg)
+ writel((value), (void *)ATMEL_BASE_HSDRAMC + HSDRAMC1_##reg)
#endif /* __ASM_AVR32_HSDRAMC1_H__ */
diff --git a/arch/avr32/cpu/hsmc3.h b/arch/avr32/cpu/hsmc3.h
index ca533b9..ac47295 100644
--- a/arch/avr32/cpu/hsmc3.h
+++ b/arch/avr32/cpu/hsmc3.h
@@ -119,8 +119,8 @@
/* Register access macros */
#define hsmc3_readl(reg) \
- readl((void *)HSMC_BASE + HSMC3_##reg)
+ readl((void *)ATMEL_BASE_HSMC + HSMC3_##reg)
#define hsmc3_writel(reg,value)\
- writel((value), (void *)HSMC_BASE + HSMC3_##reg)
+ writel((value), (void *)ATMEL_BASE_HSMC + HSMC3_##reg)
#endif /* __CPU_AT32AP_HSMC3_H__ */
diff --git a/arch/avr32/cpu/interrupts.c b/arch/avr32/cpu/interrupts.c
index c751981..c6ea435 100644
--- a/arch/avr32/cpu/interrupts.c
+++ b/arch/avr32/cpu/interrupts.c
@@ -125,7 +125,7 @@ static int set_interrupt_handler(unsigned int nr, void
(*handler)(void),
intpr = (handler_addr HANDLER_MASK);
intpr |= (priority INTLEV_MASK) INTLEV_SHIFT;
- writel(intpr, (void *)INTC_BASE + 4 * nr);
+ writel(intpr, (void *)ATMEL_BASE_INTC + 4 * nr);
return 0;
}
diff --git a/arch/avr32/include/asm/arch-at32ap700x/gpio.h
b/arch/avr32/include/asm/arch-at32ap700x/gpio.h
index b0254f2..4322eac 100644
--- a/arch/avr32/include/asm/arch-at32ap700x/gpio.h
+++ b/arch/avr32/include/asm/arch-at32ap700x/gpio.h
@@ -45,15 +45,15 @@ static inline void *pio_pin_to_port(unsigned int pin)
{
switch (pin 5) {
case 0:
- return (void *)PIOA_BASE;
+ return (void *)ATMEL_BASE_PIOA;
case 1:
- return (void *)PIOB_BASE;
+ return (void *)ATMEL_BASE_PIOB;
case 2:
- return (void *)PIOC_BASE;
+ return (void *)ATMEL_BASE_PIOC;
case 3:
- return (void *)PIOD_BASE;
+ return (void *)ATMEL_BASE_PIOD;
case 4:
- return (void *)PIOE_BASE;
+ return (void *)ATMEL_BASE_PIOE;
default:
return NULL;
}
diff --git a/arch/avr32/include/asm/arch-at32ap700x/hardware.h
b/arch/avr32/include/asm/arch-at32ap700x/hardware.h
index
[U-Boot] [PATCH v2 1/2] avr32: rename memory-map.h - hardware.h
Signed-off-by: Andreas Bießmann biessm...@corscience.de
---
changes since v1:
- only rename in this patch and fixup includes in respective includes
- use 'format-patch -C'
arch/avr32/cpu/at32ap700x/clk.c|2 +-
arch/avr32/cpu/at32ap700x/portmux.c|2 +-
arch/avr32/cpu/cpu.c |2 +-
arch/avr32/cpu/hsdramc.c |2 +-
arch/avr32/cpu/interrupts.c|2 +-
arch/avr32/cpu/portmux-gpio.c |2 +-
arch/avr32/cpu/portmux-pio.c |2 +-
arch/avr32/include/asm/arch-at32ap700x/gpio.h |2 +-
.../arch-at32ap700x/{memory-map.h = hardware.h} |0
board/miromico/hammerhead/hammerhead.c |2 +-
drivers/mmc/atmel_mci.c|2 +-
include/configs/atngw100.h |2 +-
include/configs/atstk1002.h|2 +-
include/configs/atstk1003.h|2 +-
include/configs/atstk1004.h|2 +-
include/configs/atstk1006.h|2 +-
include/configs/favr-32-ezkit.h|2 +-
include/configs/mimc200.h |2 +-
18 files changed, 17 insertions(+), 17 deletions(-)
rename arch/avr32/include/asm/arch-at32ap700x/{memory-map.h = hardware.h}
(100%)
diff --git a/arch/avr32/cpu/at32ap700x/clk.c b/arch/avr32/cpu/at32ap700x/clk.c
index 742bc6b..b63b9df 100644
--- a/arch/avr32/cpu/at32ap700x/clk.c
+++ b/arch/avr32/cpu/at32ap700x/clk.c
@@ -24,7 +24,7 @@
#include asm/io.h
#include asm/arch/clk.h
-#include asm/arch/memory-map.h
+#include asm/arch/hardware.h
#include asm/arch/portmux.h
#include sm.h
diff --git a/arch/avr32/cpu/at32ap700x/portmux.c
b/arch/avr32/cpu/at32ap700x/portmux.c
index b1f2c6f..e3e38a2 100644
--- a/arch/avr32/cpu/at32ap700x/portmux.c
+++ b/arch/avr32/cpu/at32ap700x/portmux.c
@@ -24,7 +24,7 @@
#include asm/io.h
#include asm/arch/chip-features.h
-#include asm/arch/memory-map.h
+#include asm/arch/hardware.h
#include asm/arch/portmux.h
/*
diff --git a/arch/avr32/cpu/cpu.c b/arch/avr32/cpu/cpu.c
index e4489bb..7907837 100644
--- a/arch/avr32/cpu/cpu.c
+++ b/arch/avr32/cpu/cpu.c
@@ -27,7 +27,7 @@
#include asm/sysreg.h
#include asm/arch/clk.h
-#include asm/arch/memory-map.h
+#include asm/arch/hardware.h
#include hsmc3.h
diff --git a/arch/avr32/cpu/hsdramc.c b/arch/avr32/cpu/hsdramc.c
index b6eae66..1485494 100644
--- a/arch/avr32/cpu/hsdramc.c
+++ b/arch/avr32/cpu/hsdramc.c
@@ -25,7 +25,7 @@
#include asm/sdram.h
#include asm/arch/clk.h
-#include asm/arch/memory-map.h
+#include asm/arch/hardware.h
#include hsdramc1.h
diff --git a/arch/avr32/cpu/interrupts.c b/arch/avr32/cpu/interrupts.c
index c6d8d16..c751981 100644
--- a/arch/avr32/cpu/interrupts.c
+++ b/arch/avr32/cpu/interrupts.c
@@ -27,7 +27,7 @@
#include asm/processor.h
#include asm/sysreg.h
-#include asm/arch/memory-map.h
+#include asm/arch/hardware.h
#define HANDLER_MASK 0x00ff
#define INTLEV_SHIFT 30
diff --git a/arch/avr32/cpu/portmux-gpio.c b/arch/avr32/cpu/portmux-gpio.c
index 9acd040..7b64c89 100644
--- a/arch/avr32/cpu/portmux-gpio.c
+++ b/arch/avr32/cpu/portmux-gpio.c
@@ -22,7 +22,7 @@
#include common.h
#include asm/io.h
-#include asm/arch/memory-map.h
+#include asm/arch/hardware.h
#include asm/arch/gpio.h
void portmux_select_peripheral(void *port, unsigned long pin_mask,
diff --git a/arch/avr32/cpu/portmux-pio.c b/arch/avr32/cpu/portmux-pio.c
index a29f94e..cb5e962 100644
--- a/arch/avr32/cpu/portmux-pio.c
+++ b/arch/avr32/cpu/portmux-pio.c
@@ -22,7 +22,7 @@
#include common.h
#include asm/io.h
-#include asm/arch/memory-map.h
+#include asm/arch/hardware.h
#include asm/arch/gpio.h
void portmux_select_peripheral(void *port, unsigned long pin_mask,
diff --git a/arch/avr32/include/asm/arch-at32ap700x/gpio.h
b/arch/avr32/include/asm/arch-at32ap700x/gpio.h
index 303e353..b0254f2 100644
--- a/arch/avr32/include/asm/arch-at32ap700x/gpio.h
+++ b/arch/avr32/include/asm/arch-at32ap700x/gpio.h
@@ -23,7 +23,7 @@
#define __ASM_AVR32_ARCH_GPIO_H__
#include asm/arch/chip-features.h
-#include asm/arch/memory-map.h
+#include asm/arch/hardware.h
#define NR_GPIO_CONTROLLERS5
diff --git a/arch/avr32/include/asm/arch-at32ap700x/memory-map.h
b/arch/avr32/include/asm/arch-at32ap700x/hardware.h
similarity index 100%
rename from arch/avr32/include/asm/arch-at32ap700x/memory-map.h
rename to arch/avr32/include/asm/arch-at32ap700x/hardware.h
diff --git a/board/miromico/hammerhead/hammerhead.c
b/board/miromico/hammerhead/hammerhead.c
index 78f4fd4..a0794ba 100644
--- a/board/miromico/hammerhead/hammerhead.c
+++ b/board/miromico/hammerhead/hammerhead.c
@@ -29,7 +29,7 @@
#include asm/sdram.h
#include asm/arch/clk.h
#include asm/arch/hmatrix.h
-#include asm/arch/memory-map.h
+#include asm/arch/hardware.h
#include asm/arch/mmu.h
[U-Boot] NAND on eLBC
Scott, looks like I made a mistake on current MPC8377 NAND wiring. Nand-Flash write enable is wired to LFWE1 ... I connected each WE to its corresponding CS, i.e. : - CS0/WE0 - Nor Flash - CS1/WE1 - Nand Flash - CS2/WE2 - MRAM Am I assuming right that FCM can only use WE0 ? Do you see any issue with connecting all devices to WE0 since they have distinct chip selects ? Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Weak symbols: request for comments
Hello all, I am looking for comments on the use of weak symbols in u-boot. Some context: u-boot uses weak symbols in several places to provide default definitions intended to be overriden in individual boards; this feature is broken with recent toolchains (at least gcc 4.4.4, binutils 2.20.1), and as a result only the default definitions are used, while board-specific definitions are silently discarded. The problem seems to arise because the weak definitions are seen by the linker before the board-specific ones. The linker will not look in the board-specific library archive for strong symbols that would override already defined weak symbols (this behavior is the one specified by the System V gABI, so it is correct). So, U-boot needs to be fixed. I can see the following ways forward: 1.1) Stop using weak symbols; use pre-initialized function pointers instead (possibly grouped in a struct, for cleanliness). This has the benefit of offering a clear interface and being independent of toolchain details. 1.2) Use regular (non-weak) extern declarations for overridable stuff; collect all default weak symbols into a separate library archive, to be supplied last to the linker. 1.3) Stop using a library archive for the board specific stuff. Instead, collect and link all the object files to produce the output binary. Only Makefile changes are involved, but correct behavior depends on all boards doing the right thing. 1.4) Link u-boot into a board-agnostic dynamic library, link the board-specific stuff into an executable embedding a dynamic linker, and package all this stuff somehow. Are there better options? Which one would you prefer to see implemented? For reference, here is the list of the definitions currently marked weak in the u-boot code: _machine_restart arch_memory_failure_handle arch_memory_test_advance arch_memory_test_cleanup arch_memory_test_prepare board_hwconfig board_nand_init board_reset cpu_hwconfig do_bootelf_exec do_go_exec getDebugChar kgdb_flush_cache_all kgdb_flush_cache_range kgdb_interruptible kgdb_serial_init mg_get_drv_data putDebugChar putDebugStr read_fifo spi_cs_activate spi_cs_deactivate spi_cs_is_valid system_map -- Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Sebastien, [snip] So, U-boot needs to be fixed. I can see the following ways forward: 1.1) Stop using weak symbols; use pre-initialized function pointers instead (possibly grouped in a struct, for cleanliness). This has the benefit of offering a clear interface and being independent of toolchain details. yep - this is my favorite. Main goal should always be to be as clear as possible. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Sebastien Carlier, Am 05.11.2010 11:39, schrieb Sebastien Carlier: Hello all, So, U-boot needs to be fixed. I can see the following ways forward: 1.1) Stop using weak symbols; use pre-initialized function pointers instead (possibly grouped in a struct, for cleanliness). This has the benefit of offering a clear interface and being independent of toolchain details. sounds good to me despite of grouping. Isn't grouping tough due to different weak functions for each architecture? 1.2) Use regular (non-weak) extern declarations for overridable stuff; collect all default weak symbols into a separate library archive, to be supplied last to the linker. sounds messy to me. How about different weak symbols for different architectures? regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 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] Weak symbols: request for comments
Dear Sebastien Carlier, Am 05.11.2010 11:39, schrieb Sebastien Carlier: Hello all, So, U-boot needs to be fixed. I can see the following ways forward: 1.1) Stop using weak symbols; use pre-initialized function pointers instead (possibly grouped in a struct, for cleanliness). This has the benefit of offering a clear interface and being independent of toolchain details. sounds good to me despite of grouping. Isn't grouping tough due to different weak functions for each architecture? This will build more size and relocations and you get fixups too which are/will be bad for code that runs before relocation. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Sebastien Carlier, In message 4cd3defc.7010...@gmail.com you wrote: 1.1) Stop using weak symbols; use pre-initialized function pointers instead (possibly grouped in a struct, for cleanliness). This has the benefit of offering a clear interface and being independent of toolchain details. And where would the pre-initialized function pointers come from? Without adding a hell of #ifdef's ? 1.2) Use regular (non-weak) extern declarations for overridable stuff; collect all default weak symbols into a separate library archive, to be supplied last to the linker. Not realy practicable, as the code is distributed all over the place, and should remain where it logically belongs. 1.3) Stop using a library archive for the board specific stuff. Instead, collect and link all the object files to produce the output binary. Only Makefile changes are involved, but correct behavior depends on all boards doing the right thing. Close. I think stop using a library archives and do what Linux does instead is the way to go. 1.4) Link u-boot into a board-agnostic dynamic library, link the board-specific stuff into an executable embedding a dynamic linker, and package all this stuff somehow. Sounds pretty much complicated. 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 Chapter 1 -- The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Reinhard, On 11/05/2010 12:16 PM, Reinhard Meyer wrote: 1.2) Use regular (non-weak) extern declarations for overridable stuff; collect all default weak symbols into a separate library archive, to be supplied last to the linker. Not very practical, that would require that each driver etc. would be in two parts, the main part and the weak part. It would no need weak functions, however. You are entirely correct. It would be slightly inconvenient for drivers that provide overridable stuff, but no non-standard feature is needed and the benefit of static linking is preserved. 1.3) Stop using a library archive for the board specific stuff. Instead, collect and link all the object files to produce the output binary. Only Makefile changes are involved, but correct behavior depends on all boards doing the right thing. I don't like the weak concept :) It does seem like weak symbols were designed with other uses in mind, such as C++ class members defined within a class declaration, or to weak the dependencies between libraries... but not really to allow overridable definitions (what if two objects want to override the same weak symbol in different ways?). 1.4) Link u-boot into a board-agnostic dynamic library, link the board-specific stuff into an executable embedding a dynamic linker, and package all this stuff somehow. That is too complex. Besides there are few board-agnostic parts in u-boot, many functions rely in included defines that are board specific. Agreed. Are there better options? Which one would you prefer to see implemented? Yes. The old-fashioned #define CONFIG_BOARD_INIT_F and friends method. I would prefer that one. Its not beautiful but still widely used and bullet-proof. Could you please elaborate? I have looked for things like this in the code base but I could not find what you are referring to. Regards, Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Add 'led' command
Dear Jason Kridner, In message 1288936236-30603-1-git-send-email-jkrid...@beagleboard.org you wrote: It is desired to have the led command on the BeagleBoard to allow for some interaction in the scripts. This patch allows any board implementing the coloured LED API to control the LEDs from the console. led [green | yellow | red | all ] [ on | off ] or led [ 1 | 2 | 3 | all ] [ on | off ] Adds configuration item CONFIG_CMD_LED enabling the command. Partially based on patch from Ulf Samuelsson: http://www.mail-archive.com/u-boot@lists.denx.de/msg09593.html. Signed-off-by: Jason Kridner jkrid...@beagleboard.org --- common/Makefile |1 + common/cmd_led.c | 207 ++ 2 files changed, 208 insertions(+), 0 deletions(-) create mode 100644 common/cmd_led.c I understand the requirement, but I think it is more than time to come up with a common solution here instead of adding more and more copies of very similar code. We already have: arch/arm/cpu/arm920t/ep93xx/led.c arch/arm/cpu/arm926ejs/at91/led.c board/atmel/at91cap9adk/led.c board/atmel/at91rm9200dk/led.c board/atmel/at91rm9200ek/led.c board/atmel/at91sam9260ek/led.c board/atmel/at91sam9261ek/led.c board/atmel/at91sam9263ek/led.c board/atmel/at91sam9m10g45ek/led.c board/atmel/at91sam9rlek/led.c board/eukrea/cpu9260/led.c board/logicpd/zoom2/led.c board/ns9750dev/led.c board/psyent/pk1c20/led.c board/ronetix/pm9261/led.c board/ronetix/pm9263/led.c Please, let's unify these. 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 Dear Lord: I just want *one* one-armed manager so I never have to hear On the other hand, again. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Sebastien Carlier, In message 4cd3f58f.8090...@gmail.com you wrote: It does seem like weak symbols were designed with other uses in mind, such as C++ class members defined within a class declaration, or to weak the dependencies between libraries... but not really to allow overridable definitions (what if two objects want to override the same weak symbol in different ways?). Well, but that's exactly why they are used in library code: to allow overridable definitions. Yes. The old-fashioned #define CONFIG_BOARD_INIT_F and friends method. I would prefer that one. Its not beautiful but still widely used and bullet-proof. Could you please elaborate? I have looked for things like this in the code base but I could not find what you are referring to. Don't bother looking for it. We are happy that we have eliminated a bit of the #ifdef mess. We will not add it again. 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 had the rare misfortune of being one of the first people to try and implement a PL/1 compiler. -- T. Cheatham ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Sebastien, Are there better options? Which one would you prefer to see implemented? Yes. The old-fashioned #define CONFIG_BOARD_INIT_F and friends method. I would prefer that one. Its not beautiful but still widely used and bullet-proof. Could you please elaborate? I have looked for things like this in the code base but I could not find what you are referring to. extracts from arch/arm/lib/board.c: #if defined(CONFIG_ARCH_CPU_INIT) arch_cpu_init, /* basic arch cpu dependent setup */ #endif #if defined(CONFIG_BOARD_EARLY_INIT_F) board_early_init_f, #endif #if defined(CONFIG_ARCH_MISC_INIT) /* miscellaneous arch dependent initialisations */ arch_misc_init (); #endif #if defined(CONFIG_MISC_INIT_R) /* miscellaneous platform dependent initialisations */ misc_init_r (); #endif #ifdef BOARD_LATE_INIT board_late_init (); #endif #if defined(CONFIG_RESET_PHY_R) debug (Reset Ethernet PHY\n); reset_phy(); #endif Just a few that can be enabled by board specific defines. xxxboard.h #defines them and xxxboard.c has to implement them. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP4: speed up booting on Pandaboard
On 11/04/2010 05:46 PM, Nishanth Menon wrote: Sergiy Kibrik wrote, on 11/04/2010 05:38 AM: Improved default config for OMAP4 Pandaboard for faster boot: -reduced environment size to speed up memory initialization; -USB TTY driver turned off; Do we really want to do this? well, Pandaboard has serial port. It can be used instead of usbtty -tweaked blob load address to avoid image relocation (according to default uImage load address); Signed-off-by: Sergiy Kibriksergiy.kib...@globallogic.com What kind of savings did we get? I am guessing we have some time x savings.. reducing ENV_SIZE saves ~0.2 s. turning off usbtty saves ~0.2 s. changing loadaddr saves about a second. As shown my measurements, all introduced changes save about 1.3 - 1.5 seconds. --- include/configs/omap4_panda.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index 74defab..5aba424 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -62,10 +62,10 @@ /* * Size of malloc() pool - * Total Size Environment - 256k + * Total Size Environment - 2k * Malloc - add 256k */ -#define CONFIG_ENV_SIZE(256 10) +#define CONFIG_ENV_SIZE(256 4) /me likes the change, but not sure how it saves boot time. again, it's about 0.2 seconds #define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (256 10)) /* initial data */ /* Vector Base */ @@ -117,7 +117,7 @@ /* USB device configuration */ #define CONFIG_USB_DEVICE1 -#define CONFIG_USB_TTY1 +#undef CONFIG_USB_TTY do we need to have the undef? it might be better to just drop the define perhaps? what impact do we have on boot time with this change? if someone wants to turn usbtty again, he can simply #define variable again, in case we drop the whole line it may be slightly harder to find out proper variable in the code and then #define it all over again. I just thought keeping it will clarify config in some way. #define CONFIG_SYS_CONSOLE_IS_IN_ENV1 /* Flash */ @@ -146,7 +146,7 @@ #define CONFIG_ENV_OVERWRITE #define CONFIG_EXTRA_ENV_SETTINGS \ -loadaddr=0x8200\0 \ +loadaddr=0x80007FC0\0 \ btw, Dumb question: how did we decide on this address? building from kernel.org, I see System.map @ c0004000 == 80004000 when I do make uImage, /bin/bash /home/nmenon/Src/opensource/linux-2.6/scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n 'Linux-2.6.37-rc1-5-gd88c092' 0x80007FC0 is kernel load address (0x80008000) minus size of u-boot header (64 bytes). So load address is exactly the same as image address inside loaded blob, and we avoid memmoving kernel to it's load address. -regards, Sergey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Wolfgang, On 11/05/2010 01:14 PM, Wolfgang Denk wrote: 1.1) Stop using weak symbols; use pre-initialized function pointers instead (possibly grouped in a struct, for cleanliness). This has the benefit of offering a clear interface and being independent of toolchain details. And where would the pre-initialized function pointers come from? Without adding a hell of #ifdef's ? It would not be pretty, and, as pointed out by Joakim Tjernlund, it would not work before relocation. 1.2) Use regular (non-weak) extern declarations for overridable stuff; collect all default weak symbols into a separate library archive, to be supplied last to the linker. Not realy practicable, as the code is distributed all over the place, and should remain where it logically belongs. Each module could have its own defaults.c for overridable implementations, and the build system could collect all of these. It is not a pain-free solution. 1.3) Stop using a library archive for the board specific stuff. Instead, collect and link all the object files to produce the output binary. Only Makefile changes are involved, but correct behavior depends on all boards doing the right thing. Close. I think stop using a library archives and do what Linux does instead is the way to go. Partial linking with ld -r ? That does seem like a fairly simple change. Regards, Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Wolfgang, On 11/05/2010 01:23 PM, Wolfgang Denk wrote: Dear Sebastien Carlier, In message4cd3f58f.8090...@gmail.com you wrote: It does seem like weak symbols were designed with other uses in mind, such as C++ class members defined within a class declaration, or to weak the dependencies between libraries... but not really to allow overridable definitions (what if two objects want to override the same weak symbol in different ways?). Well, but that's exactly why they are used in library code: to allow overridable definitions. If this usage were specifically designed for, do you think the linker would silently allow multiple yet conflicting weak definitions for the same symbol? It is true that weak symbols can be used to support overridable definitions, but they seem more suitable for other uses. Regards, Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP4: speed up booting on Pandaboard
Sergiy Kibrik wrote, on 11/05/2010 08:35 AM: On 11/04/2010 05:46 PM, Nishanth Menon wrote: Sergiy Kibrik wrote, on 11/04/2010 05:38 AM: Improved default config for OMAP4 Pandaboard for faster boot: -reduced environment size to speed up memory initialization; -USB TTY driver turned off; Do we really want to do this? well, Pandaboard has serial port. It can be used instead of usbtty how about all those folks who dont have a serial cable handy instead would like to power the board + see the terminal over usb? -tweaked blob load address to avoid image relocation (according to default uImage load address); Signed-off-by: Sergiy Kibriksergiy.kib...@globallogic.com What kind of savings did we get? I am guessing we have some time x savings.. reducing ENV_SIZE saves ~0.2 s. turning off usbtty saves ~0.2 s. changing loadaddr saves about a second. As shown my measurements, all introduced changes save about 1.3 - 1.5 seconds. for what? getting to u-boot shell prompt? if so, I wonder how it does it actually happen. --- include/configs/omap4_panda.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index 74defab..5aba424 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -62,10 +62,10 @@ /* * Size of malloc() pool - * Total Size Environment - 256k + * Total Size Environment - 2k * Malloc - add 256k */ -#define CONFIG_ENV_SIZE(256 10) +#define CONFIG_ENV_SIZE(256 4) /me likes the change, but not sure how it saves boot time. again, it's about 0.2 seconds surprised how changing env saves 0.2 seconds - apologies, I dont have a panda on hand at the moment to do some actual tests with the board and patch :( #define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (256 10)) /* initial data */ /* Vector Base */ @@ -117,7 +117,7 @@ /* USB device configuration */ #define CONFIG_USB_DEVICE1 -#define CONFIG_USB_TTY1 +#undef CONFIG_USB_TTY do we need to have the undef? it might be better to just drop the define perhaps? what impact do we have on boot time with this change? if someone wants to turn usbtty again, he can simply #define variable again, in case we drop the whole line it may be slightly harder to find out proper variable in the code and then #define it all over again. I just thought keeping it will clarify config in some way. adding a comment will help /* enable this to get tty over usb */ #define CONFIG_SYS_CONSOLE_IS_IN_ENV1 /* Flash */ @@ -146,7 +146,7 @@ #define CONFIG_ENV_OVERWRITE #define CONFIG_EXTRA_ENV_SETTINGS \ -loadaddr=0x8200\0 \ +loadaddr=0x80007FC0\0 \ btw, Dumb question: how did we decide on this address? building from kernel.org, I see System.map @ c0004000 == 80004000 when I do make uImage, /bin/bash /home/nmenon/Src/opensource/linux-2.6/scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n 'Linux-2.6.37-rc1-5-gd88c092' 0x80007FC0 is kernel load address (0x80008000) minus size of u-boot header (64 bytes). So load address is exactly the same as image address inside loaded blob, and we avoid memmoving kernel to it's load address. thanks for the clarification - it might be good for us to come up with something a bit more automated as you can, in theory run mkuboot.sh with a different address. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Add 'led' command
Dear Wolfgang Denk, It is desired to have the led command on the BeagleBoard to allow for some interaction in the scripts. This patch allows any board implementing the coloured LED API to control the LEDs from the console. led [green | yellow | red | all ] [ on | off ] or led [ 1 | 2 | 3 | all ] [ on | off ] Adds configuration item CONFIG_CMD_LED enabling the command. Partially based on patch from Ulf Samuelsson: http://www.mail-archive.com/u-boot@lists.denx.de/msg09593.html. Signed-off-by: Jason Kridner jkrid...@beagleboard.org --- common/Makefile |1 + common/cmd_led.c | 207 ++ 2 files changed, 208 insertions(+), 0 deletions(-) create mode 100644 common/cmd_led.c I understand the requirement, but I think it is more than time to come up with a common solution here instead of adding more and more copies of very similar code. We already have: ... arch/arm/cpu/arm926ejs/at91/led.c board/atmel/at91cap9adk/led.c board/atmel/at91rm9200dk/led.c board/atmel/at91rm9200ek/led.c board/atmel/at91sam9260ek/led.c board/atmel/at91sam9261ek/led.c board/atmel/at91sam9263ek/led.c board/atmel/at91sam9m10g45ek/led.c board/atmel/at91sam9rlek/led.c At least the atmel stuff are functions to implement the control of the LEDs (via gpio, i2c, spi etc.) which inherently is board specific; but not a command interface to control them from u-boot prompt/scripts. His patch tries to add a command, not a LED implementation. Such a command was on my mind for a while. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ftahbc020s: Faraday AHB Controller definitions
ftahbc020s.h provides the basic definitions to help a SoC which use this AHB Controller could do scalable software settings in both C codes and asm codes. Signed-off-by: Macpaul Lin macp...@andestech.com --- include/faraday/ftahbc020s.h | 72 ++ 1 files changed, 72 insertions(+), 0 deletions(-) create mode 100644 include/faraday/ftahbc020s.h diff --git a/include/faraday/ftahbc020s.h b/include/faraday/ftahbc020s.h new file mode 100644 index 000..5a18e86 --- /dev/null +++ b/include/faraday/ftahbc020s.h @@ -0,0 +1,72 @@ +/* + * Copyright (C) 2010 Andes Technology Corporation + * Macpaul Lin, Andes Technology Corporation macp...@andestech.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +/* + * FTAHBC020S - AHB Controller (Arbiter/Decoder) definitions + */ +#ifndef __FTAHBC020S_H +#define __FTAHBC202S_H + +/* + * Registers Offsets + */ +#define FTAHBC020S_SLAVE_BSR_0 0x00/* Slave n Base/Size Reg */ +#define FTAHBC020S_SLAVE_BSR_1 0x04 +#define FTAHBC020S_SLAVE_BSR_2 0x08 +#define FTAHBC020S_SLAVE_BSR_3 0x0C +#define FTAHBC020S_SLAVE_BSR_4 0x10 +#define FTAHBC020S_SLAVE_BSR_5 0x14 +#define FTAHBC020S_SLAVE_BSR_6 0x18 +#define FTAHBC020S_SLAVE_BSR_7 0x1C +#define FTAHBC020S_SLAVE_BSR_8 0x20 +#define FTAHBC020S_SLAVE_BSR_9 0x24 +#define FTAHBC020S_SLAVE_BSR_100x28 + +#define FTAHBC020S_PCR 0x80/* Priority Ctrl Reg */ +#define FTAHBC020S_TCRG0x84/* Transfer Ctrl Reg */ +#define FTAHBC020S_CR 0x88/* Ctrl Reg */ + +/* FTAHBC020S_SLAVE_BSR - Slave n Base / Size Register */ +#define FTAHBC020S_SLAVE_BSR_BASE(x) (((x) 0xFFF) 20) +#define FTAHBC020S_SLAVE_BSR_SIZE(x) (((x) 0xF) 16) + +/* FTAHBC020S_PCR - Priority Control Register */ +#define FTAHBC020S_PCR_PLEVEL_15 (1 15) +#define FTAHBC020S_PCR_PLEVEL_14 (1 14) +#define FTAHBC020S_PCR_PLEVEL_13 (1 13) +#define FTAHBC020S_PCR_PLEVEL_12 (1 12) +#define FTAHBC020S_PCR_PLEVEL_11 (1 11) +#define FTAHBC020S_PCR_PLEVEL_10 (1 10) +#define FTAHBC020S_PCR_PLEVEL_09 (1 9) +#define FTAHBC020S_PCR_PLEVEL_08 (1 8) +#define FTAHBC020S_PCR_PLEVEL_07 (1 7) +#define FTAHBC020S_PCR_PLEVEL_06 (1 6) +#define FTAHBC020S_PCR_PLEVEL_05 (1 5) +#define FTAHBC020S_PCR_PLEVEL_04 (1 4) +#define FTAHBC020S_PCR_PLEVEL_03 (1 3) +#define FTAHBC020S_PCR_PLEVEL_02 (1 2) +#define FTAHBC020S_PCR_PLEVEL_01 (1 1) + +/* FTAHBC020S_CR - Interrupt Control Register */ +#define FTAHBC020S_CR_INTSTS (1 24) +#define FTAHBC020S_CR_RESP(x) (((x) 0x3) 20) +#define FTAHBC020S_CR_INTSMASK (1 16) +#define FTAHBC020S_CR_REMAP(1 0) + +#endif /* __FTAHBC020S_H */ -- 1.7.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP4: speed up booting on Pandaboard
On 11/05/2010 03:12 PM, Nishanth Menon wrote: Sergiy Kibrik wrote, on 11/05/2010 08:35 AM: On 11/04/2010 05:46 PM, Nishanth Menon wrote: Sergiy Kibrik wrote, on 11/04/2010 05:38 AM: Improved default config for OMAP4 Pandaboard for faster boot: -reduced environment size to speed up memory initialization; -USB TTY driver turned off; Do we really want to do this? well, Pandaboard has serial port. It can be used instead of usbtty how about all those folks who dont have a serial cable handy instead would like to power the board + see the terminal over usb? you're right, it can be the reason not to touch usbtty now. -tweaked blob load address to avoid image relocation (according to default uImage load address); Signed-off-by: Sergiy Kibriksergiy.kib...@globallogic.com What kind of savings did we get? I am guessing we have some time x savings.. reducing ENV_SIZE saves ~0.2 s. turning off usbtty saves ~0.2 s. changing loadaddr saves about a second. As shown my measurements, all introduced changes save about 1.3 - 1.5 seconds. for what? getting to u-boot shell prompt? if so, I wonder how it does it actually happen. no, not getting shell, but jumping to kernel. But even in case of getting shell, why we have to wait 1 more second? --- include/configs/omap4_panda.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index 74defab..5aba424 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -62,10 +62,10 @@ /* * Size of malloc() pool - * Total Size Environment - 256k + * Total Size Environment - 2k * Malloc - add 256k */ -#define CONFIG_ENV_SIZE(256 10) +#define CONFIG_ENV_SIZE(256 4) /me likes the change, but not sure how it saves boot time. again, it's about 0.2 seconds surprised how changing env saves 0.2 seconds - apologies, I dont have a panda on hand at the moment to do some actual tests with the board and patch :( I guess it's because of memory initializaion issues in mem_malloc_init(), and because of 256k environment it takes longer to do memset. #define CONFIG_SYS_MALLOC_LEN(CONFIG_ENV_SIZE + (256 10)) /* initial data */ /* Vector Base */ @@ -117,7 +117,7 @@ /* USB device configuration */ #define CONFIG_USB_DEVICE1 -#define CONFIG_USB_TTY1 +#undef CONFIG_USB_TTY do we need to have the undef? it might be better to just drop the define perhaps? what impact do we have on boot time with this change? if someone wants to turn usbtty again, he can simply #define variable again, in case we drop the whole line it may be slightly harder to find out proper variable in the code and then #define it all over again. I just thought keeping it will clarify config in some way. adding a comment will help /* enable this to get tty over usb */ THX, I'l do that. #define CONFIG_SYS_CONSOLE_IS_IN_ENV1 /* Flash */ @@ -146,7 +146,7 @@ #define CONFIG_ENV_OVERWRITE #define CONFIG_EXTRA_ENV_SETTINGS \ -loadaddr=0x8200\0 \ +loadaddr=0x80007FC0\0 \ btw, Dumb question: how did we decide on this address? building from kernel.org, I see System.map @ c0004000 == 80004000 when I do make uImage, /bin/bash /home/nmenon/Src/opensource/linux-2.6/scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n 'Linux-2.6.37-rc1-5-gd88c092' 0x80007FC0 is kernel load address (0x80008000) minus size of u-boot header (64 bytes). So load address is exactly the same as image address inside loaded blob, and we avoid memmoving kernel to it's load address. thanks for the clarification - it might be good for us to come up with something a bit more automated as you can, in theory run mkuboot.sh with a different address. in theory yes, but practically it's just a default config for default uImage target. Can you suggest a way to coordinate load addresses across kernel bootloader build? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MPC8377: USB breaks board
Jocke, sorry to bother you again, but it might relate to our last discussion. Actually my MPC8377 based board is up and running with basic functionality. Now I'm trying to add USB support - but as soon as CONFIG_USB_EHCI_FSL is defined serial line is pretty dead again. This means again there's something wrong at the very beggining. Diff'ing the System.map gives almost identical layout up to cpu_init_f ... which adds USB specific code making the rest move, of course. The only difference is the location of __got2_entries : WORKING: 04a5 A __fixup_entries 070b A __got2_entries fc44 T version_string [...] NOT WORKING: 04a5 A __fixup_entries 0712 A __got2_entries fc44 T version_string [...] What makes __got2_entries move ? Why is __fixup_entries completely unaligned ? Looks pretty unusual to me. Any idea if this can lead to malfunction ? Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: USB breaks board
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/11/05 15:51:13: Jocke, sorry to bother you again, but it might relate to our last discussion. Actually my MPC8377 based board is up and running with basic functionality. Now I'm trying to add USB support - but as soon as CONFIG_USB_EHCI_FSL is defined serial line is pretty dead again. This means again there's something wrong at the very beggining. Diff'ing the System.map gives almost identical layout up to cpu_init_f ... which adds USB specific code making the rest move, of course. The only difference is the location of __got2_entries : WORKING: 04a5 A __fixup_entries 070b A __got2_entries fc44 T version_string [...] NOT WORKING: 04a5 A __fixup_entries 0712 A __got2_entries fc44 T version_string [...] What makes __got2_entries move ? *_entries are not addresses, they are a count(how many entries) See the linker file. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Wolfgang, I have implemented this solution: On 11/05/2010 01:14 PM, Wolfgang Denk wrote: I think stop using a library archives and do what Linux does instead is the way to go. You will find the patch here: http://io.oiioiio.com/~sebc/0001-Use-partial-linking-instead-of-building-library-arch.patch.bz2 I am not posting the patch directly to the list because it is rather large. Feedback is very welcome! Best regards, Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: USB breaks board
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/11/05 15:51:13: Jocke, sorry to bother you again, but it might relate to our last discussion. Actually my MPC8377 based board is up and running with basic functionality. Now I'm trying to add USB support - but as soon as CONFIG_USB_EHCI_FSL is defined serial line is pretty dead again. Perhaps USB becomes the console in this case and that is why you don't see anything? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] nand spl build with wrong CONFIG_SYS_TEXT_BASE
Hi Scott, Wolfgang's latest commit to change all TEXT_BASE to CONFIG_SYS_TEXT_BASE breaks the build for nand_spl. He defined CONFIG_SYS_TEXT_BASE in board header file for CONFIG_NAND, and renamed TEXT_BASE to CONFIG_SYS_TEXT_BASE in nand_spl/board/.../Makefile. Then for u-boot-spl, the CONFIG_SYS_TEXT_BASE is always the value defined in header file, which is, for example, 0xf8f82000 for MPC8536/8569/p1_p2/, not the one defined in nand-spl's Makefile, which is 0xfff0. Thus it causes the nand_spl image has wrong address from 0xf8f82000. When PAD_TO 0xfff01000, the final u-boot-spl-16k.bin will be 112M bytes. I think 83xx nand_spl might have the similar problem, but as I built 8315erdb's nand, it failed for some other multiple define for undef errors. Can you take a look at it? Defining CONFIG_SYS_TEXT_BASE in header file does impact the TEXT_BASE defined in Makefile for nand_spl. Thanks. Haiying ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: USB breaks board
On 11/05/2010 04:00 PM, Joakim Tjernlund wrote: Andre Schwarzandre.schw...@matrix-vision.de wrote on 2010/11/05 15:51:13: Jocke, sorry to bother you again, but it might relate to our last discussion. Actually my MPC8377 based board is up and running with basic functionality. Now I'm trying to add USB support - but as soon as CONFIG_USB_EHCI_FSL is defined serial line is pretty dead again. This means again there's something wrong at the very beggining. Diff'ing the System.map gives almost identical layout up to cpu_init_f ... which adds USB specific code making the rest move, of course. The only difference is the location of __got2_entries : WORKING: 04a5 A __fixup_entries 070b A __got2_entries fc44 T version_string [...] NOT WORKING: 04a5 A __fixup_entries 0712 A __got2_entries fc44 T version_string [...] What makes __got2_entries move ? *_entries are not addresses, they are a count(how many entries) See the linker file. ok - I'm no expert ... that's why I have to ask. Cheers, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP4: speed up booting on Pandaboard
Sergiy Kibrik wrote, on 11/05/2010 10:44 AM: On 11/05/2010 03:12 PM, Nishanth Menon wrote: Sergiy Kibrik wrote, on 11/05/2010 08:35 AM: On 11/04/2010 05:46 PM, Nishanth Menon wrote: Sergiy Kibrik wrote, on 11/04/2010 05:38 AM: Improved default config for OMAP4 Pandaboard for faster boot: -reduced environment size to speed up memory initialization; -USB TTY driver turned off; Do we really want to do this? well, Pandaboard has serial port. It can be used instead of usbtty how about all those folks who dont have a serial cable handy instead would like to power the board + see the terminal over usb? you're right, it can be the reason not to touch usbtty now. lets drop this change for the timebeing then. -tweaked blob load address to avoid image relocation (according to default uImage load address); Signed-off-by: Sergiy Kibriksergiy.kib...@globallogic.com What kind of savings did we get? I am guessing we have some time x savings.. reducing ENV_SIZE saves ~0.2 s. turning off usbtty saves ~0.2 s. changing loadaddr saves about a second. As shown my measurements, all introduced changes save about 1.3 - 1.5 seconds. for what? getting to u-boot shell prompt? if so, I wonder how it does it actually happen. no, not getting shell, but jumping to kernel. But even in case of getting shell, why we have to wait 1 more second? aaah, it would be good to fix up $subject to reflect this. speed up booting can mean anything. --- include/configs/omap4_panda.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index 74defab..5aba424 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -62,10 +62,10 @@ /* * Size of malloc() pool - * Total Size Environment - 256k + * Total Size Environment - 2k * Malloc - add 256k */ -#define CONFIG_ENV_SIZE(25610) +#define CONFIG_ENV_SIZE(2564) /me likes the change, but not sure how it saves boot time. again, it's about 0.2 seconds surprised how changing env saves 0.2 seconds - apologies, I dont have a panda on hand at the moment to do some actual tests with the board and patch :( I guess it's because of memory initializaion issues in mem_malloc_init(), and because of 256k environment it takes longer to do memset. interesting. thanks for the explanation. #define CONFIG_SYS_CONSOLE_IS_IN_ENV1 /* Flash */ @@ -146,7 +146,7 @@ #define CONFIG_ENV_OVERWRITE #define CONFIG_EXTRA_ENV_SETTINGS \ -loadaddr=0x8200\0 \ +loadaddr=0x80007FC0\0 \ btw, Dumb question: how did we decide on this address? building from kernel.org, I see System.map @ c0004000 == 80004000 when I do make uImage, /bin/bash /home/nmenon/Src/opensource/linux-2.6/scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n 'Linux-2.6.37-rc1-5-gd88c092' 0x80007FC0 is kernel load address (0x80008000) minus size of u-boot header (64 bytes). So load address is exactly the same as image address inside loaded blob, and we avoid memmoving kernel to it's load address. thanks for the clarification - it might be good for us to come up with something a bit more automated as you can, in theory run mkuboot.sh with a different address. in theory yes, but practically it's just a default config for default uImage target. actually there are blokes who use it that way as well. for e.g., in the old days of using BuildRoot inside TI, it just did the mkimage outside instead of just doing make uImage. Can you suggest a way to coordinate load addresses across kernel bootloader build? Hmm.. good point - need to try an idea I am thinking at the moment - this info is present in the memory already - just need to think how to drag it out -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377: USB breaks board
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/11/05 17:13:34: On 11/05/2010 04:07 PM, Joakim Tjernlund wrote: Andre Schwarzandre.schw...@matrix-vision.de wrote on 2010/11/05 15:51:13: Jocke, sorry to bother you again, but it might relate to our last discussion. Actually my MPC8377 based board is up and running with basic functionality. Now I'm trying to add USB support - but as soon as CONFIG_USB_EHCI_FSL is defined serial line is pretty dead again. Perhaps USB becomes the console in this case and that is why you don't see anything? Hmm - how can this happen ? Beats me, it was just an idea. I am not using USB at all so I really don't know what I am talking about :) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MPC8377: SerDes config
All, I'm a little confused how to setup SerDes properly on MPC8377, i.e. which function uses which port ... I'd expect the following : - SATA Ports 1+2 used on SerDes 1 - PCIe Ports 3+4 (2 times x1) on SerDes 2 This is what I've done : CONFIG_SYS_SCCR_PCIEXP1CM = 0 (disabled) CONFIG_SYS_SCCR_PCIEXP2CM = 2 CONFIG_SYS_SCCR_SATACM = 0xA0 (Port 1+2 used / 3+4 disabled) Still both SerDes are active : #define CONFIG_FSL_SERDES #define CONFIG_FSL_SERDES1 0xe3000 #define CONFIG_FSL_SERDES2 0xe3100 PCIe only gets one LAW @ CONFIG_SYS_PCIE2_BASE Board init code calls fsl_setup_serdes(CONFIG_FSL_SERDES1, FSL_SERDES_PROTO_SATA, FSL_SERDES_CLK_100, FSL_SERDES_VDD_1V); fsl_setup_serdes(CONFIG_FSL_SERDES2, FSL_SERDES_PROTO_PEX, FSL_SERDES_CLK_100, FSL_SERDES_VDD_1V) Is this supposed to be correct or have I swapped something ? Is it save to disable PEX-1 ? -- Regards, Andre MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP4: speed up booting on Pandaboard
On 11/05/2010 05:49 PM, Nishanth Menon wrote: lets drop this change for the timebeing then. agree =) Can you suggest a way to coordinate load addresses across kernel bootloader build? Hmm.. good point - need to try an idea I am thinking at the moment - this info is present in the memory already - just need to think how to drag it out I'm also quite interested in it, so will be very glad to see your suggestions. Thanks for your comments. I'll resubmit patch with different $subject. -- Regards, Sergey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP4: quick image loading memory init on Pandaboard
Improved default config for OMAP4 Pandaboard for faster boot: -reduced environment size to speed up memory initialization; -tweaked blob load address to avoid image relocation (according to default uImage load address); Signed-off-by: Sergiy Kibrik sergiy.kib...@globallogic.com --- include/configs/omap4_panda.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h index 74defab..5a2df35 100644 --- a/include/configs/omap4_panda.h +++ b/include/configs/omap4_panda.h @@ -62,10 +62,10 @@ /* * Size of malloc() pool - * Total Size Environment - 256k + * Total Size Environment - 2k * Malloc - add 256k */ -#define CONFIG_ENV_SIZE(256 10) +#define CONFIG_ENV_SIZE(256 4) #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (256 10)) /* initial data */ /* Vector Base */ @@ -146,7 +146,7 @@ #define CONFIG_ENV_OVERWRITE #define CONFIG_EXTRA_ENV_SETTINGS \ - loadaddr=0x8200\0 \ + loadaddr=0x80007FC0\0 \ console=ttyS2,115200n8\0 \ usbtty=cdc_acm\0 \ vram=16M\0 \ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] Add 'led' command
On Fri, Nov 5, 2010 at 9:13 AM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear Wolfgang Denk, It is desired to have the led command on the BeagleBoard to allow for some interaction in the scripts. This patch allows any board implementing the coloured LED API to control the LEDs from the console. led [green | yellow | red | all ] [ on | off ] or led [ 1 | 2 | 3 | all ] [ on | off ] Adds configuration item CONFIG_CMD_LED enabling the command. Partially based on patch from Ulf Samuelsson: http://www.mail-archive.com/u-boot@lists.denx.de/msg09593.html. Signed-off-by: Jason Kridner jkrid...@beagleboard.org --- common/Makefile | 1 + common/cmd_led.c | 207 ++ 2 files changed, 208 insertions(+), 0 deletions(-) create mode 100644 common/cmd_led.c I understand the requirement, but I think it is more than time to come up with a common solution here instead of adding more and more copies of very similar code. We already have: ... arch/arm/cpu/arm926ejs/at91/led.c board/atmel/at91cap9adk/led.c board/atmel/at91rm9200dk/led.c board/atmel/at91rm9200ek/led.c board/atmel/at91sam9260ek/led.c board/atmel/at91sam9261ek/led.c board/atmel/at91sam9263ek/led.c board/atmel/at91sam9m10g45ek/led.c board/atmel/at91sam9rlek/led.c At least the atmel stuff are functions to implement the control of the LEDs (via gpio, i2c, spi etc.) which inherently is board specific; but not a command interface to control them from u-boot prompt/scripts. His patch tries to add a command, not a LED implementation. Such a command was on my mind for a while. I tried to make it such that this command is enabled by the implementations on the other architectures by following the existing design. I don't know how they are making use of the LED functions, so it seems this command is required to make their implementations useful. I hope that is reason enough to at least get different maintainers to try this command out and give some additional feedback. It would be great if we had a summary of how these LED functions are used. For the BeagleBoard, we are simply enabling scripts to use this command. I think others are using the LED functions to indicate boot status and other u-boot native operations. Does such a summary exist so that I can make any command implementation suitable? Regards, Jason ___ 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
On Fri, Nov 5, 2010 at 8:02 AM, Premi, Sanjeev pr...@ti.com wrote:
-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
Re: [U-Boot] [PATCH] ARMV7: OMAP3: BeagleBoard: add xM rev B to ID table
Jason Kridner wrote, on 11/05/2010 01:46 AM:
From: Koen Kooik...@dominion.thruhere.net
Patch was updated by Jason Kridnerjkrid...@beagleboard.org:
* Use tabs to match style of other board revisions
* Only include board revisions that exist
* Default to the same configuration as the latest revision, but
without setting 'beaglerev'
Signed-off-by: Jason Kridnerjkrid...@beagleboard.org
not signed-off-by: Koen?
---
board/ti/beagle/beagle.c | 20 +++-
board/ti/beagle/beagle.h |3 ++-
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 520e57d..93c452e 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -176,7 +176,7 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM:
+ case REVISION_XM_A:
printf(Beagle xM Rev A\n);
setenv(beaglerev, xMA);
setenv(mpurate, 1000);
@@ -187,8 +187,26 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
+ case REVISION_XM_B:
+ printf(Beagle xM Rev B\n);
+ setenv(beaglerev, xMB);
+ setenv(mpurate, 1000);
+ MUX_BEAGLE_XM();
+ /* Set VAUX2 to 1.8V for EHCI PHY */
+ twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
+ TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ TWL4030_PM_RECEIVER_DEV_GRP_P1);
+ break;
default:
printf(Beagle unknown 0x%02x\n, get_board_revision());
+ setenv(mpurate, 1000);
It looks to me looking at the file that mpurate usage is CPU based and
NOT board based.. maybe you should use the cpu idendity to decide on
mpurate instead?
+ MUX_BEAGLE_XM();
+ /* Set VAUX2 to 1.8V for EHCI PHY */
+ twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
+ TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ TWL4030_PM_RECEIVER_DEV_GRP_P1);
}
switch (get_expansion_id()) {
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index 7d8dee0..fa893c4 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -37,7 +37,8 @@ const omap3_sysinfo sysinfo = {
#define REVISION_AXBX 0x7
#define REVISION_CX 0x6
#define REVISION_C4 0x5
-#define REVISION_XM 0x0
+#define REVISION_XM_A0x0
+#define REVISION_XM_B0x1
/*
* IEN - Input Enable
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] Pandora config fixes and updates
These patches update pandora's config for relocations and memory layout changes. They also sync the config with one shipped on production units. Please apply at least the first patch for v2010.12 so that we have pandora buildable. Patches generated on top of u-boot-ti, also applies on mainline u-boot. Grazvydas Ignotas (3): OMAP3: pandora: fix relocation and init memory map OMAP3: pandora: remove unused config macros OMAP3: pandora: update config for production board/pandora/config.mk | 33 --- include/configs/omap3_pandora.h | 117 +- 2 files changed, 52 insertions(+), 98 deletions(-) delete mode 100644 board/pandora/config.mk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] OMAP3: pandora: fix relocation and init memory map
Fix the build breakage introduced by the recent relocation and memory layout changes for ARM. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- board/pandora/config.mk | 33 - include/configs/omap3_pandora.h |8 2 files changed, 8 insertions(+), 33 deletions(-) delete mode 100644 board/pandora/config.mk diff --git a/board/pandora/config.mk b/board/pandora/config.mk deleted file mode 100644 index 0fab80c..000 --- a/board/pandora/config.mk +++ /dev/null @@ -1,33 +0,0 @@ -# -# (C) Copyright 2006 -# Texas Instruments, www.ti.com -# -# Pandora uses OMAP3 (ARM-CortexA8) cpu -# see http://www.ti.com/ for more information on Texas Instruments -# -# See file CREDITS for list of people who contributed to this -# project. -# -# This program is free software; you can redistribute it and/or -# modify it under the terms of the GNU General Public License as -# published by the Free Software Foundation; either version 2 of -# the License, or (at your option) any later version. -# -# This program is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 59 Temple Place, Suite 330, Boston, -# MA 02111-1307 USA -# -# Physical Address: -# 8000' (bank0) -# A000/ (bank1) -# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000 -# (mem base + reserved) - -# For use with external or internal boots. -CONFIG_SYS_TEXT_BASE = 0x80e8 diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h index b78aacf..b8cd2cd 100644 --- a/include/configs/omap3_pandora.h +++ b/include/configs/omap3_pandora.h @@ -243,6 +243,14 @@ /* SDRAM Bank Allocation method */ #define SDRC_R_B_C 1 +#define CONFIG_SYS_TEXT_BASE 0x80008000 +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_RAM_ADDR 0x4020f800 +#define CONFIG_SYS_INIT_RAM_SIZE 0x800 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR + \ + CONFIG_SYS_INIT_RAM_SIZE - \ + GENERATED_GBL_DATA_SIZE) + /*--- * FLASH and environment organization */ -- 1.6.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] OMAP3: pandora: remove unused config macros
Pandora's config has various flash related macros that are either not referenced anywhere in the code or are used by drivers that are not enabled. Remove them. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- Alternatively this old patch can be applied to clean up more OMAP boards: http://lists.denx.de/pipermail/u-boot/2010-April/070860.html include/configs/omap3_pandora.h | 20 1 files changed, 0 insertions(+), 20 deletions(-) diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h index b8cd2cd..f386bc4 100644 --- a/include/configs/omap3_pandora.h +++ b/include/configs/omap3_pandora.h @@ -261,40 +261,20 @@ #define PISMO1_NAND_SIZE GPMC_SIZE_128M #define PISMO1_ONEN_SIZE GPMC_SIZE_128M -#define CONFIG_SYS_MAX_FLASH_SECT 520 /* max number of sectors on */ - /* one chip */ -#define CONFIG_SYS_MAX_FLASH_BANKS 2 /* max number of flash banks */ #define CONFIG_SYS_MONITOR_LEN (256 10) /* Reserve 2 sectors */ #define CONFIG_SYS_FLASH_BASE boot_flash_base /* Monitor at start of flash */ #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE -#define CONFIG_SYS_ONENAND_BASEONENAND_MAP #define CONFIG_ENV_IS_IN_NAND 1 -#define ONENAND_ENV_OFFSET 0x24 /* environment starts here */ #define SMNAND_ENV_OFFSET 0x24 /* environment starts here */ #define CONFIG_SYS_ENV_SECT_SIZE boot_flash_sec #define CONFIG_ENV_OFFSET boot_flash_off #define CONFIG_ENV_ADDRSMNAND_ENV_OFFSET -/*--- - * CFI FLASH driver setup - */ -/* timeout values are in ticks */ -#define CONFIG_SYS_FLASH_ERASE_TOUT(100 * CONFIG_SYS_HZ) -#define CONFIG_SYS_FLASH_WRITE_TOUT(100 * CONFIG_SYS_HZ) - -/* Flash banks JFFS2 should use */ -#define CONFIG_SYS_MAX_MTD_BANKS (CONFIG_SYS_MAX_FLASH_BANKS + \ - CONFIG_SYS_MAX_NAND_DEVICE) -#define CONFIG_SYS_JFFS2_MEM_NAND -/* use flash_info[2] */ -#define CONFIG_SYS_JFFS2_FIRST_BANKCONFIG_SYS_MAX_FLASH_BANKS -#define CONFIG_SYS_JFFS2_NUM_BANKS 1 - #ifndef __ASSEMBLY__ extern unsigned int boot_flash_base; extern volatile unsigned int boot_flash_env_addr; -- 1.6.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] OMAP3: pandora: update config for production
Update pandora's config so that it can boot production kernels from NAND.
This enables UBI, USB, sets up NAND layout and default boot command.
It also expands malloc area so that UBI works.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
include/configs/omap3_pandora.h | 89 +++
1 files changed, 44 insertions(+), 45 deletions(-)
diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h
index f386bc4..72b0cc2 100644
--- a/include/configs/omap3_pandora.h
+++ b/include/configs/omap3_pandora.h
@@ -1,6 +1,6 @@
/*
- * (C) Copyright 2008
- * Grazvydas Ignotas nota...@gmail.com
+ * (C) Copyright 2008-2010
+ * Gražvydas Ignotas nota...@gmail.com
*
* Configuration settings for the OMAP3 Pandora.
*
@@ -59,14 +59,24 @@
* Size of malloc() pool
*/
#define CONFIG_ENV_SIZE(128 10) /* 128 KiB */
- /* Sector */
-#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (128 10))
- /* initial data */
+#define CONFIG_SYS_MALLOC_LEN (1024 * 1024 + CONFIG_ENV_SIZE)
/*
* Hardware drivers
*/
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV 1
+#define CONFIG_SYS_DEVICE_NULLDEV 1
+
+/* USB */
+#define CONFIG_MUSB_UDC1
+#define CONFIG_USB_OMAP3 1
+#define CONFIG_TWL4030_USB 1
+
+/* USB device configuration */
+#define CONFIG_USB_DEVICE 1
+#define CONFIG_USB_TTY 1
+
/*
* NS16550 Configuration
*/
@@ -101,11 +111,11 @@
#define CONFIG_CMD_EXT2/* EXT2 Support */
#define CONFIG_CMD_FAT /* FAT support */
-#define CONFIG_CMD_JFFS2 /* JFFS2 Support*/
#define CONFIG_CMD_I2C /* I2C serial bus support */
#define CONFIG_CMD_MMC /* MMC support */
#define CONFIG_CMD_NAND/* NAND support */
+#define CONFIG_CMD_CACHE /* Cache control*/
#undef CONFIG_CMD_FLASH/* flinfo, erase, protect */
#undef CONFIG_CMD_FPGA /* FPGA configuration Support */
@@ -141,52 +151,41 @@
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */
/* devices */
-#define CONFIG_JFFS2_NAND
-/* nand device jffs2 lives on */
-#define CONFIG_JFFS2_DEV nand0
-/* start of jffs2 partition */
-#define CONFIG_JFFS2_PART_OFFSET 0x68
-#define CONFIG_JFFS2_PART_SIZE 0xf98 /* size of jffs2 */
- /* partition */
+
+#ifdef CONFIG_CMD_NAND
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_MTD_PARTITIONS
+#define CONFIG_MTD_DEVICE
+#define CONFIG_CMD_UBI
+#define CONFIG_CMD_UBIFS
+#define CONFIG_RBTREE
+#define CONFIG_LZO
+
+#define MTDIDS_DEFAULT nand0=nand
+#define MTDPARTS_DEFAULT mtdparts=nand:512k(xloader),\
+ 1920k(uboot),128k(uboot-env),\
+ 10m(boot),-(rootfs)
+#else
+#define MTDPARTS_DEFAULT
+#endif
/* Environment information */
#define CONFIG_BOOTDELAY 1
#define CONFIG_EXTRA_ENV_SETTINGS \
+ usbtty=cdc_acm\0 \
loadaddr=0x8200\0 \
- console=ttyS0,115200n8\0 \
- videospec=omapfb:vram:2M,vram:4M\0 \
- mmcargs=setenv bootargs console=${console} \
- video=${videospec} \
- root=/dev/mmcblk0p2 rw \
- rootfstype=ext3 rootwait\0 \
- nandargs=setenv bootargs console=${console} \
- video=${videospec} \
- root=/dev/mtdblock4 rw \
- rootfstype=jffs2\0 \
- loadbootscript=fatload mmc 0 ${loadaddr} boot.scr\0 \
- bootscript=echo Running bootscript from mmc ...; \
- source ${loadaddr}\0 \
- loaduimage=fatload mmc 0 ${loadaddr} uImage\0 \
- mmcboot=echo Booting from mmc ...; \
- run mmcargs; \
- bootm ${loadaddr}\0 \
- nandboot=echo Booting from nand ...; \
- run nandargs; \
- nand read ${loadaddr} 28 40; \
- bootm ${loadaddr}\0 \
+ bootargs=ubi.mtd=4 ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs \
+ rw rootflags=bulk_read console=ttyS0,115200n8 \
+ vram=6272K omapfb.vram=0:3000K\0 \
+ mtdparts= MTDPARTS_DEFAULT \0 \
#define CONFIG_BOOTCOMMAND \
- if mmc init; then \
- if run loadbootscript; then \
- run bootscript; \
- else \
- if run loaduimage; then \
- run mmcboot; \
- else run nandboot; \
- fi; \
- fi; \
- else run nandboot; fi
+ if mmc init
Re: [U-Boot] patches added to u-boot-ti
On Thu, Nov 4, 2010 at 10:25 PM, Paulraj, Sandeep s-paul...@ti.com wrote: I have added quite a few patches to u-boot-ti but MAKEALL returns several errors. I think most boards have not been updated since the ARM relocation patch. Just sent patches to fix up OMAP3 pandora, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] patches added to u-boot-ti
On Thu, Nov 4, 2010 at 10:25 PM, Paulraj, Sandeep s-paul...@ti.com wrote: I have added quite a few patches to u-boot-ti but MAKEALL returns several errors. I think most boards have not been updated since the ARM relocation patch. Just sent patches to fix up OMAP3 pandora, Thanks, I saw it. I think I can add it to this release itself. Regards, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] OMAP3: pandora: remove unused config macros
Pandora's config has various flash related macros that are either not referenced anywhere in the code or are used by drivers that are not enabled. Remove them. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- Alternatively this old patch can be applied to clean up more OMAP boards: http://lists.denx.de/pipermail/u-boot/2010-April/070860.html Do you think this patch still applies clean? It will be better if you repost to refresh us all. Regards, Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [NEXT] da850evm: Add RMII support for EMAC
From: Sudhakar Rajashekhara sudhakar@ti.com
This patch is a port of the work by Sudhakar Rajeshekhara in commit
ab3effbcad8851cc65dc5241a01c064d2030a3b2 of
git://arago-project.org/git/people/sandeep/u-boot-davinci.git.
The da850 UI board has on it an RMII PHY which can be used if the MDC line
to the MII PHY on the baseboard is disabled and the RMII PHY is enabled by
configuring the values of some GPIO pins on the IO expander of the UI board.
This patch implements disabling that line via GPIO2[6], configuring the UI
board's IO expander and setting only the pinmux settings that are needed for
RMII operation.
Tested on da850evm by adding a define for CONFIG_DRIVER_TI_EMAC_USE_RMII.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Ben Gardiner bengardi...@nanometrics.ca
CC: Sandeep Paulraj s-paul...@ti.com
CC: Ben Warren biggerbadder...@gmail.com
---
Changes since work of Sudhakar Rajashekhar:
* rebased to 0c0892be0d93a5a892b93739c5eb3bf692fed4ff, resolved conflicts.
* fixup uses of pinmux[x] to pinmux(x)
---
arch/arm/include/asm/arch-davinci/hardware.h |4 +
board/davinci/da8xxevm/common.c | 14 +++
board/davinci/da8xxevm/common.h |3 +
board/davinci/da8xxevm/da850evm.c| 112 +-
drivers/net/davinci_emac.c | 41 +-
include/configs/da850evm.h |1 +
6 files changed, 170 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index 3520cf8..da1160a 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -150,6 +150,10 @@ typedef volatile unsigned int *dv_reg_p;
#define DAVINCI_INTC_BASE 0xfffee000
#define DAVINCI_BOOTCFG_BASE 0x01c14000
+#define GPIO_BANK2_REG_DIR_ADDR(DAVINCI_GPIO_BASE +
0x38)
+#define GPIO_BANK2_REG_OPDATA_ADDR (DAVINCI_GPIO_BASE + 0x3c)
+#define GPIO_BANK2_REG_SET_ADDR(DAVINCI_GPIO_BASE +
0x40)
+#define GPIO_BANK2_REG_CLR_ADDR(DAVINCI_GPIO_BASE +
0x44)
#endif /* CONFIG_SOC_DA8XX */
/* Power and Sleep Controller (PSC) Domains */
diff --git a/board/davinci/da8xxevm/common.c b/board/davinci/da8xxevm/common.c
index 9cd5204..b33b877 100644
--- a/board/davinci/da8xxevm/common.c
+++ b/board/davinci/da8xxevm/common.c
@@ -53,3 +53,17 @@ int da8xx_configure_lpsc_items(const struct lpsc_resource
*item,
return 0;
}
+
+#if defined(CONFIG_DRIVER_TI_EMAC) defined(CONFIG_MACH_DAVINCI_DA850_EVM)
+void da850_emac_mii_mode_sel(int mode_sel)
+{
+ int val;
+
+ val = readl(davinci_syscfg_regs-cfgchip3);
+ if (mode_sel == 0)
+ val = ~(1 8);
+ else
+ val |= (1 8);
+ writel(val, davinci_syscfg_regs-cfgchip3);
+}
+#endif
diff --git a/board/davinci/da8xxevm/common.h b/board/davinci/da8xxevm/common.h
index 7ae63a6..8b564f7 100644
--- a/board/davinci/da8xxevm/common.h
+++ b/board/davinci/da8xxevm/common.h
@@ -26,5 +26,8 @@ struct lpsc_resource {
void irq_init(void);
int da8xx_configure_lpsc_items(const struct lpsc_resource *item,
int n_items);
+#if defined(CONFIG_DRIVER_TI_EMAC) defined(CONFIG_MACH_DAVINCI_DA850_EVM)
+void da850_emac_mii_mode_sel(int mode_sel);
+#endif
#endif /* __COMMON_H */
diff --git a/board/davinci/da8xxevm/da850evm.c
b/board/davinci/da8xxevm/da850evm.c
index c8c5e1b..ac96818 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -54,6 +54,15 @@ static const struct pinmux_config uart_pins[] = {
#ifdef CONFIG_DRIVER_TI_EMAC
static const struct pinmux_config emac_pins[] = {
+#ifdef CONFIG_DRIVER_TI_EMAC_USE_RMII
+ { pinmux(14), 8, 2 },
+ { pinmux(14), 8, 3 },
+ { pinmux(14), 8, 4 },
+ { pinmux(14), 8, 5 },
+ { pinmux(14), 8, 6 },
+ { pinmux(14), 8, 7 },
+ { pinmux(15), 8, 1 },
+#else /* ! CONFIG_DRIVER_TI_EMAC_USE_RMII */
{ pinmux(2), 8, 1 },
{ pinmux(2), 8, 2 },
{ pinmux(2), 8, 3 },
@@ -69,10 +78,10 @@ static const struct pinmux_config emac_pins[] = {
{ pinmux(3), 8, 5 },
{ pinmux(3), 8, 6 },
{ pinmux(3), 8, 7 },
+#endif /* CONFIG_DRIVER_TI_EMAC_USE_RMII */
{ pinmux(4), 8, 0 },
{ pinmux(4), 8, 1 }
};
-#endif /* CONFIG_DRIVER_TI_EMAC */
/* I2C pin muxer settings */
static const struct pinmux_config i2c_pins[] = {
@@ -99,6 +108,13 @@ const struct pinmux_config nand_pins[] = {
};
#endif
+#ifdef CONFIG_DRIVER_TI_EMAC_USE_RMII
+#define HAS_RMII 1
+#else
+#define HAS_RMII 0
+#endif
+#endif /* CONFIG_DRIVER_TI_EMAC */
+
static const struct pinmux_resource pinmuxes[] = {
#ifdef CONFIG_SPI_FLASH
PINMUX_ITEM(spi1_pins),
@@ -170,9 +186,8 @@ int board_init(void)
#ifdef CONFIG_DRIVER_TI_EMAC
if
[U-Boot] SALE ENDS TODAY -business, consumer and healthcare email lists
This week only I can sell you ANY individual list below for just $99 or 3 for $249: ( HEALTHCARE ) - Doctors (34 different specialties) - Chiropractors - Alternative Medicine - Dentists - Veterinarians - Hospitals - National Health Service Corp Clinics - Nursing Homes - Pharmaceutical Companies - Physical Therapists - Oncology Doctors - US Surgery Centers - Massage Therapists - Acupuncturists - Medical Equipment Suppliers - Mental Health Counselors - Visiting Nurses RN's - Optometrists - Psychologists ( BUSINESS LISTS ) - Hotels - Real Estate Agents - American Business Email List - US New Business Database - Manufacturers Database - Financial Planners Database - Finance and Money Professionals Database ( CONSUMER LISTS ) - American Consumer Database - Credit Inquiries Database - American Homeowners ( PROFESSIONALS LISTS ) - USA Lawyers Database - Police and Sheriff Services - Criminal Attorneys - 142,906 email me here for counts samples: listprofession...@gmx.com to terminate please send a blank message to takeme...@gmx.com ___ 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
On Fri, Nov 5, 2010 at 12:56 PM, Nishanth Menon menon.nisha...@gmail.com wrote: Folks, I would like to work on the following: Cleanup mux configurations done in OMAP3 and 4 platforms. includes the following: a) have isolate mux configurations per IP configuration, e.g. for EHCI, we have a mux array definition for EHCI etc.. b) remove ALL mux configurations that are not relevant for u-boot functionality - currently we do all muxing in u-boot(including stuff like camera which obviously we dont use in u-boot). any kernel breakages as a result of assumptions of muxing already done is to be fixed in kernel itself - kernel *has* a mux framework for OMAP and platforms files *should* be using that for kernel functionality that they need. no point in carrying that burden in u-boot. I would like to post this patches so that for the next merge window we could pull this in and notify the linux-omap kernel guys to fix their stuff if they depend on u-boot for mux configurations - it is high time they stop being closely tied to U-boot and have capability to deal with other bootloaders which may or maynot have capability for doing muxing - it also saves us to add and maintain mux configurations for linux kernel booting - u-boot is supposed to support multiple operating systems (not just linux kernel). While I understand that you are frustrated with the slow movement in getting the kernel mux cleaned up, I really can't support deliberately breaking systems to force the issue. I don't think it does end users any service to have a u-boot upgrade break their systems. In the end, they are the ones who will be hurt and u-boot will get the blame for causing the breakage. I'd rather see us put the energy into helping get the kernel in shape. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARMV7: Overo: Automatically set clock rate to maximum if mpurate env variable is auto
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.
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
diff --git a/board/overo/overo.c b/board/overo/overo.c
index f917e40..3c9e4a6 100644
--- a/board/overo/overo.c
+++ b/board/overo/overo.c
@@ -281,6 +281,22 @@ int misc_init_r(void)
dieid_num_r();
+ if (strcmp(getenv(mpurate), auto) == 0)
+ switch (get_cpu_family()) {
+ case CPU_OMAP34XX:
+ if ((get_cpu_rev() = CPU_3XX_ES31)
+ (get_sku_id() == SKUID_CLK_720MHZ))
+ setenv(mpurate, 720);
+ else
+ setenv(mpurate, 600);
+ break;
+ case CPU_OMAP36XX:
+ setenv(mpurate, 720);
+ break;
+ default:
+ setenv(mpurate, 500);
+ }
+
return 0;
}
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 79a5b85..dbdfd9a 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -156,7 +156,7 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8200\0 \
console=ttyS2,115200n8\0 \
- mpurate=500\0 \
+ mpurate=auto\0 \
vram=12M\0 \
dvimode=1024x768mr...@60\0 \
defaultdisplay=dvi\0 \
___
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 xM rev B to ID table
On Fri, Nov 5, 2010 at 10:54 AM, Nishanth Menon
menon.nisha...@gmail.com wrote:
Jason Kridner wrote, on 11/05/2010 01:46 AM:
From: Koen Kooik...@dominion.thruhere.net
Patch was updated by Jason Kridnerjkrid...@beagleboard.org:
* Use tabs to match style of other board revisions
* Only include board revisions that exist
* Default to the same configuration as the latest revision, but
without setting 'beaglerev'
Signed-off-by: Jason Kridnerjkrid...@beagleboard.org
not signed-off-by: Koen?
---
board/ti/beagle/beagle.c | 20 +++-
board/ti/beagle/beagle.h | 3 ++-
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c
index 520e57d..93c452e 100644
--- a/board/ti/beagle/beagle.c
+++ b/board/ti/beagle/beagle.c
@@ -176,7 +176,7 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
- case REVISION_XM:
+ case REVISION_XM_A:
printf(Beagle xM Rev A\n);
setenv(beaglerev, xMA);
setenv(mpurate, 1000);
@@ -187,8 +187,26 @@ int misc_init_r(void)
TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
TWL4030_PM_RECEIVER_DEV_GRP_P1);
break;
+ case REVISION_XM_B:
+ printf(Beagle xM Rev B\n);
+ setenv(beaglerev, xMB);
+ setenv(mpurate, 1000);
+ MUX_BEAGLE_XM();
+ /* Set VAUX2 to 1.8V for EHCI PHY */
+ twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
+ TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ TWL4030_PM_RECEIVER_DEV_GRP_P1);
+ break;
default:
printf(Beagle unknown 0x%02x\n, get_board_revision());
+ setenv(mpurate, 1000);
It looks to me looking at the file that mpurate usage is CPU based and
NOT board based.. maybe you should use the cpu idendity to decide on
mpurate instead?
I noticed this too. I just submitted a patch for Overo that sets the
mpurate to the cpu maximum (based on cpu type and version) if the
mpurate environment variable is set to auto
This solves an additional issue: with things as they are now, it is
not possible for a user to set the mpurate to a specific value -- it
will always be overwritten. The scheme above allows the user to set a
specific value or to allow u-boot to set the maximum automatically.
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.
My plan was to submit a similar patch for Beagle.
Steve
+ MUX_BEAGLE_XM();
+ /* Set VAUX2 to 1.8V for EHCI PHY */
+ twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED,
+ TWL4030_PM_RECEIVER_VAUX2_VSEL_18,
+ TWL4030_PM_RECEIVER_VAUX2_DEV_GRP,
+ TWL4030_PM_RECEIVER_DEV_GRP_P1);
}
switch (get_expansion_id()) {
diff --git a/board/ti/beagle/beagle.h b/board/ti/beagle/beagle.h
index 7d8dee0..fa893c4 100644
--- a/board/ti/beagle/beagle.h
+++ b/board/ti/beagle/beagle.h
@@ -37,7 +37,8 @@ const omap3_sysinfo sysinfo = {
#define REVISION_AXBX 0x7
#define REVISION_CX 0x6
#define REVISION_C4 0x5
-#define REVISION_XM 0x0
+#define REVISION_XM_A 0x0
+#define REVISION_XM_B 0x1
/*
* IEN - Input Enable
--
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] ARM: OMAP3/4: proposal: Cleanup MUX
Steve Sakoman wrote, on 11/05/2010 10:47 PM: While I understand that you are frustrated with the slow movement in getting the kernel mux cleaned up, I really can't support deliberately breaking systems to force the issue. I don't think it does end users any service to have a u-boot upgrade break their systems. In the end, they are the ones who will be hurt and u-boot will get the blame for causing the breakage. I'd rather see us put the energy into helping get the kernel in shape. In 2009 July[1], I raised the concern for OMAP3. at that point the fact was we did not have a clean mux framework in kernel. ok great, 2010 Nov now, there is *already* a framework for doing it in kernel upstream today. What rationale is there for OMAP3 beagleboard [1] still do muxing as it does today - we as a community are lazy to clean up our code? What happend as a result? There are linux-products out there which dont use u-boot as bootloader and development non-linux OS's out there which use u-boot as a bootloader - in the case of the linux-products, surprises were found for the upstream kernel depending on u-boot for their muxes and development-OSes found the same mistake when they switched to their native bootloaders at a later point. Why should OMAP4 mux framework not move forward despite two rounds of RFC patches posted[3]? I am not asking this to be done tomorrow, I am asking our community for a deadline - If v2010.12 is too close, fine, then lets schedule it for after v2011.03 tag for example - is'nt 4 months not good enough to get an already existing mux framework upstream in kernel.org for OMAP4? or should OMAP4 products go through the same experience of OMAP3? Conceptually it is simple - a software does just what it is supposed to do - u-boot for OMAP today does way more than it's charter and I personally find it obnoxious! All I am saying is this: we all agree this is messed up, I have an itch, I am willing to do the cleanup as well, just tell me when it is right to do it, I just don't want to deal with crappy code anymore! Ref: [1] http://www.mail-archive.com/u-boot@lists.denx.de/msg17423.html [2] http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/beagle/beagle.h;h=ec0da6d745477437c1c776db7929690e1e568437;hb=HEAD [3] http://marc.info/?l=linux-omapm=12875274693w=2 -- Regards, Nishanth Menon ___ 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 xM rev B to ID table
Steve Sakoman wrote, on 11/05/2010 11:05 PM: On Fri, Nov 5, 2010 at 10:54 AM, Nishanth Menon menon.nisha...@gmail.com wrote: Jason Kridner wrote, on 11/05/2010 01:46 AM: From: Koen Kooik...@dominion.thruhere.net Patch was updated by Jason Kridnerjkrid...@beagleboard.org: * Use tabs to match style of other board revisions * Only include board revisions that exist * Default to the same configuration as the latest revision, but without setting 'beaglerev' Signed-off-by: Jason Kridnerjkrid...@beagleboard.org not signed-off-by: Koen? --- board/ti/beagle/beagle.c | 20 +++- board/ti/beagle/beagle.h |3 ++- 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/board/ti/beagle/beagle.c b/board/ti/beagle/beagle.c index 520e57d..93c452e 100644 --- a/board/ti/beagle/beagle.c +++ b/board/ti/beagle/beagle.c @@ -176,7 +176,7 @@ int misc_init_r(void) TWL4030_PM_RECEIVER_VAUX2_DEV_GRP, TWL4030_PM_RECEIVER_DEV_GRP_P1); break; - case REVISION_XM: + case REVISION_XM_A: printf(Beagle xM Rev A\n); setenv(beaglerev, xMA); setenv(mpurate, 1000); @@ -187,8 +187,26 @@ int misc_init_r(void) TWL4030_PM_RECEIVER_VAUX2_DEV_GRP, TWL4030_PM_RECEIVER_DEV_GRP_P1); break; + case REVISION_XM_B: + printf(Beagle xM Rev B\n); + setenv(beaglerev, xMB); + setenv(mpurate, 1000); + MUX_BEAGLE_XM(); + /* Set VAUX2 to 1.8V for EHCI PHY */ + twl4030_pmrecv_vsel_cfg(TWL4030_PM_RECEIVER_VAUX2_DEDICATED, + TWL4030_PM_RECEIVER_VAUX2_VSEL_18, + TWL4030_PM_RECEIVER_VAUX2_DEV_GRP, + TWL4030_PM_RECEIVER_DEV_GRP_P1); + break; default: printf(Beagle unknown 0x%02x\n, get_board_revision()); + setenv(mpurate, 1000); It looks to me looking at the file that mpurate usage is CPU based and NOT board based.. maybe you should use the cpu idendity to decide on mpurate instead? I noticed this too. I just submitted a patch for Overo that sets the mpurate to the cpu maximum (based on cpu type and version) if the mpurate environment variable is set to auto just for the record, saw this and I liked it :) thanks. This solves an additional issue: with things as they are now, it is not possible for a user to set the mpurate to a specific value -- it will always be overwritten. The scheme above allows the user to set a specific value or to allow u-boot to set the maximum automatically. 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. Errr.. that is not completely true[1](ignoring the lack of upstream DVFS for OMAP3+) - Here is the explanation for it: 36xx family of silicon comes in 4 variants - the ones that support upto 600MHz, ones that do 800MHz, ones that do 1GHz and the ones that do 1.2GHz. the defaults posted upstream enables the least common denominator - 300,600MHz and it leaves it to board files to mention if they have silicon of additional capability- unfortunately, there is no bits that tell the s/w that(for those wondering - yeah s/w folks did try to convince h/w folks for those additional bits.. but after a long debate never succeeded) :( Anyway, to put a long story short - if your board file supports 1GHz, with upstream OPP layer, you do have the flexibility to enable 1GHz OPP - just look at opp_enable[2] usage documentation [3]. I used thermal management as an example here, but no reason why we cant use it as well.. this way, you can infact support cpufreq if you would like to as well. Ref: [1] https://patchwork.kernel.org/patch/266911/ (search for omap36xx_opp_def_list) [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/opp.h;h=5449945d589f994ed5ac25f018ced4a5dc81db30;hb=HEAD#l39 [3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/power/opp.txt;h=44d87ad3cea9fd345a774e196578a0cc8bf4d779;hb=HEAD#l193 -- Regards, Nishanth Menon ___ 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
just a minor crib - $subject length is around 88 characters, it'd look
better with around 50 character length.
Steve Sakoman wrote, on 11/05/2010 10:59 PM:
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.
Signed-off-by: Steve Sakomansteve.sako...@linaro.org
---
diff --git a/board/overo/overo.c b/board/overo/overo.c
index f917e40..3c9e4a6 100644
--- a/board/overo/overo.c
+++ b/board/overo/overo.c
@@ -281,6 +281,22 @@ int misc_init_r(void)
dieid_num_r();
+ if (strcmp(getenv(mpurate), auto) == 0)
+ switch (get_cpu_family()) {
+ case CPU_OMAP34XX:
+ if ((get_cpu_rev()= CPU_3XX_ES31)
+ (get_sku_id() == SKUID_CLK_720MHZ))
+ setenv(mpurate, 720);
+ else
+ setenv(mpurate, 600);
+ break;
+ case CPU_OMAP36XX:
+ setenv(mpurate, 720);
+ break;
+ default:
+ setenv(mpurate, 500);
+ }
+
return 0;
}
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 79a5b85..dbdfd9a 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -156,7 +156,7 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8200\0 \
console=ttyS2,115200n8\0 \
- mpurate=500\0 \
+ mpurate=auto\0 \
vram=12M\0 \
dvimode=1024x768mr...@60\0 \
defaultdisplay=dvi\0 \
yep, this does look like a nice way to do it. thanks.
--
Regards,
Nishanth Menon
___
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
On 11/06/2010 12:00 AM, Nishanth Menon wrote: Steve Sakoman wrote, on 11/05/2010 10:47 PM: While I understand that you are frustrated with the slow movement in getting the kernel mux cleaned up, I really can't support deliberately breaking systems to force the issue. I don't think it does end users any service to have a u-boot upgrade break their systems. In the end, they are the ones who will be hurt and u-boot will get the blame for causing the breakage. I'd rather see us put the energy into helping get the kernel in shape. In 2009 July[1], I raised the concern for OMAP3. at that point the fact was we did not have a clean mux framework in kernel. ok great, 2010 Nov now, there is *already* a framework for doing it in kernel upstream today. What rationale is there for OMAP3 beagleboard [1] still do muxing as it does today - we as a community are lazy to clean up our code? What happend as a result? There are linux-products out there which dont use u-boot as bootloader and development non-linux OS's out there which use u-boot as a bootloader - in the case of the linux-products, surprises were found for the upstream kernel depending on u-boot for their muxes and development-OSes found the same mistake when they switched to their native bootloaders at a later point. Why should OMAP4 mux framework not move forward despite two rounds of RFC patches posted[3]? I am not asking this to be done tomorrow, I am asking our community for a deadline - If v2010.12 is too close, fine, then lets schedule it for after v2011.03 tag for example - is'nt 4 months not good enough to get an already existing mux framework upstream in kernel.org for OMAP4? or should OMAP4 products go through the same experience of OMAP3? Conceptually it is simple - a software does just what it is supposed to do - u-boot for OMAP today does way more than it's charter and I personally find it obnoxious! All I am saying is this: we all agree this is messed up, I have an itch, I am willing to do the cleanup as well, just tell me when it is right to do it, I just don't want to deal with crappy code anymore! Ref: [1] http://www.mail-archive.com/u-boot@lists.denx.de/msg17423.html [2] http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/beagle/beagle.h;h=ec0da6d745477437c1c776db7929690e1e568437;hb=HEAD [3] http://marc.info/?l=linux-omapm=12875274693w=2 Personally I'd like to see the kernel and u-boot disconnect on the pinmux; In my world I have a module with an OMAP35x on it and customers design their own baseboards and use pins as they see fit. We start with a common u-boot and kernel that operates on two SDK boards, and customers design their own baseboards assigning pins to various functions. One customer may want the camera pins as a camera while another uses them for GPIO; u-boot shouldn't care about how the kernel uses the pins, it should just pinmux what it needs(following an approximation): 1) DDR (if not already running in DDR) 2) GPMC for NAND 3) Serial console 4) USB Host (if u-boot is so configured) Then the kernel should configure pins it uses on a registered platform_device basis; i.e. setup the pinmux for that particular platform_device can probe its hardware. Then the kernel can save even more power by leaving unused pins in Mode 7 (i.e. Hi-z) that are not used which saves even more power in suspend. Previously in the OMAP kernel space u-boot was responsible for setting up the pinmux, but with the latest changes, more of the pinmux setup is moving to the kernel and it is time for a complete disconnect, i.e. the kernel must assume that anything it wants to configure needs to have its pinmux setup; yes there will be a period of pain, but its a lot easier to break the assumption than keep providing one -- Peter Barada pet...@logicpd.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
