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 9E65EC433F5 for ; Thu, 24 Mar 2022 03:18:51 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8A10A84042; Thu, 24 Mar 2022 04:18:48 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="PiL4al0B"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 9FFDF84042; Thu, 24 Mar 2022 04:18:46 +0100 (CET) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 651F984031 for ; Thu, 24 Mar 2022 04:18:42 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pf1-x432.google.com with SMTP id u22so2952774pfg.6 for ; Wed, 23 Mar 2022 20:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=1cXOjm3+TJQM3U4hto4K2w//wYJYkHJNlTvqpbEZ0lk=; b=PiL4al0B7zHTJrMdeFDUPp9DIZTFUykEhtZ88pMerNqHANieuCqUFI9aqJEry86j29 biFCeu3iW/4h/OxnfCDLwTaMrX1JjKad3L21rtjQ/IwW8CyQcNGn20APsSwjSt0N6lHq tokE5UvXqiEn4UlodZHd2uUiNp6UjTD9PRzHk218W1kPLAMrTurJ0owjh51FCXGdN59V srknCEgqePZRVCpA090vY2+UbObmsnvcbSUwKsd0JPbJMOZxLyA/2TPSZb6zFQHKQRZR o19h9C2dnKprqGya5NOvmxDPRYyg6uuNm/AqtkZiw6rOocXtx8nKeXHQZzN2BStXVlrh h69Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=1cXOjm3+TJQM3U4hto4K2w//wYJYkHJNlTvqpbEZ0lk=; b=JEp1+CV7K+j+YD5HgWdJfB/NQRwJWxSZkmjsdrVfZuoA1+Vmmy1Y/fOFnoArgr99ur IWnz4FFnJzz3oPJT+142eGMzYpz9YO98omXH9vS8HKDZXPyw4nWMsWNnEUUenJvxpeBI jVV6D0uMkZioj0ZOpRe3x56Hm0O1EwZEGoeCejO2aqmQRi2xWgRHRRXJfo8Ypyv/KUjn gDSqz4Ub9Imblqsb+GHK0yELxPA12532NOfiRSgQfW/GuqSV89waGls3Z8EzC2Dr/35z 27nD7dqdBZ0CscBYA93jlnrOURVdIzq7GngkTSk4j8IuGr4oZUYkXXTxNWyrZaYVgUdC 6hVA== X-Gm-Message-State: AOAM530wapDHg2PjHusyUqQwuUrIt8cqRbQFh2XCh2QyQfQnEXlutfWR fbqPG3OChwK0C/B0fyWF/kbDZw== X-Google-Smtp-Source: ABdhPJy4x8eMBlvZPbIXyDRd4q/NZfrJ+FWd5CGetExYZhwivIj7RiXcSxaJuZnab+EdnEKPBvCvAg== X-Received: by 2002:a63:af4b:0:b0:373:a2a1:bf9a with SMTP id s11-20020a63af4b000000b00373a2a1bf9amr2402170pgo.369.1648091920773; Wed, 23 Mar 2022 20:18:40 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:7d3a:4634:c891:518]) by smtp.gmail.com with ESMTPSA id k12-20020a635a4c000000b0037852b86236sm945931pgm.75.2022.03.23.20.18.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Mar 2022 20:18:40 -0700 (PDT) Date: Thu, 24 Mar 2022 12:18:37 +0900 From: AKASHI Takahiro To: Heinrich Schuchardt Cc: qianfan , u-boot@lists.denx.de Subject: Re: How to debug u-boot data abort Message-ID: <20220324031837.GA13268@laputa> Mail-Followup-To: AKASHI Takahiro , Heinrich Schuchardt , qianfan , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <29c55a46-ec26-8730-179e-07ad195b3c25@gmx.de> 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 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 > 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) > > => > > >