Hello Wolfgang,
Wolfgang Denk wrote:
> In message <4a48948d.7010...@denx.de> you wrote:
>>> removing the weak definition works for me ... but of course I don't want
>>> to need an extra patch. It should simply work out-of-the-box.
>> So, the only problem is/was, that this patch didn;t found his wa
The following changes since commit 3e88337b225bf796f6df21d0a7f591530e9d4ce0:
Mike Frysinger (1):
Blackfin: move ALL += u-boot.ldr to blackfin_config.mk
are available in the git repository at:
git://git.denx.de/u-boot-i2c.git master
Peter Meerwald (1):
Blackfin: TWI/I2C: fix pur
Tom wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 16:56 Thu 02 Jul , Tom wrote:
>>
>>> Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>
On 15:04 Tue 30 Jun , Tom Rix wrote:
> On build of omap3 targets in MAKEALL, the *.ERR files have
>
> cpu.c: In funct
On 01:06 Sun 05 Jul , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> In message <20090627152133.gj8...@game.jcrosoft.org> you wrote:
> > On 10:32 Wed 24 Jun , Sedji Gaouaou wrote:
> > > On the boards at91sam9260ek, at91sam9263ek and afed9260, the rstc
> > > register was
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
MAKEALL |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index f2d3b6f..bbb2546 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -512,7 +512,8 @@ LIST_ARM9=" \
mx1ads \
Dear Mike Frysinger,
In message <200907042307.28572.vap...@gentoo.org> you wrote:
>
> > > The current flash framework generally assumes that the flash in question
> > > is completely directly addressable. With the new weak accessor
> > > functions, that is no longer always the case. These allow
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message <20090705095925.gf30...@game.jcrosoft.org> you wrote:
>
> > Can you please fix the commit message? "fot" is obviously a typo;
> > I guess it should read "for" ? Thanks.
> please accept it as this, I other patch applied over it and I prefer to not
On Sunday 05 July 2009 11:15:42 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > > The current flash framework generally assumes that the flash in
> > > > question is completely directly addressable. With the new weak
> > > > accessor functions, that is no longer always the case. These allow
>
Dear Mike Frysinger,
In message <200907051312.25031.vap...@gentoo.org> you wrote:
>
> > They _would_ be useful if they could be used like in Linux, but this
> > requires at least a memory controller setup that traps of accesses to
> > certain address ranges - but we don't have virtual memory or th
On Sunday 05 July 2009 13:55:13 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > They _would_ be useful if they could be used like in Linux, but this
> > > requires at least a memory controller setup that traps of accesses to
> > > certain address ranges - but we don't have virtual memory or the
Dear Mike Frysinger,
In message <200907051503.44391.vap...@gentoo.org> you wrote:
>
> > Memory is required to be directly adressable from the CPU; if you
> > need to perform additional operations like toggeling GPIO pins to map
> > the required bank in, this probably needs memory controller s
On Sunday 05 July 2009 22:34:39 Wolfgang Denk wrote:
> > i dont mind creating a dedicated command like "fl" that would act like
> > "sf" in terms of reading/writing/erasing, but it still must be able to
> > leverage the CFI code which means using the weak GPIO accessor functions.
>
> Sounds like a
Signed-off-by: Prafulla Wadaskar
---
include/asm-arm/arch-kirkwood/kirkwood.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-arm/arch-kirkwood/kirkwood.h
b/include/asm-arm/arch-kirkwood/kirkwood.h
index 52dafc2..47679dd 100644
--- a/include/asm-arm/arch-kir
On Wednesday 01 July 2009 10:37:46 Felix Radensky wrote:
> This patch fixes printf format string compilation warnings in several
> debug statements. It also fixes the dump of DDR controller MQ registers
> found on some 44x and 46x platforms. The current register dump code
> uses incorrect DCRs to a
On Thursday 02 July 2009 07:20:51 Alessio Centazzo wrote:
> This patch fixes a debug compilation error for PPC4xx platforms, all
> other architectures are not affected by this change. The 'handler'
> pointer was undefined. The fix is exercised and has effect only if
> DEBUG is defined.
This one
On Thursday 02 July 2009 07:22:42 Alessio Centazzo wrote:
> This patch fixes a compilation warning for some Ethernet PHY-less
> PPC4xx platforms (440SPE based ones) and a potential compilation
> error for 440SP platforms (use of undefined 'ethgroup' variable).
> In the original code and in case of
On Friday 03 July 2009 16:06:06 Matthias Fuchs wrote:
> This patch implements the is_pci_host() function in a similiar way
> as it is used on 440 targets.
>
> The former path with CONFIG_PCI_HOST == PCI_HOST_AUTO does not
> build on 405EP targets because checking the PCI arbiter is different.
> So
On Monday 06 July 2009 01:10:58 Stefan Roese wrote:
> On Sunday 05 July 2009 22:34:39 Wolfgang Denk wrote:
> > > i dont mind creating a dedicated command like "fl" that would act like
> > > "sf" in terms of reading/writing/erasing, but it still must be able to
> > > leverage the CFI code which mean
> -Original Message-
> From: Mike Frysinger [mailto:vap...@gentoo.org]
> Sent: Friday, July 03, 2009 11:31 PM
> To: u-boot@lists.denx.de
> Cc: Prafulla Wadaskar; Manas Saksena; Ronen Shitrit; Nicolas
> Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek
> Subject: Re: [U-Boot
On Monday 06 July 2009 02:26:20 Prafulla Wadaskar wrote:
> From: Mike Frysinger [mailto:vap...@gentoo.org]
> > On Friday 03 July 2009 13:28:01 Prafulla Wadaskar wrote:
> > > + {
> > > + .idcode0 = MXIC_ID_MT_MX2512855E,
> > > + .idcode1 = MXIC_ID_MD_MX2512855E,
> > > + .page
On Monday 06 July 2009 07:59:25 Mike Frysinger wrote:
> On Monday 06 July 2009 01:10:58 Stefan Roese wrote:
> > On Sunday 05 July 2009 22:34:39 Wolfgang Denk wrote:
> > > > i dont mind creating a dedicated command like "fl" that would act
> > > > like "sf" in terms of reading/writing/erasing, but i
Hello Prafulla,
I have here a ARM926EJS (CPU Core Version FEROCEON_88FR131 SOC Family:
KIRKWOOD,
KW88F6281) based board, with a basic u-boot support, see:
http://git.denx.de/?p=u-boot/u-boot-testing.git;a=shortlog;h=refs/heads/keymile-suen3
and we need i2c support for it. I thought to port the
new chips supported:-
MX25L1605D, MX25L3205D, MX25L6405D, MX25L12855E
out of which MX25L6405D and MX25L12855E tested on Kirkwood platforms
Modified the Macronix flash support to use 2 bytes of device id instead of 1
This was required to support MX25L12855E
Signed-off-by: Piyush Shah
Signed-off-b
> -Original Message-
> From: Heiko Schocher [mailto:h...@denx.de]
> Sent: Monday, July 06, 2009 12:05 PM
> To: Prafulla Wadaskar
> Cc: Stefan Roese; Detlev Zundel; Brunck, Holger; U-Boot user list
> Subject: u-boot twsi i2c driver
>
> Hello Prafulla,
>
> I have here a ARM926EJS (CPU
On Sunday 05 July 2009 16:34:39 Wolfgang Denk wrote:
> Mike Frysinger wrote:
> > > Please see the archive, we had similar discussions several times a
> > > long time ago. Ulf can tell you a thing or two about it.
> >
> > i'll try searching ... any keywords to look for ?
>
> See for example the
On Monday 06 July 2009 07:41:52 Prafulla Wadaskar wrote:
> + u16 id = (u16 *) *idcode;
sorry, this wont fly on systems that cannot do unaligned accesses. i dont
know the status of the get_unaligned() type macros in u-boot, but it'll
probably be easier to just do:
idcode[0] | idcode[1] << 8;
Hello Prafulla,
Prafulla Wadaskar wrote:
>> -Original Message-
>> From: Heiko Schocher [mailto:h...@denx.de]
>> Sent: Monday, July 06, 2009 12:05 PM
>> To: Prafulla Wadaskar
>> Cc: Stefan Roese; Detlev Zundel; Brunck, Holger; U-Boot user list
>> Subject: u-boot twsi i2c driver
>>
>> Hello
27 matches
Mail list logo
