Re: [U-Boot-Users] [U-Boot] ARM / PXA unapplied patches

support for Freescale's i.M > 6209 08/20 "Gururaja Hebbar Would like to know the status of the Patches > 6407 08/23 Dirk Behme [U-Boot] [PATCH] ARM: Update mach-types.h I wonder if there are any news on this? Having this not applied locks us from sending our OMAP3 patch

Re: [U-Boot-Users] [Patch 00/17] U-Boot-V2: Support for OMAP3 and SDP3430

I thank Dirk for guiding me on creation of patches, Laurent for pointing out > the dcache issue in my first rev and lots of folks for writing the initial > code. The complete series (all 17 patches): Acked-by: Dirk Behme <[EMAIL PROTECTED]> Dirk --

[U-Boot-Users] [PATCH] Fix warning in env_nand.c if compiled for DaVinci Schmoogie

ompatible pointer type if compiled for davinci_schmoogie_config. Signed-off-by: Dirk Behme <[EMAIL PROTECTED]> Index: uboot_davinci/common/env_nand.c === --- uboot_davinci.orig/common/env_nand.c +++ uboot_davinci/common/env_nand

Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm

Peter Pearse wrote: >>-Original Message- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>Sent: 11 April 2008 14:18 >>To: Peter Pearse >>Cc: 'Guennadi Liakhovetski'; u-boot-users@lists.sourceforge.net >>Subject: Re: [U-Boot-Users] [GIT PULL] Please pull u-boot-arm >> >>In message <[EM

Re: [U-Boot-Users] Release status - open patches, pull requests etc.

Wolfgang Denk wrote: > Hi everybody, > > as you are probably aware of, we have only 4 more days with an open > merge window left (the merge window for 1.3.3 is open until Mar 31, > 23:59:59 MET). > > I think I have now applied (or rejected) all patches I felt > responsible for myself,

[U-Boot-Users] [PATCH v2] ARM: Davinci: Fix DM644x timer overflow handling and cleanup

). Many thanks to Troy Kisky <[EMAIL PROTECTED]> and Pieter Voorthuijsen <[EMAIL PROTECTED]> for the hints & testing! Patch is compile tested with davinci_dvevm & sonata & schmoogie configuration and tested by Pieter on DaVinci EVM hardware. Signed-off-by: Dirk

Re: [U-Boot-Users] [PATCH] DM644x: (2nd try) This adds support for theProdrive PMDRA board, based on a DM6441

Pieter Voorthuijsen wrote: >>-Original Message- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>In message >><[EMAIL PROTECTED]> >>you wrote: >> >>>2nd try, previous one was wrapped: >>>Double checked spaces and coding style... >> >>Sorry, I know this must be frustrating to you, bu

Re: [U-Boot-Users] [PATCH] ARM: Davinci: Fix DM644x timer overflow handling and cleanup

y okay, it > missed to divide CFG_HZ_CLOCK by 16, too. Fix this. > > [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/38179 > > - Remove software division of timer count value (DIV(x) macro) and do it in > hardware (TIM_CLK_DIV). > > Many thanks to Troy Kisky <

Re: [U-Boot-Users] multiple definition of __udivsi3 when using divide operation on unsigned long numbers

Gururaja Hebbar K R wrote: > Hi, > > I am trying to compile uboot 1.3.1 for arm926ejs processor. i am using > CodeSourcery arm-none-linux-gnueabi toolchain (gcc version 4.2.1 > (CodeSourcery Sourcery G++ Lite 2007q3-51)) . > > i am trying to write a driver for our on board mmc controller. i need

[U-Boot-Users] [PATCH] ARM: Davinci: Fix DM644x timer overflow handling and cleanup

(TIM_CLK_DIV). Many thanks to Troy Kisky <[EMAIL PROTECTED]> for his hints! Patch is compile tested with davinci_dvevm & sonata & schmoogie configuration. Anybody can test it on real hardware? Pieter? Signed-off-by: Dirk Behme <[EMAIL PROTECTED]> Index: uboot_davinci/cpu/arm92

Re: [U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

timer, but sounds like an option. This will need some changes to davinci/timer.c to handle 64bit timer, but this shouldn't be to hard, right? Do you like to send a patch? Many thanks Dirk > -Original Message- > From: Dirk Behme [mailto:[EMAIL PROTECTED] > Sent: donde

Re: [U-Boot-Users] DaVinci DM644x timer problem (divided by 16)

Pieter Voorthuijsen wrote: > Hello, > > Some months ago, a patch was submitted ([ARM] fix timer overflow in > DaVinci). The result was that in /cpu/arm926ejs/davinci/timer.c > read_timer was divided by 16. > > http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=ea686f52e4 > 5b3df293886

[U-Boot-Users] Broken (ARM) build, was: u-boot patch submission process

Haavard Skinnemoen wrote: > On Mon, 11 Feb 2008 05:43:18 +0100 > Dirk Behme <[EMAIL PROTECTED]> wrote: > > >>[U-Boot-Users] [PATCH] [DRIVERS] is onlyavailable >>for ppc boards. >> >>I'm assuming this will eventually be properly patched in the main

Re: [U-Boot-Users] u-boot patch submission process

Todd Fischer wrote: > I am working on a patch to add DM355 SoC support to u-boot git tree. I > am following the steps listed at > http://www.denx.de/wiki/UBoot/DevelopmentProcess. Since the DM355 has > an ARM9 processor, I am creating a patch for the u-boot-arm git tree. > > Since one of the

Re: [U-Boot-Users] [ARM] fix timer overflow in DaVinci

Peter Pearse wrote: > Dirk > Your patch is available for test from > > cg-clone git://linux-arm.org/u-boot-armdev.git#071012_davinci_timer > > Please confirm that the code builds & runs for DaVinci > cg-clone git://linux-arm.org/u-boot-armdev.git#071012_davinci_timer arm_git > cd arm_g

Re: [U-Boot-Users] PATCH: fix timer overflow in DaVinci

und time was doubled. > Shall I treat it as a submitted patch? Yes, please. Thanks for asking! Best regards Dirk >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf >>Of Dirk Behme >>Sent: 20 October 2007 07:24 >>

[U-Boot-Users] [PATCH] Correct NAND erase percentage output

4000 instead Erasing at 0x10 -- 100% complete. OK > -- cut -- This patch is against u-boot-nand-flash.git. Signed-off-by: Dirk Behme <[EMAIL PROTECTED]> --- drivers/mtd/nand/nand_util.c_orig 2008-01-14 21:13:10.0 +0100 +++ drivers/mtd/nand/nand_util.c2008-01-14 21:

Re: [U-Boot-Users] NAND driver updates

[EMAIL PROTECTED] wrote: > On Sat, 5 Jan 2008, Stefan Roese wrote: > > Here comes a trivial patch to cpu/arm926ejs/davinci/nand.c. Unfortunately I > don't have hardware handy so I can not test it at the moment but changes are > rather trivial so it should work. It would be nice if somebody with a