<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/fs, branch v2014.07</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>fs: ext4: fix writing zero-length files</title>
<updated>2014-06-19T15:18:53+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2014-06-11T18:46:16+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=d018028055a21a28adef16b7f95422c426b46d60'/>
<id>d018028055a21a28adef16b7f95422c426b46d60</id>
<content type='text'>
ext4fs_allocate_blocks() always allocates at least one block for a file.
If the file size is zero, this causes total_remaining_blocks to
underflow, which then causes an apparent hang while 2^32 blocks are
allocated.

To solve this, check that total_remaining_blocks is non-zero as part of
the loop condition (i.e. before each loop) rather than at the end of
the loop.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ext4fs_allocate_blocks() always allocates at least one block for a file.
If the file size is zero, this causes total_remaining_blocks to
underflow, which then causes an apparent hang while 2^32 blocks are
allocated.

To solve this, check that total_remaining_blocks is non-zero as part of
the loop condition (i.e. before each loop) rather than at the end of
the loop.

Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>jffs2:jffs2_1pass.c: remove double braces</title>
<updated>2014-06-11T20:27:06+00:00</updated>
<author>
<name>Jeroen Hofstee</name>
<email>jeroen@myspectrum.nl</email>
</author>
<published>2014-06-10T22:40:25+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=46f46fd48e08ccd0f0cf2e9f38b5f32ad530a33f'/>
<id>46f46fd48e08ccd0f0cf2e9f38b5f32ad530a33f</id>
<content type='text'>
Clang interpretes an if condition like  "if ((a = b) == NULL)
as it tries to assign a value in a statement. Hence if you do
"if ((something)) it warns you that you might be confused.
Hence drop the double braces for plane if statements.

Signed-off-by: Jeroen Hofstee &lt;jeroen@myspectrum.nl&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Clang interpretes an if condition like  "if ((a = b) == NULL)
as it tries to assign a value in a statement. Hence if you do
"if ((something)) it warns you that you might be confused.
Hence drop the double braces for plane if statements.

Signed-off-by: Jeroen Hofstee &lt;jeroen@myspectrum.nl&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: correctly zero filename</title>
<updated>2014-06-11T20:27:05+00:00</updated>
<author>
<name>Jeroen Hofstee</name>
<email>jeroen@myspectrum.nl</email>
</author>
<published>2014-06-09T13:29:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=46a5707d9c2eefa23e88f7c63999adb9190c5b46'/>
<id>46a5707d9c2eefa23e88f7c63999adb9190c5b46</id>
<content type='text'>
Since ALLOC_CACHE_ALIGN_BUFFER declares a char* for filename
sizeof(filename) is not the size of the buffer. Use the already
known length instead.

cc: Uma Shankar &lt;uma.shankar@samsung.com&gt;
cc: Manjunatha C Achar &lt;a.manjunatha@samsung.com&gt;
cc: Marek Vasut &lt;marek.vasut@gmail.com&gt;
Signed-off-by: Jeroen Hofstee &lt;jeroen@myspectrum.nl&gt;
Acked-by: Marek Vasut &lt;marex@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since ALLOC_CACHE_ALIGN_BUFFER declares a char* for filename
sizeof(filename) is not the size of the buffer. Use the already
known length instead.

cc: Uma Shankar &lt;uma.shankar@samsung.com&gt;
cc: Manjunatha C Achar &lt;a.manjunatha@samsung.com&gt;
cc: Marek Vasut &lt;marek.vasut@gmail.com&gt;
Signed-off-by: Jeroen Hofstee &lt;jeroen@myspectrum.nl&gt;
Acked-by: Marek Vasut &lt;marex@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>disk: part_efi: clarify lbaint_t usage</title>
<updated>2014-06-05T18:44:56+00:00</updated>
<author>
<name>Steve Rae</name>
<email>srae@broadcom.com</email>
</author>
<published>2014-05-26T18:52:23+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=e04350d2991ed628587e94b5b6d89c24f439e172'/>
<id>e04350d2991ed628587e94b5b6d89c24f439e172</id>
<content type='text'>
- update the comments regarding lbaint_t usage
- cleanup casting of values related to the lbaint_t type
- cleanup of a type that requires a u64

Tested on little endian ARMv7 and ARMv8 configurations

Signed-off-by: Steve Rae &lt;srae@broadcom.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- update the comments regarding lbaint_t usage
- cleanup casting of values related to the lbaint_t type
- cleanup of a type that requires a u64

Tested on little endian ARMv7 and ARMv8 configurations

Signed-off-by: Steve Rae &lt;srae@broadcom.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs/fat: correct FAT16/12 file finding in root dir</title>
<updated>2014-05-12T20:31:51+00:00</updated>
<author>
<name>Wu, Josh</name>
<email>Josh.wu@atmel.com</email>
</author>
<published>2014-05-08T08:14:07+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=dd6d7967dfa88bd51062a8afb004962d16006ecd'/>
<id>dd6d7967dfa88bd51062a8afb004962d16006ecd</id>
<content type='text'>
When write a file into FAT file system, it will search a match file in
root dir. So the find_directory_entry() will get the first cluster of
root dir content and search the directory item one by one. If the file
is not found, we will call get_fatent_value() to get next cluster of root
dir via lookup the FAT table and continue the search.

The issue is in FAT16/12 system, we cannot get root dir's next clust
from FAT table. The FAT table only be use to find the clust of data
aera in FAT16/12.

In FAT16/12 if the clust is in root dir, the clust number is a negative
number or 0, 1. Since root dir is located in front of the data area.
Data area start clust #2. So the root dir clust number should &lt; 2.

This patch will check above situation before call get_fatenv_value().
If curclust is &lt; 2, include minus number, we just increase one on the
curclust since root dir is in continous cluster.

The patch also add a sanity check for entry in get_fatenv_value().

Signed-off-by: Josh Wu &lt;josh.wu@atmel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When write a file into FAT file system, it will search a match file in
root dir. So the find_directory_entry() will get the first cluster of
root dir content and search the directory item one by one. If the file
is not found, we will call get_fatent_value() to get next cluster of root
dir via lookup the FAT table and continue the search.

The issue is in FAT16/12 system, we cannot get root dir's next clust
from FAT table. The FAT table only be use to find the clust of data
aera in FAT16/12.

In FAT16/12 if the clust is in root dir, the clust number is a negative
number or 0, 1. Since root dir is located in front of the data area.
Data area start clust #2. So the root dir clust number should &lt; 2.

This patch will check above situation before call get_fatenv_value().
If curclust is &lt; 2, include minus number, we just increase one on the
curclust since root dir is in continous cluster.

The patch also add a sanity check for entry in get_fatenv_value().

Signed-off-by: Josh Wu &lt;josh.wu@atmel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: fat_write: fix the incorrect last cluster checking</title>
<updated>2014-05-12T20:31:50+00:00</updated>
<author>
<name>Wu, Josh</name>
<email>Josh.wu@atmel.com</email>
</author>
<published>2014-05-08T08:14:06+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=2e98f70882f8c1a09b662137884c1435a97c9a1c'/>
<id>2e98f70882f8c1a09b662137884c1435a97c9a1c</id>
<content type='text'>
In fat_write.c, the last clust condition check is incorrect:

  if ((curclust &gt;= 0xffffff8) || (curclust &gt;= 0xfff8)) {
  	... ...
  }

For example, in FAT32 if curclust is 0x11000. It is a valid clust.
But on above condition check, it will be think as a last clust.

So the correct last clust check should be:
  in fat32, curclust &gt;= 0xffffff8
  in fat16, curclust &gt;= 0xfff8
  in fat12, curclust &gt;= 0xff8

This patch correct the last clust check.

Signed-off-by: Josh Wu &lt;josh.wu@atmel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In fat_write.c, the last clust condition check is incorrect:

  if ((curclust &gt;= 0xffffff8) || (curclust &gt;= 0xfff8)) {
  	... ...
  }

For example, in FAT32 if curclust is 0x11000. It is a valid clust.
But on above condition check, it will be think as a last clust.

So the correct last clust check should be:
  in fat32, curclust &gt;= 0xffffff8
  in fat16, curclust &gt;= 0xfff8
  in fat12, curclust &gt;= 0xff8

This patch correct the last clust check.

Signed-off-by: Josh Wu &lt;josh.wu@atmel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs:ext4:write:fix: Reinitialize global variables after updating a file</title>
<updated>2014-05-12T20:31:50+00:00</updated>
<author>
<name>Łukasz Majewski</name>
<email>l.majewski@samsung.com</email>
</author>
<published>2014-05-06T07:36:05+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8b454eeeea0ba021ee27f3e103daf1f8fa87bd16'/>
<id>8b454eeeea0ba021ee27f3e103daf1f8fa87bd16</id>
<content type='text'>
This bug shows up when file stored on the ext4 file system is updated.

The ext4fs_delete_file() is responsible for deleting file's (e.g. uImage)
data.
However some global data (especially ext4fs_indir2_block), which is used
during file deletion are left unchanged.

The ext4fs_indir2_block pointer stores reference to old ext4 double
indirect allocated blocks. When it is unchanged, after file deletion,
ext4fs_write_file() uses the same pointer (since it is already initialized
- i.e. not NULL) to return number of blocks to write. This trunks larger
file when previous one was smaller.

Lets consider following scenario:

1. Flash target with ext4 formatted boot.img (which has uImage [*] on itself)
2. Developer wants to upload their custom uImage [**]
	- When new uImage [**] is smaller than the [*] - everything works
	correctly - we are able to store the whole smaller file with corrupted
	ext4fs_indir2_block pointer
	- When new uImage [**] is larger than the [*] - theCRC is corrupted,
	since truncation on data stored at eMMC was done.
