On Wed, Jan 03, 2024 at 07:12:20PM +0100, Ahmad Fatoum wrote:
> An EFI stubbed ARM64 kernel can be booted either via EFI or via the
> normal boot protocol. We'll want barebox to be able to behave the same,
> so extend section alignment to enable this.
This description reads as if it would change s
On Wed, Jan 03, 2024 at 07:12:25PM +0100, Ahmad Fatoum wrote:
> EFI loader will need to parse and load PE executables. Add functions to
> facilitate that. The API is inspired by the already existing ELF API.
>
> Signed-off-by: Ahmad Fatoum
> ---
> common/Kconfig | 3 +
> common/Makef
On Wed, Jan 03, 2024 at 07:12:50PM +0100, Ahmad Fatoum wrote:
> We already have a few users that will want to print EFI device paths and
> will gain quite a few more with incoming loader support, so let's allow
> printing them directly with printf with the %pD format specifier.
>
> Signed-off-by:
On Tue, Jan 02, 2024 at 06:00:53PM +0100, Ahmad Fatoum wrote:
> struct regmap::max_register is in units of struct regmap::reg_stride.
> To get the total number or registers, we need to divide by reg_stride
> before adding one, but we ended up adding one before division.
>
> This is wrong at differ
On Wed, Jan 03, 2024 at 11:16:23AM +0100, Ahmad Fatoum wrote:
> blockdevice_unregister only calls devfs_remove on the root cdev and
> leaves the partition cdevs dangling. This doesn't break until the
> block device parent struct device is freed at which time, it will
> iterate over its cdevs to fre
clang warns that cr should be an unsigned long as it's used to
initialize a register argument for the mrs instruction.
Change the type from unsigned int to unsigned long to fix this.
Signed-off-by: Ahmad Fatoum
---
arch/arm/mach-layerscape/ppa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
On Fri, Jan 05, 2024 at 02:10:00PM +0100, Ahmad Fatoum wrote:
> The commit introducing help text for the individual options,
> inadvertently modified the usage string. Revert that single line.
>
> Fixes: 94a2b2b28738 ("rsatoc: support generating standalone keys unreferenced
> by FIT keyring")
> S
The receive buffer needs to be cacheline aligned for cache maintenance
to avoid invalidating unrelated malloc memory. This was so far not the
case due to malloc's minimum alignment of 8-byte (with TLSF), so switch
to dma_alloc instead.
Signed-off-by: Ahmad Fatoum
---
drivers/net/fsl-fman.c | 4 +
The first time a buffer is provided to a device, it needs to be mapped
with dma_map_single, before dma_sync_single_for_* may be called.
>From a cache coherence point of view, dma_map_single and
dma_sync_single_for_device have the same effect, but the former
is necessary, so DMA API debugging can c
There are no architectures left defining their own dma_alloc/dma_free.
Instead, they define DMA_ALIGNMENT and use 's common
implementation.
This will be useful later on, as we can use DMA_ALIGNMENT for sanity
checking with CONFIG_DMA_DEBUG_API. Till then, ensure we get no new
architecture-specific
will take care to define dma_alloc with DMA_ALIGNMENT as
alignment. As 32 is the default and may not be applicable to the used
processor, we define DMA_ALIGNMENT and drop the now duplicate code.
Signed-off-by: Ahmad Fatoum
---
arch/mips/include/asm/dma.h | 9 ++---
1 file changed, 2 inserti
will take care to define dma_alloc with DMA_ALIGNMENT as
alignment. As 32 is the default and we for some reason, use 64 for
sandbox, define DMA_ALIGNMENT and drop the now duplicate code.
Signed-off-by: Ahmad Fatoum
---
arch/sandbox/include/asm/dma.h | 6 +-
1 file changed, 1 insertion(+), 5
will take care to define dma_alloc with DMA_ALIGNMENT as
alignment. As 32 is the default and we for need 64 for kvx,
define DMA_ALIGNMENT and drop the now duplicate code.
Signed-off-by: Ahmad Fatoum
---
arch/kvx/include/asm/dma.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff
Hi Ahmad,
Comments are below.
On Tue, 2 Jan 2024 18:00:55 +0100
Ahmad Fatoum wrote:
> The max_register must be a multiple of the register stride, which is not
> the case for (384 / 4) - 1 == 95. Instead, we should be setting 380, so
> fix the calculation to do this.
>
> Fixes: 094ce0ee7cdf ("
Hello Robin,
On 08.01.24 11:29, Robin van der Gracht wrote:
> Hi Ahmad,
>
> Comments are below.
>
> On Tue, 2 Jan 2024 18:00:55 +0100
> Ahmad Fatoum wrote:
>
>> The max_register must be a multiple of the register stride, which is not
>> the case for (384 / 4) - 1 == 95. Instead, we should be
Hello Ahmad,
On Mon, 8 Jan 2024 11:44:00 +0100
Ahmad Fatoum wrote:
> Hello Robin,
>
> On 08.01.24 11:29, Robin van der Gracht wrote:
> > Hi Ahmad,
> >
> > Comments are below.
> >
> > On Tue, 2 Jan 2024 18:00:55 +0100
> > Ahmad Fatoum wrote:
> >
> >> The max_register must be a multiple of
Hello Ahmad,
On 1/8/24 11:24, Ahmad Fatoum wrote:
will take care to define dma_alloc with DMA_ALIGNMENT as
alignment. As 32 is the default and we for need 64 for kvx,
define DMA_ALIGNMENT and drop the now duplicate code.
Signed-off-by: Ahmad Fatoum
---
arch/kvx/include/asm/dma.h | 6 +-
On Mon, 8 Jan 2024 12:17:09 +0100
Robin van der Gracht wrote:
...
> >
> > barebox@Linux Automation MC-1 board:/ ls -l /dev/stm32-bsec
> > crw---384 /dev/stm32-bsec
>
> Thats more like it. I'll apply the full series and recheck.
This works as expected. Thanks.
Minor note:
A
After a run of test/generate-dummy-fw.sh, following dummy firmware is
generated and is not matched by any .gitignore:
arch/arm/boards/globalscale-mirabox/binary.0
arch/arm/boards/lenovo-ix4-300d/binary.0
arch/arm/boards/marvell-armada-xp-db/binary.0
arch/arm/boards/marvell-armada-xp-gp/bin
Only three of the compatibles listed exist in up-to-date upstream device
trees. As barebox need not worry about backwards compatibility with
older device trees, remove the rest that would never be matched.
Signed-off-by: Ahmad Fatoum
---
drivers/usb/dwc3/dwc3-of-simple.c | 6 --
1 file chang
20 matches
Mail list logo
