On Monday 06 July 2009 04:47:41 Stefan Roese wrote:
> On Monday 06 July 2009 10:37:10 Mike Frysinger wrote:
> > On Monday 06 July 2009 03:25:43 Stefan Roese wrote:
> > > On Monday 06 July 2009 09:04:44 Mike Frysinger wrote:
> > > > we would want to avoid ambiguity -- is
> > > > "nor" referring to t
On Monday 06 July 2009 10:47:41 Stefan Roese wrote:
> > > > i guess each flash type would parse the additional commands however
> > > > it liked and so the mtd command would just act as a multiplexer at
> > > > this point. the current spi flash "sf" command is pretty flexible --
> > > > you specify
On Monday 06 July 2009 10:37:10 Mike Frysinger wrote:
> On Monday 06 July 2009 03:25:43 Stefan Roese wrote:
> > On Monday 06 July 2009 09:04:44 Mike Frysinger wrote:
> > > > I kind of like the idea to create a new set of commands for accessing
> > > > such board specific NOR FLASH (can be used on "
On Monday 06 July 2009 03:25:43 Stefan Roese wrote:
> On Monday 06 July 2009 09:04:44 Mike Frysinger wrote:
> > > I kind of like the idea to create a new set of commands for accessing
> > > such board specific NOR FLASH (can be used on "normal" NOR FLASH as
> > > well). Perhaps we could make it "ge
Dear Mike Frysinger,
In message <200907060242.09196.vap...@gentoo.org> you wrote:
>
> there are a few references to "grant's idea" and "grant's work". this is all
> before my time hacking on u-boot, but i vaguely recall this being related to
> u-boot being fully relocatable and not anything to
On Monday 06 July 2009 09:04:44 Mike Frysinger wrote:
> > I kind of like the idea to create a new set of commands for accessing
> > such board specific NOR FLASH (can be used on "normal" NOR FLASH as
> > well). Perhaps we could make it "generic" in a way that it can be used
> > for all kind of "MTD
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
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: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
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
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
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 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 <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 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 <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
On Saturday 04 July 2009 19:39:45 Wolfgang Denk wrote:
> In message Mike Frysinger wrote:
> > From: Harald Krapfenbauer
> >
> > The current flash framework generally assumes that the flash in question
> > is completely directly addressable. With the new weak accessor
> > functions, that is no lon
Dear Mike Frysinger,
In message <1246387465-13156-1-git-send-email-vap...@gentoo.org> you wrote:
> From: Harald Krapfenbauer
>
> The current flash framework generally assumes that the flash in question
> is completely directly addressable. With the new weak accessor functions,
> that is no long
On Tuesday 30 June 2009 14:44:25 Mike Frysinger wrote:
> + if (dst < CONFIG_SYS_SDRAM_BASE ||
> + (dst + size) > (CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_MAX_RAM_SIZE)) {
> + printf("Error: memory area %#08lx to %#08lx is not in RAM\n",
> +dst, dst + size);
>
From: Harald Krapfenbauer
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 us to hook up flashes
whose pins are only partially directly addressable wh
20 matches
Mail list logo
