<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/fs, branch v2021.10</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: avoid superfluous messages</title>
<updated>2021-09-24T16:09:46+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>heinrich.schuchardt@canonical.com</email>
</author>
<published>2021-09-20T12:15:03+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=3bd0e2caa974aa300aadad171abe741d6edbc3b3'/>
<id>3bd0e2caa974aa300aadad171abe741d6edbc3b3</id>
<content type='text'>
Output like the following is quite irritating:

    =&gt; bootefi hello
    Scanning disk mmc2.blk...
    No valid Btrfs found
    Bad magic number for SquashFS image.
    ** Unrecognized filesystem type **
    Scanning disk mmc1.blk...
    No valid Btrfs found
    Bad magic number for SquashFS image.
    ** Unrecognized filesystem type **
    Scanning disk mmc0.blk...
    No valid Btrfs found
    Bad magic number for SquashFS image.
    ** Unrecognized filesystem type **

Albeit a whole disk may be formatted with a filesystem in most cases
a partition table is used and the whole disk (partition number 0) doesn't
contain a filesytem. Some partitions may only contain a blob. Not seeing a
filesytem on the whole disk or on any partition is only worth a debug
message.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Output like the following is quite irritating:

    =&gt; bootefi hello
    Scanning disk mmc2.blk...
    No valid Btrfs found
    Bad magic number for SquashFS image.
    ** Unrecognized filesystem type **
    Scanning disk mmc1.blk...
    No valid Btrfs found
    Bad magic number for SquashFS image.
    ** Unrecognized filesystem type **
    Scanning disk mmc0.blk...
    No valid Btrfs found
    Bad magic number for SquashFS image.
    ** Unrecognized filesystem type **

Albeit a whole disk may be formatted with a filesystem in most cases
a partition table is used and the whole disk (partition number 0) doesn't
contain a filesytem. Some partitions may only contain a blob. Not seeing a
filesytem on the whole disk or on any partition is only worth a debug
message.

Signed-off-by: Heinrich Schuchardt &lt;heinrich.schuchardt@canonical.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>btrfs: Use default subvolume as filesystem root</title>
<updated>2021-09-01T14:11:24+00:00</updated>
<author>
<name>Matwey V. Kornilov</name>
<email>matwey.kornilov@gmail.com</email>
</author>
<published>2021-08-01T20:52:16+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=94509b79b13e69c209199af0757afbde8d2ebd6d'/>
<id>94509b79b13e69c209199af0757afbde8d2ebd6d</id>
<content type='text'>
BTRFS volume consists of a number of subvolumes which can be mounted separately
from each other. The top-level subvolume always exists even if no subvolumes
were created manually. A subvolume can be denoted as the default subvolume i.e.
the subvolume which is mounted by default.

The default "default subvolume" is the top-level one, but this is far from the
common practices used in the wild. For instance, openSUSE provides an OS
snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root
filesystem is located into a separate subvolume which is "default" but not
"top-level". That means that the /boot/dtb/ directory is also located inside
this default subvolume instead of top-level one.

However, the existing btrfs u-boot driver always uses the top-level subvolume
as the filesystem root. This behaviour 1) is inconsistent with

    mount /dev/sda1 /target

command, which mount the default subvolume 2) leads to the issues when
/boot/dtb cannot be found properly (see the reference).

This patch uses the default subvolume as the filesystem root to overcome
mentioned issues.

Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656
Signed-off-by: Matwey V. Kornilov &lt;matwey.kornilov@gmail.com&gt;
Fixes: f06bfcf54d0e ("fs: btrfs: Crossport open_ctree_fs_info() from btrfs-progs")
Reviewed-by: Qu Wenruo &lt;wqu@suse.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
BTRFS volume consists of a number of subvolumes which can be mounted separately
from each other. The top-level subvolume always exists even if no subvolumes
were created manually. A subvolume can be denoted as the default subvolume i.e.
the subvolume which is mounted by default.

The default "default subvolume" is the top-level one, but this is far from the
common practices used in the wild. For instance, openSUSE provides an OS
snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root
filesystem is located into a separate subvolume which is "default" but not
"top-level". That means that the /boot/dtb/ directory is also located inside
this default subvolume instead of top-level one.

However, the existing btrfs u-boot driver always uses the top-level subvolume
as the filesystem root. This behaviour 1) is inconsistent with

    mount /dev/sda1 /target

command, which mount the default subvolume 2) leads to the issues when
/boot/dtb cannot be found properly (see the reference).

This patch uses the default subvolume as the filesystem root to overcome
mentioned issues.

Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656
Signed-off-by: Matwey V. Kornilov &lt;matwey.kornilov@gmail.com&gt;
Fixes: f06bfcf54d0e ("fs: btrfs: Crossport open_ctree_fs_info() from btrfs-progs")
Reviewed-by: Qu Wenruo &lt;wqu@suse.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs/squashfs: Fix some hardlinks reading the wrong inode</title>
<updated>2021-08-04T19:58:31+00:00</updated>
<author>
<name>Campbell Suter</name>
<email>campbell@snapit.group</email>
</author>
<published>2021-04-30T04:45:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a1ff2cb4d433f983b25a2b2920dbfcea5dc4555c'/>
<id>a1ff2cb4d433f983b25a2b2920dbfcea5dc4555c</id>
<content type='text'>
In SquashFS, the contents of a directory is stored by
squashfs_directory_entry structures which contain the file's name, inode
and position within the filesystem.

