Hi Przemyslaw, On 11 December 2014 at 05:01, Przemyslaw Marczak <p.marc...@samsung.com> wrote: > > 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.
This is very interesting\! Is this the same failure that I saw on this thread? http://u-boot.10912.n7.nabble.com/PATCH-U-Boot-ARM-rpi-b-detect-board-revision-td196720.html (search for fatload) "I tried this out. It worked OK for me except that it can't find the device tree file bcm2835-rpi-b-rev2.dtb. Oddly I can fatload it from /bcm2835-rpi-b-rev2.dtb but when I try from /syslinux/..//bcm2835-rpi-b-rev2.dtb it fails and cannot find the file. Reducing the filename length to 8 chars works. I wonder what year of my life FAT will stop plaguing me? " Also can you write a test for this in test/fs/fs-test.sh? Regards, Simon [snip] _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot