Re: [U-Boot] RFC: split ARM repo and distribute workload
Dear Wolfgang, Wolfgang Denk wrote: Texas Instruments (OMAP): Dirk Behme? Or are there any volunteers at TI? I really like to see someone from TI here, instead. Looking at some past discussions, I think somebody from TI would be the best. E.g.: - While discussing the board/vendor directory change, we were unsure who might be the vendor of which board. Somebody from TI would know best. - While discussing the OMAP3 cache move, we were unsure what's about the ROM code calling and where/when this is necessary. Someone from TI would know best, too. - etc, etc. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MCI support for AT91 family processors.
Oh ... I had a more recent patch, but looks like it didn't make it to the list. It already fixes a large parts of your comments. Thanks for the review please use MCI0_BASE and MCI1_BASE so we can detect if the soc support multiple mci and please move it to soc header I'll send a patch to clean the other I'm not sure what other you're talking about Regards, -- Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] boot linux data aboot for S3C2440A
fluke56512 wrote: mini2440 is not cheap for a student in my country. 2009-09-05 I just want to say sorry for this mistake Cheers, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AT91: Add support for blue_LED_* and add coloured_LED_init to at91/led.c
On Sat, 05 Sep 2009 01:47 +0200, Jean-Christophe PLAGNIOL-VILLARD wrote :
On 10:36 Thu 20 Aug , Albin Tonnerre wrote:
On Thu, Aug 20, 2009 at 02:00:45AM +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote :
On 10:49 Tue 18 Aug , Albin Tonnerre wrote:
On Tue, Aug 18, 2009 at 12:51:48AM +0200, Jean-Christophe
PLAGNIOL-VILLARD wrote :
no please take a look on the other LED thread
Would you please provide a pointer to this thread ? THe only one
remotely
related I can find is
http://lists.denx.de/pipermail/u-boot/2009-May/052160.html, and you did
not
participate in this one ...
I've as I'm the one who ask Daniel Gorsulowski to base his new code (this
patch)
against Ulf precedent patch and as other people have done the same
comment as I will do
no need to repeat it
Ok, so I'm really confused now. This patch does exactly what you're arguing
against in the rest of your mail, and you still don't provide a pointer to
Ulf's
patch.
Would you mind *explaining* to me what your plan is? I just can't get it.
something like this for assembly
.macro set_led \num, \state
call (c or assembly) set_led_state num state
.endm
.macore set_led_red \state
call (c or assembly) set_led_state CONFIG_SYS_LED_RED state
.endm
and for c
void set_led(int num, int state)
{
}
void set_reg_led(int state)
{
set_led(CONFIG_SYS_LED_RED, state);
}
etc... for all colour
Ok. So what about implementing the current, existing LED API ?
you'd get:
void status_led_set (int led, int state);
that sound a lot like your set_led function. And then
status_led_set(STATUS_LED_{YELLOW,BLUE,RED}, state)
which is basically the same as your set_reg_led?
Cheers,
--
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MCI support for AT91 family processors.
On 11:03 Sat 05 Sep , Albin Tonnerre wrote: Oh ... I had a more recent patch, but looks like it didn't make it to the list. It already fixes a large parts of your comments. Thanks for the review please use MCI0_BASE and MCI1_BASE so we can detect if the soc support multiple mci and please move it to soc header I'll send a patch to clean the other I'm not sure what other you're talking about take a look in the atmel_spi driver the number of MCI will be detected depending on the MCIx_BASE declared in the soc header Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4]: bitops cleanup and fixes
On 22:14 Fri 04 Sep , Wolfgang Denk wrote: Dear Simon Kagstrom, In message 20090831113210.02299...@marrow.netinsight.se you wrote: On Mon, 24 Aug 2009 09:06:05 +0200 Simon Kagstrom simon.kagst...@netinsight.net wrote: This update to the patch series just cleans up the commit messages to have the comments in the git comments section. Sorry to ping you all, but are there any more comments on work to be done before this patch series can be accepted? The patches were these: [PATCH v4 1/4]: Move __set/clear_bit from ubifs.h to bitops.h [PATCH v4 2/4]: arm: Make arm bitops endianness-independent [PATCH v4 3/4]: Define ffs/fls for all architectures [PATCH v4 4/4]: arm: Define test_and_set_bit and test_and_clear bit for ARM I think we're just waiting for an ARM custodian to pick this up. I've already ack the patches at the V2 version so I wait other arch Maintainer comment as it will impact everyone Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91: move base address define to soc header
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com --- include/asm-arm/arch-at91/at91cap9.h|4 include/asm-arm/arch-at91/at91sam9260.h |4 include/asm-arm/arch-at91/at91sam9261.h |3 +++ include/asm-arm/arch-at91/at91sam9263.h |4 include/asm-arm/arch-at91/at91sam9g45.h |5 + include/asm-arm/arch-at91/at91sam9rl.h |3 +++ include/asm-arm/arch-at91/hardware.h| 18 -- 7 files changed, 23 insertions(+), 18 deletions(-) diff --git a/include/asm-arm/arch-at91/at91cap9.h b/include/asm-arm/arch-at91/at91cap9.h index b128ac5..98bfcc7 100644 --- a/include/asm-arm/arch-at91/at91cap9.h +++ b/include/asm-arm/arch-at91/at91cap9.h @@ -109,6 +109,10 @@ #define AT91_USART1AT91CAP9_BASE_US1 #define AT91_USART2AT91CAP9_BASE_US2 +#define AT91_BASE_SPI AT91CAP9_BASE_SPI0 +#define AT91_ID_UHPAT91CAP9_ID_UHP +#define AT91_PMC_UHP AT91CAP9_PMC_UHP + /* * SCKCR flags */ diff --git a/include/asm-arm/arch-at91/at91sam9260.h b/include/asm-arm/arch-at91/at91sam9260.h index 73975f4..f2aef8a 100644 --- a/include/asm-arm/arch-at91/at91sam9260.h +++ b/include/asm-arm/arch-at91/at91sam9260.h @@ -105,6 +105,10 @@ #define AT91_USART4AT91SAM9260_BASE_US4 #define AT91_USART5AT91SAM9260_BASE_US5 +#define AT91_BASE_SPI AT91SAM9260_BASE_SPI0 +#define AT91_ID_UHPAT91SAM9260_ID_UHP +#define AT91_PMC_UHP AT91SAM926x_PMC_UHP + /* * Internal Memory. */ diff --git a/include/asm-arm/arch-at91/at91sam9261.h b/include/asm-arm/arch-at91/at91sam9261.h index b303e07..55bd49a 100644 --- a/include/asm-arm/arch-at91/at91sam9261.h +++ b/include/asm-arm/arch-at91/at91sam9261.h @@ -88,6 +88,9 @@ #define AT91_USART1AT91SAM9261_BASE_US1 #define AT91_USART2AT91SAM9261_BASE_US2 +#define AT91_BASE_SPI AT91SAM9261_BASE_SPI0 +#define AT91_ID_UHPAT91SAM9261_ID_UHP +#define AT91_PMC_UHP AT91SAM926x_PMC_UHP /* * Internal Memory. diff --git a/include/asm-arm/arch-at91/at91sam9263.h b/include/asm-arm/arch-at91/at91sam9263.h index 966a683..d862129 100644 --- a/include/asm-arm/arch-at91/at91sam9263.h +++ b/include/asm-arm/arch-at91/at91sam9263.h @@ -108,6 +108,10 @@ #define AT91_SMC AT91_SMC0 #define AT91_SDRAMCAT91_SDRAMC0 +#define AT91_BASE_SPI AT91SAM9263_BASE_SPI0 +#define AT91_ID_UHPAT91SAM9263_ID_UHP +#define AT91_PMC_UHP AT91SAM926x_PMC_UHP + /* * Internal Memory. */ diff --git a/include/asm-arm/arch-at91/at91sam9g45.h b/include/asm-arm/arch-at91/at91sam9g45.h index 0feed9c..d02b157 100644 --- a/include/asm-arm/arch-at91/at91sam9g45.h +++ b/include/asm-arm/arch-at91/at91sam9g45.h @@ -114,6 +114,11 @@ #define AT91_USART2AT91SAM9G45_BASE_US2 #define AT91_USART3AT91SAM9G45_BASE_US3 +#define AT91_BASE_EMAC AT91SAM9G45_BASE_EMAC +#define AT91_BASE_SPI AT91SAM9G45_BASE_SPI0 +#define AT91_ID_UHPAT91SAM9G45_ID_UHPHS +#define AT91_PMC_UHP AT91SAM926x_PMC_UHP + /* * Internal Memory. */ diff --git a/include/asm-arm/arch-at91/at91sam9rl.h b/include/asm-arm/arch-at91/at91sam9rl.h index 4dd8037..3638f92 100644 --- a/include/asm-arm/arch-at91/at91sam9rl.h +++ b/include/asm-arm/arch-at91/at91sam9rl.h @@ -99,6 +99,9 @@ #define AT91_USART2AT91SAM9RL_BASE_US2 #define AT91_USART3AT91SAM9RL_BASE_US3 +#define AT91_BASE_SPI AT91SAM9RL_BASE_SPI +#define AT91_ID_UHPAT91SAM9RL_ID_UHP + /* * Internal Memory. diff --git a/include/asm-arm/arch-at91/hardware.h b/include/asm-arm/arch-at91/hardware.h index de06a10..56fbf04 100644 --- a/include/asm-arm/arch-at91/hardware.h +++ b/include/asm-arm/arch-at91/hardware.h @@ -20,34 +20,16 @@ #include asm/arch/at91rm9200.h #elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9G20) #include asm/arch/at91sam9260.h -#define AT91_BASE_SPI AT91SAM9260_BASE_SPI0 -#define AT91_ID_UHPAT91SAM9260_ID_UHP -#define AT91_PMC_UHP AT91SAM926x_PMC_UHP #elif defined(CONFIG_AT91SAM9261) || defined(CONFIG_AT91SAM9G10) #include asm/arch/at91sam9261.h -#define AT91_BASE_SPI AT91SAM9261_BASE_SPI0 -#define AT91_ID_UHPAT91SAM9261_ID_UHP -#define AT91_PMC_UHP AT91SAM926x_PMC_UHP #elif defined(CONFIG_AT91SAM9263) #include asm/arch/at91sam9263.h -#define AT91_BASE_SPI AT91SAM9263_BASE_SPI0 -#define AT91_ID_UHPAT91SAM9263_ID_UHP -#define AT91_PMC_UHP AT91SAM926x_PMC_UHP #elif defined(CONFIG_AT91SAM9RL) #include asm/arch/at91sam9rl.h -#define AT91_BASE_SPI AT91SAM9RL_BASE_SPI -#define AT91_ID_UHPAT91SAM9RL_ID_UHP #elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) #include asm/arch/at91sam9g45.h -#define AT91_BASE_EMAC AT91SAM9G45_BASE_EMAC -#define AT91_BASE_SPI AT91SAM9G45_BASE_SPI0 -#define AT91_ID_UHP AT91SAM9G45_ID_UHPHS -#define AT91_PMC_UHPAT91SAM926x_PMC_UHP #elif defined(CONFIG_AT91CAP9) #include asm/arch/at91cap9.h -#define AT91_BASE_SPI AT91CAP9_BASE_SPI0 -#define AT91_ID_UHPAT91CAP9_ID_UHP -#define AT91_PMC_UHP AT91CAP9_PMC_UHP #elif defined(CONFIG_AT91X40)
[U-Boot] [PATCH v2] AT91: Add SD/MMC controller support
This patch allows to use the atmel_mci SD/MMC driver on the at91 architecture.
It contains:
- initialization code for the MCI controller for all the supported AT91. It
allows the use of only one controller even if a SoC has two controllers
(anyway there's no support for it in atmel_mci as of now)
- the necessary get_mci_clk_rate function
- definition of MMCI_BASE for use in atmel_mci
- the cpu_mmc_init function. As of now this is not used, but will be required
when atmel_mci is ported to the new generic mmc API.
Signed-off-by: Albin Tonnerre albin.tonne...@free-electrons.com
---
Changes since v1
(http://lists.denx.de/pipermail/u-boot/2009-September/059665.html):
- Fix the MCI controller ID in the init code for CAP9, SAM9263 and SAM9G45
- Move AT91_BASE_MCI* define to soc header
- define AT91_BASE_MCI{0,1} instead of AT91_BASE_MCI for boards which have 2
controllers
- rework the way MMCI_BASE is defined accordingly
Note: I am fully aware that MMCI0_BASE and MMCI1_BASE should be defined, instead
of MMCI_BASE. However, I'd rather wait until the patch that switches atmel_mci
to the generic mmc API is accepted, as it will be easier to do it then.
cpu/arm926ejs/at91/at91cap9_devices.c | 37 ++
cpu/arm926ejs/at91/at91sam9260_devices.c| 27 +
cpu/arm926ejs/at91/at91sam9261_devices.c| 18 +
cpu/arm926ejs/at91/at91sam9263_devices.c| 55 +++
cpu/arm926ejs/at91/at91sam9m10g45_devices.c | 55 +++
cpu/arm926ejs/at91/at91sam9rl_devices.c | 22 +++
cpu/arm926ejs/at91/cpu.c|7 +++
include/asm-arm/arch-at91/at91_common.h |2 +
include/asm-arm/arch-at91/at91cap9.h|3 +
include/asm-arm/arch-at91/at91sam9260.h |2 +
include/asm-arm/arch-at91/at91sam9261.h |1 +
include/asm-arm/arch-at91/at91sam9263.h |3 +
include/asm-arm/arch-at91/at91sam9g45.h |3 +
include/asm-arm/arch-at91/at91sam9rl.h |1 +
include/asm-arm/arch-at91/clk.h |5 ++
include/asm-arm/arch-at91/memory-map.h |6 +++
16 files changed, 247 insertions(+), 0 deletions(-)
diff --git a/cpu/arm926ejs/at91/at91cap9_devices.c
b/cpu/arm926ejs/at91/at91cap9_devices.c
index 39e405f..53a58a9 100644
--- a/cpu/arm926ejs/at91/at91cap9_devices.c
+++ b/cpu/arm926ejs/at91/at91cap9_devices.c
@@ -79,6 +79,43 @@ void at91_serial_hw_init(void)
#endif
}
+#ifdef CONFIG_ATMEL_MCI
+#ifdef CONFIG_AT91_MCI0
+void at91_mci0_hw_init(unsigned long mask)
+{
+ at91_sys_write(AT91_PMC_PCER, 1 AT91CAP9_ID_MCI0);
+ at91_set_A_periph(AT91_PIN_PA2, 0);
+
+ if (mask (1 0)) {
+ at91_set_A_periph(AT91_PIN_PA0, 1);
+ at91_set_A_periph(AT91_PIN_PA1, 1);
+ if (mask (1 1)) {
+ at91_set_A_periph(AT91_PIN_PA3, 1);
+ at91_set_A_periph(AT91_PIN_PA4, 1);
+ at91_set_A_periph(AT91_PIN_PA5, 1);
+ }
+ }
+}
+#endif
+#ifdef CONFIG_AT91_MCI1
+void at91_mci1_hw_init(unsigned long mask)
+{
+ at91_sys_write(AT91_PMC_PCER, 1 AT91CAP9_ID_MCI1);
+ at91_set_A_periph(AT91_PIN_PA16, 0);
+
+ if (mask (1 0)) {
+ at91_set_A_periph(AT91_PIN_PA17, 1);
+ at91_set_A_periph(AT91_PIN_PA18, 1);
+ if (mask (1 1)) {
+ at91_set_A_periph(AT91_PIN_PA19, 1);
+ at91_set_A_periph(AT91_PIN_PA20, 1);
+ at91_set_A_periph(AT91_PIN_PA21, 1);
+ }
+ }
+}
+#endif
+#endif
+
#ifdef CONFIG_HAS_DATAFLASH
void at91_spi0_hw_init(unsigned long cs_mask)
{
diff --git a/cpu/arm926ejs/at91/at91sam9260_devices.c
b/cpu/arm926ejs/at91/at91sam9260_devices.c
index f86cb99..ea22030 100644
--- a/cpu/arm926ejs/at91/at91sam9260_devices.c
+++ b/cpu/arm926ejs/at91/at91sam9260_devices.c
@@ -75,6 +75,33 @@ void at91_serial_hw_init(void)
#endif
}
+#ifdef CONFIG_ATMEL_MCI
+void at91_mci0_hw_init(unsigned long mask)
+{
+ at91_sys_write(AT91_PMC_PCER, 1 AT91SAM9260_ID_MCI);
+ at91_set_A_periph(AT91_PIN_PA8, 0);
+
+ if (mask (1 0)) {
+ at91_set_A_periph(AT91_PIN_PA6, 1);
+ at91_set_A_periph(AT91_PIN_PA7, 1);
+ if (mask (1 1)) {
+ at91_set_A_periph(AT91_PIN_PA9, 1);
+ at91_set_A_periph(AT91_PIN_PA10, 1);
+ at91_set_A_periph(AT91_PIN_PA11, 1);
+ }
+ }
+ if (mask (1 2)) {
+ at91_set_B_periph(AT91_PIN_PA0, 1);
+ at91_set_B_periph(AT91_PIN_PA1, 1);
+ if (mask (1 3)) {
+ at91_set_B_periph(AT91_PIN_PA3, 1);
+ at91_set_B_periph(AT91_PIN_PA4, 1);
+ at91_set_B_periph(AT91_PIN_PA5, 1);
+ }
+ }
+}
+#endif /* ATMEL_MCI */
+
#if
Re: [U-Boot] [PATCH] AT91: Add support for blue_LED_* and add coloured_LED_init to at91/led.c
On 13:20 Sat 05 Sep , Albin Tonnerre wrote:
On Sat, 05 Sep 2009 01:47 +0200, Jean-Christophe PLAGNIOL-VILLARD wrote :
On 10:36 Thu 20 Aug , Albin Tonnerre wrote:
On Thu, Aug 20, 2009 at 02:00:45AM +0200, Jean-Christophe
PLAGNIOL-VILLARD wrote :
On 10:49 Tue 18 Aug , Albin Tonnerre wrote:
On Tue, Aug 18, 2009 at 12:51:48AM +0200, Jean-Christophe
PLAGNIOL-VILLARD wrote :
no please take a look on the other LED thread
Would you please provide a pointer to this thread ? THe only one
remotely
related I can find is
http://lists.denx.de/pipermail/u-boot/2009-May/052160.html, and you
did not
participate in this one ...
I've as I'm the one who ask Daniel Gorsulowski to base his new code
(this patch)
against Ulf precedent patch and as other people have done the same
comment as I will do
no need to repeat it
Ok, so I'm really confused now. This patch does exactly what you're
arguing
against in the rest of your mail, and you still don't provide a pointer
to Ulf's
patch.
Would you mind *explaining* to me what your plan is? I just can't get it.
something like this for assembly
.macro set_led \num, \state
call (c or assembly) set_led_state num state
.endm
.macore set_led_red \state
call (c or assembly) set_led_state CONFIG_SYS_LED_RED state
.endm
and for c
void set_led(int num, int state)
{
}
void set_reg_led(int state)
{
set_led(CONFIG_SYS_LED_RED, state);
}
etc... for all colour
Ok. So what about implementing the current, existing LED API ?
you'd get:
void status_led_set (int led, int state);
that sound a lot like your set_led function. And then
status_led_set(STATUS_LED_{YELLOW,BLUE,RED}, state)
which is basically the same as your set_reg_led?
so you use this one instead
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] fsl: add register read-back to set_law()
On Fri, Sep 4, 2009 at 5:05 PM, Timur Tabiti...@freescale.com wrote: After programming a new LAW, we should read-back the LAWAR register so that we sync the writes. Otherwise, code that attempts to use the new LAW-mapped memory might fail. This should say, code that attempts to use the new LAW-mapped memory right away might fail. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM Pull Request
On 07:37 Sat 05 Sep , Dirk Behme wrote: Dear Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: Hi, Please pull The following changes since commit 3aa8b68d80dbcb6829af60485c1e388b39af793d: Wolfgang Denk (1): Merge branch 'next' of ../next are available in the git repository at: git://git.denx.de/u-boot-arm.git master Albin Tonnerre (3): at91sam9260/afeb9260: Fix SPI initialization Add support for the Calao SBC35-A9G20 board Support for the Calao TNY-A9260/TNY-A9G20 boards Frederik Kriewitz (1): Add support for the DevKit8000 board I'd like to have the omap3_devkit8000.h version of that patch, instead. this one is fine no need not the omap3_devkit8000 version Additionally, http://lists.denx.de/pipermail/u-boot/2009-August/058492.html as I said now more than 10 times on omap3 we can use the generic ARMV7 cache code as on Samsung Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards
This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and
s3c2410 cpu's which fixes various problems such as the timeouts in tftp being
too short.
Tested on an Embest SBC2440-II Board with local u-boot patches as I don't
have any s3c2400 or s3c2410 boards but need this patch applying before I can
submit patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets
and no new warnings or errors were found.
It was originally submitted on 21/06/2009 but didn't get into the 2009.08
release, and Jean-Pierre made one comment on the original patch (see
http://lists.denx.de/pipermail/u-boot/2009-July/055470.html). I've made two
changes to the original patch:
- it's been re-based to the current release
- I've re-named get_timer_raw() to get_ticks() in response to Jean-Pierre's
comment
This affects the sbc2410, smdk2400, smdk2410 and trab boards. I've copied it
directly to the maintainers of all except the sbc2410 which doesn't have an
entry in MAINTAINERS.
Signed-off-by: Kevin Morfitt kmorf...@aselaptop-1.localdomain
---
cpu/arm920t/s3c24x0/timer.c | 36
include/configs/sbc2410x.h |4 +---
include/configs/smdk2400.h |4 +---
include/configs/smdk2410.h |4 +---
include/configs/trab.h | 12 +---
5 files changed, 24 insertions(+), 36 deletions(-)
diff --git a/cpu/arm920t/s3c24x0/timer.c b/cpu/arm920t/s3c24x0/timer.c
index c8c7cdb..db472bf 100644
--- a/cpu/arm920t/s3c24x0/timer.c
+++ b/cpu/arm920t/s3c24x0/timer.c
@@ -39,6 +39,7 @@
#endif
int timer_load_val = 0;
+static ulong timer_clk;
/* macro to read the 16 bit timer */
static inline ulong READ_TIMER(void)
@@ -66,6 +67,7 @@ int timer_init (void)
* @33.25MHz and 15625 @ 50 MHz
*/
timer_load_val = get_PCLK()/(2 * 16 * 100);
+ timer_clk = get_PCLK() / (2 * 16);
}
/* load value for 10 ms timeout */
lastdec = timers-TCNTB4 = timer_load_val;
@@ -100,13 +102,13 @@ void set_timer (ulong t)
void udelay (unsigned long usec)
{
ulong tmo;
- ulong start = get_timer(0);
+ ulong start = get_ticks();
tmo = usec / 1000;
tmo *= (timer_load_val * 100);
tmo /= 1000;
- while ((ulong)(get_timer_masked () - start) tmo)
+ while ((ulong) (get_ticks() - start) tmo)
/*NOP*/;
}
@@ -119,18 +121,9 @@ void reset_timer_masked (void)
ulong get_timer_masked (void)
{
- ulong now = READ_TIMER();
-
- if (lastdec = now) {
- /* normal mode */
- timestamp += lastdec - now;
- } else {
- /* we have an overflow ... */
- timestamp += lastdec + timer_load_val - now;
- }
- lastdec = now;
+ ulong tmr = get_ticks();
- return timestamp;
+ return tmr / (timer_clk / CONFIG_SYS_HZ);
}
void udelay_masked (unsigned long usec)
@@ -148,10 +141,10 @@ void udelay_masked (unsigned long usec)
tmo /= (1000*1000);
}
- endtime = get_timer_masked () + tmo;
+ endtime = get_ticks() + tmo;
do {
- ulong now = get_timer_masked ();
+ ulong now = get_ticks();
diff = endtime - now;
} while (diff = 0);
}
@@ -162,7 +155,18 @@ void udelay_masked (unsigned long usec)
*/
unsigned long long get_ticks(void)
{
- return get_timer(0);
+ ulong now = READ_TIMER();
+
+ if (lastdec = now) {
+ /* normal mode */
+ timestamp += lastdec - now;
+ } else {
+ /* we have an overflow ... */
+ timestamp += lastdec + timer_load_val - now;
+ }
+ lastdec = now;
+
+ return timestamp;
}
/*
diff --git a/include/configs/sbc2410x.h b/include/configs/sbc2410x.h
index f2ea926..e6886cf 100644
--- a/include/configs/sbc2410x.h
+++ b/include/configs/sbc2410x.h
@@ -139,9 +139,7 @@
#defineCONFIG_SYS_LOAD_ADDR0x3300 /* default load
address */
-/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
-/* it to wrap 100 times (total 1562500) to get 1 sec. */
-#defineCONFIG_SYS_HZ 1562500
+#defineCONFIG_SYS_HZ 1000
/* valid baudrates */
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 }
diff --git a/include/configs/smdk2400.h b/include/configs/smdk2400.h
index c234177..a1beb65 100644
--- a/include/configs/smdk2400.h
+++ b/include/configs/smdk2400.h
@@ -141,9 +141,7 @@
#defineCONFIG_SYS_LOAD_ADDR0x0cf0 /* default load
address */
-/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */
-/* it to wrap 100 times (total 1562500) to get 1 sec. */
-#defineCONFIG_SYS_HZ 1562500
+#defineCONFIG_SYS_HZ 1000
/* valid baudrates */
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400,
[U-Boot] s3c24x0 code changes
I submitted patches in the last merge window to add support for the Embest SBC2440-II Board but ran out of time to deal with all of the comments on the patches. Because it was a series of 7 patches comments on the early patches in the series meant I had to re-work all other patches. I'd like to try again in this merge window but do it in stages, waiting until the patches of each stage get accepted before starting the next stage. The stages would be: 1. re-format the existing s3c24x0 code to meet the u-boot code style guidelines 2. add support for the s3c2440 cpu 3. add support for the Embest SBC2440-II Board I'm aware that other changes are required to the s3c24x0 code such as moving all driver code to the drivers directory, using a shared start.S for all s3c24x0 cpu's, and cleaning up the #ifdef's that check which s3c24x0 cpu we're building for, and I could do these and/or other changes before step 3 if anyone would prefer. I guess that when a dedicated Samsung SoC custodian starts work they may have other ideas as well. I'm more concerned to make it manageable than to get the SBC2440-II supported quickly. Anyway, the code style changes in the original patch generated a few comments so I thought I'd describe what I intend to do in case anyone has any comments before I submit the patches. My plan is to make the following changes: - run Lindent -kr -i8 -l80 on all s3c24x0 code then manually clean up the resulting files - change the existing S3C24X0 register struct's to use lower case names instead of upper case names - make the code use the readx/writex access functions - submit the s3c24x0 NAND driver changes as a separate patch Is there anything else anyone would like to see done in the code style changes? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add support for Eukrea CPU9260/CPU9G20 SBC
these boards are built around Atmel's AT91SAM9260/9G20 and have up to 64MB of NOR flash, up to 128MB of SDRAM, up to 2GB of NAND and include a 10/100 Ethernet PHY in RMII mode. Signed-off-by: Eric Benard e...@eukrea.com --- MAINTAINERS|5 + MAKEALL|2 + Makefile |8 + board/eukrea/cpu9260/Makefile | 59 + board/eukrea/cpu9260/config.mk |1 + board/eukrea/cpu9260/cpu9260.c | 218 + board/eukrea/cpu9260/led.c | 153 cpu/arm926ejs/at91/lowlevel_init.S |3 +- include/configs/cpu9260.h | 453 9 files changed, 901 insertions(+), 1 deletions(-) create mode 100644 board/eukrea/cpu9260/Makefile create mode 100644 board/eukrea/cpu9260/config.mk create mode 100644 board/eukrea/cpu9260/cpu9260.c create mode 100644 board/eukrea/cpu9260/led.c create mode 100644 include/configs/cpu9260.h diff --git a/MAINTAINERS b/MAINTAINERS index d674753..4b961b1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -525,6 +525,11 @@ Dirk Behme dirk.be...@gmail.com omap3_beagleARM CORTEX-A8 (OMAP3530 SoC) +Eric Benard e...@eukrea.com + + cpu9260 ARM926EJS (AT91SAM9260 SoC) + cpu9G20 ARM926EJS (AT91SAM9G20 SoC) + Rishi Bhattacharya ri...@ti.com omap5912osk ARM926EJS diff --git a/MAKEALL b/MAKEALL index 85f99ef..7a438f7 100755 --- a/MAKEALL +++ b/MAKEALL @@ -605,6 +605,8 @@ LIST_at91= \ at91sam9m10g45ek\ at91sam9rlek\ cmc_pu2 \ + CPU9260 \ + CPU9G20 \ csb637 \ kb9202 \ meesc \ diff --git a/Makefile b/Makefile index dd01b66..1d1ded4 100644 --- a/Makefile +++ b/Makefile @@ -2863,6 +2863,14 @@ at91sam9rlek_config : unconfig fi; @$(MKCONFIG) -a at91sam9rlek arm arm926ejs at91sam9rlek atmel at91 +CPU9G20_128M_config \ +CPU9G20_config \ +CPU9260_128M_config \ +CPU9260_config : unconfig + @mkdir -p $(obj)include + @echo #define CONFIG_$(@:_config=) 1 $(obj)include/config.h + @$(MKCONFIG) -a cpu9260 arm arm926ejs cpu9260 eukrea at91 + meesc_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91 diff --git a/board/eukrea/cpu9260/Makefile b/board/eukrea/cpu9260/Makefile new file mode 100644 index 000..a718014 --- /dev/null +++ b/board/eukrea/cpu9260/Makefile @@ -0,0 +1,59 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop stelian@leadtechdesign.com +# Lead Tech Design www.leadtechdesign.com +# Ilko Iliev www.ronetix.at +# +# (C) Copyright 2009 +# Eric Benard e...@eukrea.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS-y += $(BOARD).o +COBJS-y += led.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y) $(SOBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/eukrea/cpu9260/config.mk b/board/eukrea/cpu9260/config.mk new file mode 100644 index 000..9ce161e --- /dev/null +++ b/board/eukrea/cpu9260/config.mk @@ -0,0 +1 @@ +TEXT_BASE = 0x21f0 diff --git a/board/eukrea/cpu9260/cpu9260.c b/board/eukrea/cpu9260/cpu9260.c new file mode 100644 index 000..cff4a63 --- /dev/null +++ b/board/eukrea/cpu9260/cpu9260.c @@ -0,0 +1,218 @@ +/* + * (C) Copyright 2007-2008 + * Stelian Pop stelian@leadtechdesign.com + * Lead Tech Design www.leadtechdesign.com + * Ilko Iliev www.ronetix.at + * + * (C) Copyright 2009 + * Eric Benard e...@eukrea.com + * + * See
Re: [U-Boot] [PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards
On 16:33 Sat 05 Sep , kevin.morf...@fearnside-systems.co.uk wrote: This sets CONFIG_SYS_HZ to 1000 for all boards that use the s3c2400 and s3c2410 cpu's which fixes various problems such as the timeouts in tftp being too short. Tested on an Embest SBC2440-II Board with local u-boot patches as I don't have any s3c2400 or s3c2410 boards but need this patch applying before I can submit patches for the SBC2440-II Board. Also, ran MAKEALL for all ARM9 targets and no new warnings or errors were found. It was originally submitted on 21/06/2009 but didn't get into the 2009.08 release, and Jean-Pierre made one comment on the original patch (see http://lists.denx.de/pipermail/u-boot/2009-July/055470.html). I've made two changes to the original patch: - it's been re-based to the current release - I've re-named get_timer_raw() to get_ticks() in response to Jean-Pierre's comment This affects the sbc2410, smdk2400, smdk2410 and trab boards. I've copied it directly to the maintainers of all except the sbc2410 which doesn't have an entry in MAINTAINERS. Signed-off-by: Kevin Morfitt kmorf...@aselaptop-1.localdomain --- cpu/arm920t/s3c24x0/timer.c | 36 include/configs/sbc2410x.h |4 +--- include/configs/smdk2400.h |4 +--- include/configs/smdk2410.h |4 +--- include/configs/trab.h | 12 +--- 5 files changed, 24 insertions(+), 36 deletions(-) Need to be test on trab or other but looks fine Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is there any full story about how to take advantage FDT function ?
Gao Ya'nan wrote: And how to configure the kernel to minimize the code modification ? I am porting U-Boot and Linux to a new board with a MPC875 processor and two serial chips, and U-Boot runs well now. I hear that the FDT function can tell the kernel devices information more flexibly and reduce the code modification indirectly. But I didn't find enough materials to make my head clear, so any tip is greatly appreciated. Thanks. Hi Gao, I'm not up on 8xx, but it may not have been pulled forward into the powerpc architecture (still ppc). The powerpc architecture switch is where linux/u-boot started using the FDT. Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Is there any full story about how to take advantage FDT function ?
Hi, Jerry. 2009/9/6 Jerry Van Baren gvb.ub...@gmail.com: Gao Ya'nan wrote: And how to configure the kernel to minimize the code modification ? I am porting U-Boot and Linux to a new board with a MPC875 processor and two serial chips, and U-Boot runs well now. I hear that the FDT function can tell the kernel devices information more flexibly and reduce the code modification indirectly. But I didn't find enough materials to make my head clear, so any tip is greatly appreciated. Thanks. Hi Gao, I'm not up on 8xx, but it may not have been pulled forward into the powerpc architecture (still ppc). The powerpc architecture switch is where linux/u-boot started using the FDT. I use U-Boot-V2009.8 and Linux-DENX-v2.6.30.3, and I can't find arch/ppc any more. So, I think FDT will work well in MPC8xx platform. But I don't know how to use it, perhaps I shoud try the standard MPC885 configuration and dtb file. Best regards, gvb Thanks. Best regards Gao Ya'nan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