The inode number is not stored directly; instead each directory has one
or more headers which set a base inode number, and files store the
offset from that to the file's inode number.

In mksquashfs, each inode is allocated a number in the same order as
they are written to the directory table; thus the offset from the
header's base inode number to the file's inode number is usually
positive.

Hardlinks are simply stored with two directory entries referencing the
same file. This means the second entry will thus have an inode number
much lower than the surrounding files. Since the header's base inode
number comes from the first entry that uses the header, this delta will
usually be negative.

Previously, U-Boot's squashfs_directory_entry.inode_offset field was
declared as an unsigned value. Thus when a negative value was found, it
would either resolve to an invalid inode number or to that of an
unrelated file.

A squashfs image to test this can be created like so:

    echo hi &gt; sqfs_test_files/001-root-file
    mkdir     sqfs_test_files/002-subdir
    touch     sqfs_test_files/002-subdir/003-file
    ln        sqfs_test_files/{001-root-file,002-subdir/004-link}
    mksquashfs sqfs_test_files/ test.sqfs -noappend

Note that squashfs sorts the files ASCIIbetacally, so we can use the
names to control the order they appear in. The ordering is important -
the first reference to the file must have a lower inode number than the
directory in which the second reference resides, and the second
reference cannot be the first file in the directory.

Listing this sample image in U-Boot results in:

=&gt; sqfsls virtio 2 002-subdir
         0   003-file
Inode not found.
         0   004-link

Signed-off-by: Campbell Suter &lt;campbell@snapit.group&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In SquashFS, the contents of a directory is stored by
squashfs_directory_entry structures which contain the file's name, inode
and position within the filesystem.

The inode number is not stored directly; instead each directory has one
or more headers which set a base inode number, and files store the
offset from that to the file's inode number.

In mksquashfs, each inode is allocated a number in the same order as
they are written to the directory table; thus the offset from the
header's base inode number to the file's inode number is usually
positive.

Hardlinks are simply stored with two directory entries referencing the
same file. This means the second entry will thus have an inode number
much lower than the surrounding files. Since the header's base inode
number comes from the first entry that uses the header, this delta will
usually be negative.

Previously, U-Boot's squashfs_directory_entry.inode_offset field was
declared as an unsigned value. Thus when a negative value was found, it
would either resolve to an invalid inode number or to that of an
unrelated file.

A squashfs image to test this can be created like so:

    echo hi &gt; sqfs_test_files/001-root-file
    mkdir     sqfs_test_files/002-subdir
    touch     sqfs_test_files/002-subdir/003-file
    ln        sqfs_test_files/{001-root-file,002-subdir/004-link}
    mksquashfs sqfs_test_files/ test.sqfs -noappend

Note that squashfs sorts the files ASCIIbetacally, so we can use the
names to control the order they appear in. The ordering is important -
the first reference to the file must have a lower inode number than the
directory in which the second reference resides, and the second
reference cannot be the first file in the directory.

Listing this sample image in U-Boot results in:

=&gt; sqfsls virtio 2 002-subdir
         0   003-file
Inode not found.
         0   004-link

Signed-off-by: Campbell Suter &lt;campbell@snapit.group&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>global: Convert simple_strtoul() with hex to hextoul()</title>
<updated>2021-08-02T17:32:14+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2021-07-24T15:03:29+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7e5f460ec457fe310156e399198a41eb0ce1e98c'/>
<id>7e5f460ec457fe310156e399198a41eb0ce1e98c</id>
<content type='text'>
It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.

Add a proper comment to simple_strtoul() while we are here.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.

Add a proper comment to simple_strtoul() while we are here.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Use LIB_UUID with ACPIGEN and FS_BTRFS</title>
<updated>2021-07-28T18:27:54+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2021-07-02T18:36:15+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8b6ee2484cf7eadc2be6e1768f894acd07856b43'/>
<id>8b6ee2484cf7eadc2be6e1768f894acd07856b43</id>
<content type='text'>
Since the ACPI-generation code makes use of UUIDs we typically need to
enabled UUID support for it to build. Add a new Kconfig condition.

Use it for BTRFS also.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since the ACPI-generation code makes use of UUIDs we typically need to
enabled UUID support for it to build. Add a new Kconfig condition.

Use it for BTRFS also.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cbfs: Check offset range when reading a file</title>
<updated>2021-07-15T22:42:05+00:00</updated>
<author>
<name>Simon Glass</name>
<email>sjg@chromium.org</email>
</author>
<published>2021-05-14T01:39:27+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=99eaf1fcaa260dceea25ed25830498abf70f0728'/>
<id>99eaf1fcaa260dceea25ed25830498abf70f0728</id>
<content type='text'>
Add a check that the offset is within the allowed range.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reported-by: Coverity (CID: 331155)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a check that the offset is within the allowed range.

