[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Mike Frysinger]

From: Harald Krapfenbauer <Harald.Krapfenbauer@bluetechnix.at>

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 while the rest are
connected to GPIOs.  Since all the erase/write commands go through the
weak accessor functions, those work transparently.  But for reading from
the flash, the common memory function is still used and this does not go
through the weak accessor functions.  So we need a dedicated command to
make sure the weak accessor functions are used to do the actual reading.

Signed-off-by: Harald Krapfenbauer <Harald.Krapfenbauer@bluetechnix.at>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 common/cmd_flash.c |   66 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/flash.h    |    7 +++++
 2 files changed, 73 insertions(+), 0 deletions(-)

diff --git a/common/cmd_flash.c b/common/cmd_flash.c
index 9f27ab0..b8d305b 100644
--- a/common/cmd_flash.c
+++ b/common/cmd_flash.c
@@ -696,6 +696,72 @@ int flash_sect_protect (int p, ulong addr_first, ulong addr_last)
 }
 #endif /* CONFIG_SYS_NO_FLASH */
 
+#if defined(CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS) && !defined(CONFIG_SYS_NO_FLASH)
+int do_flread(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+	ulong src, dst, size;
+	u8 *psrc, *pdst, *pend;
+	flash_info_t *info = &flash_info[0];
+
+	if (argc != 4) {
+		cmd_usage(cmdtp);
+		return 1;
+	}
+
+	src = simple_strtoul(argv[1], NULL, 16);
+	dst = simple_strtoul(argv[2], NULL, 16);
+	size = simple_strtoul(argv[3], NULL, 16);
+	if (src < info->start[0] ||
+	    (src + size) > (info->start[0] + info->size)) {
+		printf("Error: memory area %#08lx to %#08lx is not in FLASH\n",
+		       src, src + size);
+		return 1;
+	}
+	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);
+		return 1;
+	}
+
+	psrc = (void *)src;
+	pend = psrc + size;
+	pdst = (void *)dst;
+	if ((src & 0x3) == (dst & 0x3)) {
+		/* copy byte-wise until we get a 32-bit-aligned address */
+		while ((u32)psrc & 0x3) {
+			*pdst = flash_read8(psrc);
+			++pdst;
+			++psrc;
+		}
+		/* copy 32-bit words */
+		while (psrc < pend - 3) {
+			u32 *pdst32 = (void *)pdst,
+			    *psrc32 = (void *)psrc;
+			*pdst32 = flash_read32(psrc32);
+			pdst = (void *)++pdst32;
+			psrc = (void *)++psrc32;
+		}
+	}
+	/* copy remaining byte-wise */
+	while (psrc < pend) {
+		*pdst = flash_read8(psrc);
+		++pdst;
+		++psrc;
+	}
+
+	printf("Done.\n");
+
+	return 0;
+}
+
+U_BOOT_CMD(
+	flread,  4,  0,  do_flread,
+	"read from FLASH to RAM",
+	"src dest length\n"
+	"    - copy 'length' bytes from FLASH addr 'src' to RAM addr 'dest'\n"
+);
+#endif
 
 /**************************************************/
 #if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_CMD_MTDPARTS)
diff --git a/include/flash.h b/include/flash.h
index b016162..c5e7bf4 100644
--- a/include/flash.h
+++ b/include/flash.h
@@ -104,6 +104,13 @@ extern int flash_write (char *, ulong, ulong);
 extern flash_info_t *addr2info (ulong);
 extern int write_buff (flash_info_t *info, uchar *src, ulong addr, ulong cnt);
 
+/* drivers/mtd/cfi_flash.c */
+#ifdef CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
+extern u8 flash_read8(void *addr);
+extern u16 flash_read16(void *addr);
+extern u32 flash_read32(void *addr);
+#endif
+
 /* drivers/mtd/cfi_mtd.c */
 #ifdef CONFIG_FLASH_CFI_MTD
 extern int cfi_mtd_init(void);
-- 
1.6.3.3

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Mike Frysinger]

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);
> +		return 1;
> +	}

actually, now that i think about it and read the diff yet again, this check 
doesnt make sense.  if the user gives a bad address, that is their fault.  
this prevents reading of the flash into say on-chip data SRAMs on a Blackfin 
part, or into SRAM that is mapped into the async bank.

