On Mittwoch, 9. Juli 2025 19:05 Sam Protsenko wrote:
> > I think we need to distinguish two cases:
> > 1. The caller explicitly does not want to have an initramfs. e.g. you run
> > "bootm addr1 - addr3".
>
> Yes, so fdt_delprop() lines should be probably moved to appropriate
> users, e.g. image_
On Mittwoch, 9. Juli 2025 00:58 Sam Protsenko wrote:
> fdt_initrd() function (where initrd dts properties are removed) is
> called two times:
>
> 1. First it's called by EFI boot manager (e.g. as a part of U-Boot
> Standard Boot mechanism) when it's installing FDT:
>
> fdt_initrd
> image_
an initrd before us and configuring the addresses
in the live device tree we get handed over.
Especially the setting `auto_initramfs` in config.txt is dangerous.
When enabled (default), the firmware tries to be smart and looks for
initramfs files.
Signed-off-by: Richard Weinberger
---
Hi!
This fo
On Donnerstag, 27. März 2025 17:24 Mauro Salvini wrote:
> could be related tho this [1]?
>
> I sent this patch some years ago but was never accepted in u-boot tree.
> But meta-rpi uses it in u-boot recipe [2].
Uh, good point!
In our initial experiments we have used meta-raspberrypi but now we don
Hi!
We recently started using U-Boot on various Raspberry Pi 5 boards
with different hardware configurations.
While testing, Simon noticed unusual boot failures, such as the kernel
failing to boot with no output or U-Boot reporting:
"ERROR: Did not find a cmdline Flattened Device Tree."
Today, I
Gesendet: Donnerstag, 21. November 2024 23:32:09
> Betreff: [PATCH v2 3/8] test_ut: Add an image size to setup_image()
> Add a parameter to indicate the size of the image to build.
>
> Signed-off-by: Simon Glass
> Signed-off-by: Richard Weinberger
This SoB chain is odd.
I think "Co-developed-by: Richard Weinberger " is more correct.
Same for 7/8.
Thanks,
//richard
- Ursprüngliche Mail -
> Von: "Simon Glass"
> This series rebases and tidies up a series sent by Richard Weinberger
> to use unpriviliged code to build the test images.
>
> Link: https://patchwork.ozlabs.org/project/uboot/list/?series=417786
>
> Chan
- Ursprüngliche Mail -
> Von: "Tom Rini"
> An: "u-boot"
> CC: "Simon Glass" , "Joao Marcos Costa"
> , "Thomas Petazzoni"
> , "Jerome Forissier"
> , "Sughosh Ganu"
> , "Caleb Connolly" ,
> "richard"
> Gesendet: Montag, 7. Oktober 2024 19:15:05
> Betreff: Fwd: New Defects reported by Co
Simon,
Am Sonntag, 18. August 2024, 17:47:01 CEST schrieb Simon Glass:
> In that file, this is the line that builds the tools:
>
> ./tools/buildman/buildman -T0 -o ${UBOOT_TRAVIS_BUILD_DIR}
> -w --board tools-only
>
> and this adds the built scripts/dtc to the path, but you could just
Simon,
Am Sonntag, 18. August 2024, 17:25:37 CEST schrieb Simon Glass:
> > So, can we please have mkimage inside the Docker image?
>
> Sorry about all your trouble. Perhaps we should add a comment about
No need to worry. :)
> specifically what the code is for. Also, once you get all this in, we
Am Freitag, 16. August 2024, 00:14:18 CEST schrieb Tom Rini:
> This brings two new pylint errors:
> test/py/tests/fs_helper.py:47:12: E0704: The raise statement is not inside an
> except clause (misplaced-bare-raise)
This raise was on purpose, I wanted the test to fail when an unsupported
filesy
Heinrich,
Am Freitag, 9. August 2024, 18:13:27 CEST schrieb 'Heinrich Schuchardt' via
upstream:
> Thank you for pointing at the problematic code.
>
> You are calling __builtin_add_overflow(int, int, size_t *).
>
> __builtin_add_overflow() is not defined in the C-standard.
>
> Is there any well
Currently, zalloc() calls uncondtionally memset(),
if the allocation failes, memset() will write to a null pointer.
Fix by using kzalloc().
Signed-off-by: Richard Weinberger
---
fs/ext4/ext4_common.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/ext4_common.h
can overwrite memory.
Avoid the overflow by using the __builtin_add_overflow() helper.
Signed-off-by: Richard Weinberger
---
fs/ext4/ext4_common.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 52152a2295..36999b608f
Both gcc and clang support this for a long time.
Make sure the feature is present.
Signed-off-by: Richard Weinberger
---
include/linux/compiler_types.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 1a3060117f
Mattijs,
Am Dienstag, 6. August 2024, 17:32:58 CEST schrieb Mattijs Korpershoek:
> Hi Richard,
>
> Thank you for the patch.
>
> On ven., août 02, 2024 at 11:33, Richard Weinberger wrote:
>
> > Since no mounting happens anymore, rename the "mnt"
> >
res needs to be large enough to store both strings rem and target,
plus the path separator and the terminator.
Currently the space for the path separator is not accounted, so
the heap is corrupted by one byte.
Signed-off-by: Richard Weinberger
---
fs/squashfs/sqfs.c | 7 +--
1 file changed
The squashfs driver blindly follows symlinks, and calls sqfs_size()
recursively. So an attacker can create a crafted filesystem and with
a deep enough nesting level a stack overflow can be achieved.
Fix by limiting the nesting level to 8.
Signed-off-by: Richard Weinberger
---
Changes since v1
The function can fail and return NULL.
Signed-off-by: Richard Weinberger
Reviewed-by: Miquel Raynal
---
fs/squashfs/sqfs.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 16a07c0622..fa99d514f2 100644
--- a/fs/squashfs/sqfs.c
A carefully crafted squashfs filesystem can exhibit an extremly large
inode size and overflow the calculation in sqfs_inode_size().
As a consequence, the squashfs driver will read from wrong locations.
Fix by using __builtin_add_overflow() to detect the overflow.
Signed-off-by: Richard
() helper.
Signed-off-by: Richard Weinberger
Reviewed-by: Miquel Raynal
---
fs/squashfs/sqfs.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 1430e671a5..16a07c0622 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
Since U-Boot does not support memory overcommit we can
enforce that the allocation size is within the malloc area.
This is a simple and efficient hardening measure to mitigate
further integer overflows in dlmalloc.
Signed-off-by: Richard Weinberger
---
common/dlmalloc.c | 9 ++---
1 file
Make sure that the new break is within mem_malloc_start
and mem_malloc_end before making progress.
ulong new = old + increment; can overflow for extremely large
increment values and memset() can get wrongly called.
Signed-off-by: Richard Weinberger
---
common/dlmalloc.c | 6 +++---
1 file
sbrk() assumes ptrdiff_t is large enough to enlarge/shrink the heap
by LONG_MIN/LONG_MAX.
So, use the long type, also to match the rest of the Linux ecosystem.
Signed-off-by: Richard Weinberger
---
arch/x86/include/asm/posix_types.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
t and ppcboot since ever
and predates the CVS history.
Doug Lea's original dlmalloc implementation also doesn't have it.
Signed-off-by: Richard Weinberger
---
common/dlmalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
i
Like for test_fs, no need to mess with loop mounts.
Signed-off-by: Richard Weinberger
---
test/py/tests/test_ut.py | 93 +++-
1 file changed, 34 insertions(+), 59 deletions(-)
diff --git a/test/py/tests/test_ut.py b/test/py/tests/test_ut.py
index 3cef6c29fa
x27;t care about user IDs
and no device files are needed.
If user IDs start to matter it's still possible to use wrapper
tools like fakeroot in future while filling the fs.
Signed-off-by: Richard Weinberger
---
test/py/tests/fs_helper.py| 11 +-
test/py/tests/test_fs/conftes
Since no mounting happens anymore, rename the "mnt"
directory to "scratch" and the related variables.
Signed-off-by: Richard Weinberger
---
test/py/tests/test_fs/conftest.py | 66 +++
1 file changed, 33 insertions(+), 33 deletions(-)
diff -
Simon,
Am Donnerstag, 1. August 2024, 16:42:14 CEST schrieb Simon Glass:
> > + debug("Copying bootstage from %p to %p\n", gd->bootstage, to);
> > + memcpy(to, gd->bootstage, sizeof(struct bootstage_data));
> > + data = gd->bootstage = to;
>
> should be a separate line (patman/ch
ays
large enough and reading beyond the allocation length of gd->bootstage
caused no problem due to the U-Boot memory layout.
Fix by using the correct size and perform the initial copy directly
in bootstage_relocate() to have the whole relocation process in the
same function.
Signed-off-by: Richar
Simon,
Am Samstag, 13. Juli 2024, 17:13:50 CEST schrieb Simon Glass:
> Can you use 'bootstage' as the commit tag?
Sure.
> > + debug("Copying bootstage from %p to %p\n", gd->bootstage,
> > + gd->new_bootstage);
> > + memcpy(gd->new_bootstage, gd->bootstage, sizeof(struct
Evaluate the filesystem incompat and ro_compat bit fields to judge
whether the filesystem can be read or written.
For the read side only a scary warning is shown so far.
I'd love to abort mounting too, but I fear this will break some setups
where the driver works by chance.
Signed-off-by: Ri
Am Mittwoch, 17. Juli 2024, 10:26:29 CEST schrieb Miquel Raynal:
> > Since U-Boot lacks a common filesystem code, there will be always
> > duplication. I can happily add a common define for the value.
>
> Oh yeah, I meant a define in squashfs' code.
Ah! I thought I did so, but seems like I did th
Hi Miquel,
Am Mittwoch, 17. Juli 2024, 10:06:35 CEST schrieb 'Miquel Raynal' via upstream:
> Hi Richard,
>
> rich...@nod.at wrote on Fri, 12 Jul 2024 10:23:44 +0200:
>
> > The squashfs driver blindly follows symlinks, and calls sqfs_size()
> > recursively. So an attacker can create a crafted fil
Hi!
While inspecting various security aspects of U-Boot I noticed some
issues around dlmalloc and asking for your feedback, especially for the
first issue.
I'm CC'ing Barebox folks since Barebox seems to be based on the same
dlmalloc-implementation as U-Boot does.
1. Integer Overflow While Comput
Am Freitag, 12. Juli 2024, 13:15:56 CEST schrieb 'Heinrich Schuchardt' via
upstream:
> Memalign() is called in many code locations.
>
> If memalign() has a bug, it needs to be fixed in memalign. We should not
> try to work around it in all callers.
Agreed, I did already:
See https://lists.denx.d
Am Freitag, 12. Juli 2024, 13:19:32 CEST schrieb Heinrich Schuchardt:
> > Hm, I see man built-ins in the U-Boot source.
> > Why is this one special?
>
> See the definition of COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW in
> include/linux/compiler-clang.h.
So I can't use __builtin_add_overflow() because
Am Freitag, 12. Juli 2024, 13:10:12 CEST schrieb 'Heinrich Schuchardt' via
upstream:
> On 02.07.24 21:42, Richard Weinberger wrote:
> > While zalloc() takes a size_t type, adding 1 to the le32 variable
> > will overflow.
> > A carefully crafted ext4 filesyst
Am Freitag, 12. Juli 2024, 11:46:08 CEST schrieb 'Heinrich Schuchardt' via
upstream:
> Am 12. Juli 2024 10:24:54 MESZ schrieb Richard Weinberger :
> >Make sure that tm_mday and tm_mon are within the expected
> >range. Upper layers such as rtc_calc_weekday() will use
&
Make sure that tm_mday and tm_mon are within the expected
range. Upper layers such as rtc_calc_weekday() will use
them as lookup keys for arrays and this can cause out of
bounds memory accesses.
Signed-off-by: Richard Weinberger
---
fs/fat/fat.c | 5 +++--
1 file changed, 3 insertions(+), 2
The squashfs driver blindly follows symlinks, and calls sqfs_size()
recursively. So an attacker can create a crafted filesystem and with
a deep enough nesting level a stack overflow can be achieved.
Fix by limiting the nesting level to 8.
Signed-off-by: Richard Weinberger
---
fs/squashfs
The function can fail and return NULL.
Signed-off-by: Richard Weinberger
---
fs/squashfs/sqfs.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 16a07c0622..fa99d514f2 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
A carefully crafted squashfs filesystem can exhibit an extremly large
inode size and overflow the calculation in sqfs_inode_size().
As a consequence, the squashfs driver will read from wrong locations.
Fix by using __builtin_add_overflow() to detect the overflow.
Signed-off-by: Richard
() helper.
Signed-off-by: Richard Weinberger
---
fs/squashfs/sqfs.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
index 1430e671a5..16a07c0622 100644
--- a/fs/squashfs/sqfs.c
+++ b/fs/squashfs/sqfs.c
@@ -422,8 +422,10 @@ static
ays
large enough and reading beyond the allocation length of gd->bootstage
caused no problem due to the U-Boot memory layout.
Fix by using the correct size and perform the initial copy directly
in bootstage_relocate() to have the whole relocation process in the
same function.
Signed-off-by: Richar
Tom,
Am Donnerstag, 11. Juli 2024, 17:45:17 CEST schrieb Tom Rini:
> The problem here is that "zalloc" is inline and so this change causes
> about 1KiB of growth on platforms which enable ext4 and so at least
> mx6sabresd now overflows it's maximum size. Looking harder, I think the
> best solution
CONFIG_SYS_MALLOC_LEN.
Signed-off-by: Richard Weinberger
---
FWIW, I didn't investigate further why memalign() fails for large sizes.
Maybe this is an issue on it's own.
Thanks,
//richard
---
fs/ext4/ext4_common.h | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
can overwrite memory.
Avoid the overflow by using the __builtin_add_overflow() helper.
Signed-off-by: Richard Weinberger
---
fs/ext4/ext4_common.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 2ff0dca249..32364b72fb
Evaluate the filesystem incompat and ro_compat bit fields to judge
whether the filesystem can be read or written.
For the read side only a scary warning is shown so far.
I'd love to abort mounting too, but I fear this will break some setups
where the driver works by chance.
Signed-off-by: Ri
Evaluate the filesystem incompat and ro_compat bit fields to judge
whether the filesystem can be read or written.
For the read side only a scary warning is shown so far.
I'd love to about mounting too, but I fear this will break some setups
where the driver works by chance.
Signed-off-by: Ri
- Ursprüngliche Mail -
> Von: "Tom Rini"
> An: "richard"
> CC: "u-boot" , "Joe Hershberger"
> , "Ramon Fried"
> Gesendet: Donnerstag, 31. August 2023 18:27:03
> Betreff: Re: [PATCH] net: wget: Avoid packet queue over
> Make sure to stay within bounds, as a misbehaving HTTP server
> can trigger a buffer overflow if not properly handled.
>
> Cc: Joe Hershberger
> Cc: Ramon Fried
> Signed-off-by: Richard Weinberger
> ---
> net/wget.c | 10 +-
> 1 file changed, 9 insert
Make sure to stay within bounds, as a misbehaving HTTP server
can trigger a buffer overflow if not properly handled.
Cc: Joe Hershberger
Cc: Ramon Fried
Signed-off-by: Richard Weinberger
---
net/wget.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/wget.c b
1] |= val >> rbits;
> + pos[1] |= val >> (bits_per_block - rbits);
Looks good to me.
Fixes: 9c3736a3de21 ("mtd: nand: Add core infrastructure to deal with
NAND devices")
Reviewed-by: Richard Weinberger
--
Thanks,
//richard
On Sun, May 17, 2020 at 1:28 PM Jupiter wrote:
>
> Sorry for a bit recalcitrant with the issue of calling 'ubi part"
> error -74 -EBADMSG, is it MTD issue or u-boot issue?
>
> I used Linux kernel 4.19 to flash UBIFS volume images ubi.img to
> imx6ull NAND using following command in Linux:
>
> flas
Mark,
Am Donnerstag, 12. Juli 2018, 16:03:43 CEST schrieb Mark Spieth:
> >Mark, can you please file a patch and send it to linux-mtd mailing
> >list?
> >Such a change needs to go through Linux and then to u-boot.
> >But first we need to think about and discuss it in detail.
>
> Will do.
Did you
Marek,
Am Freitag, 13. Juli 2018, 10:53:48 CEST schrieb Marek Vasut:
> On 07/13/2018 10:15 AM, Richard Weinberger wrote:
> > Am Freitag, 13. Juli 2018, 10:00:23 CEST schrieb Marek Vasut:
> >> CCing Richard, btw ubifs in U-Boot is completely broken.
> >
> > BTW: Can
Am Freitag, 13. Juli 2018, 10:00:23 CEST schrieb Marek Vasut:
> CCing Richard, btw ubifs in U-Boot is completely broken.
BTW: Can you please define "completely broken"?
Last week it used to work here. ;)
Thanks,
//richard
___
U-Boot mailing list
U-Boot
Am Freitag, 13. Juli 2018, 10:00:23 CEST schrieb Marek Vasut:
> On 07/13/2018 09:44 AM, Heiko Schocher wrote:
> > Hello Masahiro,
> >
> > Am 13.07.2018 um 06:44 schrieb Masahiro Yamada:
> >> Hi.
> >>
> >>
> >> I was playing around with the ditro-boot on NAND + UBI.
> >>
> >> I was hit by a problem
Mark,
Am Donnerstag, 12. Juli 2018, 07:22:13 CEST schrieb Heiko Schocher:
> Hello Mark,
>
> added Richard Weinberger to cc...
>
> Am 12.07.2018 um 02:28 schrieb Mark Spieth:
> > Hi
> >
> > In the process of investigating a boot failure on one of our devices, t
Patrice,
Am Dienstag, 26. Juni 2018, 15:01:14 CEST schrieb Patrice CHOTARD:
> Following your remark, Christophe and i relaunched our test setup to go
> deeper in the analysis of the issue we saw. Unfortunately we can't
> reproduced it. We have now some doubt.
Ok.
> >
> >> By checking ubifs s
Patrice,
Am Montag, 25. Juni 2018, 13:54:12 CEST schrieb Patrice Chotard:
> Sometimes, at boot time, following issue appears:
> Error reading superblock on volume 'ubi0:boot' errno=-22!
>
> This error is coming from wrong ubi_num and wrong ubi_id in the superblock.
> (ubi_num = -1 and vol_id = -1
Am Montag, 25. Juni 2018, 16:27:45 CEST schrieb Jagan Teki:
> I understand the new MTD dm abstraction in U-Boot is not possible for
> direct syncing from Linux, but we really want the u-boot way of
> handling drivers and trying to copy code from Linux by removing
> __UBOOT__ or any Linux specific m
Am Montag, 25. Juni 2018, 11:09:41 CEST schrieb Boris Brezillon:
> +Richard to comment on the MTD abstraction stuff and how uboot port
> of UBI might be impacted by some changes requested here.
>
> Hi Jagan,
>
> On Mon, 25 Jun 2018 13:59:37 +0530
> Jagan Teki wrote:
>
> >
> > I've looked the c
Am Dienstag, 22. Mai 2018, 12:56:48 CEST schrieb Marek Vasut:
> On 05/10/2018 10:57 PM, Marek Vasut wrote:
> > On 04/27/2018 03:51 PM, Patrice Chotard wrote:
> >> This patch solves assert failed displayed in the console during a boot.
> >> The root cause is that the ubifs_inode is not already alloc
Am Dienstag, 22. Mai 2018, 08:30:45 CEST schrieb Heiko Schocher:
> Hello Richard,
>
> Am 21.05.2018 um 21:31 schrieb Richard Weinberger:
> > Patrice,
> >
> > Am Montag, 21. Mai 2018, 16:07:41 CEST schrieb Richard Weinberger:
> >>> e->p
Otto,
Am Dienstag, 22. Mai 2018, 03:30:04 CEST schrieb Otto Blom:
> Hi Richard !
>
> To summarize the observations from the last few days.
>
> * Linux 4.9 & U-boot 2018 behave the same when attempting to read from
> a ubifs file system
> * Whenever Linux 4.14 writes to a ubifs there is some form
Patrice,
Am Montag, 21. Mai 2018, 16:07:41 CEST schrieb Richard Weinberger:
> > e->pnum = aeb->pnum;
> > e->ec = aeb->ec;
> > ubi->lookuptbl[e->pnum] = e;
> > + ubi->thread_enabled = 1;
>
> This
Patrice,
Am Montag, 21. Mai 2018, 15:38:57 CEST schrieb Patrice CHOTARD:
> Hi Richard, Heiko
>
> Since f82290afc847 ("mtd: ubi: Fix worker handling"),
> when booting from NAND, on a fresh NAND just after being flashed (and
> only in this case), we got the following log:
>
> ubi0: default fastma
Am Samstag, 19. Mai 2018, 01:56:33 CEST schrieb Otto Blom:
> UBIFS error (ubi0:0 pid 0): crypto_comp_decompress: cannot decompress
> 2801 bytes, compressor lzo, error -6
LZO_E_LOOKBEHIND_OVERRUN...
> UBIFS error (ubi0:0 pid 0): ubifs_decompress: cannot decompress 2801
> bytes, compressor lzo, err
Otto,
Am Freitag, 18. Mai 2018, 23:02:17 CEST schrieb Otto Blom:
> Hallo Heiko & Richard !
>
> Turns out the len and out_len do not match, much like you suspected.
> Out_len is 2 bytes short (4094 vs 4096) See log below
>
> UBIFS DBG tnc: search key (5725, data, 124)
> UBIFS DBG tnc: found 1, lv
Otto, Heiko,
Am Freitag, 18. Mai 2018, 10:44:43 CEST schrieb Heiko Schocher:
> Hello Otto,
>
> Am 17.05.2018 um 23:12 schrieb Otto Blom:
> > Hi There !
> >
> > I'm seeing a strange problem with u-boot 2018.1 and Linux 4.14 (Xilinx
> > Petalinux 2018.1).
> > If I write a ubifs image to flash usin
r a full scan?
Booting a kernel without Fastmap support. B-)
> > For Linux I suggest this fix:
> >
> > From 48287459cf8717cffac5aed423937cd7ba4360ab Mon Sep 17 00:00:00 2001
> > From: Richard Weinberger
> > Date: Tue, 16 Jan 2018 14:12:46 +0100
> > Subject:
always update the Fastmap
upon detach.
Martin, can you please explain what corruption you see?
From reading the code I'd assume that you miss volumes but a full scan would
recover everything.
For Linux I suggest this fix:
From 48287459cf8717cffac5aed423937cd7ba4360ab Mon Sep 17 00:00:00 2001
Fro
Hi!
On Thu, Aug 11, 2016 at 4:26 AM, J Mo wrote:
> I tried re-flashing my UBI and tftpbooting my kernel before u-boot could
> ever get a chance to mangle it, and now I get much further, though I'm still
> not able to mount my rootfs for unknown reasons:
>
> [3.772502] ubi0: attaching mtd1
Am 11.08.2016 um 13:49 schrieb Daniel Golle:
> Hi!
>
> On Thu, Aug 11, 2016 at 04:28:47AM -0700, J Mo wrote:
>>
>> I got that good old feeling... like I just jumped onto a bag of flaming poo.
>> Ha ha
>>
>>
>>
>> On 08/11/2016 03:40 AM, Daniel Golle wrote:
>>>
>>> Understandable. However, we also
Am 26.04.2016 um 07:17 schrieb Heiko Schocher:
> Also, as the UBI/UIFS case may show, it is not always a trivial job
> to do such a sync, as concepts in Linux changes ...
While we are at it, how do you QA?
Did you ever port port UBI or MTD tests to u-boot and let them run?
Maybe there are more iss
Am 25.04.2016 um 07:46 schrieb Heiko Schocher:
> Hello Boris,
>
> Am 22.04.2016 um 14:21 schrieb Boris Brezillon:
>> On Fri, 22 Apr 2016 13:53:00 +0200
>> Heiko Schocher wrote:
>>
>>>
An alternative approach would be not executing work
directly while scheduling it but in produce_free_pe
Heiko,
Am 22.04.2016 um 12:20 schrieb Heiko Schocher:
>> Think of places where work is scheduled but the caller blocked
>> the worker because the work has to be done later.
>> Fastmap is one of these use cases but AFAIK it won't matter
>> as no CPU scheduler is involved and will interrupt Fastmap.
Am 21.04.2016 um 14:14 schrieb Boris Brezillon:
No idea, if the correct fix not would be to move this erase_worker
call after the attach phase ended, as Richard suggested, or if this
fix is also valid ...
>>>
>>> I discussed that with Richard, and I think moving the ->free_count
>>>
Am 02.02.2016 um 11:54 schrieb Heiko Schocher:
> Set free_count to zero before walking through ai->erase list
> in wl_init().
>
> As U-Boot has no workqueue/threads, it immediately calls
> erase_worker(), which increase for each erased block
> free_count. Without this patch, free_count gets after
Am 20.10.2015 um 06:00 schrieb Heiko Schocher:
> Hello Richard
>
> Am 19.10.2015 um 23:48 schrieb Richard Weinberger:
>> Am 19.10.2015 um 23:40 schrieb Ezequiel Garcia:
>>> On 19 October 2015 at 17:22, Richard Weinberger wrote:
>>>> Am 19.10.2015 um 15:47
Am 19.10.2015 um 23:40 schrieb Ezequiel Garcia:
> On 19 October 2015 at 17:22, Richard Weinberger wrote:
>> Am 19.10.2015 um 15:47 schrieb Ezequiel Garcia:
>>> After some further investigation, printing the counters as Richard suggested
>>> I found it was a bug on my s
Am 19.10.2015 um 15:47 schrieb Ezequiel Garcia:
> After some further investigation, printing the counters as Richard suggested
> I found it was a bug on my side :-( The Linux partition and the U-Boot
> partition
> had different size (i.e. PEB count) and so Fastmap complained :-(
>
> We trimmed th
Am 17.10.2015 um 20:07 schrieb Ezequiel Garcia:
> However, I'm still seeing the same warning I had before, when my partition
> is attached:
>
> ubi0: default fastmap pool size: 200
> ubi0: default fastmap WL pool size: 100
> ubi0: attaching mtd1
> WARNING in drivers/mtd/ubi/fastmap.c line 846
> ub
Am 08.10.2015 um 16:58 schrieb Hans de Goede:
>> Compiling stops, as it is an "error" ... renaming this var, and error
>> go away ...
>
> I believe that in certain configs free is a #define on u-boot, which is
> likely causing this problem.
Ahhh!
As soon you #define something the symbol is burned
Hi!
Am 08.10.2015 um 14:51 schrieb Heiko Schocher:
> Hello Ezequiel, Richard,
>
> Am 02.10.2015 um 18:27 schrieb Ezequiel Garcia:
>> Hello Heiko,
>>
>> According to Richard Weinberger, UBI fastmap is broken in U-Boot.
>> There are plenty
>> of fixes in Lin
Hi!
Am 03.10.2015 um 06:27 schrieb Heiko Schocher:
>>> According to Richard Weinberger, UBI fastmap is broken in U-Boot.
>>> There are plenty
>>> of fixes in Linux that we should pull in U-Boot to fix it.
>
> Thanks for pointing!
>
>> BTW: it is not
Hi!
Am 02.10.2015 um 18:27 schrieb Ezequiel Garcia:
> Hello Heiko,
>
> According to Richard Weinberger, UBI fastmap is broken in U-Boot.
> There are plenty
> of fixes in Linux that we should pull in U-Boot to fix it.
BTW: it is not broken in terms of you broke it.
It is just
Am 05.07.2014 11:48, schrieb Thomas Gleixner:
> +/**
> + * ubi_calc_fm_size - calculates the fastmap size in bytes for an UBI device.
> + * @ubi: UBI device description object
> + */
> +static size_t ubi_calc_fm_size(struct ubi_scan_info *ubi)
> +{
> + size_t size;
> +
> + size = sizeof(str
Am 25.09.2013 15:39, schrieb Richard Genoud:
> 2013/9/25 Richard Weinberger :
>> Am 25.09.2013 14:13, schrieb Richard Genoud:
>>>> Before we waste time, please ensure that you have all recent UBI fixes
>>>> applied.
>>>> UBI: Fix PEB leak in wear_lev
Am 25.09.2013 14:13, schrieb Richard Genoud:
>> Before we waste time, please ensure that you have all recent UBI fixes
>> applied.
>> UBI: Fix PEB leak in wear_leveling_worker() (Merged into 3.12-rc1, on it's
>> way to -stable)
>> UBI: Fix invalidate_fastmap() (Merged into 3.12-rc1)
>> UBI: Fix r
Hi!
Am 25.09.2013 12:59, schrieb Richard Genoud:
>
> [CC u-boot ML since it may not be a kernel only related bug(s)]
>
> Hi Richard, Artem,
>
> I'm still playing with fastmap and I ran into something.
> It's involving u-boot's "ubi write" command and fastmap.
> What I'm doing is:
> - Flashing a
93 matches
Mail list logo