3. When uImage CRC error appears, then reboot and LTHOR/DFU reflashing causes
	proper setting of ext4fs_indir2_block() and after that uImage[**]
	is successfully stored (correct uImage [*] metadata is stored at an
	eMMC on the first flashing).

Due to above the bug was very difficult to reproduce.
This patch sets default values for all ext4fs_indir* pointers/variables.

Signed-off-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This bug shows up when file stored on the ext4 file system is updated.

The ext4fs_delete_file() is responsible for deleting file's (e.g. uImage)
data.
However some global data (especially ext4fs_indir2_block), which is used
during file deletion are left unchanged.

The ext4fs_indir2_block pointer stores reference to old ext4 double
indirect allocated blocks. When it is unchanged, after file deletion,
ext4fs_write_file() uses the same pointer (since it is already initialized
- i.e. not NULL) to return number of blocks to write. This trunks larger
file when previous one was smaller.

Lets consider following scenario:

1. Flash target with ext4 formatted boot.img (which has uImage [*] on itself)
2. Developer wants to upload their custom uImage [**]
	- When new uImage [**] is smaller than the [*] - everything works
	correctly - we are able to store the whole smaller file with corrupted
	ext4fs_indir2_block pointer
	- When new uImage [**] is larger than the [*] - theCRC is corrupted,
	since truncation on data stored at eMMC was done.
3. When uImage CRC error appears, then reboot and LTHOR/DFU reflashing causes
	proper setting of ext4fs_indir2_block() and after that uImage[**]
	is successfully stored (correct uImage [*] metadata is stored at an
	eMMC on the first flashing).

Due to above the bug was very difficult to reproduce.
This patch sets default values for all ext4fs_indir* pointers/variables.

Signed-off-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs:ext4:cleanup: Remove superfluous code</title>
<updated>2014-05-12T20:31:50+00:00</updated>
<author>
<name>Łukasz Majewski</name>
<email>l.majewski@samsung.com</email>
</author>
<published>2014-05-06T07:36:04+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=35dd055b94eb3ed8c21595eedd740431866b2f26'/>
<id>35dd055b94eb3ed8c21595eedd740431866b2f26</id>
<content type='text'>
Code responsible for handling situation when ext4 has block size of 1024B
can be ordered to take less space.

This patch does that for ext4 common and write files.

Signed-off-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Code responsible for handling situation when ext4 has block size of 1024B
can be ordered to take less space.

This patch does that for ext4 common and write files.

Signed-off-by: Lukasz Majewski &lt;l.majewski@samsung.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: ubifs: drop __DATE__ and __TIME__</title>
<updated>2014-05-12T19:19:46+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.m@jp.panasonic.com</email>
</author>
<published>2014-04-18T10:09:50+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9995d8c8dca4dced5be7c86f75cf53d3166bdead'/>
<id>9995d8c8dca4dced5be7c86f75cf53d3166bdead</id>
<content type='text'>
__DATE__ and __TIME__ makes the build non-deterministic.
Drop the debug message using them.

Signed-off-by: Masahiro Yamada &lt;yamada.m@jp.panasonic.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
__DATE__ and __TIME__ makes the build non-deterministic.
Drop the debug message using them.

Signed-off-by: Masahiro Yamada &lt;yamada.m@jp.panasonic.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: fat: Fix cache align error message in fatwrite</title>
<updated>2014-05-12T19:19:45+00:00</updated>
<author>
<name>Nobuhiro Iwamatsu</name>
<email>nobuhiro.iwamatsu.yj@renesas.com</email>
</author>
<published>2014-04-08T02:12:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8abd053cf07a1e4264d59c671e05a602fc7a31ad'/>
<id>8abd053cf07a1e4264d59c671e05a602fc7a31ad</id>
<content type='text'>
Use of malloc of do_fat_write() causes cache error on ARM v7 platforms.
Perhaps, the same problem will occur at any other CPUs.
This replaces malloc with memalign to fix cache buffer alignment.

Signed-off-by: Nobuhiro Iwamatsu &lt;nobuhiro.iwamatsu.yj@renesas.com&gt;
Signed-off-by: Yoshiyuki Ito &lt;yoshiyuki.ito.ub@renesas.com&gt;
Tested-by: Hector Palacios &lt;hector.palacios@digi.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use of malloc of do_fat_write() causes cache error on ARM v7 platforms.
Perhaps, the same problem will occur at any other CPUs.
This replaces malloc with memalign to fix cache buffer alignment.

Signed-off-by: Nobuhiro Iwamatsu &lt;nobuhiro.iwamatsu.yj@renesas.com&gt;
Signed-off-by: Yoshiyuki Ito &lt;yoshiyuki.ito.ub@renesas.com&gt;
Tested-by: Hector Palacios &lt;hector.palacios@digi.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