once Stefan (and anyone else) gets a chance to review, i'll post a new patch
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090630/24237e13/attachment.pgp 

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Wolfgang Denk]

Dear Mike Frysinger,

In message <1246387465-13156-1-git-send-email-vapier@gentoo.org> you wrote:
> From: Harald Krapfenbauer <Harald.Krapfenbauer@bluetechnix.at>
> 
> 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 while the rest are
> connected to GPIOs.  Since all the erase/write commands go through the

Either you or me misunderstand the purpose of these weak accessor
functions.

> weak accessor functions, those work transparently.  But for reading from
> the flash, the common memory function is still used and this does not go
> through the weak accessor functions.  So we need a dedicated command to
> make sure the weak accessor functions are used to do the actual reading.

Nope. This ain't working.

Either we have flash memory; then it is a mandatory requirent that we
can access the flash memory  using  all  memory  accessing  commands,
including  "cp",  "md"  etc. This is not the case on any devices that
require additional address switching, like  on  processors  that  use
things  like bank switching signals in addition to the normal address
lines.

Otherwise we have some form of storage device, which cannot be
accessed with commands like "cp", "md", or "erase".


NAK.

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: wd at denx.de
"A dirty mind is a joy forever."                       - Randy Kunkee

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Mike Frysinger]

On Saturday 04 July 2009 19:39:45 Wolfgang Denk wrote:
> In message Mike Frysinger wrote:
> > From: Harald Krapfenbauer <Harald.Krapfenbauer@bluetechnix.at>
> >
> > 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 while the rest
> > are connected to GPIOs.  Since all the erase/write commands go through
> > the
>
> Either you or me misunderstand the purpose of these weak accessor
> functions.

the original purpose of the weak accessor functions did not include this 
functionality, but there was no way previously to do this -- transparently 
access parallel flashes that do not have all address lines hooked up to the 
normal address bus.

i see the functions being useful in the same way we have mtd mapping drivers 
under Linux.

> > weak accessor functions, those work transparently.  But for reading from
> > the flash, the common memory function is still used and this does not go
> > through the weak accessor functions.  So we need a dedicated command to
> > make sure the weak accessor functions are used to do the actual reading.
>
> Nope. This ain't working.
>
> Either we have flash memory; then it is a mandatory requirent that we
> can access the flash memory  using  all  memory  accessing  commands,
> including  "cp",  "md"  etc. This is not the case on any devices that
> require additional address switching, like  on  processors  that  use
> things  like bank switching signals in addition to the normal address
> lines.
>
> Otherwise we have some form of storage device, which cannot be
> accessed with commands like "cp", "md", or "erase".

yes, the current flash subsystem is limited in this area.  it lacks something 
akin to the Linux mtd mapping drivers.  but this is something to be fixed, not 
something to say "well that hardware doesnt make sense and anyone who wants to 
do that is not supported".  saying "no" to flread is one thing, but saying no 
to the entire idea of supporting these types of devices is wrong imo.

previously these boards had to replicate the CFI drivers entirely just to do 
the bank switching.  the weak accessor functions means now they need all of 
~50 lines of board specific code and they can use all of the common CFI code 
for free.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090704/c5596014/attachment.pgp 

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200907042307.28572.vapier@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 us to hook up
> > > flashes whose pins are only partially directly addressable while the rest
> > > are connected to GPIOs.  Since all the erase/write commands go through
> > > the
> >
> > Either you or me misunderstand the purpose of these weak accessor
> > functions.
>
> the original purpose of the weak accessor functions did not include this 
> functionality, but there was no way previously to do this -- transparently
> access parallel flashes that do not have all address lines hooked up to the
> normal address bus.

You cannot do it transparently with these  functions  either.  Simple
memory  accesses  like  "cp",  "md",  "mm"  etc.  will  still  not be
available. Reading or writing an image to a  partition  that  crosses
banks  is  not  available.  Accessing  files  from a file system that
crosses banks does not work. And so on.

> i see the functions being useful in the same way we have mtd mapping drivers 
> under Linux.

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 linke
in U-Boot. At least not yet ;-)

