[U-Boot] [PATCH] flread: new command for reading indirect mapped flashes
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);
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
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
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
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
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
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
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
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
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@denx.de =====================================================================
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
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@denx.de =====================================================================
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
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@denx.de =====================================================================
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
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@denx.de =====================================================================
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@denx.de =====================================================================
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
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
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
participants (3)
-
Mike Frysinger -
Stefan Roese -
Wolfgang Denk