Hi Przemyslaw, On 17 December 2014 at 02:03, Przemyslaw Marczak <p.marc...@samsung.com> wrote: > Hello, > > > On 12/16/2014 11:26 PM, Simon Glass wrote: >> >> 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 >> > > Before, I wrote, that sandbox seems to be broken, sorry for this - it was > just my dirty repo - sandbox compiles and works well.
Somewhat bewildering, but it does not in fact fix my problem. Here is a compressed version of the fat filesystem if you want to take a look: https://drive.google.com/file/d/0B7WYZbZ9zd-3NGRMNkFQQTdtV2M/view?usp=sharing Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