> > Either we have flash memory; then it is a mandatory requirent that we
> > can access the flash memory  using  all  memory  accessing  commands,
> > including  "cp",  "md"  etc. This is not the case on any devices that
> > require additional address switching, like  on  processors  that  use
> > things  like bank switching signals in addition to the normal address
> > lines.
> >
> > Otherwise we have some form of storage device, which cannot be
> > accessed with commands like "cp", "md", or "erase".
>
> yes, the current flash subsystem is limited in this area.  it lacks something 
> akin to the Linux mtd mapping drivers.  but this is something to be fixed, not 
> something to say "well that hardware doesnt make sense and anyone who wants to 
> do that is not supported".  saying "no" to flread is one thing, but saying no 
> to the entire idea of supporting these types of devices is wrong imo.

I did not say that. I just NAKed the flread patch.

> previously these boards had to replicate the CFI drivers entirely just to do 
> the bank switching.  the weak accessor functions means now they need all of 
> ~50 lines of board specific code and they can use all of the common CFI code 
> for free.

Use it for what? See above - none of the frequently used commands  to
access  flash memory is working as is. Yes, you can hack a set of new
commands - flread, flwrite, flcopy, flmd and whatever you  like.  But
don't expect these to do into mainline.

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: wd at denx.de
In general, if you think something isn't in Perl, try it out, because
it usually is :-) - Larry Wall in <1991Jul31.174523.9447@netlabs.com>

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Mike Frysinger]

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
> > > > us to hook up flashes whose pins are only partially directly
> > > > addressable while the rest are connected to GPIOs.  Since all the
> > > > erase/write commands go through the
> > >
> > > Either you or me misunderstand the purpose of these weak accessor
> > > functions.
> >
> > the original purpose of the weak accessor functions did not include this
> > functionality, but there was no way previously to do this --
> > transparently access parallel flashes that do not have all address lines
> > hooked up to the normal address bus.
>
> You cannot do it transparently with these  functions  either.  Simple
> memory  accesses  like  "cp",  "md",  "mm"  etc.  will  still  not be
> available. Reading or writing an image to a  partition  that  crosses
> banks  is  not  available.  Accessing  files  from a file system that
> crosses banks does not work. And so on.

erasing/writing does work transparently as the CFI layer grabs the addresses 
before they're put onto the bus, and the weak accessors do the setup.  same 
goes for file system commands.

> > i see the functions being useful in the same way we have mtd mapping
> > drivers under Linux.
>
> 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 linke
> in U-Boot. At least not yet ;-)

the mapping drivers dont have any direct dependency on the memory controller 
in any way.  the input to the mapping driver is the mtd and desired offset to 
access.  here you can do any crazy magic you want, including but not limited 
to, memory controller tricks.  in the case of gpio flashes, the gpio pins are 
taken from the address and the real address is accessed.

> > > Either we have flash memory; then it is a mandatory requirent that we
> > > can access the flash memory  using  all  memory  accessing  commands,
> > > including  "cp",  "md"  etc. This is not the case on any devices that
> > > require additional address switching, like  on  processors  that  use
> > > things  like bank switching signals in addition to the normal address
> > > lines.
> > >
> > > Otherwise we have some form of storage device, which cannot be
> > > accessed with commands like "cp", "md", or "erase".
> >
> > yes, the current flash subsystem is limited in this area.  it lacks
> > something akin to the Linux mtd mapping drivers.  but this is something
> > to be fixed, not something to say "well that hardware doesnt make sense
> > and anyone who wants to do that is not supported".  saying "no" to flread
> > is one thing, but saying no to the entire idea of supporting these types
> > of devices is wrong imo.
>
> I did not say that. I just NAKed the flread patch.

OK

> > previously these boards had to replicate the CFI drivers entirely just to
> > do the bank switching.  the weak accessor functions means now they need
> > all of ~50 lines of board specific code and they can use all of the
> > common CFI code for free.
>
> Use it for what? See above - none of the frequently used commands  to
> access  flash memory is working as is. Yes, you can hack a set of new
> commands - flread, flwrite, flcopy, flmd and whatever you  like.  But
> don't expect these to do into mainline.

