From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DA72DC433EF for ; Thu, 24 Mar 2022 07:39:02 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id A4E2F83A83; Thu, 24 Mar 2022 08:38:59 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=163.com header.i=@163.com header.b="lhhRz8oi"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9CAA384067; Thu, 24 Mar 2022 08:38:57 +0100 (CET) Received: from m12-11.163.com (m12-11.163.com [220.181.12.11]) by phobos.denx.de (Postfix) with ESMTP id EB8D384021 for ; Thu, 24 Mar 2022 08:38:52 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=qianfanguijin@163.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Message-ID:Date:MIME-Version:Subject:From; bh=bQ+X7 xnJ9c0BejL3eIDIeW/gW5YzXrvwz/X1ATumvqU=; b=lhhRz8oiXGDxrRY8pqc2O IJpH9bH9DXkyn16Y9afXHmJ/w95H1BJxCeK0X7+qs4BJpV3n9rBezk7gFO/zRVmq AG4Hn2gs7/fttwhruCSUBVwMdbkJC9eApT4D7vvFwCClWjNlGF68mLZy4MBIMsZ9 uf6A4hxvF3SffJk3urZaXQ= Received: from [192.168.3.109] (unknown [218.201.129.19]) by smtp7 (Coremail) with SMTP id C8CowACnHoP1Hzximor+Dw--.6607S2; Thu, 24 Mar 2022 15:38:29 +0800 (CST) Message-ID: <70164a79-296e-3413-c8e8-bfa8703ecfb3@163.com> Date: Thu, 24 Mar 2022 15:38:23 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: How to debug u-boot data abort Content-Language: en-US To: AKASHI Takahiro , Heinrich Schuchardt , u-boot@lists.denx.de References: <7536b9e1-de7a-a492-6951-485d4eb75df1@163.com> <2fe3a2a4-ec68-b18f-3446-ae6cb4de6d32@163.com> <29c55a46-ec26-8730-179e-07ad195b3c25@gmx.de> <20220324031837.GA13268@laputa> From: qianfan In-Reply-To: <20220324031837.GA13268@laputa> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: C8CowACnHoP1Hzximor+Dw--.6607S2 X-Coremail-Antispam: 1Uf129KBjvJXoW3WF13XryxKF1kWFW8WFyrtFb_yoWxKFyDpF ZrJayfKr4kJryUtw15tr1rW3Wayr4kGF1UWry8G34UCFn09F12qr47t3WjkFyUur48Ar1j qr1UJ3Zxur1jyw7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jbjjgUUUUU= X-Originating-IP: [218.201.129.19] X-CM-SenderInfo: htld0w5dqj3xxmlqqiywtou0bp/1tbiQhbN7VaEBRtgrgAAs2 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean 在 2022/3/24 11:18, AKASHI Takahiro 写道: > On Wed, Mar 23, 2022 at 09:27:08AM +0100, Heinrich Schuchardt wrote: >> On 3/23/22 08:45, qianfan wrote: >>> 在 2022/3/23 10:28, qianfan 写道: >>>> Hi: >>>> >>>> I had a custom AM335X board connected my computer by usbnet. It always >>>> report data abort when 'dhcp': >>>> >>>> Next it the log: >>>> >>>> U-Boot 2022.01-rc1-00183-gfa5b4e2d19-dirty (Feb 25 2022 - 15:45:02 +0800) >>>> >>>> CPU  : AM335X-GP rev 2.1 >>>> Model: WISDOM AM335X CCT >>>> DRAM:  512 MiB >>>> NAND:  256 MiB >>>> MMC:   OMAP SD/MMC: 0 >>>> Loading Environment from NAND... *** Warning - bad CRC, using default >>>> environment >>>> >>>> Net:   Could not get PHY for ethernet@4a100000: addr 0 >>>> eth2: ethernet@4a100000, eth3: usb_ether >>>> Hit any key to stop autoboot:  0 >>>> => setenv autoload no >>>> => dhcp >>>> using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in >>>> MAC de:ad:be:ef:00:01 >>>> HOST MAC de:ad:be:ef:00:00 >>>> RNDIS ready >>>> musb-hdrc: peripheral reset irq lost! >>>> high speed config #2: 2 mA, Ethernet Gadget, using RNDIS >>>> USB RNDIS network up! >>>> BOOTP broadcast 1 >>>> BOOTP broadcast 2 >>>> BOOTP broadcast 3 >>>> DHCP client bound to address 192.168.200.4 (757 ms) >>>> data abort >> This could be an alignment error. >> >>>> pc : [<9fe9b0a2>]          lr : [<9febbc3f>] >>>> reloc pc : [<808130a2>]    lr : [<80833c3f>] >> You can use these addresses together with the u-boot.map file to figure >> out in which function the abort occurs and from where it was called. >> >> Use 'arm-linux-gnueabihf-objdump -S -D' to find the exact code positions. >> >>>> sp : 9de53410  ip : 9de53578     fp : 00000001 >>>> r10: 9de5345c  r9 : 9de67e80     r8 : 9febbae5 >>>> r7 : 9de72c30  r6 : 9feec710     r5 : 0000000d  r4 : 00000018 >>>> r3 : 3fdd8e04  r2 : 00000002     r1 : 9feec728  r0 : 9feec700 >>>> Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32 (T) >>>> Code: f023 0303 60ca 4403 (6091) 685a >> This is how to find the exact instruction causing the problem: >> >> $ echo 'Code: f023 0303 60ca 4403 (6091) 685a' | \ >>> ARCH=arm scripts/decodecode >> Code: f023 0303 60ca 4403 (6091) 685a >> All code >> ======== >> 0: 23 f0 and %eax,%esi >> 2: 03 03 add (%rbx),%eax >> 4: ca 60 03 lret $0x360 >> 7:* 44 91 rex.R xchg %eax,%ecx <-- >> trapping instruction >> 9: 60 (bad) >> a: 5a pop %rdx >> b: 68 .byte 0x68 >> >> Code starting with the faulting instruction >> =========================================== >> 0: 91 xchg %eax,%ecx >> 1: 60 (bad) >> 2: 5a pop %rdx >> 3: 68 .byte 0x68 > The code looks like x86 instructions. > Please don't forget to add "CROSS_COMPILE=..." :) > > Code: f023 0303 60ca 4403 (6091) 685a > All code > ======== > 0: f023 0303 bic.w r3, r3, #3 > 4: 60ca str r2, [r1, #12] > 6: 4403 add r3, r0 > 8:* 6091 str r1, [r2, #8] <-- trapping instruction > a: 685a ldr r2, [r3, #4] > > Code starting with the faulting instruction > =========================================== > 0: 6091 str r1, [r2, #8] > 2: 685a ldr r2, [r3, #4] > > Then, > ${CROSS_COMPILE}objdump --disassemble=malloc -lS ${BUILDDIR}/u-boot | grep -A 10 -B 20 ${PATTERN} > # Here, PATTERN may be the instruction ("6091") or the location ("8081496c" in your case?) > > or similarly > > ${CROSS_COMPILE}gdb --batch -ex "disas/m ${LOC}" ${BUILDDIR}/u-boot | grep -A 10 -B 20 ${LOC} > # Here, LOC is your "reloc pc" (0x80817586) > > gives you some hint about the exact location. > > -Takahiro Akashi Hi: Thanks for your's guide. I know the pc in malloc and lr is env_attr_walk. But can't get the full stack or malloc. I can't understand dlmalloc's logic and it's hard to me to solve this problem. > > >> I hope this helps to figure out, where exactly the problem occurs >> >> Best regards >> >> Heinrich >> >>>> Resetting CPU ... >>>> >>>> resetting ... >>>> >>>> >>>> It's there has any doc about how to debug data abort? Or is the bug is >>>> already fixed? >>>> >>>> Thanks >>>> >>> This bug doesn't fixed on master code. I found v2021.01 is good and >>> v2021.04-rc2 is bad. >>> >>> Also I had tested this on beaglebone black with am335x_evm_defconfig, >>> has the simliar problem. >>> >>> find the first bug commit via 'git bisect': it told me that commit >>> e97eb638de0dc8f6e989e20eaeb0342f103cb917 broke it. But it is very >>> strange due to this commit doesn't touch any dhcp or network code. >>> >>> ➜  u-boot-main git:(e97eb638de) ✗ git bisect bug >>> e97eb638de0dc8f6e989e20eaeb0342f103cb917 is the first bug commit >>> commit e97eb638de0dc8f6e989e20eaeb0342f103cb917 >>> Author: Heinrich Schuchardt >>> Date:   Wed Jan 20 22:21:53 2021 +0100 >>> >>>     fs: fat: consistent error handling for flush_dir() >>> >>>     Provide function description for flush_dir(). >>>     Move all error messages for flush_dir() from the callers to the >>> function. >>>     Move mapping of errors to -EIO to the function. >>>     Always check return value of flush_dir() (Coverity CID 316362). >>> >>>     In fat_unlink() return -EIO if flush_dirty_fat_buffer() fails. >>> >>>     Signed-off-by: Heinrich Schuchardt >>> >>> :040000 040000 2281a449f2d134078d7faa1ee735a367b55aad7e >>> 77d188b1c99181fd71f2167fdeee3434a09db209 M      fs >>> >>> >>> 184aa6504143b452132e28cd3ebecc7b941cdfa1 is the first commit before >>> e97eb638de0dc8f6e989e20eaeb0342f103cb917: >>> >>> * e97eb638de0dc8f6e989e20eaeb0342f103cb917 fs: fat: consistent error >>> handling for flush_dir() >>> *   184aa6504143b452132e28cd3ebecc7b941cdfa1 Merge tag >>> 'u-boot-rockchip-20210121' of >>> https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip >>> |\ >>> | * 9ddc0787bd660214366e386ce689dd78299ac9d0 pci: Add Rockchip dwc based >>> PCIe controller driver >>> >>> I checked 184aa6504143b452132e28cd3ebecc7b941cdfa1 can work fine. >>> >>> U-Boot 2021.01-00688-g184aa65041-dirty (Mar 23 2022 - 15:07:56 +0800) >>> >>> CPU  : AM335X-GP rev 2.1 >>> Model: TI AM335x BeagleBone Black >>> DRAM:  512 MiB >>> WDT:   Started with servicing (60s timeout) >>> NAND:  0 MiB >>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1 >>> Loading Environment from FAT... not set. Validating first >>> E-fuse MAC >>> Net:   eth2: ethernet@4a100000, eth3: usb_ether >>> Hit any key to stop autoboot:  0 >>> => dhcp >>> ethernet@4a100000 Waiting for PHY auto negotiation to complete......... >>> TIMEOUT ! >>> using musb-hdrc, OUT ep1out IN ep1in STATUS ep2in >>> MAC de:ad:be:ef:00:01 >>> HOST MAC de:ad:be:ef:00:00 >>> RNDIS ready >>> musb-hdrc: peripheral reset irq lost! >>> high speed config #2: 2 mA, Ethernet Gadget, using RNDIS >>> USB RNDIS network up! >>> BOOTP broadcast 1 >>> BOOTP broadcast 2 >>> BOOTP broadcast 3 >>> DHCP client bound to address 192.168.200.157 (757 ms) >>> Using usb_ether device >>> TFTP from server 192.168.200.1; our IP address is 192.168.200.157 >>> Filename 'u-boot.img'. >>> Load address: 0x82000000 >>> Loading: ################################################################# >>> ################################################################# >>> ################################################################# >>>          ######################### >>>          2.5 MiB/s >>> done >>> Bytes transferred = 1123888 (112630 hex) >>> => >>>