From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?Br=FCns=2C_Stefan?= Date: Fri, 9 Sep 2016 16:34:40 +0000 Subject: [U-Boot] [PATCH 2/2] fs/fat: Optimizes memory size with single global variable instead of 3 In-Reply-To: References: <1469686268-30805-1-git-send-email-tfchee@altera.com> Message-ID: <1665374.aYEjcpluY2@sbruens-linux> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sonntag, 14. August 2016 00:57:38 CEST Beno?t Th?baudeau wrote: > Hi, > > On Tue, Aug 2, 2016 at 9:35 PM, Beno?t Th?baudeau > > wrote: > > On Tue, Aug 2, 2016 at 8:53 PM, Stephen Warren wrote: > >> On 07/28/2016 12:11 AM, Tien Fong Chee wrote: > >>> Single 64KB get_contents_vfatname_block global variable would be used > >>> for > >>> all FAT implementation instead of allocating additional two global > >>> variables > >>> which are get_denfromdir_block and do_fat_read_at_block. This > >>> implementation > >>> can help in saving up 128KB memory space. > >> > >> The series, > >> > >> Tested-by: Stephen Warren > >> (via DFU's FAT reading/writing on various Tegra; likely primarily FAT > >> rather than VFAT though) > >> > >> Reviewed-by: Stephen Warren > > > > I suspect that reading a filename with VFAT entries crossing a cluster > > boundary in a FAT32 root directory will be broken by this series. I do > > not have time to test this and other corner cases right now though, > > but it will be possible in the next few weeks. > > I have tested VFAT long filenames with the current implementation on > Sandbox. It's completely broken: > - There is a length limit somewhere between 111 and 120 characters, > instead of 256 characters. Beyond this limit, the files are invisible > with ls. That one is expected. U-Boot limits the extended name to 9 "slots", each 26 bytes. As filenames are encoded as UTF-16/UCS-2, each ASCII character uses two bytes -> 9 * 26 / 2 = 117. > - Some filenames are truncated or mixed up between files. I have > tested 111-character random filenames for 1000 empty files in the root > directory. Most filenames had the expected length, but a few were > shorter or longer. Where there any filenames with characters outside the ASCII range? There may have been some double en-/decoding of UTF-8 vs UTF-16. Kind regards, Stefan