but they do work because of how the flash subsystem interacts with the rest of 
the system.  it just may inadvertently overlay other things in the physical 
memory map if it follows too closely to the flash.

as an actual example, the cm-bf537e has a 4 meg flash hooked up to 0x20000000 
but the highest address line is handled with a GPIO (meaning 2 megs is 
physically mapped).  using the weak accessor functions, the GPIO is toggled 
transparently and the address in question is munged such that it stays in the 
2 meg boundary.  that means the CFI layer sees:
flash 0: 0x20000000 + 0x400000
so any access from the command line between 0x20000000 and 0x20400000 that 
requires assistance from the CFI layer goes through the accessor functions.  
that means erasing/writing as well as filesystem accesses.  since the read 
command is the only one to not do checking of the flash_info structure, we 
need the dedicated flread command.

the downside here is that anything between 0x20200000 and 0x20400000 is not 
actually physically mapped to the flash device, but any flash related command 
will think it is.  so it'd be a problem if you tried to hook up two flashes 
back to back.  that hasnt been a use case that ive seen thus far.  after all, 
it's generally cheaper to buy a larger memory than to try and buy two smaller 
ones as is connecting/testing/etc...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090705/2ae8d0f1/attachment.pgp 

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200907051312.25031.vapier@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 the linke
> > in U-Boot. At least not yet ;-)
>
> the mapping drivers dont have any direct dependency on the memory controller 
> in any way.  the input to the mapping driver is the mtd and desired offset to 
> access.  here you can do any crazy magic you want, including but not limited 
> to, memory controller tricks.  in the case of gpio flashes, the gpio pins are 
> taken from the address and the real address is accessed.

You are missing the point that we are talking about flash _memory_
here, which is accessed using an address in the CPU's address space.
If you  have N banks of flash _memory_, each of these banks must be
assigned it's own, unique region in the CPU's address space.

What you are talking about is not flash _memory_ but a flash based
storage _device_.

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 support.
At least I cannot think of another solution.

> as an actual example, the cm-bf537e has a 4 meg flash hooked up to 0x20000000 
> but the highest address line is handled with a GPIO (meaning 2 megs is 
> physically mapped).  using the weak accessor functions, the GPIO is toggled
> transparently and the address in question is munged such that it stays in the 
> 2 meg boundary.  that means the CFI layer sees:
> flash 0: 0x20000000 + 0x400000
> so any access from the command line between 0x20000000 and 0x20400000 that
> requires assistance from the CFI layer goes through the accessor functions.
> that means erasing/writing as well as filesystem accesses.  since the read 
> command is the only one to not do checking of the flash_info structure, we 
> need the dedicated flread command.

What you describe is a storage device, not much different from NAND
flash or any other storage device.

If you had an implementation that supported 4  MiB  of  flash  memory
mapped  at  0x20000000, then this flash memory would be accessable by
driving the address lines  to  any  address  in  the  0x20000000  ...
0x203FFFFF  range. The fact that you need a driver (MTD) even to read
the device is a clear indication that it is not memory.

Let me give you a different example - for flash memory it is possible
to manually perform for example a sector erase by doing something like

	mw.b 20200AAA AA
	mw.b 20200555 55
	mw.b 20200AAA 80
	mw.b 20200AAA AA
	mw.b 20200555 55

or similar - I guess this will not work as expected in your case,
becuase what you implement is not a memory interface, but a storage
device.


Please note that I do not say that support for such a configuration is
not useful - it definitely _is_ useful. But then be honest to yourself
and don't try to disguise this as memory - as suggested by you, it is
a storage device, and I will not accept attempts to access storage
devices of any kinds through a memory interface.


Please see the archive, we had similar discussions  several  times  a
long  time  ago. Ulf can tell you a thing or two about it. For me one
important decision criterion is whether I can do the same actions  in
U-Boot  and in a JTAG debugger; in your case, running "md 0x201FFF80"
in U-Boot and at the BDI3000's telnet prompt would NOT show the  very
same  results,  which they have to if there is memory mapped at these
addresses.


> the downside here is that anything between 0x20200000 and 0x20400000 is not 
> actually physically mapped to the flash device, but any flash related command 
> will think it is.  so it'd be a problem if you tried to hook up two flashes 

