[PATCH] crypto: crc32: use uint32_t instead of ulong

2023-08-25 Thread Ahmad Fatoum
Using ulong just wastes space on 64-bit platforms, so use fixed size 32-bit integers instead. Signed-off-by: Ahmad Fatoum --- crypto/crc32.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/crypto/crc32.c b/crypto/crc32.c index 998cbc9de297..95cb2212db2b

[PATCH] fixup! fastboot: scale default sparse max_download_size with available memory

2023-08-25 Thread Ahmad Fatoum
mem_malloc_end is the end address, so we need to add one to get the size out. Signed-off-by: Ahmad Fatoum --- Forgot to squash --- include/memory.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/memory.h b/include/memory.h index 73642dd5aaa5..9c2a037610b6 100644 ---

[PATCH] fastboot: scale default sparse max_download_size with available memory

2023-08-25 Thread Ahmad Fatoum
The fastboot host tool chokes when asked to sparse images that are not 4K-aligned: error: write_sparse_skip_chunk: don't care size 4280912 is not a multiple of the block size 4096 This is often not a problem, because disk images tend to be 4K-aligned and are best converted to sparse images

[PATCH] ARM: stm32mp: phycore: register barebox update handlers

2023-08-25 Thread Ahmad Fatoum
We have barebox update handlers for updating barebox on SD (ssbl GPT partition) and on eMMC boot partition (with or without TF-A). Let's put them to use. Signed-off-by: Ahmad Fatoum --- Only build-tested. Waiting for ejo's Tested-by --- arch/arm/boards/phytec-phycore-stm32mp1/board.c | 13

Re: [PATCH 2/2] FIT: do not decompress ramdisks even if asked

2023-08-25 Thread Christian Eggers
On Friday, 25 August 2023, 12:22:46 CEST, Ahmad Fatoum wrote: > Linux will decompress its own ramdisk, so a well-formed ITS would > specify compression = "none", so the bootloader doesn't unpack the > ramdisk and the kernel takes care of it. > > Some older versions of the Yocto

Re: FIT: support for compressed images breaks existing images

2023-08-25 Thread Ahmad Fatoum
Hello Christian, On 25.08.23 11:44, Christian Eggers wrote: > Hi Ahmad, > > On Wednesday, 23 August 2023, 18:32:06 CEST, Ahmad Fatoum wrote: >> I need not tell you though that latest is greatest and all that ;) > > after rebasing my internal branch to v2023.8.0, my system doesn't > boot

[PATCH 2/2] FIT: do not decompress ramdisks even if asked

2023-08-25 Thread Ahmad Fatoum
Linux will decompress its own ramdisk, so a well-formed ITS would specify compression = "none", so the bootloader doesn't unpack the ramdisk and the kernel takes care of it. Some older versions of the Yocto kernel-fitimage.bbclass did populate compression != "none" for ramdisks, so now barebox

[PATCH 1/2] FIT: refactor compression handling into separate function

2023-08-25 Thread Ahmad Fatoum
There are four conditions that need to be true for successful decompression and the follow-up commit will add one more. Thus split off the compression handling to aid readability. No functional change. Signed-off-by: Ahmad Fatoum --- common/image-fit.c | 62

[PATCH] aiodev: port Linux vf610-adc driver

2023-08-25 Thread Christian Eggers
This driver works with the ADC on i.MX6SLX, i.MX6UL and i.MX6ULL. Port the Linux v6.4 driver of the peripheral to make them usable in barebox. Signed-off-by: Christian Eggers --- This port has been heavily inspired by the imx7d_adc driver, ported by Ahmad Fatoum. drivers/aiodev/Kconfig |

FIT: support for compressed images breaks existing images

2023-08-25 Thread Christian Eggers
Hi Ahmad, On Wednesday, 23 August 2023, 18:32:06 CEST, Ahmad Fatoum wrote: > I need not tell you though that latest is greatest and all that ;) after rebasing my internal branch to v2023.8.0, my system doesn't boot anymore: Booting entry '/dev/nand0.root.ubi.kernel0' FIT: Opened FIT image:

Re: [PATCH] mci: sdhci: don't hang indefinitely waiting for DMA completion

2023-08-25 Thread Marco Felsch
On 23-08-24, Ahmad Fatoum wrote: > barebox was observed to hang on an i.MX8MP while reading ext_csd from > a broken eMMC that even bootROM refused to boot from. For PIO, we > already have a maximum wait time of 10s. Do the same for DMA. > > It's unlikely that in that state any further