[U-Boot] [PATCH] fs: fat: read: fix fat16 ls/read issue

[Simon Glass]

Hi Przemyslaw,

On 11 December 2014 at 05:01, Przemyslaw Marczak <p.marczak at 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]