Gotcha. This is not the characteristics of memory, but  a storage
device. Use a storage device driver for such a setup.

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: wd at denx.de
There's an old story about the person who wished his computer were as
easy to use as his telephone. That wish has come  true,  since  I  no
longer know how to use my telephone.

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Mike Frysinger]

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 linke
> > > in U-Boot. At least not yet ;-)
> >
> > the mapping drivers dont have any direct dependency on the memory
> > controller in any way.  the input to the mapping driver is the mtd and
> > desired offset to access.  here you can do any crazy magic you want,
> > including but not limited to, memory controller tricks.  in the case of
> > gpio flashes, the gpio pins are taken from the address and the real
> > address is accessed.
>
> You are missing the point that we are talking about flash _memory_
> here, which is accessed using an address in the CPU's address space.
> If you  have N banks of flash _memory_, each of these banks must be
> assigned it's own, unique region in the CPU's address space.
>
> What you are talking about is not flash _memory_ but a flash based
> storage _device_.

i dont see much point in distinguishing the two, but i understand what you're 
going for now

> 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 support.
> At least I cannot think of another solution.

i dont really know what you mean.  in my gpio flash example, there is 
literally no other software or hardware changes necessary.  the fact that one 
or two address lines is handled by GPIOs makes no difference at all to the 
rest of the hardware.

> If you had an implementation that supported 4  MiB  of  flash  memory
> mapped  at  0x20000000, then this flash memory would be accessable by
> driving the address lines  to  any  address  in  the  0x20000000  ...
> 0x203FFFFF  range. The fact that you need a driver (MTD) even to read
> the device is a clear indication that it is not memory.

the lower two megs that are physically mapped are fully usable today without 
any changes.  in other words, if i configured the board to lie and treat it as 
a 2 meg CFI flash at 0x20000000, it'd work the same way as any other CFI flash 
device.  all the commands you refer to work fine.

> Please note that I do not say that support for such a configuration is
> not useful - it definitely _is_ useful. But then be honest to yourself
> and don't try to disguise this as memory - as suggested by you, it is
> a storage device, and I will not accept attempts to access storage
> devices of any kinds through a memory interface.

my purpose is clear -- to maximize device support with as little 
changes/overhead as possible and get merged into mainline.

> 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 ?

> For me one
> important decision criterion is whether I can do the same actions  in
> U-Boot  and in a JTAG debugger; in your case, running "md 0x201FFF80"
> in U-Boot and at the BDI3000's telnet prompt would NOT show the  very
> same  results,  which they have to if there is memory mapped at these
> addresses.

u-boot and jtag would always show the exact same results in this case.  they 
just may not do what you expect them.  i.e. if the GPIO line is high, then 
reading 0x20000000 - 0x20200000 will access the top half of the flash, not the 
bottom half.

> > the downside here is that anything between 0x20200000 and 0x20400000 is
> > not actually physically mapped to the flash device, but any flash related
> > command will think it is.  so it'd be a problem if you tried to hook up
> > two flashes
>
> Gotcha. This is not the characteristics of memory, but  a storage
> device. Use a storage device driver for such a setup.

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.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090705/34ad569c/attachment-0001.pgp 

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200907051503.44391.vapier@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 support.
> > At least I cannot think of another solution.
>
> i dont really know what you mean.  in my gpio flash example, there is 
> literally no other software or hardware changes necessary.  the fact that one 
> or two address lines is handled by GPIOs makes no difference at all to the
> rest of the hardware.

Yes, it does. These GPIO lines are not part of the CPU's address
signals. If the CPU attempts to fetch data from 0x20300000 it will not
see the expected data from the midle of the second bank.

> > If you had an implementation that supported 4  MiB  of  flash  memory
> > mapped  at  0x20000000, then this flash memory would be accessable by
> > driving the address lines  to  any  address  in  the  0x20000000  ...
> > 0x203FFFFF  range. The fact that you need a driver (MTD) even to read
> > the device is a clear indication that it is not memory.
>
> the lower two megs that are physically mapped are fully usable today without 
> any changes.  in other words, if i configured the board to lie and treat it as 
> a 2 meg CFI flash at 0x20000000, it'd work the same way as any other CFI flash 
> device.  all the commands you refer to work fine.

