On Tue, Jul 30, 2024 at 01:10:05PM +0200, Ahmad Fatoum wrote:
> On 30.07.24 10:55, Sascha Hauer wrote:
> > On Tue, Jul 30, 2024 at 09:19:22AM +0200, Ahmad Fatoum wrote:
> >> We mainly implement cdev erase for raw flashes. Many block devices, like
> >> NVMe, SSD or SD/MMC are also flash-based and ex
On 30.07.24 12:05, Sascha Hauer wrote:
> On Tue, Jul 30, 2024 at 09:19:26AM +0200, Ahmad Fatoum wrote:
>> +__be32 *ssr;
>> +int err;
>> +unsigned int au, eo, et, es;
>> +
>> +if (!IS_ENABLED(CONFIG_MCI_ERASE))
>> +return -ENOSYS;
>
> I think we settled on using -EOPNOT
Hello Yann,
On 30.07.24 11:23, Yann Sionneau wrote:
> Hello Ahmad,
Thanks for the review. Can you please trim your replies in longer mails,
so it's easier to find the review?
>
> Le 7/30/24 à 09:19, Ahmad Fatoum a écrit :
>> From: Ahmad Fatoum
>> + while (i < blkcnt) {
>> + sector_t
On 30.07.24 11:06, Sascha Hauer wrote:
> On Tue, Jul 30, 2024 at 09:19:23AM +0200, Ahmad Fatoum wrote:
>> In preparation for adding more boolean flags, turn the current two bools
>> into two bits sharing the same u8-sized member.
>>
>> Signed-off-by: Ahmad Fatoum
>> ---
>> include/mci.h | 4 ++--
On 30.07.24 10:55, Sascha Hauer wrote:
> On Tue, Jul 30, 2024 at 09:19:22AM +0200, Ahmad Fatoum wrote:
>> We mainly implement cdev erase for raw flashes. Many block devices, like
>> NVMe, SSD or SD/MMC are also flash-based and expose a mechanism or
>> multiple to trigger an erase on hardware or fla
Hello Sascha,
On 30.07.24 11:18, Sascha Hauer wrote:
> On Tue, Jul 30, 2024 at 09:19:25AM +0200, Ahmad Fatoum wrote:
>> There's a more specific CONFIG_MCI_WRITE that's so far only used to
>> remove write support for in the Atmel MCI driver. We should use the same
>> symbol also to remove support i
On 30.07.24 11:25, Yann Sionneau wrote:
> Hello Ahmad,
>
> Le 7/30/24 à 09:19, Ahmad Fatoum a écrit :
>> This introduces no functional change, but adds a number of definitions
>> that will come in handy when adding erase support in a later commit.
>>
>> Signed-off-by: Ahmad Fatoum
>> ---
>> inc
On 24-07-30, Ahmad Fatoum wrote:
> Hello Marco,
>
> On 7/4/24 10:15, Marco Felsch wrote:
> > Hi Ahmad,
> >
> > On 24-07-03, Ahmad Fatoum wrote:
> >> Hello Marco,
> >>
> >> On 03.07.24 19:20, Marco Felsch wrote:
> >>> The HAB code needs an special [Unlock] instruction to keep the
> >>> SRK_REVOKE
On Mon, 29 Jul 2024 16:30:06 +0200, Ahmad Fatoum wrote:
> Many SoCs feature multiple instances of the same watchdog IP. For
> example, the i.MX8MP has three watchdogs, which would be called wdog0,
> wdog1, wdog2 in barebox, but they would all have imxwd as restart
> handler name.
>
> To be able
On Tue, 30 Jul 2024 10:34:50 +0200, Ahmad Fatoum wrote:
> We already have three CONSOLE_ACTIVATE options and every one of them has
> drawbacks:
>
> - ACTIVATE_ALL: May write barebox log to external devices like MCUs
> that don't expect it
>
> - ACTIVATE_FIRST: Not applicable for most sy
On Fri, 26 Jul 2024 14:23:36 +0200, Ahmad Fatoum wrote:
> CONFIG_CONSOLE_ACTIVATE_NONE is an unfortunate name. The help text
> explains how consoles are still activated, but omits the main way they
> are activated: The device tree's /chosen/stdout-path property.
>
> Similarly, CONFIG_CONSOLE_ACT
On Tue, Jul 30, 2024 at 09:19:28AM +0200, Ahmad Fatoum wrote:
> mci_card_probe is called for both SD cards and MMC, so reporting that
> an SD Card was successfully added is misleading.
>
> There is an info message that reports whether it's a MMC or SD card
> already, so just remove the SD from thi
On Tue, Jul 30, 2024 at 09:19:27AM +0200, Ahmad Fatoum wrote:
> In barebox, the dirty block cache for a given device is flushed when
> closing all file descriptors to it, a cached block needs to be evicted
> due to pressure or when barebox shuts down.
>
> There are valid uses to do it explicitly h
On Tue, Jul 30, 2024 at 09:19:26AM +0200, Ahmad Fatoum wrote:
> /**
> * Read one or several block(s) of data from the card
> * @param mci MCI instance
> @@ -773,6 +850,49 @@ static int sd_switch(struct mci *mci, unsigned mode,
> unsigned group,
> return mci_send_cmd(mci, &cmd, &data);
>
On Wed, 24 Jul 2024 11:25:52 +0200, Ahmad Fatoum wrote:
> The function dt_struct_advance() is used to advance a pointer to the next
> offset within the structure block, while checking that the result is in
> bounds.
>
> Unfortunately, the function used a signed size argument. This had the
> effe
On Tue, 02 Jul 2024 21:44:27 +0200, Richard Weinberger wrote:
> While zalloc() takes a size_t type, adding 1 to the le32 variable
> will overflow.
> A carefully crafted ext4 filesystem can exhibit an inode size of 0x
> and as consequence zalloc() will do a zero allocation.
>
> Later in t
On Tue, Jul 30, 2024 at 09:16:32AM +0200, Ahmad Fatoum wrote:
> In barebox, the dirty block cache for a given device is flushed when
> closing all file descriptors to it, a cached block needs to be evicted
> due to pressure or when barebox shuts down.
>
> There are valid uses to do it explicitly h
Hello Ahmad,
Le 7/30/24 à 09:19, Ahmad Fatoum a écrit :
This introduces no functional change, but adds a number of definitions
that will come in handy when adding erase support in a later commit.
Signed-off-by: Ahmad Fatoum
---
include/mci.h | 61 +
Hello Ahmad,
Le 7/30/24 à 09:19, Ahmad Fatoum a écrit :
From: Ahmad Fatoum
A common optimization for flashing is to skip gaps between partitions
and only flash actual data. The problem with that is that data from
the previous installation may persist and confuse later software, e.g.
an existin
On Tue, Jul 30, 2024 at 09:19:25AM +0200, Ahmad Fatoum wrote:
> There's a more specific CONFIG_MCI_WRITE that's so far only used to
> remove write support for in the Atmel MCI driver. We should use the same
> symbol also to remove support in the MCI core instead of relying on its
> parent CONFIG_BL
On Tue, Jul 30, 2024 at 09:19:23AM +0200, Ahmad Fatoum wrote:
> In preparation for adding more boolean flags, turn the current two bools
> into two bits sharing the same u8-sized member.
>
> Signed-off-by: Ahmad Fatoum
> ---
> include/mci.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletion
On Tue, Jul 30, 2024 at 09:19:22AM +0200, Ahmad Fatoum wrote:
> We mainly implement cdev erase for raw flashes. Many block devices, like
> NVMe, SSD or SD/MMC are also flash-based and expose a mechanism or
> multiple to trigger an erase on hardware or flash translation layer
> level without an acco
We already have three CONSOLE_ACTIVATE options and every one of them has
drawbacks:
- ACTIVATE_ALL: May write barebox log to external devices like MCUs
that don't expect it
- ACTIVATE_FIRST: Not applicable for most systems that probe from
device tree, where the order of probe is not n
CONFIG_CONSOLE_ACTIVATE_NONE is an unfortunate name. The help text
explains how consoles are still activated, but omits the main way they
are activated: The device tree's /chosen/stdout-path property.
Similarly, CONFIG_CONSOLE_ACTIVATE_(FIRST/NONE) don't talk about the
implications of selecting th
On 7/30/24 10:09, Sascha Hauer wrote:
> On Fri, Jul 26, 2024 at 02:26:22PM +0200, Ahmad Fatoum wrote:
>> We already have three CONSOLE_ACTIVATE options and every one of them has
>> drawbacks:
>>
>> - ACTIVATE_ALL: May write barebox log to external devices like MCUs
>> that don't expect it
On 7/30/24 10:31, Sascha Hauer wrote:
> On Tue, Jul 30, 2024 at 09:19:20AM +0200, Ahmad Fatoum wrote:
>> Many managed flashes provide an erase operation, which need not be used
>> for regular writes, but is provided nonetheless for efficient clearing
>> of large regions of storage to a fixed bit
On Tue, Jul 30, 2024 at 09:19:20AM +0200, Ahmad Fatoum wrote:
> Many managed flashes provide an erase operation, which need not be used
> for regular writes, but is provided nonetheless for efficient clearing
> of large regions of storage to a fixed bit pattern. The erase type allows
> users to spe
Hello Marco,
On 7/4/24 10:15, Marco Felsch wrote:
> Hi Ahmad,
>
> On 24-07-03, Ahmad Fatoum wrote:
>> Hello Marco,
>>
>> On 03.07.24 19:20, Marco Felsch wrote:
>>> The HAB code needs an special [Unlock] instruction to keep the
>>> SRK_REVOKE fuse bank unlocked. This is required if a key needs to
On Wed, 24 Jul 2024 11:09:32 +0200, Ahmad Fatoum wrote:
> ramfs_find_chunk finds the correct chunk and additionally returns via
> argument pointers the offset to use and the remaining length.
>
> While correct, the way the remaining len is calculated can be simplified
> by using the offset previ
On Wed, 24 Jul 2024 11:25:52 +0200, Ahmad Fatoum wrote:
> The function dt_struct_advance() is used to advance a pointer to the next
> offset within the structure block, while checking that the result is in
> bounds.
>
> Unfortunately, the function used a signed size argument. This had the
> effe
On Mon, 22 Jul 2024 19:24:10 +0200, Ahmad Fatoum wrote:
> The function dt_struct_advance() is used to advance a pointer to the next
> offset within the structure block, while checking that the result is in
> bounds.
>
> Unfortunately, the function used a signed size argument. This had the
> effe
On Wed, 24 Jul 2024 11:47:02 +0200, Ahmad Fatoum wrote:
> RSA keys are appended onto rsa_keys with rsa_key_add, so it makes sense
> that rsa_key_free would remove them from the key ring's linked list.
>
> It's possible to have "standalone" RSA keys outside the key ring, but
> those would be glob
On Wed, 24 Jul 2024 11:47:45 +0200, Ahmad Fatoum wrote:
> calloc() should allocate a memory buffer that fits the product of its
> arguments or return NULL if this is not possible.
>
> We violated this so far and a wraparound would result in allocating a
> too small buffer leading to buffer overf
On Wed, 24 Jul 2024 11:47:31 +0200, Ahmad Fatoum wrote:
> All other prints in the file use the DMA address except for this single
> print inside debug_dma_map(). Let's use the DMA address there as well to
> fix the warning about casting a 32-bit pointer to a 64 bit integer and
> to align error me
On Fri, 26 Jul 2024 13:25:56 +0200, Ahmad Fatoum wrote:
> Unlike regular environment variables, device parameters have to be
> explicitly created before they are used:
>
> global.linux.bootargs.memsize="mem=3072M"
> Cannot set parameter global.linux.bootargs.memsize: No such device
>
> The
On Wed, 24 Jul 2024 17:23:27 +0200, Ahmad Fatoum wrote:
> For cache-incoherent DMA, dma_sync_single_for_cpu with DMA_FROM_DEVICE
> invalidates the cache, so no stale lines in the cache hide what the
> hardware had written to RAM.
>
> On the same systems, dma_sync_single_for_device with DMA_FROM_
On Fri, Jul 26, 2024 at 02:26:22PM +0200, Ahmad Fatoum wrote:
> We already have three CONSOLE_ACTIVATE options and every one of them has
> drawbacks:
>
> - ACTIVATE_ALL: May write barebox log to external devices like MCUs
> that don't expect it
>
> - ACTIVATE_FIRST: Not applicable for mos
On Mon, 29 Jul 2024 16:33:47 +0200, Ahmad Fatoum wrote:
> The board code has nothing baseboard-specific: It just registers the
> barebox update handler and activates the environment on the bootsource,
> both of which are applicable to any boards using the same SoM.
>
> Therefore, let's replace t
On Mon, 29 Jul 2024 16:33:46 +0200, Ahmad Fatoum wrote:
> While the eMMC is indeed uSDHC3, the board's device tree aliases shuffle
> around the order, so the eMMC is at mmc0 and the SD is at mmc1.
>
> We thus need to follow suit in the board code as to register the correct
> device with the eMMC
On Mon, 29 Jul 2024 16:32:33 +0200, Ahmad Fatoum wrote:
> The current message only lists the handler name, but to understand why
> the operation failed, it's useful to print also the path of the device
> that wasn't found. Change the info message to list both.
>
>
Applied, thanks!
[1/1] bbu:
On Mon, 29 Jul 2024 15:51:37 +0200, Ahmad Fatoum wrote:
> ARM: cpu: uncompress: fix endmem passed to print_pbl_mem_layout
>
> The function expects the end of memory and not a size as second
> argument.
>
>
Applied, thanks!
[1/1] fixup! ARM: cpuinfo: add option to print early memory map
On Mon, 29 Jul 2024 00:19:29 +0300, Antony Pavlov wrote:
>
Applied, thanks!
[1/1] MIPS: : use generic io accessors
https://git.pengutronix.de/cgit/barebox/commit/?id=4a0b13ce8a61 (link may
not be stable)
Best regards,
--
Sascha Hauer
On Mon, 29 Jul 2024 21:06:53 +0200, Ahmad Fatoum wrote:
> mci_card_probe is called for both SD cards and MMC, so reporting that
> an SD Card was successfully added is misleading.
>
> There is an info message that reports whether it's a MMC or SD card
> already, so just remove the SD from this la
On Mon, 29 Jul 2024 19:22:49 +0200, Ahmad Fatoum wrote:
> The function behaves differently depending on whether priv->ext_reset
> and priv->suspend_in_lpm is set. To make the debugging prints more
> useful add this information into the debug message.
>
>
Applied, thanks!
[1/1] watchdog: imxwd
On Mon, 29 Jul 2024 16:34:39 +0200, Sascha Hauer wrote:
> Fix incompatible pointer warning. the ioctl() op now takes a unsigned
> int as command argument.
>
>
Applied, thanks!
[1/1] optee: ioctl takes unsigned int argument
https://git.pengutronix.de/cgit/barebox/commit/?id=aa650bf29486
To test proper operations of block device operations, add a command that
prints how many sectors were read/written/erased for a device so far.
Signed-off-by: Ahmad Fatoum
---
commands/Kconfig| 11 +
commands/Makefile | 1 +
commands/blkstats.c | 60
This introduces no functional change, but adds a number of definitions
that will come in handy when adding erase support in a later commit.
Signed-off-by: Ahmad Fatoum
---
include/mci.h | 61 ++-
1 file changed, 60 insertions(+), 1 deletion(-)
dif
Many managed flashes provide an erase operation, which need not be used
for regular writes, but is provided nonetheless for efficient clearing
of large regions of storage to a fixed bit pattern. The erase type allows
users to specify _why_ the erase operation is done, so the driver or
the core code
From: Ahmad Fatoum
A common optimization for flashing is to skip gaps between partitions
and only flash actual data. The problem with that is that data from
the previous installation may persist and confuse later software, e.g.
an existing barebox state partition not contained in the image may
su
A common optimization for flashing is to skip gaps between partitions
and only flash actual data. The problem with that is that data from
the previous installation may persist and confuse later software, e.g.
an existing barebox state partition not contained in the image may
survive, when the expec
In preparation for adding more boolean flags, turn the current two bools
into two bits sharing the same u8-sized member.
Signed-off-by: Ahmad Fatoum
---
include/mci.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/mci.h b/include/mci.h
index 773aed896c96..4f1ff9d
mci_card_probe is called for both SD cards and MMC, so reporting that
an SD Card was successfully added is misleading.
There is an info message that reports whether it's a MMC or SD card
already, so just remove the SD from this last debug print.
Signed-off-by: Ahmad Fatoum
---
drivers/mci/mci-c
We have two places where we flush chunks: when explicitly flushing
all buffered blocks and when there are no idle blocks.
A third place will be added soon for the new erasure callback, so
prepare for that by factoring out the helper.
Signed-off-by: Ahmad Fatoum
---
common/block.c | 42 +
There's a more specific CONFIG_MCI_WRITE that's so far only used to
remove write support for in the Atmel MCI driver. We should use the same
symbol also to remove support in the MCI core instead of relying on its
parent CONFIG_BLOCK_WRITE option.
Signed-off-by: Ahmad Fatoum
---
drivers/mci/mci-c
In barebox, the dirty block cache for a given device is flushed when
closing all file descriptors to it, a cached block needs to be evicted
due to pressure or when barebox shuts down.
There are valid uses to do it explicitly however:
- When benchmarking write speed to a block device
- Before
We mainly implement cdev erase for raw flashes. Many block devices, like
NVMe, SSD or SD/MMC are also flash-based and expose a mechanism or
multiple to trigger an erase on hardware or flash translation layer
level without an accompanied write.
To make it possible to use this functionality elsewher
In barebox, the dirty block cache for a given device is flushed when
closing all file descriptors to it, a cached block needs to be evicted
due to pressure or when barebox shuts down.
There are valid uses to do it explicitly however:
- When benchmarking write speed to a block device
- Before
57 matches
Mail list logo
