fat.h unconditionally defines CONFIG_SUPPORT_VFAT (and has done since
2003), so as a result VFAT support is always enabled regardless of
whether a board config defines it or not. Drop this unnecessary option.
Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
The message "reading %s\n" may be interesting when
debugging but otherwise it is superfluous.
Only output the message when debugging.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Before this patch one could receive following errors when executing "fatls"
command on machine with cache enabled (ex i.MX6Q) :
=> fatls mmc 0:1
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
CACHE: Misaligned operation at range [4f59dfc8, 4f59e7c8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x4f59dfc8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x4f59e7c8
To alleviate this problem - the calloc()s have been replaced with
malloc_cache_aligned() and memset().
After those changes the buffers are properly aligned (with both start
address and size) to SoC cache line.
Fixes: 09fa964bba ("fs/fat: Fix 'CACHE: Misaligned operation at range' warnings")
Suggested-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Check malloc() return values and properly unwind on errors so
memory allocated for fat_itr structures get freed properly.
Also fixes a leak of fsdata.fatbuf in fat_size().
Fixes: 2460098cff ("fs/fat: Reduce stack usage")
Reported-by: Coverity (CID: 167225, 167233, 167234)
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Tom Rini <trini@konsulko.com>
The 'block' field of fat_itr needs to be properly aligned for DMA and
while it does have '__aligned(ARCH_DMA_MINALIGN)', the fat_itr structure
itself needs to be properly aligned as well.
While at it use malloc_cache_aligned() for the other aligned allocations
in the file as well.
Fixes: 2460098cff ("fs/fat: Reduce stack usage")
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Tom Rini <trini@konsulko.com>
If we end up back in the root directory via a '..' directory entry, set
itr->is_root accordingly. Failing to do that gives spews like
"Invalid FAT entry" and being unable to access directory entries located
past the first cluster of the root directory.
Fixes: 8eafae209c ("fat/fs: convert to directory iterators")
Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
We have limited stack in SPL builds. Drop itrblock and move to
malloc/free of itr to move this off of the stack. As part of this fix a
double-free issue in fat_size().
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Rework to use malloc/free as moving this to a global overflows some SH
targets.
A new fatbuf was allocated by get_fs_info() (called by fat_itr_root()),
but not freed, resulting in eventually running out of memory. Spotted
by running 'ls -r' in a large FAT filesystem from Shell.efi.
fatbuf is mainly used to cache FAT entry lookups (get_fatent())..
possibly once fat_write.c it can move into the iterator to simplify
this.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Łukasz Majewski <lukma@denx.de>
Use the clust_to_sect() helper that was introduced earlier, and add an
inverse sect_to_clust(), plus update the various spots that open-coded
this conversion previously.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Noticed when comparing our output to linux. There are some lcase bits
which control whether filename and/or extension should be downcase'd.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Łukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a generic implementation of 'ls' using opendir/readdir/closedir, and
replace fat's custom implementation. Other filesystems should move to
the generic implementation after they add opendir/readdir/closedir
support.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Łukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Implement the readdir interface using the directory iterators.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Łukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
And drop a whole lot of ugly code!
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Łukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Untangle directory traversal into a simple iterator, to replace the
existing multi-purpose do_fat_read_at() + get_dentfromdir().
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Łukasz Majewski <lukma@denx.de>
Want to re-use this in fat dirent iterator in next patch.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Łukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The function blk_dread will return -ENOSYS on failure or on success the
number of blocks read, which must be the number asked to read (otherwise
it failed somewhere). Correct this check.
Signed-off-by: Tom Rini <trini@konsulko.com>
At present CONFIG_CMD_SATA enables the 'sata' command which also brings
in SATA support. Some boards may wish to enable SATA without the command.
Add a separate CONFIG to permit this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present IDE support is controlled by CONFIG_CMD_IDE. Add a separate
CONFIG_IDE option so that IDE support can be enabled without requiring
the 'ide' command.
Update existing users and move the ide driver into drivers/block since
it should not be in common/.
Signed-off-by: Simon Glass <sjg@chromium.org>
Doing unaligned reads is not supported on all architectures, use
byte sized reads of the little endian buffer.
Rename off16 to off8, as it reflects the buffer offset in byte
granularity (offset is in entry, i.e. 12 bit, granularity).
Fix a regression introduced in 8d48c92b45
Reported-by: Oleksandr Tymoshenko <gonzo@bluezbox.com>
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Tested-by: Oleksandr Tymoshenko <gonzo@bluezbox.com>
We convert CONFIG_PARTITION_UUIDS to Kconfig first. But in order to cleanly
update all of the config files we must also update CMD_PART and CMD_GPT to also
be in Kconfig in order to avoid complex logic elsewhere to update all of the
config files.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay73@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Instead of shuffling bits from two adjacent 16 bit words, use one 16 bit
word with the appropriate byte offset in the buffer.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
get_fatent_value(...) flushes changed FAT entries to disk when fetching
the next FAT blocks, in every other aspect it is identical to
get_fatent(...).
Provide a stub implementation for flush_dirty_fat_buffer if
CONFIG_FAT_WRITE is not set. Calling flush_dirty_fat_buffer during read
only operation is fine as it checks if any buffers needs flushing.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The FAT is read/flushed in segments of 6 (FATBUFBLOCKS) disk sectors. The
last segment may be less than 6 sectors, cap the length.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com>
The code caches 6 sectors of the FAT. On FAT traversal, the old contents
needs to be flushed to disk, but only if any FAT entries had been modified.
Explicitly flag the buffer on modification.
Currently, creating a new file traverses the whole FAT up to the first
free cluster and rewrites the on-disk blocks.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
This option currently enables both the command and the SCSI functionality.
Rename the existing option to CONFIG_SCSI since most of the code relates
to the feature.
Signed-off-by: Simon Glass <sjg@chromium.org>
To ease conversion to driver model, add helper functions which deal with
calling each block device method. With driver model we can reimplement these
functions with the same arguments.
Use inline functions to avoid increasing code size on some boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
This is a device number, and we want to use 'dev' to mean a driver model
device. Rename the member.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Rename three partition functions so that they start with part_. This makes
it clear what they relate to.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long
and causes 80-column violations, rename it to struct blk_desc.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
This will allow the implementation to make use of data in the block_dev
structure beyond the base device number. This will be useful so that eMMC
block devices can encompass the HW partition ID rather than treating this
out-of-band. Equally, the existence of the priv field is crying out for
this patch to exist.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
It is very common that FAT code is using following pattern:
if (disk_{read|write}() < 0)
return -1;
Up till now the above code was dead, since disk_{read|write) could only
return value >= 0.
As a result some errors from medium layer (i.e. eMMC/SD) were not caught.
The above behavior was caused by block_{read|write|erase} declared at
struct block_dev_desc (@part.h). It returns unsigned long, where 0
indicates error and > 0 indicates that medium operation was correct.
This patch as error regards 0 returned from block_{read|write|erase}
when nr_blocks is grater than zero. Read/Write operation with nr_blocks=0
should return 0 and hence is not considered as an error.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Test HW: Odroid XU3 - Exynos 5433
Now that we have a new header file for cache-aligned allocation, we should
move the stack-based allocation macro there also.
Signed-off-by: Simon Glass <sjg@chromium.org>
The FAT code contains a special case to parse the root directory. This
is needed since the root directory location/layout on disk is special
cased for FAT12/16. In particular, the location and size of the FAT12/16
root directory is hard-coded and contiguous, whereas all FAT12/16 non-root
directories, and all FAT32 directories, are stored in a non-contiguous
fashion, with the layout represented by a linked-list of clusters in the
FAT.
If a file path contains ../ (for example /extlinux/../bcm2835-rpi-cm.dtb),
it is possible to need to parse the root directory for the first element
in the path (requiring application of the special case), then a sub-
directory (in the general way), then re-parse the root directory (again
requiring the special case). However, the current code in U-Boot only
applies the special case for the very first path element, and never for
any later path element. When reparsing the root directory without
applying the special case, any file in a sector (or cluster?) other than
the first sector/cluster of the root directory will not be found.
This change modifies the non-root-dir-parsing loop of do_fat_read_at()
to detect if it's walked back to the root directory, and if so, jumps
back to the special case code that handles parsing of the root directory.
This change was tested using sandbox by executing:
./u-boot -c "host bind 0 ../sd-p1.bin; ls host 0:0"
./u-boot -c "host bind 0 ../sd-p1.bin; ls host 0:0 /"
./u-boot -c "host bind 0 ../sd-p1.bin; ls host 0:0 /extlinux"
./u-boot -c "host bind 0 ../sd-p1.bin; ls host 0:0 /extlinux/"
./u-boot -c "host bind 0 ../sd-p1.bin; ls host 0:0 /extlinux/.."
./u-boot -c "host bind 0 ../sd-p1.bin; ls host 0:0 /extlinux/../"
./u-boot -c "host bind 0 ../sd-p1.bin; ls host 0:0 /extlinux/../backup"
./u-boot -c "host bind 0 ../sd-p1.bin; ls host 0:0 /extlinux/../backup/"
./u-boot -c "host bind 0 ../sd-p1.bin; ls host 0:0 /extlinux/../backup/.."
./u-boot -c "host bind 0 ../sd-p1.bin; ls host 0:0 /extlinux/../backup/../"
./u-boot -c "host bind 0 ../sd-p1.bin; load host 0:0 0 /bcm2835-rpi-cm.dtb"
./u-boot -c "host bind 0 ../sd-p1.bin; load host 0:0 0 /extlinux/../bcm2835-rpi-cm.dtb"
./u-boot -c "host bind 0 ../sd-p1.bin; load host 0:0 0 /backup/../bcm2835-rpi-cm.dtb"
./u-boot -c "host bind 0 ../sd-p1.bin; load host 0:0 0 /extlinux/..backup/../bcm2835-rpi-cm.dtb"
./u-boot -c "host bind 0 ../sd-p1.bin; load host 0:0 0 /extlinux/../backup/../bcm2835-rpi-cm.dtb"
(/extlinux and /backup are in different sectors so trigger some different
cases, and bcm2835-rpi-cm.dtb is in a sector of the root directory other
than the first).
In all honesty, this change is a bit of a hack, using goto and all.
However, as demonstrated above it appears to work well in practice, is
quite minimal, likely doesn't introduce any risk of regressions, and
hopefully doesn't introduce any maintenance issues.
The correct fix would be to collapse the root and non-root loops in
do_fat_read_at() and get_dentfromdir() into a single loop that has a
small special-case when moving from one sector to the next, to handle
the layout difference of root/non-root directories. AFAIK all other
aspects of directory parsing are identical. However, that's a much
larger change which needs significantly more thought before it's
implemented.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
The present fat implementation ignores FAT16 long name
directory entries which aren't placed in a single sector.
This was becouse of the buffer was always filled by the
two sectors, and the loop was made also for two sectors.
If some file long name entries are stored in two sectors,
the we have two cases:
Case 1:
Both of sectors are in the buffer - all required data
for long file name is in the buffer.
- Read OK!
Case 2:
The current directory entry is placed at the end of the
second buffered sector. And the next entries are placed
in a sector which is not buffered yet. Then two next
sectors are buffered and the mentioned entry is ignored.
- Read fail!
This commit fixes this issue by:
- read two sectors after loop on each single is done
- keep the last used sector as a first in the buffer
before the read of two next
The commit doesn't affects the fat32 imlementation,
which works good as previous.
Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Cc: Mikhail Zolotaryov <lebon@lebon.org.ua>
Cc: Tom Rini <trini@ti.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Suriyan Ramasami <suriyan.r@gmail.com>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Wolfgang Denk <wd@denx.de>
Tested-by: Simon Glass <sjg@chomium.org>
The sandbox/ext4/fat/generic fs commands do not gracefully deal with files
greater than 2GB. Negative values are returned in such cases.
To handle this, the fs functions have been modified to take an additional
parameter of type "* loff_t" which is then populated. The return value
of the fs functions are used only for error conditions.
Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
[trini: Update board/gdsys/p1022/controlcenterd-id.c,
drivers/fpga/zynqpl.c for changes]
Signed-off-by: Tom Rini <trini@ti.com>
Change the internal FAT functions to use loff_t for offsets.
Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
[trini: Fix fs/fat/fat.c for min3 updates]
Signed-off-by: Tom Rini <trini@ti.com>
U-Boot has never cared about the type when we get max/min of two
values, but Linux Kernel does. This commit gets min, max, min3, max3
macros synced with the kernel introducing type checks.
Many of references of those macros must be fixed to suppress warnings.
We have two options:
- Use min, max, min3, max3 only when the arguments have the same type
(or add casts to the arguments)
- Use min_t/max_t instead with the appropriate type for the first
argument
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Pavel Machek <pavel@denx.de>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
[trini: Fixup arch/blackfin/lib/string.c]
Signed-off-by: Tom Rini <trini@ti.com>
These commands may be used to determine the size of a file without
actually reading the whole file content into memory. This may be used
to determine if the file will fit into the memory buffer that will
contain it. In particular, the DFU code will use it for this purpose
in the next commit.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This hooks into the generic "file exists" support added in an earlier
patch, and provides an implementation for the FAT filesystem.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
It doesn't make a lot of sense to have these methods in fs.c. They are
filesystem-specific, not generic code. Add each to the relevant
filesystem and remove the associated #ifdefs in fs.c.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
ifdefs in the code are making it harder to read.
The use of simple if(vfat_enabled) makes no more code and is cleaner.
(the code is discarded by the compiler instead of the preprocessor.)
NB: if -O0 is used, the code won't be discarded
and bonus, now the code compiles even if CONFIG_SUPPORT_VFAT is not
defined.
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
toupper/tolower function are already declared, so use them.
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Stefano Babic <sbabic@denx.de>
In case a function argument is known/fixed size array in C, the argument is
still decoyed as pointer instead ( T f(U n[k]) ~= T fn(U *n) ) and therefore
calling sizeof on the function argument will result in the size of the pointer,
not the size of the array.
The VFAT code contains such a bug, this patch fixes it.
Reported-by: Aaron Williams <Aaron.Williams@cavium.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <tom.rini@gmail.com>
Cc: Aaron Williams <Aaron.Williams@cavium.com>
Tested-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
This makes the FAT filesystem API more consistent with other block-based
filesystems. If in the future standard multi-filesystem commands such as
"ls" or "load" are implemented, having FAT work the same way as other
filesystems will be necessary.
Convert cmd_fat.c to the new API, so the code looks more like other files
implementing the same commands for other filesystems.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
cur_part_info.{name,type} are strings. So, we don't need to memset()
the entire thing, just put the NULL-termination in the first byte.
Add missing initialization of the bootable and uuid fields.
None of these fields are actually used by fat.c. However, since it
stores the entire disk_partition_t, we should make sure that all fields
are valid.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
A future patch will implement the more standard filesystem API
fat_set_blk_dev(). This API has no way to know which partition number
the partition represents. Equally, future DM rework will make the
concept of partition number harder to pass around.
So, simply remove cur_part_nr from fat.c; its only use is in a
diagnostic printf, and the context where it's printed should make it
obvious which partition is referred to anyway (since the partition ID
would come from the user command-line that caused it).
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
The mkcksum() function now takes one parameter, the pointer to
11-byte wide character array, which it then operates on.
Currently, the function is wrongly passed (dir_entry)->name, which
is only 8-byte wide character array. Though by further inspecting
the dir_entry structure, it can be noticed that the name[8] entry
is immediatelly followed by ext[3] entry. Thus, name[8] and ext[3]
in the dir_entry structure actually work as this 11-byte wide array
since they're placed right next to each other by current compiler
behavior.
Depending on this is obviously wrong, thus fix this by correctly
passing both (dir_entry)->name and (dir_entry)->ext to the mkcksum()
function and adjust the function appropriately.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Tom Rini <trini@ti.com>
The recent switch to use get_device_and_partition() from do_fat_ls()
broke the ability to access a FAT filesystem directly on a whole device;
FAT only works within a partition on a device.
This change makes e.g. "fatls mmc 0:0" work; explicitly requesting
partition ID 0 is something that get_device_and_partition() fully
supports. However, fat_register_device() expects partition ID 1 to be
used in the full-disk case; partition ID 1 was previously implicitly
specified when the user didn't actually specify a partition ID. Update
fat_register_device() to expect the correct ID.
This change does imply that if a user explicitly executes "fatls mmc 0:1"
then this will fail, and may be a change in behaviour.
Note that this still prevents "fatls mmc 0:auto" from working. The next
patch will fix that.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
When storage devices contain files larger than the embedded RAM, it is
useful 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, etc.).
Hence, this patch makes it possible by adding a new FAT API to read
files from a given position. This patch also adds this feature to the
fatload command.
Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
Cc: Wolfgang Denk <wd@denx.de>
Signed-off-by: Tom Rini <trini@ti.com>