Agreed. That's the current status quo. There are for example a number
of MPC5200 systems that can access  (in  U-Boot)  only  half  of  the
physically available flash memory because of this.

> my purpose is clear -- to maximize device support with as little 
> changes/overhead as possible and get merged into mainline.

I appreciate this.

> > 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 these threads:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/26014
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/27363/focus=27372
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/28528/focus=28754

and so on. Or search for "storage device" & "flash memory" :-)

> > U-Boot  and in a JTAG debugger; in your case, running "md 0x201FFF80"
> > in U-Boot and at the BDI3000's telnet prompt would NOT show the  very
> > same  results,  which they have to if there is memory mapped at these
> > addresses.
>
> u-boot and jtag would always show the exact same results in this case.  they 
> just may not do what you expect them.  i.e. if the GPIO line is high, then
> reading 0x20000000 - 0x20200000 will access the top half of the flash, not the 
> bottom half.

> 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 plan.

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: wd at denx.de
If the odds are a million to one against something occuring,  chances
are 50-50 it will.

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Stefan Roese]

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 plan.

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 
devices". How about this "mtd" commandset:

Select MTD NOR device #1 (2nd NOR device):
=> mtd device nor 1

Or via mtdparts/mtdids:
=> mtd device nor0

After this selection the "mtd" commands could be used to access the FLASH 
device:

=> mtd erase
=> mtd read
=> mtd write

This way all these commands would be FLASH type independent. We could perhaps 
consolidate all those multiple commandsets (nand, onenand etc) into this one 
over time.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Mike Frysinger]

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 means using the weak GPIO accessor
> > > functions.
> >
> > Sounds like a plan.
>
> 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 devices". How about this "mtd" commandset:

makes sense to me.  i'm assuming you're not also proposing doing the first cut 
implementation yourself :).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090706/b845e388/attachment.pgp 

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Stefan Roese]

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 it still must be
> > > > able to leverage the CFI code which means using the weak GPIO
> > > > accessor functions.
> > >
> > > Sounds like a plan.
> >
> > 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 devices". How about this "mtd" commandset:
>
> makes sense to me.  i'm assuming you're not also proposing doing the first
> cut implementation yourself :).

No, sorry. :)

But we (you?) should wait with such an implementation until we get a bit more 
feedback from the community about this.

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Mike Frysinger]

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 means using the weak GPIO accessor
> > > functions.
> >
> > Sounds like a plan.
>
> 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 devices". How about this "mtd" commandset:
>
> Select MTD NOR device #1 (2nd NOR device):
> => mtd device nor 1
>
> Or via mtdparts/mtdids:
> => mtd device nor0

so both syntaxes would be available when mtdparts support is enabled, or would 
it be one or the other ?  we would want to avoid ambiguity -- is "nor" 
referring to the nor flashes or is it referring to a partition named "nor".

what flash devices does mtdparts support now ?  i'm not really familiar with 
it and the README and doc/ files doesnt seem to cover it.

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 the spi chip 
select to select the device and you can specify other parameters dynamically 
(like frequency).  so when folding it in, we'd have:
=> mtd device sf <cs> [speed] [mode]

common/cmd_mtd.c
common/cmd_mtd_sf.c
common/cmd_mtd_nor.c
...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090706/598ae3cd/attachment.pgp 

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Stefan Roese]

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 devices". How about this "mtd" commandset:
> >
> > Select MTD NOR device #1 (2nd NOR device):
> > => mtd device nor 1
> >
> > Or via mtdparts/mtdids:
> > => mtd device nor0
>
> so both syntaxes would be available when mtdparts support is enabled, or
> would it be one or the other ?

I didn't make my mind up until now. I was just throwing out an idea.

> we would want to avoid ambiguity -- is
> "nor" referring to the nor flashes or is it referring to a partition named
> "nor".

The first version would refer "nor" as flash type and the 2nd one "nor0" as a 
device name from mtdparts/mtdids.

> what flash devices does mtdparts support now ?  i'm not really familiar
> with it and the README and doc/ files doesnt seem to cover it.

