On Fri, Jun 21, 2019 at 03:35:35PM +0200, Marek Szyprowski wrote:
> JOURNAL is optional for EXT4 (and EXT3) filesystems, so add support for
> skipping it. This fixes corrupting EXT4 volumes without JOURNAL after
> using uboot's 'ext4write' command.
>
> Signed-off-by: Marek Szyprowski
> Reviewed-
On Fri, Jun 21, 2019 at 03:32:51PM +0200, Marek Szyprowski wrote:
> The block count entry in the EXT4 filesystem disk structures uses
> standard 512-bytes units for most of the typical files. The only
> exception are HUGE files, which use the filesystem block size, but those
> are not supported by
On Fri, 21 Jun 2019 15:35:35 +0200
Marek Szyprowski wrote:
> JOURNAL is optional for EXT4 (and EXT3) filesystems, so add support
> for skipping it. This fixes corrupting EXT4 volumes without JOURNAL
> after using uboot's 'ext4write' command.
>
> Signed-off-by: Marek Szyprowski
> ---
> fs/ext4/
On Fri, 21 Jun 2019 15:32:51 +0200
Marek Szyprowski wrote:
> The block count entry in the EXT4 filesystem disk structures uses
> standard 512-bytes units for most of the typical files. The only
> exception are HUGE files, which use the filesystem block size, but
> those are not supported by uboot
The block count entry in the EXT4 filesystem disk structures uses
standard 512-bytes units for most of the typical files. The only
exception are HUGE files, which use the filesystem block size, but those
are not supported by uboot's EXT4 implementation anyway. This patch fixes
the EXT4 code to use
JOURNAL is optional for EXT4 (and EXT3) filesystems, so add support for
skipping it. This fixes corrupting EXT4 volumes without JOURNAL after
using uboot's 'ext4write' command.
Signed-off-by: Marek Szyprowski
---
fs/ext4/ext4_journal.c | 4
fs/ext4/ext4_journal.h | 2 ++
2 files changed, 6
Extent index blocks are read many times when reading completely a big file.
This is time costly if underlying driver is slow.
Caching the first index blocks cost a bit of RAM but speed up file reading a
lot.
---
fs/ext4/ext4_common.c | 93 ---
fs/ex
A sparse file may have regions not mapped by any extents, at the start
or at the end of the file, or anywhere between, thus not finding a
matching extent region is never an error.
Found by python filesystem tests.
Signed-off-by: Stefan Brüns
---
fs/ext4/ext4_common.c | 31 +++---
On Freitag, 2. September 2016 10:53:08 CEST you wrote:
> >
> > Adding this to the current test script is somewhat problematic. The test
> > runs all tests for fat and ext4, so each testcase should be file system
> > agnostic. Unfortunately fat and ext4 (at least as implemented in U-Boot)
> > have
On Sun, Aug 28, 2016 at 09:44:41PM +0200, Stefan Bruens wrote:
> On Freitag, 19. August 2016 15:54:51 CEST you wrote:
> > On Sun, Aug 14, 2016 at 05:11:04AM +0200, Stefan Brüns wrote:
> > > The following command triggers a segfault in search_dir:
> > > ./sandbox/u-boot -c 'host bind 0 ./sandbox/tes
On Freitag, 19. August 2016 15:54:51 CEST you wrote:
> On Sun, Aug 14, 2016 at 05:11:04AM +0200, Stefan Brüns wrote:
> > The following command triggers a segfault in search_dir:
> > ./sandbox/u-boot -c 'host bind 0 ./sandbox/test/fs/3GB.ext4.img ;
> >
> > ext4write host 0 0 /./foo 0x10'
> >
>
On Sun, Aug 14, 2016 at 05:11:04AM +0200, Stefan Brüns wrote:
> The following command triggers a segfault in search_dir:
> ./sandbox/u-boot -c 'host bind 0 ./sandbox/test/fs/3GB.ext4.img ;
> ext4write host 0 0 /./foo 0x10'
>
> The following command triggers a segfault in check_filename:
> ./s
The following command triggers a segfault in search_dir:
./sandbox/u-boot -c 'host bind 0 ./sandbox/test/fs/3GB.ext4.img ;
ext4write host 0 0 /./foo 0x10'
The following command triggers a segfault in check_filename:
./sandbox/u-boot -c 'host bind 0 ./sandbox/test/fs/3GB.ext4.img ;
ext4writ
On 11/04/2014 05:21 PM, Lukasz Majewski wrote:
> After the clean up performed in the commit 1151b7ac10b81ecbb the DFU
> subsystem requires absolute patch for correct operation.
s/patch/path
>
> Signed-off-by: Lukasz Majewski
Acked-by: Robert Baldyga
> ---
> include/configs/s5p_goni.h | 4 ++
After the clean up performed in the commit 1151b7ac10b81ecbb the DFU
subsystem requires absolute patch for correct operation.
Signed-off-by: Lukasz Majewski
---
include/configs/s5p_goni.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/s5p_goni.h b/include
After the clean up performed in the commit 1151b7ac10b81ecbb the DFU subsystem
requires absolute patch for correct operation.
Signed-off-by: Lukasz Majewski
---
include/configs/trats.h | 6 +++---
include/configs/trats2.h | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git
Dear Lukasz,
In message <20140131110818.07d79eac@amdc2363> you wrote:
>
> > I do not see any such need. Hex input base is the established and
> > documented default - ext4write is not a special command, so why should
> > we mention this here when we do not mention it anywhere else?
>
> If now a
Hi Wolfgang,
> Dear Lukasz,
>
> In message <20140131102755.63297928@amdc2363> you wrote:
> >
> > > ext4write mmc 0:2 ${addr} ${filename} ${filesize}
> > >
> > > Change this to use the standard notation of base 16 input format.
> > > See also commit b770e88
> > >
> > > WARNING: this is a chan
Dear Lukasz,
In message <20140131102755.63297928@amdc2363> you wrote:
>
> > ext4write mmc 0:2 ${addr} ${filename} ${filesize}
> >
> > Change this to use the standard notation of base 16 input format.
> > See also commit b770e88
> >
> > WARNING: this is a change to the user interface!!
>
>
Hi Wolfgang,
> Unlike other commands (for example, "fatwrite"), ext4write would
> interpret the "sizebytes" as decimal number. This is not only
> inconsistend and unexpected to most users, it also breaks usage
> like this:
>
> tftp ${addr} ${name}
> ext4write mmc 0:2 ${addr} ${filena
Unlike other commands (for example, "fatwrite"), ext4write would
interpret the "sizebytes" as decimal number. This is not only
inconsistend and unexpected to most users, it also breaks usage
like this:
tftp ${addr} ${name}
ext4write mmc 0:2 ${addr} ${filename} ${filesize}
Change
On Thu, May 23, 2013 at 02:22:10PM -0600, Stephen Warren wrote:
> From: Stephen Warren
>
> Commit 50ce4c0 "fs/ext4: Support device block sizes != 512 bytes"
> modified ext4fs_set_blk_dev() to calculate total_sect based on
> get_fs()->dev_desc->log2blksz rather than SECTOR_SIZE. However, this
> v
From: Stephen Warren
Commit 50ce4c0 "fs/ext4: Support device block sizes != 512 bytes"
modified ext4fs_set_blk_dev() to calculate total_sect based on
get_fs()->dev_desc->log2blksz rather than SECTOR_SIZE. However, this
value wasn't yet assigned. Move the assignment earlier so the code
doesn't cra
On Tue, Oct 23, 2012 at 04:49:25PM -0700, Simon Glass wrote:
> Fix the following error in the ext4 command:
>
> cmd_ext4.c:110:3: error: format '%lu' expects argument of type
> 'long unsigned int', but argument 4 has type 'int' [-Werror=format]
>
> Signed-off-by: Simon Glass
Applied to u-boot/
Fix the following error in the ext4 command:
cmd_ext4.c:110:3: error: format '%lu' expects argument of type
'long unsigned int', but argument 4 has type 'int' [-Werror=format]
Signed-off-by: Simon Glass
---
common/cmd_ext4.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --gi
On Tue, Sep 18, 2012 at 12:05:28PM -0600, Stephen Warren wrote:
> From: Stephen Warren
>
> DMA buffer cache invalidation requires that buffers have cache-aligned
> buffer locations and sizes. Use memalign() and ALLOC_CACHE_ALIGN_BUFFER()
> to ensure this.
>
> On Tegra at least, without this fix
From: Stephen Warren
DMA buffer cache invalidation requires that buffers have cache-aligned
buffer locations and sizes. Use memalign() and ALLOC_CACHE_ALIGN_BUFFER()
to ensure this.
On Tegra at least, without this fix, the following fail commands fail in
u-boot-master/ext4, but succeeded at the
Dear Jorgen Lundman,
In message <4fbb2f6f.5000...@lundman.net> you wrote:
>
> Alas, I know from experience that Microsoft's C compiler does not
> initialise global variables (to make it faster one assumes) which has led
> to hours of debugging.
That would be a violation of existing C standards
Dear Jorgen Lundman,
In message <4fbb0bbe.6050...@lundman.net> you wrote:
> > These patches will likely not get reviewed and definitely will not get
> > merged unless that are posted to the mailing list
>
> Ok, is it better if I use "git format-patch" and send them on the list?
Please read the d
Hi Jorgen,
On Tue, May 22, 2012 at 4:17 PM, Jorgen Lundman wrote:
>
>
>> Uninitialized global and static variables reside in .bss and are set
>> to zero during relocation. Initialised globals and static variables go
>> into .data
>
>
> Alas, I know from experience that Microsoft's C compiler does
Uninitialized global and static variables reside in .bss and are set
to zero during relocation. Initialised globals and static variables go
into .data
Alas, I know from experience that Microsoft's C compiler does not
initialise global variables (to make it faster one assumes) which has led
Hi Jorgen,
On Tue, May 22, 2012 at 3:55 PM, Jorgen Lundman wrote:
>> Yes, that is exactly what you should do.
>>
>> But before you post them, make sure you run them through checkpatch.pl
>> first and resolve/explain any errors or warnings
>
>
> Wow, ohhweee this will take a little while.
>
> How
On Tue, May 22, 2012 at 02:55:57PM +0900, Jorgen Lundman wrote:
>
> ERROR: do not initialise globals to 0 or NULL
> #596: FILE: fs/zfs/zfs.c:33:
> +block_dev_desc_t *zfs_dev_desc = NULL;
>
> That strikes me as dangerous. One lets you fail gracefully (Sorry, X
> has not been initialised) and the o
Yes, that is exactly what you should do.
But before you post them, make sure you run them through checkpatch.pl
first and resolve/explain any errors or warnings
Wow, ohhweee this will take a little while.
How set in stone is the output of checkpatch.pl ? Specifically;
ERROR: do not initialise
Hi Jorgen,
On Tue, May 22, 2012 at 1:45 PM, Jorgen Lundman wrote:
>> These patches will likely not get reviewed and definitely will not get
>> merged unless that are posted to the mailing list
>
>
> Ok, is it better if I use "git format-patch" and send them on the list?
Yes, that is exactly what
These patches will likely not get reviewed and definitely will not get
merged unless that are posted to the mailing list
Ok, is it better if I use "git format-patch" and send them on the list?
There is a new limit of 2TB with 512 byte blocks. To go beyond that would
require "disk_partition_
Hi Jorgen
On Tue, May 22, 2012 at 1:31 PM, Jorgen Lundman wrote:
>
> Slowly getting the hang of github and u-boot. I took a fork of u-boot
> 20120520, and merged in the EXT4 patched.
>
> In addition to Samsung's work;
>
> * Fix minor string ext2->ext4
> * 'unsigned' sectors for volumes over 1TB
Slowly getting the hang of github and u-boot. I took a fork of u-boot
20120520, and merged in the EXT4 patched.
In addition to Samsung's work;
* Fix minor string ext2->ext4
* 'unsigned' sectors for volumes over 1TB
* changed to fit with current u-boot compile env
https://github.com/lundma
38 matches
Mail list logo
