usb:composite: data abort on second ums launch

[Mattijs Korpershoek]

Hi Zixun,

On lun., mars 24, 2025 at 18:33, Zixun LI <admin at hifiphile.com> wrote:

> On Mon, Mar 24, 2025 at 6:21 PM Mattijs Korpershoek
> <mkorpershoek at 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 at ffe03000: 0, mmc at ffe05000: 1, mmc at 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 at 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