Right now it supports NAND, OneNAND and NOR (if CONFIG_FLASH_CFI_MTD is 
enabled). Others can be easily added (see drivers/mtd/cfi_mtd.c for NOR).

> 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 the
> spi chip select to select the device and you can specify other parameters
> dynamically (like frequency).  so when folding it in, we'd have:
> => mtd device sf <cs> [speed] [mode]
>
> common/cmd_mtd.c
> common/cmd_mtd_sf.c
> common/cmd_mtd_nor.c

I was more thinking about adding the MTD layer to all FLASH types supported by 
this new commandset. Then accessing the device is done via the MTD functions 
pointers (mtd->erase, mtd->read, etc). Special FLASH type specific stuff still 
needs to be handled in some additional drivers (like OOB handling for 
NAND/OneNAND, or SF specific stuff) though.

BTW: Adding the MTD layer to those other FLASH types like SF has the 
advantage, that things like UBI/UBIFS could be used on those devices as well.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Mike Frysinger]

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 "generic" in a way that it can be used
> > > for all kind of "MTD devices". How about this "mtd" commandset:
> > >
> > > Select MTD NOR device #1 (2nd NOR device):
> > > => mtd device nor 1
> > >
> > > Or via mtdparts/mtdids:
> > > => mtd device nor0
> >
> > so both syntaxes would be available when mtdparts support is enabled, or
> > would it be one or the other ?
>
> I didn't make my mind up until now. I was just throwing out an idea.
>
> > we would want to avoid ambiguity -- is
> > "nor" referring to the nor flashes or is it referring to a partition
> > named "nor".
>
> The first version would refer "nor" as flash type and the 2nd one "nor0" as
> a device name from mtdparts/mtdids.

so people wouldnt be able to name a mtdpart "nor"

> > what flash devices does mtdparts support now ?  i'm not really familiar
> > with it and the README and doc/ files doesnt seem to cover it.
>
> Right now it supports NAND, OneNAND and NOR (if CONFIG_FLASH_CFI_MTD is
> enabled). Others can be easily added (see drivers/mtd/cfi_mtd.c for NOR).

so FLASH_CFI_MTD is merely glue between the existing CFI flash driver and the 
MTD layers ?

> > 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 the spi chip select to select the device and you can specify
> > other parameters dynamically (like frequency).  so when folding it in,
> > we'd have: => mtd device sf <cs> [speed] [mode]
> >
> > common/cmd_mtd.c
> > common/cmd_mtd_sf.c
> > common/cmd_mtd_nor.c
>
> I was more thinking about adding the MTD layer to all FLASH types supported
> by this new commandset. Then accessing the device is done via the MTD
> functions pointers (mtd->erase, mtd->read, etc). Special FLASH type
> specific stuff still needs to be handled in some additional drivers (like
> OOB handling for NAND/OneNAND, or SF specific stuff) though.

ok, this seems like it should be doable in a gradual progression.  i.e. today 
i am only concerned with nor flash, so getting a base framework with that as 
the only supported flash should be fine.  once we know it can replace the 
existing cmd_flash.c functions, we can look at folding in other flash types.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090706/f667c052/attachment.pgp 

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Stefan Roese]

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 "normal" NOR FLASH as
> > > > well). Perhaps we could make it "generic" in a way that it can be
> > > > used for all kind of "MTD devices". How about this "mtd" commandset:
> > > >
> > > > Select MTD NOR device #1 (2nd NOR device):
> > > > => mtd device nor 1
> > > >
> > > > Or via mtdparts/mtdids:
> > > > => mtd device nor0
> > >
> > > so both syntaxes would be available when mtdparts support is enabled,
> > > or would it be one or the other ?
> >
> > I didn't make my mind up until now. I was just throwing out an idea.
> >
> > > we would want to avoid ambiguity -- is
> > > "nor" referring to the nor flashes or is it referring to a partition
> > > named "nor".
> >
> > The first version would refer "nor" as flash type and the 2nd one "nor0"
> > as a device name from mtdparts/mtdids.
>
> so people wouldnt be able to name a mtdpart "nor"

