Hi Przemyslaw, On 12 December 2014 at 08:30, Przemyslaw Marczak <p.marc...@samsung.com> wrote: > Hello, > > > On 12/12/2014 01:32 AM, Simon Glass wrote: >> >> 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] >> > > Probably this is an another case which is caused by the sector buffer bug. > Does this patch fixed your issue? > > I have some simple test for manual use with the ums tool. > It just copy the test files to the tested fat16 partition mounted using the > UMS, next it computes CRC32 of those files on the host and next using U-Boot > fatload/crc32 commands - it tests the read feature. But it's not full > automated - I didn't work on getting the log from U-Boot console. > > So I could check if the file checksums are proper and if all files were > found on the partiion, by the U-Boot read command. It's not useful for the > "test/fs/fs-test.sh" because this is not designed for the sandbox. > My test writes some commands directly to U-Boot console, like this: echo > "some cmd" > /dev/ttyS0. > > Unfortunately the sandbox config seems to be broken. > > The bug was not so obvious, any read/write on fat partition can change fat > directory entries or add the new ones and then all data can be read right. > > I will send the scripts for such simple test.
I'm not sure if it fixes my problem but it seems likely. I will see if I can make time to test it. If you want to write input data to U-Boot sandbox we can do that fairly easily. You can import cros_subprocess and use the function there to generate output from your test and inspect the input from U-Boot's command line. Let me know if you'd like an example. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