Signed-off-by: Simon Glass &lt;sjg@chromium.org&gt;
Reported-by: Coverity (CID: 331155)
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: fat: add file attributes to struct fs_dirent</title>
<updated>2021-07-12T18:30:48+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>xypron.glpk@gmx.de</email>
</author>
<published>2021-05-15T20:06:16+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=13c11c665320beff22ea94674da42719b6281501'/>
<id>13c11c665320beff22ea94674da42719b6281501</id>
<content type='text'>
When reading a directory in the UEFI file system we have to return file
attributes and timestamps. Copy this data to the directory entry structure.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When reading a directory in the UEFI file system we have to return file
attributes and timestamps. Copy this data to the directory entry structure.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs/squashfs: fix reading of fragmented files</title>
<updated>2021-06-10T00:58:20+00:00</updated>
<author>
<name>Joao Marcos Costa</name>
<email>jmcosta944@gmail.com</email>
</author>
<published>2021-05-17T21:20:38+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=0008d8086649d3bb3afd0c4697f5b73ccf6f293d'/>
<id>0008d8086649d3bb3afd0c4697f5b73ccf6f293d</id>
<content type='text'>
The fragmented files were not correctly read because of two issues:

- The squashfs_file_info struct has a field named 'comp', which tells if
the file's fragment is compressed or not. This field was always set to
'true' in sqfs_get_regfile_info and sqfs_get_lregfile_info. It should
actually take sqfs_frag_lookup's return value. This patch addresses
these two assignments.

- In sqfs_read, the fragments (compressed or not) were copied to the
output buffer through a for loop which was reading data at the wrong
offset. Replace these loops by equivalent calls to memcpy, with the
right parameters.

I tested this patch by comparing the MD5 checksum of a few fragmented
files with the respective md5sum output in sandbox, considering both
compressed and uncompressed fragments.

Signed-off-by: Joao Marcos Costa &lt;jmcosta944@gmail.com&gt;
Tested-by: Richard Genoud &lt;richard.genoud@posteo.net&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The fragmented files were not correctly read because of two issues:

- The squashfs_file_info struct has a field named 'comp', which tells if
the file's fragment is compressed or not. This field was always set to
'true' in sqfs_get_regfile_info and sqfs_get_lregfile_info. It should
actually take sqfs_frag_lookup's return value. This patch addresses
these two assignments.

- In sqfs_read, the fragments (compressed or not) were copied to the
output buffer through a for loop which was reading data at the wrong
offset. Replace these loops by equivalent calls to memcpy, with the
right parameters.

I tested this patch by comparing the MD5 checksum of a few fragmented
files with the respective md5sum output in sandbox, considering both
compressed and uncompressed fragments.

Signed-off-by: Joao Marcos Costa &lt;jmcosta944@gmail.com&gt;
Tested-by: Richard Genoud &lt;richard.genoud@posteo.net&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs: btrfs: Add missing cache aligned allocation</title>
<updated>2021-05-26T21:26:07+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2021-05-17T22:39:39+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=9e8bb078859a559b17effdb21bafdb050b859b6e'/>
<id>9e8bb078859a559b17effdb21bafdb050b859b6e</id>
<content type='text'>
The superblock buffer must be cache aligned, since it might be used
in DMA context, allocate it using ALLOC_CACHE_ALIGN_BUFFER() just
like it was done in btrfs_read_superblock() and read_tree_node().

This fixes this output on boot and non-working btrfs on iMX53:
CACHE: Misaligned operation at range [ced299d0, ced2a9d0]

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marek Behún &lt;marek.behun@nic.cz&gt;
Cc: Qu Wenruo &lt;wqu@suse.com&gt;
Reviewed-by: Marek Behún &lt;marek.behun@nic.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The superblock buffer must be cache aligned, since it might be used
in DMA context, allocate it using ALLOC_CACHE_ALIGN_BUFFER() just
like it was done in btrfs_read_superblock() and read_tree_node().

This fixes this output on boot and non-working btrfs on iMX53:
CACHE: Misaligned operation at range [ced299d0, ced2a9d0]

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Marek Behún &lt;marek.behun@nic.cz&gt;
Cc: Qu Wenruo &lt;wqu@suse.com&gt;
Reviewed-by: Marek Behún &lt;marek.behun@nic.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>fs/squashfs: zero out unused fields in fs_dirent</title>
<updated>2021-05-26T21:26:07+00:00</updated>
<author>
<name>Heinrich Schuchardt</name>
<email>xypron.glpk@gmx.de</email>
</author>
<published>2021-05-17T06:21:39+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=53ba2c21c2df142b37bb2f0d6850d79dcfd8976f'/>
<id>53ba2c21c2df142b37bb2f0d6850d79dcfd8976f</id>
<content type='text'>
When reading directories the UEFI sub-system must supply file attributes
and timestamps. These fields will have to be added to struct fs_dirent.
SquashFS should not fill these fields with random data. Ensure that they
are zeroed out.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When reading directories the UEFI sub-system must supply file attributes
and timestamps. These fields will have to be added to struct fs_dirent.
SquashFS should not fill these fields with random data. Ensure that they
are zeroed out.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
