Hi Zixun, On lun., mars 24, 2025 at 18:33, Zixun LI <ad...@hifiphile.com> wrote:
> On Mon, Mar 24, 2025 at 6:21 PM Mattijs Korpershoek > <mkorpersh...@baylibre.com> wrote: >> I've tried to reproduce this on master (2025.04-rc4-g244e61fbb7f5) and I >> don't reproduce this with the VIM3 board using >> khadas-vim3_android_ab_defconfig: >> >> I'll try to understand why it's behaving differently between the >> sam9x60-curiosity and the vim3. > > Thank you for your test, I think it's because VIM3 is a large SoC with > plenty of RAM > (SYS_MALLOC_LEN=0x08000000) while SAM9X60 is much smaller > (SYS_MALLOC_LEN=0x81000). You are right, I've applied the following diff: diff --git a/configs/khadas-vim3_android_ab_defconfig b/configs/khadas-vim3_android_ab_defconfig index a078c5d363ae..c8d1cc69f1fb 100644 --- a/configs/khadas-vim3_android_ab_defconfig +++ b/configs/khadas-vim3_android_ab_defconfig @@ -3,7 +3,7 @@ CONFIG_SYS_BOARD="vim3" CONFIG_SYS_CONFIG_NAME="khadas-vim3_android" CONFIG_ARCH_MESON=y CONFIG_TEXT_BASE=0x01000000 -CONFIG_SYS_MALLOC_LEN=0x08000000 +CONFIG_SYS_MALLOC_LEN=0x81000 CONFIG_NR_DRAM_BANKS=1 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000 And with this, I can reproduce the issue you have reported: U-Boot 2025.04-rc4-g0eeeeabb7cb1 (Mar 24 2025 - 18:37:26 +0100) khadas-vim3 Model: Khadas VIM3 SoC: Amlogic Meson G12B (A311D) Revision 29:b (10:2) DRAM: 2 GiB (effective 3.8 GiB) Core: 407 devices, 36 uclasses, devicetree: separate MMC: mmc@ffe03000: 0, mmc@ffe05000: 1, mmc@ffe07000: 2 Loading Environment from MMC... MMC Device -1 not found *** Warning - No MMC card found, using default environment In: usbkbd,serial Out: vidconsole,serial Err: vidconsole,serial Net: eth0: ethernet@ff3f0000 Hit any key to stop autoboot: 0 => ums 0 mmc 2 UMS: LUN 0, dev mmc 2, hwpart 0, sector 0x0, count 0x3a3e000 |crq->brequest:0x0 CTRL+C - Operation aborted => ums 0 mmc 2 UMS: LUN 0, dev mmc 2, hwpart 0, sector 0x0, count 0x3a3e000 "Synchronous Abort" handler, esr 0x96000004, far 0xfffffffff2ea40f0 elr: 000000000102ddf4 lr : 000000000105c828 (reloc) elr: 00000000f2f34df4 lr : 00000000f2f63828 x0 : 0000000100000000 x1 : 0000000100000000 x2 : 0000000000000000 x3 : fffffffff2ea40e0 x4 : 00000000f2fca1b8 x5 : 00000000f2ea40e0 x6 : 00000000f2fca1c8 x7 : 00000000f2ee6780 x8 : 000000000000003f x9 : 0000000000000004 x10: 0000000000000058 x11: 00000000000058c4 x12: 0000000000000000 x13: 00000000f2e62800 x14: 00000000f4ec0040 x15: 0000000000000000 x16: 00000000f2f63684 x17: 0000000000c0c0c0 x18: 00000000f2e75e00 x19: 00000000f2ea4010 x20: 00000000fffffff4 x21: 00000000f2e9d500 x22: 00000000f2ea40f0 x23: 00000000f2ea4050 x24: 00000000f2f62ebc x25: 00000000f2fd0000 x26: 00000000f2ea1cd0 x27: 0000000000000000 x28: 0000000000000000 x29: 00000000f2e62290 Code: d00004a6 910720c6 cb000063 8b000021 (f9400860) Resetting CPU ... resetting ... > > Each time when ums is called 2*FSG_BUFLEN, 256kB buffer is allocated > and it seems not > freed as fsg_common_release() is not called. > > Zixun