On 09/14/2012 03:03 PM, Benoît Thébaudeau wrote:
On Friday, September 14, 2012 10:49:04 PM, Tom Rini wrote:
On Mon, Sep 03, 2012 at 04:17:09PM +0200, Beno??t Th??baudeau wrote:
Dear Wolfgang Denk,
On Sunday, September 2, 2012 5:28:09 PM, Wolfgang Denk wrote:
Dear Beno??t Th??baudeau,
In message 1285759492.332736.1342790529256.JavaMail.root@advansee.com you wrote:
When storage devices contain files larger than the embedded RAM, it is usef> ul to be able to read these files by chunks, e.g. for a software update to the embedded NAND Flash from an external storage device (USB stick, SD card, et> c.).
Hence, this patch makes it possible by adding a new FAT API to read files f> rom a given position.
Signed-off-by: Beno??t Th??baudeau benoit.thebaudeau@advansee.com Cc: Wolfgang Denk wd@denx.de
Changes for v2:
- Patch renumbering because of the new v2 1/8.
- Possible code style changes due to the new v2 1/8.
- Add missing vairable renaming to fat_write.c.
.../fs/fat/fat.c | 88 ++++++++++++++++> ---- .../fs/fat/fat_write.c | 18 ++-- 2 files changed, 80 insertions(+), 26 deletions(-)
I don't see any command line interface to actually use this code.
How would I put this to use?
Here is the current "fatload" command line interface: fatload <interface> <dev[:part]> <addr> <filename> [bytes]
Do you prefer to change it to: fatload <interface> <dev[:part]> <addr> <filename> [offset] [bytes]
or to have a new dedicated command, or something else?
Lets go with: fatload <interface> <dev[:part]> <addr> <filename> [bytes] [offset] and update the long help text to mention both bytes and offset and that offset requires bytes.
OK. Do you want that in an update of this patch or in a separate patch?
New patch to replace this.
You're right: Having [bytes] before [offset] will avoid breaking the current users of this command. However, this has one drawback: fatls first has to be used to get the file size (with [offset] first, 0 could be easily used for offset to access [bytes]). Hence, still with [bytes] first, would you like to have some special bytes value (let's say -1 or any negative value) meaning "from offset to end of file"?
Lets go with -1 meaning until end of file since we don't have a good way today to determine total filesize.