Yes, this doesn't make much sense. It's probably better to only use the 2nd 
approach via the mtdparts/mtdids name.

> > > what flash devices does mtdparts support now ?  i'm not really familiar
> > > with it and the README and doc/ files doesnt seem to cover it.
> >
> > Right now it supports NAND, OneNAND and NOR (if CONFIG_FLASH_CFI_MTD is
> > enabled). Others can be easily added (see drivers/mtd/cfi_mtd.c for NOR).
>
> so FLASH_CFI_MTD is merely glue between the existing CFI flash driver and
> the MTD layers ?

Correct. And such glue layers could be added for other FLASH technologies like 
SF as well.

> > > 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 the spi chip select to select the device and you can specify
> > > other parameters dynamically (like frequency).  so when folding it in,
> > > we'd have: => mtd device sf <cs> [speed] [mode]
> > >
> > > common/cmd_mtd.c
> > > common/cmd_mtd_sf.c
> > > common/cmd_mtd_nor.c
> >
> > I was more thinking about adding the MTD layer to all FLASH types
> > supported by this new commandset. Then accessing the device is done via
> > the MTD functions pointers (mtd->erase, mtd->read, etc). Special FLASH
> > type specific stuff still needs to be handled in some additional drivers
> > (like OOB handling for NAND/OneNAND, or SF specific stuff) though.
>
> ok, this seems like it should be doable in a gradual progression.  i.e.
> today i am only concerned with nor flash, so getting a base framework with
> that as the only supported flash should be fine.  once we know it can
> replace the existing cmd_flash.c functions, we can look at folding in other
> flash types. -mike

I think this is a doable approach. But we first need a general consent on 
this. Other opinions on this are welcome...

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Stefan Roese]

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 the spi chip select to select the device and you can
> > > > specify other parameters dynamically (like frequency).  so when
> > > > folding it in, we'd have: => mtd device sf <cs> [speed] [mode]
> > > >
> > > > common/cmd_mtd.c
> > > > common/cmd_mtd_sf.c
> > > > common/cmd_mtd_nor.c
> > >
> > > I was more thinking about adding the MTD layer to all FLASH types
> > > supported by this new commandset. Then accessing the device is done via
> > > the MTD functions pointers (mtd->erase, mtd->read, etc). Special FLASH
> > > type specific stuff still needs to be handled in some additional
> > > drivers (like OOB handling for NAND/OneNAND, or SF specific stuff)
> > > though.
> >
> > ok, this seems like it should be doable in a gradual progression.  i.e.
> > today i am only concerned with nor flash, so getting a base framework
> > with that as the only supported flash should be fine.  once we know it
> > can replace the existing cmd_flash.c functions, we can look at folding in
> > other flash types. -mike
>
> I think this is a doable approach. But we first need a general consent on
> this. Other opinions on this are welcome...

No further responses on this. So it seems nobody objects this approach to move 
to a common command interface for all flash types.

Mike, what are your plans here? Will you work in this "mtd" commands interface 
at some time?

Thanks.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Mike Frysinger]

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 the nor flashes or is it referring to a partition
> > > > named "nor".
> > >
> > > The first version would refer "nor" as flash type and the 2nd one
> > > "nor0" as a device name from mtdparts/mtdids.
> >
> > so people wouldnt be able to name a mtdpart "nor"
>
> Yes, this doesn't make much sense. It's probably better to only use the 2nd
> approach via the mtdparts/mtdids name.

when mtdparts support is enabled, sure.  the logic could be fairly dynamic -- 
if you give it two args, it is referring to a flash type and a flash #.  if 
you give it one, it defaults to mtdparts if it's enabled.  if no mtdpart 
exists named that way, it falls back to flash type and flash 0.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090710/75c6ede1/attachment.pgp 

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Mike Frysinger]

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 these threads:
>
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/26014
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/27363/focus=27372
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/28528/focus=28754
>
> and so on. Or search for "storage device" & "flash memory" :-)

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 do with interfaces to flash 
devices ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090706/5a755438/attachment.pgp 

[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200907060242.09196.vapier@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 do with interfaces to flash 
> devices ?

I think so, but I don't remember any details either.

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: wd at denx.de
People have one thing in common: they are all different.